From: khc@pm.waw.pl (Krzysztof Halasa)
To: Andy Green <andy@warmcat.com>
Cc: Jean Delvare <khali@linux-fr.org>,
linux-kernel@vger.kernel.org, lm-sensors@lm-sensors.org
Subject: [lm-sensors] Black box flight recorder for Linux
Date: Wed, 07 Jun 2006 23:52:42 +0000 [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 at 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
WARNING: multiple messages have this Message-ID (diff)
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
next prev parent reply other threads:[~2006-06-07 23:52 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-08 11:12 Black box flight recorder for Linux 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 ` [lm-sensors] " Krzysztof Halasa
2006-04-19 10:47 ` Krzysztof Halasa
2006-04-19 20:20 ` [lm-sensors] " Rudolf Marek
2006-04-19 20:20 ` Rudolf Marek
2006-04-19 23:02 ` Krzysztof Halasa
2006-04-19 23:02 ` Krzysztof Halasa
2006-06-06 17:42 ` Krzysztof Halasa
2006-06-06 17:42 ` Krzysztof Halasa
2006-06-07 8:03 ` [lm-sensors] " Jean Delvare
2006-06-07 8:03 ` Jean Delvare
2006-06-07 10:18 ` [lm-sensors] " Andy Green
2006-06-07 10:18 ` Andy Green
2006-06-07 23:52 ` Krzysztof Halasa [this message]
2006-06-07 23:52 ` Krzysztof Halasa
2006-04-11 11:21 ` Jan Engelhardt
2006-04-10 3:06 ` Russell Senior
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.