GPIO support for HTC Dream
Jamie Lokier
jamie at shareable.org
Tue Dec 15 15:48:03 EST 2009
H Hartley Sweeten wrote:
> From Pavel's implementation it appears that the gpio's are organized
> as a number of 8-bit ports. Each of these ports only have one 8-bit
> register. Writing a '1' to a bit in the register makes the
> associated pin a high-level output. Writing a '0' makes the pin a
> low-level output or an input pin. Reading the port at this point
> will return the actual 'input' level of the pin.
>
> The hardware seems a bit strange and I just wanted to verify that this is
> correct. If it is, this would explain the need to keep the 'shadow' contents
> of the port in order to set the 'direction' of a pin.
It sounds similar to the PCF8575 (except polarity is reversed), which
is an I2C-driven GPIO chip with "quasi-bidirectional I/O pins", so not
completely weird.
The PCF8575 is more or less an open collector output - it drives a pin
low when 0 is written, and lets it be pulled high by an external
resistor when 1 is written, and reads return the current measured
level. So by writing 1, you can use the pin as an input, or you can
use it as an output by using a pull-up resistor.
However, to complicate matters, when transitioning from 0 to 1, the
PCF8575 briefly drives the output high, to ensure that a pulled up
output has a rapid transition.
Because of that, you *must not* write 0->1 transitions to the PCF8575
for a GPIO that is driven low by something else, unless you want a
current spike. So you can't use it as an open collector bus, for
example, and it's important to maintain a shadow variable so that you
don't write back bit values read from the chip.
(I don't know why they don't just use separate enable and value bits
like everything else, but there you go).
Perhaps the Dream's GPIOs are similar, but with opposite polarity.
If it also has the same transition driving spike, writing a 1->0
transition would be bad for the hardware making the shadow variable
even more important.
> I was also wondering if the initial 'shadow' value needs to be written to the
> port at init in order to correctly establish the output value for specific
> pins.
If it's like the PCF8575, after hard reset the bits will all be
configured in the input state, and rely on external pull-downs to set
bootup values.
-- Jamie
More information about the linux-arm-kernel
mailing list