About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / gpio / driver.txt




Custom Search

Based on kernel version 3.16. Page generated on 2014-08-06 21:39 EST.

1	GPIO Descriptor Driver Interface
2	================================
3	
4	This document serves as a guide for GPIO chip drivers writers. Note that it
5	describes the new descriptor-based interface. For a description of the
6	deprecated integer-based GPIO interface please refer to gpio-legacy.txt.
7	
8	Each GPIO controller driver needs to include the following header, which defines
9	the structures used to define a GPIO driver:
10	
11		#include <linux/gpio/driver.h>
12	
13	
14	Internal Representation of GPIOs
15	================================
16	
17	Inside a GPIO driver, individual GPIOs are identified by their hardware number,
18	which is a unique number between 0 and n, n being the number of GPIOs managed by
19	the chip. This number is purely internal: the hardware number of a particular
20	GPIO descriptor is never made visible outside of the driver.
21	
22	On top of this internal number, each GPIO also need to have a global number in
23	the integer GPIO namespace so that it can be used with the legacy GPIO
24	interface. Each chip must thus have a "base" number (which can be automatically
25	assigned), and for each GPIO the global number will be (base + hardware number).
26	Although the integer representation is considered deprecated, it still has many
27	users and thus needs to be maintained.
28	
29	So for example one platform could use numbers 32-159 for GPIOs, with a
30	controller defining 128 GPIOs at a "base" of 32 ; while another platform uses
31	numbers 0..63 with one set of GPIO controllers, 64-79 with another type of GPIO
32	controller, and on one particular board 80-95 with an FPGA. The numbers need not
33	be contiguous; either of those platforms could also use numbers 2000-2063 to
34	identify GPIOs in a bank of I2C GPIO expanders.
35	
36	
37	Controller Drivers: gpio_chip
38	=============================
39	
40	In the gpiolib framework each GPIO controller is packaged as a "struct
41	gpio_chip" (see linux/gpio/driver.h for its complete definition) with members
42	common to each controller of that type:
43	
44	 - methods to establish GPIO direction
45	 - methods used to access GPIO values
46	 - method to return the IRQ number associated to a given GPIO
47	 - flag saying whether calls to its methods may sleep
48	 - optional debugfs dump method (showing extra state like pullup config)
49	 - optional base number (will be automatically assigned if omitted)
50	 - label for diagnostics and GPIOs mapping using platform data
51	
52	The code implementing a gpio_chip should support multiple instances of the
53	controller, possibly using the driver model. That code will configure each
54	gpio_chip and issue gpiochip_add(). Removing a GPIO controller should be rare;
55	use gpiochip_remove() when it is unavoidable.
56	
57	Most often a gpio_chip is part of an instance-specific structure with state not
58	exposed by the GPIO interfaces, such as addressing, power management, and more.
59	Chips such as codecs will have complex non-GPIO state.
60	
61	Any debugfs dump method should normally ignore signals which haven't been
62	requested as GPIOs. They can use gpiochip_is_requested(), which returns either
63	NULL or the label associated with that GPIO when it was requested.
64	
65	
66	GPIO drivers providing IRQs
67	---------------------------
68	It is custom that GPIO drivers (GPIO chips) are also providing interrupts,
69	most often cascaded off a parent interrupt controller, and in some special
70	cases the GPIO logic is melded with a SoC's primary interrupt controller.
71	
72	The IRQ portions of the GPIO block are implemented using an irqchip, using
73	the header <linux/irq.h>. So basically such a driver is utilizing two sub-
74	systems simultaneously: gpio and irq.
75	
76	GPIO irqchips usually fall in one of two categories:
77	
78	* CHAINED GPIO irqchips: these are usually the type that is embedded on
79	  an SoC. This means that there is a fast IRQ handler for the GPIOs that
80	  gets called in a chain from the parent IRQ handler, most typically the
81	  system interrupt controller. This means the GPIO irqchip is registered
82	  using irq_set_chained_handler() or the corresponding
83	  gpiochip_set_chained_irqchip() helper function, and the GPIO irqchip
84	  handler will be called immediately from the parent irqchip, while
85	  holding the IRQs disabled. The GPIO irqchip will then end up calling
86	  something like this sequence in its interrupt handler:
87	
88	  static irqreturn_t tc3589x_gpio_irq(int irq, void *data)
89	      chained_irq_enter(...);
90	      generic_handle_irq(...);
91	      chained_irq_exit(...);
92	
93	  Chained GPIO irqchips typically can NOT set the .can_sleep flag on
94	  struct gpio_chip, as everything happens directly in the callbacks.
95	
96	* NESTED THREADED GPIO irqchips: these are off-chip GPIO expanders and any
97	  other GPIO irqchip residing on the other side of a sleeping bus. Of course
98	  such drivers that need slow bus traffic to read out IRQ status and similar,
99	  traffic which may in turn incur other IRQs to happen, cannot be handled
100	  in a quick IRQ handler with IRQs disabled. Instead they need to spawn a
101	  thread and then mask the parent IRQ line until the interrupt is handled
102	  by the driver. The hallmark of this driver is to call something like
103	  this in its interrupt handler:
104	
105	  static irqreturn_t tc3589x_gpio_irq(int irq, void *data)
106	      ...
107	      handle_nested_irq(irq);
108	
109	  The hallmark of threaded GPIO irqchips is that they set the .can_sleep
110	  flag on struct gpio_chip to true, indicating that this chip may sleep
111	  when accessing the GPIOs.
112	
113	To help out in handling the set-up and management of GPIO irqchips and the
114	associated irqdomain and resource allocation callbacks, the gpiolib has
115	some helpers that can be enabled by selecting the GPIOLIB_IRQCHIP Kconfig
116	symbol:
117	
118	* gpiochip_irqchip_add(): adds an irqchip to a gpiochip. It will pass
119	  the struct gpio_chip* for the chip to all IRQ callbacks, so the callbacks
120	  need to embed the gpio_chip in its state container and obtain a pointer
121	  to the container using container_of().
122	  (See Documentation/driver-model/design-patterns.txt)
123	
124	* gpiochip_set_chained_irqchip(): sets up a chained irq handler for a
125	  gpio_chip from a parent IRQ and passes the struct gpio_chip* as handler
126	  data. (Notice handler data, since the irqchip data is likely used by the
127	  parent irqchip!) This is for the chained type of chip.
128	
129	To use the helpers please keep the following in mind:
130	
131	- Make sure to assign all relevant members of the struct gpio_chip so that
132	  the irqchip can initialize. E.g. .dev and .can_sleep shall be set up
133	  properly.
134	
135	It is legal for any IRQ consumer to request an IRQ from any irqchip no matter
136	if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and
137	irq_chip are orthogonal, and offering their services independent of each
138	other.
139	
140	gpiod_to_irq() is just a convenience function to figure out the IRQ for a
141	certain GPIO line and should not be relied upon to have been called before
142	the IRQ is used.
143	
144	So always prepare the hardware and make it ready for action in respective
145	callbacks from the GPIO and irqchip APIs. Do not rely on gpiod_to_irq() having
146	been called first.
147	
148	This orthogonality leads to ambiguities that we need to solve: if there is
149	competition inside the subsystem which side is using the resource (a certain
150	GPIO line and register for example) it needs to deny certain operations and
151	keep track of usage inside of the gpiolib subsystem. This is why the API
152	below exists.
153	
154	
155	Locking IRQ usage
156	-----------------
157	Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
158	to mark the GPIO as being used as an IRQ:
159	
160		int gpiod_lock_as_irq(struct gpio_desc *desc)
161	
162	This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
163	is released:
164	
165		void gpiod_unlock_as_irq(struct gpio_desc *desc)
166	
167	When implementing an irqchip inside a GPIO driver, these two functions should
168	typically be called in the .startup() and .shutdown() callbacks from the
169	irqchip.
Hide Line Numbers
About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Information is copyright its respective author. All material is available from the Linux Kernel Source distributed under a GPL License. This page is provided as a free service by mjmwired.net.