Hi Jon,
Jonathan Corbet schrieb:
Sorry if I'm slow...*you* try giving talks in Germany and Japan in the
same week and we'll see how responsive you are...:)
On Sun, 26 Sep 2010 17:50:41 +0200
Florian Tobias Schandinat <FlorianSchandinat@xxxxxx> wrote:
You're right, we may not only change the entry. The device code also needs to be
changed. The situation is like this:
0x2c are essentially two GPIO ports but those can be used to emulate one I2C
port. At the moment it is only used as I2C port with a little hack in the I2C
code. I believe it would be good to change it to always be a GPIO port (as that
is what it really is, at least for all documented IGPs) and emulate I2C on top
of that if needed. Sadly VIAs emulation (using 2 pins) differs from the generic
one in i2c-gpio.c (using 1 pin), so we can't reuse that but the emulation code
shouldn't be much code anyway.
When I first set up the GPIO/I2C code, I tried to configure it "the way
it's always been," in the hope of not breaking anything. I'd always
figured that people would want to change things, which is why the code
is done the way it is. Of course, I never got around to implementing
the configuration-time (or even runtime) selection mechanism. But I
did always figure that OLPC would need a non-standard configuration.
Florian, I'm not sure what you're saying about changing how the ports
are used. All of the ports are essentially the same, regardless of
what they are called; you either have two GPIOs, or you have one for
i2c data, the other for the clock. There are some minor differences in
how the ports are programmed, but it's pretty much insignificant.
Jon, do you claim that 0x26 and 0x31 are essentially the same as the the GPIO ports?
I am no specialist on this but this is how I understand the GPIO pins work:
Each pin has one status, data and output enable bit. As long as output enable is
set (not set to 0) the pin is actively driven high or low depending on what is
in the data bit. Reading the status bit while output enable is set is pretty
senseless as we either read what we write or (on bus collision) the result is
undefined. Reading when output enable is not set works as expected.
In contrast I2C is defined with a bus voltage and we have only the possibility
to drive the pins low or tristated. When tristated we can read the bus (high if
no other/slave devices drives it low).
After having a look at the relevant openchrome code (ViaI2C3):
http://openchrome.org/trac/browser/trunk/src/via_i2c.c
as well as VIAs X-Server (as far as I can decipher it) and assuming that this
code was tested I am confident that our code is broken (for example we never set
output enable back to 0). So I think we should just enable GPIO on that port as
I2C on it looks very broken anyway.
I plan to test whether a correct implementation can be done on top of GPIO.
That's probably just for the get_* functions set the direction to input,
read the bit and return (maybe setting up an open drain as described in gpio.txt
before all this), for set_* functions set the direction to output with
the desired value and return.
The only problem I have is that I probably do not have a way to actually test
whether the end result works, but maybe I'm lucky and suddenly a device will be
detected that currently is not.
Thanks,
Florian Tobias Schandinat
--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
