mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Krzysztof Halasa <khc@pm.waw.pl>
To: Andy Green <andy@warmcat.com>
Cc: Jean Delvare <khali@linux-fr.org>,
	linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org
Subject: Re: Black box flight recorder for Linux
Date: Thu, 08 Jun 2006 01:52:42 +0200	[thread overview]
Message-ID: <m3irncr0ad.fsf@defiant.localdomain> (raw)
In-Reply-To: <4486A7FC.2090904@warmcat.com> (Andy Green's message of "Wed, 07 Jun 2006 11:18:36 +0100")

Hi,

Andy Green <andy@warmcat.com> writes:

> A whole other way forward is to consider to replace the EEPROM from
> the original proposal (which does provide its own advantages such as
> simplicity, I accept) with something else that ends up on another
> PC. In this concept some logic presents a fake I2C peripheral to the
> DDC interface at an I2C address of our choosing.  This logic acts as a
> bidirectional "UART" type of thing, allowing transfer of data in both
> directions between the Linux box being debugged and another PC.

Right. I think one could use something like ATMEL 89F2051 (20-pin 8051
non-SMD clones with flash and hardware UART) or something similar.

Client I2C is difficult in Linux (using general purpose I/O port) but
with a dedicated CPU it's not a problem (not sure about 400 kHz access).

> http://warmcat.com/milksop/filtror.html

Well, that's a bit more complicated. I'm not going to try that on
an experimental PCB :-)

> However this would be much simpler, not even needing RAM.  It can hook
> to the second PC by the same I2C method, parallel printer port, RS232
> or USB depending on the level of complexity of the design.
>
> I guess the link will feel quite like a 9600 or 19200 baud serial port
> in terms of throughput.

Depends on I2C. With something like 400 kHz it should be faster,
probably like 115200.

> Maybe this effort is considered too esoteric, but it seems to me to be
> a reason to keep the DDC access drivers standalone, the
> hardware-specific framebuffer drivers can call through to them and we
> can use them in a clean way.  I realize this is a bit of a late
> objection and that there was not previously much point to keeping them
> as separate things in the world.

Actually we have:
- the Xserver "hardware access" issue
- DRI/DRM
- now the I2C bus driver
- frame buffer

To avoid conflicts we really need them managed by a single driver.
Probably the GGI (KGI?) should be revisited?

Long-term project, unfortunatelly, but I think we'll have to do that
eventually.

The I2C, graphics subsystem and DRI/DRM could be sub-modules, with
the master module only keeping track of hardware access, mode
settings etc.
-- 
Krzysztof Halasa

  reply	other threads:[~2006-06-07 23:52 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-04-08 11:12 James Courtier-Dutton
2006-04-08 13:41 ` Andi Kleen
2006-04-08 19:42   ` Guennadi Liakhovetski
2006-04-08 16:40 ` Lee Revell
2006-04-08 17:30 ` Matti Aarnio
2006-04-09 19:23 ` Krzysztof Halasa
2006-04-10 12:01   ` Andy Green
2006-04-10 19:24     ` Krzysztof Halasa
2006-04-19 10:47       ` Krzysztof Halasa
2006-04-19 20:20         ` [lm-sensors] " Rudolf Marek
2006-04-19 23:02           ` Krzysztof Halasa
2006-06-06 17:42     ` Krzysztof Halasa
2006-06-07  8:03       ` Jean Delvare
2006-06-07 10:18         ` Andy Green
2006-06-07 23:52           ` Krzysztof Halasa [this message]
2006-04-11 11:21   ` Jan Engelhardt
2006-04-10  3:06 ` Russell Senior
     [not found] <5ZjEd-4ym-37@gated-at.bofh.it>
     [not found] ` <5ZlZk-7VF-13@gated-at.bofh.it>
2006-04-08 14:05   ` Robert Hancock
2006-04-08  7:17     ` Andi Kleen
2006-04-08 16:28       ` James Courtier-Dutton
2006-04-08 22:28         ` JustFillBug
2006-04-09 17:09           ` James Courtier-Dutton
2006-04-10 18:53             ` Ville Herva
2006-04-09 15:04         ` Andi Kleen
2006-04-09 19:25           ` Eric W. Biederman
2006-04-10 12:18       ` linux-os (Dick Johnson)
2006-04-10 19:44         ` Krzysztof Halasa
2006-04-10 20:07           ` linux-os (Dick Johnson)
2006-04-08 22:45 linux

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3irncr0ad.fsf@defiant.localdomain \
    --to=khc@pm.waw.pl \
    --cc=andy@warmcat.com \
    --cc=khali@linux-fr.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lm-sensors@lm-sensors.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®