linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jamie@shareable.org (Jamie Lokier)
To: linux-arm-kernel@lists.infradead.org
Subject: GPIO support for HTC Dream
Date: Tue, 15 Dec 2009 20:48:03 +0000	[thread overview]
Message-ID: <20091215204803.GA26319@shareable.org> (raw)
In-Reply-To: <BD79186B4FD85F4B8E60E381CAEE19090200E9C6@mi8nycmail19.Mi8.com>

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

  parent reply	other threads:[~2009-12-15 20:48 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-08 10:28 GPIO support for HTC Dream Pavel Machek
2009-12-08 20:22 ` Ryan Mallon
2009-12-08 21:37   ` Pavel Machek
2009-12-08 21:53     ` Ryan Mallon
2009-12-10 16:26       ` Pavel Machek
2009-12-08 21:56     ` Arve Hjønnevåg
2009-12-09 11:32       ` Pavel Machek
2009-12-08 21:46   ` Pavel Machek
2009-12-08 22:03     ` Joe Perches
2009-12-09 11:46       ` Pavel Machek
2009-12-08 22:10     ` Ryan Mallon
2009-12-09 23:40       ` Ryan Mallon
2009-12-10 17:24         ` Pavel Machek
2009-12-10 17:41           ` Mark Brown
2009-12-10 19:49           ` Ryan Mallon
2009-12-10 23:14             ` H Hartley Sweeten
2009-12-11 19:58               ` Pavel Machek
2009-12-11 22:10               ` Pavel Machek
2009-12-11 22:40                 ` Arve Hjønnevåg
2009-12-11 23:12                   ` H Hartley Sweeten
2009-12-16 22:53                     ` Pavel Machek
2009-12-16 23:03                       ` Daniel Walker
2009-12-11 23:04                 ` H Hartley Sweeten
2009-12-14  6:45                   ` Pavel Machek
2009-12-14 17:54                     ` Daniel Walker
2009-12-14 18:12                       ` H Hartley Sweeten
2009-12-15  6:40                         ` Arve Hjønnevåg
2009-12-15 19:12                           ` Pavel Machek
2009-12-15 20:07                             ` Daniel Walker
2009-12-15 21:21                               ` Pavel Machek
2009-12-15 20:48                         ` Jamie Lokier [this message]
2009-12-15 21:07                           ` Brian Swetland
2009-12-14 19:00                     ` H Hartley Sweeten
2009-12-15 19:47                       ` Pavel Machek
2009-12-15 20:15                         ` H Hartley Sweeten
2009-12-15 20:47                           ` Pavel Machek
2009-12-15 21:16                           ` [patch] " Pavel Machek
2009-12-25 17:10                             ` Pavel Machek
2009-12-25 23:49                               ` Daniel Walker
2009-12-26  8:51                                 ` Pavel Machek
2009-12-15 20:24                         ` Ryan Mallon
2009-12-15 20:44                           ` Pavel Machek
2009-12-15  6:48                     ` Arve Hjønnevåg
2009-12-11 23:28                 ` Russell King - ARM Linux
2009-12-11 23:50                   ` H Hartley Sweeten
2009-12-14  6:24                   ` Pavel Machek
2009-12-10 16:57       ` Pavel Machek
2009-12-08 22:45 ` Russell King - ARM Linux
2009-12-09  0:39   ` Arve Hjønnevåg
2009-12-09 11:37     ` Pavel Machek
2009-12-09 11:42       ` Arve Hjønnevåg
2009-12-10 16:27         ` Pavel Machek
2009-12-09 16:18       ` Daniel Walker
2009-12-13 21:29         ` Pavel Machek
2009-12-13 21:38           ` Brian Swetland
2009-12-15 19:09             ` Pavel Machek
2009-12-14 17:40           ` Daniel Walker
2009-12-15 19:10             ` Pavel Machek
2009-12-09 11:41   ` Pavel Machek

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=20091215204803.GA26319@shareable.org \
    --to=jamie@shareable.org \
    --cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).