1 |
3 |
xianfeng |
GPIO Interfaces
|
2 |
|
|
|
3 |
|
|
This provides an overview of GPIO access conventions on Linux.
|
4 |
|
|
|
5 |
|
|
|
6 |
|
|
What is a GPIO?
|
7 |
|
|
===============
|
8 |
|
|
A "General Purpose Input/Output" (GPIO) is a flexible software-controlled
|
9 |
|
|
digital signal. They are provided from many kinds of chip, and are familiar
|
10 |
|
|
to Linux developers working with embedded and custom hardware. Each GPIO
|
11 |
|
|
represents a bit connected to a particular pin, or "ball" on Ball Grid Array
|
12 |
|
|
(BGA) packages. Board schematics show which external hardware connects to
|
13 |
|
|
which GPIOs. Drivers can be written generically, so that board setup code
|
14 |
|
|
passes such pin configuration data to drivers.
|
15 |
|
|
|
16 |
|
|
System-on-Chip (SOC) processors heavily rely on GPIOs. In some cases, every
|
17 |
|
|
non-dedicated pin can be configured as a GPIO; and most chips have at least
|
18 |
|
|
several dozen of them. Programmable logic devices (like FPGAs) can easily
|
19 |
|
|
provide GPIOs; multifunction chips like power managers, and audio codecs
|
20 |
|
|
often have a few such pins to help with pin scarcity on SOCs; and there are
|
21 |
|
|
also "GPIO Expander" chips that connect using the I2C or SPI serial busses.
|
22 |
|
|
Most PC southbridges have a few dozen GPIO-capable pins (with only the BIOS
|
23 |
|
|
firmware knowing how they're used).
|
24 |
|
|
|
25 |
|
|
The exact capabilities of GPIOs vary between systems. Common options:
|
26 |
|
|
|
27 |
|
|
- Output values are writable (high=1, low=0). Some chips also have
|
28 |
|
|
options about how that value is driven, so that for example only one
|
29 |
|
|
value might be driven ... supporting "wire-OR" and similar schemes
|
30 |
|
|
for the other value (notably, "open drain" signaling).
|
31 |
|
|
|
32 |
|
|
- Input values are likewise readable (1, 0). Some chips support readback
|
33 |
|
|
of pins configured as "output", which is very useful in such "wire-OR"
|
34 |
|
|
cases (to support bidirectional signaling). GPIO controllers may have
|
35 |
|
|
input de-glitch logic, sometimes with software controls.
|
36 |
|
|
|
37 |
|
|
- Inputs can often be used as IRQ signals, often edge triggered but
|
38 |
|
|
sometimes level triggered. Such IRQs may be configurable as system
|
39 |
|
|
wakeup events, to wake the system from a low power state.
|
40 |
|
|
|
41 |
|
|
- Usually a GPIO will be configurable as either input or output, as needed
|
42 |
|
|
by different product boards; single direction ones exist too.
|
43 |
|
|
|
44 |
|
|
- Most GPIOs can be accessed while holding spinlocks, but those accessed
|
45 |
|
|
through a serial bus normally can't. Some systems support both types.
|
46 |
|
|
|
47 |
|
|
On a given board each GPIO is used for one specific purpose like monitoring
|
48 |
|
|
MMC/SD card insertion/removal, detecting card writeprotect status, driving
|
49 |
|
|
a LED, configuring a transceiver, bitbanging a serial bus, poking a hardware
|
50 |
|
|
watchdog, sensing a switch, and so on.
|
51 |
|
|
|
52 |
|
|
|
53 |
|
|
GPIO conventions
|
54 |
|
|
================
|
55 |
|
|
Note that this is called a "convention" because you don't need to do it this
|
56 |
|
|
way, and it's no crime if you don't. There **are** cases where portability
|
57 |
|
|
is not the main issue; GPIOs are often used for the kind of board-specific
|
58 |
|
|
glue logic that may even change between board revisions, and can't ever be
|
59 |
|
|
used on a board that's wired differently. Only least-common-denominator
|
60 |
|
|
functionality can be very portable. Other features are platform-specific,
|
61 |
|
|
and that can be critical for glue logic.
|
62 |
|
|
|
63 |
|
|
Plus, this doesn't define an implementation framework, just an interface.
|
64 |
|
|
One platform might implement it as simple inline functions accessing chip
|
65 |
|
|
registers; another might implement it by delegating through abstractions
|
66 |
|
|
used for several very different kinds of GPIO controller.
|
67 |
|
|
|
68 |
|
|
That said, if the convention is supported on their platform, drivers should
|
69 |
|
|
use it when possible. Platforms should declare GENERIC_GPIO support in
|
70 |
|
|
Kconfig (boolean true), which multi-platform drivers can depend on when
|
71 |
|
|
using the include file:
|
72 |
|
|
|
73 |
|
|
#include
|
74 |
|
|
|
75 |
|
|
If you stick to this convention then it'll be easier for other developers to
|
76 |
|
|
see what your code is doing, and help maintain it.
|
77 |
|
|
|
78 |
|
|
Note that these operations include I/O barriers on platforms which need to
|
79 |
|
|
use them; drivers don't need to add them explicitly.
|
80 |
|
|
|
81 |
|
|
|
82 |
|
|
Identifying GPIOs
|
83 |
|
|
-----------------
|
84 |
|
|
GPIOs are identified by unsigned integers in the range 0..MAX_INT. That
|
85 |
|
|
reserves "negative" numbers for other purposes like marking signals as
|
86 |
|
|
"not available on this board", or indicating faults. Code that doesn't
|
87 |
|
|
touch the underlying hardware treats these integers as opaque cookies.
|
88 |
|
|
|
89 |
|
|
Platforms define how they use those integers, and usually #define symbols
|
90 |
|
|
for the GPIO lines so that board-specific setup code directly corresponds
|
91 |
|
|
to the relevant schematics. In contrast, drivers should only use GPIO
|
92 |
|
|
numbers passed to them from that setup code, using platform_data to hold
|
93 |
|
|
board-specific pin configuration data (along with other board specific
|
94 |
|
|
data they need). That avoids portability problems.
|
95 |
|
|
|
96 |
|
|
So for example one platform uses numbers 32-159 for GPIOs; while another
|
97 |
|
|
uses numbers 0..63 with one set of GPIO controllers, 64-79 with another
|
98 |
|
|
type of GPIO controller, and on one particular board 80-95 with an FPGA.
|
99 |
|
|
The numbers need not be contiguous; either of those platforms could also
|
100 |
|
|
use numbers 2000-2063 to identify GPIOs in a bank of I2C GPIO expanders.
|
101 |
|
|
|
102 |
|
|
Whether a platform supports multiple GPIO controllers is currently a
|
103 |
|
|
platform-specific implementation issue.
|
104 |
|
|
|
105 |
|
|
|
106 |
|
|
Using GPIOs
|
107 |
|
|
-----------
|
108 |
|
|
One of the first things to do with a GPIO, often in board setup code when
|
109 |
|
|
setting up a platform_device using the GPIO, is mark its direction:
|
110 |
|
|
|
111 |
|
|
/* set as input or output, returning 0 or negative errno */
|
112 |
|
|
int gpio_direction_input(unsigned gpio);
|
113 |
|
|
int gpio_direction_output(unsigned gpio, int value);
|
114 |
|
|
|
115 |
|
|
The return value is zero for success, else a negative errno. It should
|
116 |
|
|
be checked, since the get/set calls don't have error returns and since
|
117 |
|
|
misconfiguration is possible. You should normally issue these calls from
|
118 |
|
|
a task context. However, for spinlock-safe GPIOs it's OK to use them
|
119 |
|
|
before tasking is enabled, as part of early board setup.
|
120 |
|
|
|
121 |
|
|
For output GPIOs, the value provided becomes the initial output value.
|
122 |
|
|
This helps avoid signal glitching during system startup.
|
123 |
|
|
|
124 |
|
|
Setting the direction can fail if the GPIO number is invalid, or when
|
125 |
|
|
that particular GPIO can't be used in that mode. It's generally a bad
|
126 |
|
|
idea to rely on boot firmware to have set the direction correctly, since
|
127 |
|
|
it probably wasn't validated to do more than boot Linux. (Similarly,
|
128 |
|
|
that board setup code probably needs to multiplex that pin as a GPIO,
|
129 |
|
|
and configure pullups/pulldowns appropriately.)
|
130 |
|
|
|
131 |
|
|
|
132 |
|
|
Spinlock-Safe GPIO access
|
133 |
|
|
-------------------------
|
134 |
|
|
Most GPIO controllers can be accessed with memory read/write instructions.
|
135 |
|
|
That doesn't need to sleep, and can safely be done from inside IRQ handlers.
|
136 |
|
|
|
137 |
|
|
Use these calls to access such GPIOs:
|
138 |
|
|
|
139 |
|
|
/* GPIO INPUT: return zero or nonzero */
|
140 |
|
|
int gpio_get_value(unsigned gpio);
|
141 |
|
|
|
142 |
|
|
/* GPIO OUTPUT */
|
143 |
|
|
void gpio_set_value(unsigned gpio, int value);
|
144 |
|
|
|
145 |
|
|
The values are boolean, zero for low, nonzero for high. When reading the
|
146 |
|
|
value of an output pin, the value returned should be what's seen on the
|
147 |
|
|
pin ... that won't always match the specified output value, because of
|
148 |
|
|
issues including wire-OR and output latencies.
|
149 |
|
|
|
150 |
|
|
The get/set calls have no error returns because "invalid GPIO" should have
|
151 |
|
|
been reported earlier from gpio_direction_*(). However, note that not all
|
152 |
|
|
platforms can read the value of output pins; those that can't should always
|
153 |
|
|
return zero. Also, using these calls for GPIOs that can't safely be accessed
|
154 |
|
|
without sleeping (see below) is an error.
|
155 |
|
|
|
156 |
|
|
Platform-specific implementations are encouraged to optimize the two
|
157 |
|
|
calls to access the GPIO value in cases where the GPIO number (and for
|
158 |
|
|
output, value) are constant. It's normal for them to need only a couple
|
159 |
|
|
of instructions in such cases (reading or writing a hardware register),
|
160 |
|
|
and not to need spinlocks. Such optimized calls can make bitbanging
|
161 |
|
|
applications a lot more efficient (in both space and time) than spending
|
162 |
|
|
dozens of instructions on subroutine calls.
|
163 |
|
|
|
164 |
|
|
|
165 |
|
|
GPIO access that may sleep
|
166 |
|
|
--------------------------
|
167 |
|
|
Some GPIO controllers must be accessed using message based busses like I2C
|
168 |
|
|
or SPI. Commands to read or write those GPIO values require waiting to
|
169 |
|
|
get to the head of a queue to transmit a command and get its response.
|
170 |
|
|
This requires sleeping, which can't be done from inside IRQ handlers.
|
171 |
|
|
|
172 |
|
|
Platforms that support this type of GPIO distinguish them from other GPIOs
|
173 |
|
|
by returning nonzero from this call:
|
174 |
|
|
|
175 |
|
|
int gpio_cansleep(unsigned gpio);
|
176 |
|
|
|
177 |
|
|
To access such GPIOs, a different set of accessors is defined:
|
178 |
|
|
|
179 |
|
|
/* GPIO INPUT: return zero or nonzero, might sleep */
|
180 |
|
|
int gpio_get_value_cansleep(unsigned gpio);
|
181 |
|
|
|
182 |
|
|
/* GPIO OUTPUT, might sleep */
|
183 |
|
|
void gpio_set_value_cansleep(unsigned gpio, int value);
|
184 |
|
|
|
185 |
|
|
Other than the fact that these calls might sleep, and will not be ignored
|
186 |
|
|
for GPIOs that can't be accessed from IRQ handlers, these calls act the
|
187 |
|
|
same as the spinlock-safe calls.
|
188 |
|
|
|
189 |
|
|
|
190 |
|
|
Claiming and Releasing GPIOs (OPTIONAL)
|
191 |
|
|
---------------------------------------
|
192 |
|
|
To help catch system configuration errors, two calls are defined.
|
193 |
|
|
However, many platforms don't currently support this mechanism.
|
194 |
|
|
|
195 |
|
|
/* request GPIO, returning 0 or negative errno.
|
196 |
|
|
* non-null labels may be useful for diagnostics.
|
197 |
|
|
*/
|
198 |
|
|
int gpio_request(unsigned gpio, const char *label);
|
199 |
|
|
|
200 |
|
|
/* release previously-claimed GPIO */
|
201 |
|
|
void gpio_free(unsigned gpio);
|
202 |
|
|
|
203 |
|
|
Passing invalid GPIO numbers to gpio_request() will fail, as will requesting
|
204 |
|
|
GPIOs that have already been claimed with that call. The return value of
|
205 |
|
|
gpio_request() must be checked. You should normally issue these calls from
|
206 |
|
|
a task context. However, for spinlock-safe GPIOs it's OK to request GPIOs
|
207 |
|
|
before tasking is enabled, as part of early board setup.
|
208 |
|
|
|
209 |
|
|
These calls serve two basic purposes. One is marking the signals which
|
210 |
|
|
are actually in use as GPIOs, for better diagnostics; systems may have
|
211 |
|
|
several hundred potential GPIOs, but often only a dozen are used on any
|
212 |
|
|
given board. Another is to catch conflicts between drivers, reporting
|
213 |
|
|
errors when drivers wrongly think they have exclusive use of that signal.
|
214 |
|
|
|
215 |
|
|
These two calls are optional because not not all current Linux platforms
|
216 |
|
|
offer such functionality in their GPIO support; a valid implementation
|
217 |
|
|
could return success for all gpio_request() calls. Unlike the other calls,
|
218 |
|
|
the state they represent doesn't normally match anything from a hardware
|
219 |
|
|
register; it's just a software bitmap which clearly is not necessary for
|
220 |
|
|
correct operation of hardware or (bug free) drivers.
|
221 |
|
|
|
222 |
|
|
Note that requesting a GPIO does NOT cause it to be configured in any
|
223 |
|
|
way; it just marks that GPIO as in use. Separate code must handle any
|
224 |
|
|
pin setup (e.g. controlling which pin the GPIO uses, pullup/pulldown).
|
225 |
|
|
|
226 |
|
|
|
227 |
|
|
GPIOs mapped to IRQs
|
228 |
|
|
--------------------
|
229 |
|
|
GPIO numbers are unsigned integers; so are IRQ numbers. These make up
|
230 |
|
|
two logically distinct namespaces (GPIO 0 need not use IRQ 0). You can
|
231 |
|
|
map between them using calls like:
|
232 |
|
|
|
233 |
|
|
/* map GPIO numbers to IRQ numbers */
|
234 |
|
|
int gpio_to_irq(unsigned gpio);
|
235 |
|
|
|
236 |
|
|
/* map IRQ numbers to GPIO numbers */
|
237 |
|
|
int irq_to_gpio(unsigned irq);
|
238 |
|
|
|
239 |
|
|
Those return either the corresponding number in the other namespace, or
|
240 |
|
|
else a negative errno code if the mapping can't be done. (For example,
|
241 |
|
|
some GPIOs can't used as IRQs.) It is an unchecked error to use a GPIO
|
242 |
|
|
number that wasn't set up as an input using gpio_direction_input(), or
|
243 |
|
|
to use an IRQ number that didn't originally come from gpio_to_irq().
|
244 |
|
|
|
245 |
|
|
These two mapping calls are expected to cost on the order of a single
|
246 |
|
|
addition or subtraction. They're not allowed to sleep.
|
247 |
|
|
|
248 |
|
|
Non-error values returned from gpio_to_irq() can be passed to request_irq()
|
249 |
|
|
or free_irq(). They will often be stored into IRQ resources for platform
|
250 |
|
|
devices, by the board-specific initialization code. Note that IRQ trigger
|
251 |
|
|
options are part of the IRQ interface, e.g. IRQF_TRIGGER_FALLING, as are
|
252 |
|
|
system wakeup capabilities.
|
253 |
|
|
|
254 |
|
|
Non-error values returned from irq_to_gpio() would most commonly be used
|
255 |
|
|
with gpio_get_value(), for example to initialize or update driver state
|
256 |
|
|
when the IRQ is edge-triggered.
|
257 |
|
|
|
258 |
|
|
|
259 |
|
|
Emulating Open Drain Signals
|
260 |
|
|
----------------------------
|
261 |
|
|
Sometimes shared signals need to use "open drain" signaling, where only the
|
262 |
|
|
low signal level is actually driven. (That term applies to CMOS transistors;
|
263 |
|
|
"open collector" is used for TTL.) A pullup resistor causes the high signal
|
264 |
|
|
level. This is sometimes called a "wire-AND"; or more practically, from the
|
265 |
|
|
negative logic (low=true) perspective this is a "wire-OR".
|
266 |
|
|
|
267 |
|
|
One common example of an open drain signal is a shared active-low IRQ line.
|
268 |
|
|
Also, bidirectional data bus signals sometimes use open drain signals.
|
269 |
|
|
|
270 |
|
|
Some GPIO controllers directly support open drain outputs; many don't. When
|
271 |
|
|
you need open drain signaling but your hardware doesn't directly support it,
|
272 |
|
|
there's a common idiom you can use to emulate it with any GPIO pin that can
|
273 |
|
|
be used as either an input or an output:
|
274 |
|
|
|
275 |
|
|
LOW: gpio_direction_output(gpio, 0) ... this drives the signal
|
276 |
|
|
and overrides the pullup.
|
277 |
|
|
|
278 |
|
|
HIGH: gpio_direction_input(gpio) ... this turns off the output,
|
279 |
|
|
so the pullup (or some other device) controls the signal.
|
280 |
|
|
|
281 |
|
|
If you are "driving" the signal high but gpio_get_value(gpio) reports a low
|
282 |
|
|
value (after the appropriate rise time passes), you know some other component
|
283 |
|
|
is driving the shared signal low. That's not necessarily an error. As one
|
284 |
|
|
common example, that's how I2C clocks are stretched: a slave that needs a
|
285 |
|
|
slower clock delays the rising edge of SCK, and the I2C master adjusts its
|
286 |
|
|
signaling rate accordingly.
|
287 |
|
|
|
288 |
|
|
|
289 |
|
|
What do these conventions omit?
|
290 |
|
|
===============================
|
291 |
|
|
One of the biggest things these conventions omit is pin multiplexing, since
|
292 |
|
|
this is highly chip-specific and nonportable. One platform might not need
|
293 |
|
|
explicit multiplexing; another might have just two options for use of any
|
294 |
|
|
given pin; another might have eight options per pin; another might be able
|
295 |
|
|
to route a given GPIO to any one of several pins. (Yes, those examples all
|
296 |
|
|
come from systems that run Linux today.)
|
297 |
|
|
|
298 |
|
|
Related to multiplexing is configuration and enabling of the pullups or
|
299 |
|
|
pulldowns integrated on some platforms. Not all platforms support them,
|
300 |
|
|
or support them in the same way; and any given board might use external
|
301 |
|
|
pullups (or pulldowns) so that the on-chip ones should not be used.
|
302 |
|
|
|
303 |
|
|
There are other system-specific mechanisms that are not specified here,
|
304 |
|
|
like the aforementioned options for input de-glitching and wire-OR output.
|
305 |
|
|
Hardware may support reading or writing GPIOs in gangs, but that's usually
|
306 |
|
|
configuration dependent: for GPIOs sharing the same bank. (GPIOs are
|
307 |
|
|
commonly grouped in banks of 16 or 32, with a given SOC having several such
|
308 |
|
|
banks.) Some systems can trigger IRQs from output GPIOs. Code relying on
|
309 |
|
|
such mechanisms will necessarily be nonportable.
|
310 |
|
|
|
311 |
|
|
Dynamic definition of GPIOs is not currently supported; for example, as
|
312 |
|
|
a side effect of configuring an add-on board with some GPIO expanders.
|
313 |
|
|
|
314 |
|
|
These calls are purely for kernel space, but a userspace API could be built
|
315 |
|
|
on top of it.
|