Eric Lee / smarc-ti-linux-kernel

Download as
Browse Code ยป

Commit f5de611148c8370cbe50796ca5567ca624b99686

Authored by David Brownell
Committed by Linus Torvalds
1 parent 7de970e11f
Exists in master and in 20 other branches dlt-processor-sdk-linux-03.00.00.04, newt-ti-linux-3.12.y, processor-sdk-linux-01.00.00, processor-sdk-linux-02.00.01, smarc-ti-linux-3.12.10, smarc-ti-linux-3.12.y, smarc-ti-linux-3.14.y, smarc-ti-linux-3.15.y, smarc-ti-lsk-linux-4.1.y, smarct3x-processor-sdk-04.01.00.06, smarct3x-processor-sdk-linux-02.00.01, smarct3x-processor-sdk-linux-03.00.00.04, smarct4x-800-processor-sdk-linux-02.00.01, smarct4x-processor-sdk-04.01.00.06, smarct4x-processor-sdk-linux-02.00.01, smarct4x-processor-sdk-linux-03.00.00.04, ti-linux-3.12.y, ti-linux-3.14.y, ti-linux-3.15.y, ti-lsk-linux-4.1.y

[PATCH] GPIO core documentation 

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>

Showing 1 changed file with 10 additions and 7 deletions Side-by-side Diff

Documentation/gpio.txt
Diff comments   View file @ f5de611
... ... @@ -78,7 +78,8 @@
78 78 -----------------
79 79 GPIOs are identified by unsigned integers in the range 0..MAX_INT. That
80 80 reserves "negative" numbers for other purposes like marking signals as
81   -"not available on this board", or indicating faults.
  81 +"not available on this board", or indicating faults. Code that doesn't
  82 +touch the underlying hardware treats these integers as opaque cookies.
82 83  
83 84 Platforms define how they use those integers, and usually #define symbols
84 85 for the GPIO lines so that board-specific setup code directly corresponds
85 86  
... ... @@ -139,10 +140,10 @@
139 140 The get/set calls have no error returns because "invalid GPIO" should have
140 141 been reported earlier in gpio_set_direction(). However, note that not all
141 142 platforms can read the value of output pins; those that can't should always
142   -return zero. Also, these calls will be ignored for GPIOs that can't safely
143   -be accessed wihtout sleeping (see below).
  143 +return zero. Also, using these calls for GPIOs that can't safely be accessed
  144 +without sleeping (see below) is an error.
144 145  
145   -Platform-specific implementations are encouraged to optimise the two
  146 +Platform-specific implementations are encouraged to optimize the two
146 147 calls to access the GPIO value in cases where the GPIO number (and for
147 148 output, value) are constant. It's normal for them to need only a couple
148 149 of instructions in such cases (reading or writing a hardware register),
... ... @@ -239,7 +240,8 @@
239 240 system wakeup capabilities.
240 241  
241 242 Non-error values returned from irq_to_gpio() would most commonly be used
242   -with gpio_get_value().
  243 +with gpio_get_value(), for example to initialize or update driver state
  244 +when the IRQ is edge-triggered.
243 245  
244 246  
245 247  
246 248  
... ... @@ -260,9 +262,10 @@
260 262 There are other system-specific mechanisms that are not specified here,
261 263 like the aforementioned options for input de-glitching and wire-OR output.
262 264 Hardware may support reading or writing GPIOs in gangs, but that's usually
263   -configuration dependednt: for GPIOs sharing the same bank. (GPIOs are
  265 +configuration dependent: for GPIOs sharing the same bank. (GPIOs are
264 266 commonly grouped in banks of 16 or 32, with a given SOC having several such
265   -banks.) Code relying on such mechanisms will necessarily be nonportable.
  267 +banks.) Some systems can trigger IRQs from output GPIOs. Code relying on
  268 +such mechanisms will necessarily be nonportable.
266 269  
267 270 Dynamic definition of GPIOs is not currently supported; for example, as
268 271 a side effect of configuring an add-on board with some GPIO expanders.