xref: /linux/Documentation/driver-api/gpio/driver.rst (revision bab2c80e5a6c855657482eac9e97f5f3eedb509a)
1================================
2GPIO Descriptor Driver Interface
3================================
4
5This document serves as a guide for GPIO chip drivers writers. Note that it
6describes the new descriptor-based interface. For a description of the
7deprecated integer-based GPIO interface please refer to gpio-legacy.txt.
8
9Each GPIO controller driver needs to include the following header, which defines
10the structures used to define a GPIO driver:
11
12	#include <linux/gpio/driver.h>
13
14
15Internal Representation of GPIOs
16================================
17
18Inside a GPIO driver, individual GPIOs are identified by their hardware number,
19which is a unique number between 0 and n, n being the number of GPIOs managed by
20the chip. This number is purely internal: the hardware number of a particular
21GPIO descriptor is never made visible outside of the driver.
22
23On top of this internal number, each GPIO also need to have a global number in
24the integer GPIO namespace so that it can be used with the legacy GPIO
25interface. Each chip must thus have a "base" number (which can be automatically
26assigned), and for each GPIO the global number will be (base + hardware number).
27Although the integer representation is considered deprecated, it still has many
28users and thus needs to be maintained.
29
30So for example one platform could use numbers 32-159 for GPIOs, with a
31controller defining 128 GPIOs at a "base" of 32 ; while another platform uses
32numbers 0..63 with one set of GPIO controllers, 64-79 with another type of GPIO
33controller, and on one particular board 80-95 with an FPGA. The numbers need not
34be contiguous; either of those platforms could also use numbers 2000-2063 to
35identify GPIOs in a bank of I2C GPIO expanders.
36
37
38Controller Drivers: gpio_chip
39=============================
40
41In the gpiolib framework each GPIO controller is packaged as a "struct
42gpio_chip" (see linux/gpio/driver.h for its complete definition) with members
43common to each controller of that type:
44
45 - methods to establish GPIO line direction
46 - methods used to access GPIO line values
47 - method to set electrical configuration for a given GPIO line
48 - method to return the IRQ number associated to a given GPIO line
49 - flag saying whether calls to its methods may sleep
50 - optional line names array to identify lines
51 - optional debugfs dump method (showing extra state like pullup config)
52 - optional base number (will be automatically assigned if omitted)
53 - optional label for diagnostics and GPIO chip mapping using platform data
54
55The code implementing a gpio_chip should support multiple instances of the
56controller, possibly using the driver model. That code will configure each
57gpio_chip and issue ``gpiochip_add[_data]()`` or ``devm_gpiochip_add_data()``.
58Removing a GPIO controller should be rare; use ``[devm_]gpiochip_remove()``
59when it is unavoidable.
60
61Often a gpio_chip is part of an instance-specific structure with states not
62exposed by the GPIO interfaces, such as addressing, power management, and more.
63Chips such as audio codecs will have complex non-GPIO states.
64
65Any debugfs dump method should normally ignore signals which haven't been
66requested as GPIOs. They can use gpiochip_is_requested(), which returns either
67NULL or the label associated with that GPIO when it was requested.
68
69RT_FULL: the GPIO driver should not use spinlock_t or any sleepable APIs
70(like PM runtime) in its gpio_chip implementation (.get/.set and direction
71control callbacks) if it is expected to call GPIO APIs from atomic context
72on -RT (inside hard IRQ handlers and similar contexts). Normally this should
73not be required.
74
75
76GPIO electrical configuration
77-----------------------------
78
79GPIOs can be configured for several electrical modes of operation by using the
80.set_config() callback. Currently this API supports setting debouncing and
81single-ended modes (open drain/open source). These settings are described
82below.
83
84The .set_config() callback uses the same enumerators and configuration
85semantics as the generic pin control drivers. This is not a coincidence: it is
86possible to assign the .set_config() to the function gpiochip_generic_config()
87which will result in pinctrl_gpio_set_config() being called and eventually
88ending up in the pin control back-end "behind" the GPIO controller, usually
89closer to the actual pins. This way the pin controller can manage the below
90listed GPIO configurations.
91
92If a pin controller back-end is used, the GPIO controller or hardware
93description needs to provide "GPIO ranges" mapping the GPIO line offsets to pin
94numbers on the pin controller so they can properly cross-reference each other.
95
96
97GPIOs with debounce support
98---------------------------
99
100Debouncing is a configuration set to a pin indicating that it is connected to
101a mechanical switch or button, or similar that may bounce. Bouncing means the
102line is pulled high/low quickly at very short intervals for mechanical
103reasons. This can result in the value being unstable or irqs fireing repeatedly
104unless the line is debounced.
105
106Debouncing in practice involves setting up a timer when something happens on
107the line, wait a little while and then sample the line again, so see if it
108still has the same value (low or high). This could also be repeated by a clever
109state machine, waiting for a line to become stable. In either case, it sets
110a certain number of milliseconds for debouncing, or just "on/off" if that time
111is not configurable.
112
113
114GPIOs with open drain/source support
115------------------------------------
116
117Open drain (CMOS) or open collector (TTL) means the line is not actively driven
118high: instead you provide the drain/collector as output, so when the transistor
119is not open, it will present a high-impedance (tristate) to the external rail::
120
121
122   CMOS CONFIGURATION      TTL CONFIGURATION
123
124            ||--- out              +--- out
125     in ----||                   |/
126            ||--+         in ----|
127                |                |\
128               GND	           GND
129
130This configuration is normally used as a way to achieve one of two things:
131
132- Level-shifting: to reach a logical level higher than that of the silicon
133  where the output resides.
134
135- inverse wire-OR on an I/O line, for example a GPIO line, making it possible
136  for any driving stage on the line to drive it low even if any other output
137  to the same line is simultaneously driving it high. A special case of this
138  is driving the SCL and SCA lines of an I2C bus, which is by definition a
139  wire-OR bus.
140
141Both usecases require that the line be equipped with a pull-up resistor. This
142resistor will make the line tend to high level unless one of the transistors on
143the rail actively pulls it down.
144
145The level on the line will go as high as the VDD on the pull-up resistor, which
146may be higher than the level supported by the transistor, achieving a
147level-shift to the higher VDD.
148
149Integrated electronics often have an output driver stage in the form of a CMOS
150"totem-pole" with one N-MOS and one P-MOS transistor where one of them drives
151the line high and one of them drives the line low. This is called a push-pull
152output. The "totem-pole" looks like so::
153
154                     VDD
155                      |
156            OD    ||--+
157         +--/ ---o||     P-MOS-FET
158         |        ||--+
159    IN --+            +----- out
160         |        ||--+
161         +--/ ----||     N-MOS-FET
162            OS    ||--+
163                      |
164                     GND
165
166The desired output signal (e.g. coming directly from some GPIO output register)
167arrives at IN. The switches named "OD" and "OS" are normally closed, creating
168a push-pull circuit.
169
170Consider the little "switches" named "OD" and "OS" that enable/disable the
171P-MOS or N-MOS transistor right after the split of the input. As you can see,
172either transistor will go totally numb if this switch is open. The totem-pole
173is then halved and give high impedance instead of actively driving the line
174high or low respectively. That is usually how software-controlled open
175drain/source works.
176
177Some GPIO hardware come in open drain / open source configuration. Some are
178hard-wired lines that will only support open drain or open source no matter
179what: there is only one transistor there. Some are software-configurable:
180by flipping a bit in a register the output can be configured as open drain
181or open source, in practice by flicking open the switches labeled "OD" and "OS"
182in the drawing above.
183
184By disabling the P-MOS transistor, the output can be driven between GND and
185high impedance (open drain), and by disabling the N-MOS transistor, the output
186can be driven between VDD and high impedance (open source). In the first case,
187a pull-up resistor is needed on the outgoing rail to complete the circuit, and
188in the second case, a pull-down resistor is needed on the rail.
189
190Hardware that supports open drain or open source or both, can implement a
191special callback in the gpio_chip: .set_config() that takes a generic
192pinconf packed value telling whether to configure the line as open drain,
193open source or push-pull. This will happen in response to the
194GPIO_OPEN_DRAIN or GPIO_OPEN_SOURCE flag set in the machine file, or coming
195from other hardware descriptions.
196
197If this state can not be configured in hardware, i.e. if the GPIO hardware does
198not support open drain/open source in hardware, the GPIO library will instead
199use a trick: when a line is set as output, if the line is flagged as open
200drain, and the IN output value is low, it will be driven low as usual. But
201if the IN output value is set to high, it will instead *NOT* be driven high,
202instead it will be switched to input, as input mode is high impedance, thus
203achieveing an "open drain emulation" of sorts: electrically the behaviour will
204be identical, with the exception of possible hardware glitches when switching
205the mode of the line.
206
207For open source configuration the same principle is used, just that instead
208of actively driving the line low, it is set to input.
209
210
211GPIO drivers providing IRQs
212---------------------------
213It is custom that GPIO drivers (GPIO chips) are also providing interrupts,
214most often cascaded off a parent interrupt controller, and in some special
215cases the GPIO logic is melded with a SoC's primary interrupt controller.
216
217The IRQ portions of the GPIO block are implemented using an irqchip, using
218the header <linux/irq.h>. So basically such a driver is utilizing two sub-
219systems simultaneously: gpio and irq.
220
221RT_FULL: a realtime compliant GPIO driver should not use spinlock_t or any
222sleepable APIs (like PM runtime) as part of its irq_chip implementation.
223
224* spinlock_t should be replaced with raw_spinlock_t [1].
225* If sleepable APIs have to be used, these can be done from the .irq_bus_lock()
226  and .irq_bus_unlock() callbacks, as these are the only slowpath callbacks
227  on an irqchip. Create the callbacks if needed [2].
228
229GPIO irqchips usually fall in one of two categories:
230
231* CHAINED GPIO irqchips: these are usually the type that is embedded on
232  an SoC. This means that there is a fast IRQ flow handler for the GPIOs that
233  gets called in a chain from the parent IRQ handler, most typically the
234  system interrupt controller. This means that the GPIO irqchip handler will
235  be called immediately from the parent irqchip, while holding the IRQs
236  disabled. The GPIO irqchip will then end up calling something like this
237  sequence in its interrupt handler::
238
239    static irqreturn_t foo_gpio_irq(int irq, void *data)
240        chained_irq_enter(...);
241        generic_handle_irq(...);
242        chained_irq_exit(...);
243
244  Chained GPIO irqchips typically can NOT set the .can_sleep flag on
245  struct gpio_chip, as everything happens directly in the callbacks: no
246  slow bus traffic like I2C can be used.
247
248  RT_FULL: Note, chained IRQ handlers will not be forced threaded on -RT.
249  As result, spinlock_t or any sleepable APIs (like PM runtime) can't be used
250  in chained IRQ handler.
251  If required (and if it can't be converted to the nested threaded GPIO irqchip)
252  a chained IRQ handler can be converted to generic irq handler and this way
253  it will be a threaded IRQ handler on -RT and a hard IRQ handler on non-RT
254  (for example, see [3]).
255  Know W/A: The generic_handle_irq() is expected to be called with IRQ disabled,
256  so the IRQ core will complain if it is called from an IRQ handler which is
257  forced to a thread. The "fake?" raw lock can be used to W/A this problem::
258
259	raw_spinlock_t wa_lock;
260	static irqreturn_t omap_gpio_irq_handler(int irq, void *gpiobank)
261		unsigned long wa_lock_flags;
262		raw_spin_lock_irqsave(&bank->wa_lock, wa_lock_flags);
263		generic_handle_irq(irq_find_mapping(bank->chip.irq.domain, bit));
264		raw_spin_unlock_irqrestore(&bank->wa_lock, wa_lock_flags);
265
266* GENERIC CHAINED GPIO irqchips: these are the same as "CHAINED GPIO irqchips",
267  but chained IRQ handlers are not used. Instead GPIO IRQs dispatching is
268  performed by generic IRQ handler which is configured using request_irq().
269  The GPIO irqchip will then end up calling something like this sequence in
270  its interrupt handler::
271
272    static irqreturn_t gpio_rcar_irq_handler(int irq, void *dev_id)
273        for each detected GPIO IRQ
274            generic_handle_irq(...);
275
276  RT_FULL: Such kind of handlers will be forced threaded on -RT, as result IRQ
277  core will complain that generic_handle_irq() is called with IRQ enabled and
278  the same W/A as for "CHAINED GPIO irqchips" can be applied.
279
280* NESTED THREADED GPIO irqchips: these are off-chip GPIO expanders and any
281  other GPIO irqchip residing on the other side of a sleeping bus. Of course
282  such drivers that need slow bus traffic to read out IRQ status and similar,
283  traffic which may in turn incur other IRQs to happen, cannot be handled
284  in a quick IRQ handler with IRQs disabled. Instead they need to spawn a
285  thread and then mask the parent IRQ line until the interrupt is handled
286  by the driver. The hallmark of this driver is to call something like
287  this in its interrupt handler::
288
289    static irqreturn_t foo_gpio_irq(int irq, void *data)
290        ...
291        handle_nested_irq(irq);
292
293  The hallmark of threaded GPIO irqchips is that they set the .can_sleep
294  flag on struct gpio_chip to true, indicating that this chip may sleep
295  when accessing the GPIOs.
296
297To help out in handling the set-up and management of GPIO irqchips and the
298associated irqdomain and resource allocation callbacks, the gpiolib has
299some helpers that can be enabled by selecting the GPIOLIB_IRQCHIP Kconfig
300symbol:
301
302* gpiochip_irqchip_add(): adds a chained irqchip to a gpiochip. It will pass
303  the struct gpio_chip* for the chip to all IRQ callbacks, so the callbacks
304  need to embed the gpio_chip in its state container and obtain a pointer
305  to the container using container_of().
306  (See Documentation/driver-model/design-patterns.txt)
307
308* gpiochip_irqchip_add_nested(): adds a nested irqchip to a gpiochip.
309  Apart from that it works exactly like the chained irqchip.
310
311* gpiochip_set_chained_irqchip(): sets up a chained irq handler for a
312  gpio_chip from a parent IRQ and passes the struct gpio_chip* as handler
313  data. (Notice handler data, since the irqchip data is likely used by the
314  parent irqchip!).
315
316* gpiochip_set_nested_irqchip(): sets up a nested irq handler for a
317  gpio_chip from a parent IRQ. As the parent IRQ has usually been
318  explicitly requested by the driver, this does very little more than
319  mark all the child IRQs as having the other IRQ as parent.
320
321If there is a need to exclude certain GPIOs from the IRQ domain, you can
322set .irq.need_valid_mask of the gpiochip before gpiochip_add_data() is
323called. This allocates an .irq.valid_mask with as many bits set as there
324are GPIOs in the chip. Drivers can exclude GPIOs by clearing bits from this
325mask. The mask must be filled in before gpiochip_irqchip_add() or
326gpiochip_irqchip_add_nested() is called.
327
328To use the helpers please keep the following in mind:
329
330- Make sure to assign all relevant members of the struct gpio_chip so that
331  the irqchip can initialize. E.g. .dev and .can_sleep shall be set up
332  properly.
333
334- Nominally set all handlers to handle_bad_irq() in the setup call and pass
335  handle_bad_irq() as flow handler parameter in gpiochip_irqchip_add() if it is
336  expected for GPIO driver that irqchip .set_type() callback have to be called
337  before using/enabling GPIO IRQ. Then set the handler to handle_level_irq()
338  and/or handle_edge_irq() in the irqchip .set_type() callback depending on
339  what your controller supports.
340
341It is legal for any IRQ consumer to request an IRQ from any irqchip no matter
342if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and
343irq_chip are orthogonal, and offering their services independent of each
344other.
345
346gpiod_to_irq() is just a convenience function to figure out the IRQ for a
347certain GPIO line and should not be relied upon to have been called before
348the IRQ is used.
349
350So always prepare the hardware and make it ready for action in respective
351callbacks from the GPIO and irqchip APIs. Do not rely on gpiod_to_irq() having
352been called first.
353
354This orthogonality leads to ambiguities that we need to solve: if there is
355competition inside the subsystem which side is using the resource (a certain
356GPIO line and register for example) it needs to deny certain operations and
357keep track of usage inside of the gpiolib subsystem. This is why the API
358below exists.
359
360
361Locking IRQ usage
362-----------------
363Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
364to mark the GPIO as being used as an IRQ::
365
366	int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset)
367
368This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
369is released::
370
371	void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset)
372
373When implementing an irqchip inside a GPIO driver, these two functions should
374typically be called in the .startup() and .shutdown() callbacks from the
375irqchip.
376
377When using the gpiolib irqchip helpers, these callback are automatically
378assigned.
379
380Real-Time compliance for GPIO IRQ chips
381---------------------------------------
382
383Any provider of irqchips needs to be carefully tailored to support Real Time
384preemption. It is desirable that all irqchips in the GPIO subsystem keep this
385in mind and do the proper testing to assure they are real time-enabled.
386So, pay attention on above " RT_FULL:" notes, please.
387The following is a checklist to follow when preparing a driver for real
388time-compliance:
389
390- ensure spinlock_t is not used as part irq_chip implementation;
391- ensure that sleepable APIs are not used as part irq_chip implementation.
392  If sleepable APIs have to be used, these can be done from the .irq_bus_lock()
393  and .irq_bus_unlock() callbacks;
394- Chained GPIO irqchips: ensure spinlock_t or any sleepable APIs are not used
395  from chained IRQ handler;
396- Generic chained GPIO irqchips: take care about generic_handle_irq() calls and
397  apply corresponding W/A;
398- Chained GPIO irqchips: get rid of chained IRQ handler and use generic irq
399  handler if possible :)
400- regmap_mmio: Sry, but you are in trouble :( if MMIO regmap is used as for
401  GPIO IRQ chip implementation;
402- Test your driver with the appropriate in-kernel real time test cases for both
403  level and edge IRQs.
404
405
406Requesting self-owned GPIO pins
407-------------------------------
408
409Sometimes it is useful to allow a GPIO chip driver to request its own GPIO
410descriptors through the gpiolib API. Using gpio_request() for this purpose
411does not help since it pins the module to the kernel forever (it calls
412try_module_get()). A GPIO driver can use the following functions instead
413to request and free descriptors without being pinned to the kernel forever::
414
415	struct gpio_desc *gpiochip_request_own_desc(struct gpio_desc *desc,
416						    const char *label)
417
418	void gpiochip_free_own_desc(struct gpio_desc *desc)
419
420Descriptors requested with gpiochip_request_own_desc() must be released with
421gpiochip_free_own_desc().
422
423These functions must be used with care since they do not affect module use
424count. Do not use the functions to request gpio descriptors not owned by the
425calling driver.
426
427* [1] http://www.spinics.net/lists/linux-omap/msg120425.html
428* [2] https://lkml.org/lkml/2015/9/25/494
429* [3] https://lkml.org/lkml/2015/9/25/495
430