Techwizz/kernel-fxtec-pro1x
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

[PATCH] GPIO core documentation

Browse source 
Small updates to the GPIO documentation, addressing feedback and
fixing a few spelling errors.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
David Brownell 2007-02-16 01:27:14 -08:00 committed by Linus Torvalds
parent 7de970e11f
commit f5de611148
1 changed files with 10 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

17
Documentation/gpio.txt
View file

@ -78,7 +78,8 @@ Identifying GPIOs
-----------------
GPIOs are identified by unsigned integers in the range 0..MAX_INT. That
reserves "negative" numbers for other purposes like marking signals as
"not available on this board", or indicating faults.
"not available on this board", or indicating faults. Code that doesn't
touch the underlying hardware treats these integers as opaque cookies.
Platforms define how they use those integers, and usually #define symbols
for the GPIO lines so that board-specific setup code directly corresponds
@ -139,10 +140,10 @@ issues including wire-OR and output latencies.
The get/set calls have no error returns because "invalid GPIO" should have
been reported earlier in gpio_set_direction(). However, note that not all
platforms can read the value of output pins; those that can't should always
return zero. Also, these calls will be ignored for GPIOs that can't safely
be accessed wihtout sleeping (see below).
return zero. Also, using these calls for GPIOs that can't safely be accessed
without sleeping (see below) is an error.
Platform-specific implementations are encouraged to optimise the two
Platform-specific implementations are encouraged to optimize the two
calls to access the GPIO value in cases where the GPIO number (and for
output, value) are constant. It's normal for them to need only a couple
of instructions in such cases (reading or writing a hardware register),
@ -239,7 +240,8 @@ options are part of the IRQ interface, e.g. IRQF_TRIGGER_FALLING, as are
system wakeup capabilities.
Non-error values returned from irq_to_gpio() would most commonly be used
with gpio_get_value().
with gpio_get_value(), for example to initialize or update driver state
when the IRQ is edge-triggered.
@ -260,9 +262,10 @@ pullups (or pulldowns) so that the on-chip ones should not be used.
There are other system-specific mechanisms that are not specified here,
like the aforementioned options for input de-glitching and wire-OR output.
Hardware may support reading or writing GPIOs in gangs, but that's usually
configuration dependednt: for GPIOs sharing the same bank. (GPIOs are
configuration dependent: for GPIOs sharing the same bank. (GPIOs are
commonly grouped in banks of 16 or 32, with a given SOC having several such
banks.) Code relying on such mechanisms will necessarily be nonportable.
banks.) Some systems can trigger IRQs from output GPIOs. Code relying on
such mechanisms will necessarily be nonportable.
Dynamic definition of GPIOs is not currently supported; for example, as
a side effect of configuring an add-on board with some GPIO expanders.