About Kernel Documentation Linux Kernel Contact Linux Resources Linux Blog

Documentation / gpio / driver.txt

Custom Search

Based on kernel version 4.9. Page generated on 2016-12-21 14:34 EST.

1	GPIO Descriptor Driver Interface
2	================================
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.
8	Each GPIO controller driver needs to include the following header, which defines
9	the structures used to define a GPIO driver:
11		#include <linux/gpio/driver.h>
14	Internal Representation of GPIOs
15	================================
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.
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.
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.
37	Controller Drivers: gpio_chip
38	=============================
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:
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
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.
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.
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.
65	RT_FULL: GPIO driver should not use spinlock_t or any sleepable APIs
66	(like PM runtime) in its gpio_chip implementation (.get/.set and direction
67	control callbacks) if it is expected to call GPIO APIs from atomic context
68	on -RT (inside hard IRQ handlers and similar contexts). Normally this should
69	not be required.
72	GPIOs with open drain/source support
73	------------------------------------
75	Open drain (CMOS) or open collector (TTL) means the line is not actively driven
76	high: instead you provide the drain/collector as output, so when the transistor
77	is not open, it will present a high-impedance (tristate) to the external rail.
82	            ||--- out              +--- out
83	     in ----||                   |/
84	            ||--+         in ----|
85	                |                |\
86	               GND	           GND
88	This configuration is normally used as a way to achieve one of two things:
90	- Level-shifting: to reach a logical level higher than that of the silicon
91	  where the output resides.
93	- inverse wire-OR on an I/O line, for example a GPIO line, making it possible
94	  for any driving stage on the line to drive it low even if any other output
95	  to the same line is simultaneously driving it high. A special case of this
96	  is driving the SCL and SCA lines of an I2C bus, which is by definition a
97	  wire-OR bus.
99	Both usecases require that the line be equipped with a pull-up resistor. This
100	resistor will make the line tend to high level unless one of the transistors on
101	the rail actively pulls it down.
103	The level on the line will go as high as the VDD on the pull-up resistor, which
104	may be higher than the level supported by the transistor, achieveing a
105	level-shift to the higher VDD.
107	Integrated electronics often have an output driver stage in the form of a CMOS
108	"totem-pole" with one N-MOS and one P-MOS transistor where one of them drives
109	the line high and one of them drives the line low. This is called a push-pull
110	output. The "totem-pole" looks like so:
112	                 VDD
113	                  |
114	        OD    ||--+
115	     +--/ ---o||     P-MOS-FET
116	     |        ||--+
117	IN --+            +----- out
118	     |        ||--+
119	     +--/ ----||     N-MOS-FET
120	        OS    ||--+
121	                  |
122	                 GND
124	The desired output signal (e.g. coming directly from some GPIO output register)
125	arrives at IN. The switches named "OD" and "OS" are normally closed, creating
126	a push-pull circuit.
128	Consider the little "switches" named "OD" and "OS" that enable/disable the
129	P-MOS or N-MOS transistor right after the split of the input. As you can see,
130	either transistor will go totally numb if this switch is open. The totem-pole
131	is then halved and give high impedance instead of actively driving the line
132	high or low respectively. That is usually how software-controlled open
133	drain/source works.
135	Some GPIO hardware come in open drain / open source configuration. Some are
136	hard-wired lines that will only support open drain or open source no matter
137	what: there is only one transistor there. Some are software-configurable:
138	by flipping a bit in a register the output can be configured as open drain
139	or open source, in practice by flicking open the switches labeled "OD" and "OS"
140	in the drawing above.
142	By disabling the P-MOS transistor, the output can be driven between GND and
143	high impedance (open drain), and by disabling the N-MOS transistor, the output
144	can be driven between VDD and high impedance (open source). In the first case,
145	a pull-up resistor is needed on the outgoing rail to complete the circuit, and
146	in the second case, a pull-down resistor is needed on the rail.
148	Hardware that supports open drain or open source or both, can implement a
149	special callback in the gpio_chip: .set_single_ended() that takes an enum flag
150	telling whether to configure the line as open drain, open source or push-pull.
151	This will happen in response to the GPIO_OPEN_DRAIN or GPIO_OPEN_SOURCE flag
152	set in the machine file, or coming from other hardware descriptions.
154	If this state can not be configured in hardware, i.e. if the GPIO hardware does
155	not support open drain/open source in hardware, the GPIO library will instead
156	use a trick: when a line is set as output, if the line is flagged as open
157	drain, and the IN output value is low, it will be driven low as usual. But
158	if the IN output value is set to high, it will instead *NOT* be driven high,
159	instead it will be switched to input, as input mode is high impedance, thus
160	achieveing an "open drain emulation" of sorts: electrically the behaviour will
161	be identical, with the exception of possible hardware glitches when switching
162	the mode of the line.
164	For open source configuration the same principle is used, just that instead
165	of actively driving the line low, it is set to input.
168	GPIO drivers providing IRQs
169	---------------------------
170	It is custom that GPIO drivers (GPIO chips) are also providing interrupts,
171	most often cascaded off a parent interrupt controller, and in some special
172	cases the GPIO logic is melded with a SoC's primary interrupt controller.
174	The IRQ portions of the GPIO block are implemented using an irqchip, using
175	the header <linux/irq.h>. So basically such a driver is utilizing two sub-
176	systems simultaneously: gpio and irq.
178	RT_FULL: GPIO driver should not use spinlock_t or any sleepable APIs
179	(like PM runtime) as part of its irq_chip implementation on -RT.
180	- spinlock_t should be replaced with raw_spinlock_t [1].
181	- If sleepable APIs have to be used, these can be done from the .irq_bus_lock()
182	  and .irq_bus_unlock() callbacks, as these are the only slowpath callbacks
183	  on an irqchip. Create the callbacks if needed [2].
185	GPIO irqchips usually fall in one of two categories:
187	* CHAINED GPIO irqchips: these are usually the type that is embedded on
188	  an SoC. This means that there is a fast IRQ handler for the GPIOs that
189	  gets called in a chain from the parent IRQ handler, most typically the
190	  system interrupt controller. This means the GPIO irqchip is registered
191	  using irq_set_chained_handler() or the corresponding
192	  gpiochip_set_chained_irqchip() helper function, and the GPIO irqchip
193	  handler will be called immediately from the parent irqchip, while
194	  holding the IRQs disabled. The GPIO irqchip will then end up calling
195	  something like this sequence in its interrupt handler:
197	  static irqreturn_t tc3589x_gpio_irq(int irq, void *data)
198	      chained_irq_enter(...);
199	      generic_handle_irq(...);
200	      chained_irq_exit(...);
202	  Chained GPIO irqchips typically can NOT set the .can_sleep flag on
203	  struct gpio_chip, as everything happens directly in the callbacks.
205	  RT_FULL: Note, chained IRQ handlers will not be forced threaded on -RT.
206	  As result, spinlock_t or any sleepable APIs (like PM runtime) can't be used
207	  in chained IRQ handler.
208	  if required (and if it can't be converted to the nested threaded GPIO irqchip)
209	  - chained IRQ handler can be converted to generic irq handler and this way
210	  it will be threaded IRQ handler on -RT and hard IRQ handler on non-RT
211	  (for example, see [3]).
212	  Know W/A: The generic_handle_irq() is expected to be called with IRQ disabled,
213	  so IRQ core will complain if it will be called from IRQ handler which is
214	  forced thread. The "fake?" raw lock can be used to W/A this problem:
216		raw_spinlock_t wa_lock;
217		static irqreturn_t omap_gpio_irq_handler(int irq, void *gpiobank)
218			unsigned long wa_lock_flags;
219			raw_spin_lock_irqsave(&bank->wa_lock, wa_lock_flags);
220			generic_handle_irq(irq_find_mapping(bank->chip.irqdomain, bit));
221			raw_spin_unlock_irqrestore(&bank->wa_lock, wa_lock_flags);
223	* GENERIC CHAINED GPIO irqchips: these are the same as "CHAINED GPIO irqchips",
224	  but chained IRQ handlers are not used. Instead GPIO IRQs dispatching is
225	  performed by generic IRQ handler which is configured using request_irq().
226	  The GPIO irqchip will then end up calling something like this sequence in
227	  its interrupt handler:
229	  static irqreturn_t gpio_rcar_irq_handler(int irq, void *dev_id)
230		for each detected GPIO IRQ
231			generic_handle_irq(...);
233	  RT_FULL: Such kind of handlers will be forced threaded on -RT, as result IRQ
234	  core will complain that generic_handle_irq() is called with IRQ enabled and
235	  the same W/A as for "CHAINED GPIO irqchips" can be applied.
237	* NESTED THREADED GPIO irqchips: these are off-chip GPIO expanders and any
238	  other GPIO irqchip residing on the other side of a sleeping bus. Of course
239	  such drivers that need slow bus traffic to read out IRQ status and similar,
240	  traffic which may in turn incur other IRQs to happen, cannot be handled
241	  in a quick IRQ handler with IRQs disabled. Instead they need to spawn a
242	  thread and then mask the parent IRQ line until the interrupt is handled
243	  by the driver. The hallmark of this driver is to call something like
244	  this in its interrupt handler:
246	  static irqreturn_t tc3589x_gpio_irq(int irq, void *data)
247	      ...
248	      handle_nested_irq(irq);
250	  The hallmark of threaded GPIO irqchips is that they set the .can_sleep
251	  flag on struct gpio_chip to true, indicating that this chip may sleep
252	  when accessing the GPIOs.
254	To help out in handling the set-up and management of GPIO irqchips and the
255	associated irqdomain and resource allocation callbacks, the gpiolib has
256	some helpers that can be enabled by selecting the GPIOLIB_IRQCHIP Kconfig
257	symbol:
259	* gpiochip_irqchip_add(): adds an irqchip to a gpiochip. It will pass
260	  the struct gpio_chip* for the chip to all IRQ callbacks, so the callbacks
261	  need to embed the gpio_chip in its state container and obtain a pointer
262	  to the container using container_of().
263	  (See Documentation/driver-model/design-patterns.txt)
265	  If there is a need to exclude certain GPIOs from the IRQ domain, one can
266	  set .irq_need_valid_mask of the gpiochip before gpiochip_add_data() is
267	  called. This allocates .irq_valid_mask with as many bits set as there are
268	  GPIOs in the chip. Drivers can exclude GPIOs by clearing bits from this
269	  mask. The mask must be filled in before gpiochip_irqchip_add() is called.
271	* gpiochip_set_chained_irqchip(): sets up a chained irq handler for a
272	  gpio_chip from a parent IRQ and passes the struct gpio_chip* as handler
273	  data. (Notice handler data, since the irqchip data is likely used by the
274	  parent irqchip!) This is for the chained type of chip. This is also used
275	  to set up a nested irqchip if NULL is passed as handler.
277	To use the helpers please keep the following in mind:
279	- Make sure to assign all relevant members of the struct gpio_chip so that
280	  the irqchip can initialize. E.g. .dev and .can_sleep shall be set up
281	  properly.
283	- Nominally set all handlers to handle_bad_irq() in the setup call and pass
284	  handle_bad_irq() as flow handler parameter in gpiochip_irqchip_add() if it is
285	  expected for GPIO driver that irqchip .set_type() callback have to be called
286	  before using/enabling GPIO IRQ. Then set the handler to handle_level_irq()
287	  and/or handle_edge_irq() in the irqchip .set_type() callback depending on
288	  what your controller supports.
290	It is legal for any IRQ consumer to request an IRQ from any irqchip no matter
291	if that is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and
292	irq_chip are orthogonal, and offering their services independent of each
293	other.
295	gpiod_to_irq() is just a convenience function to figure out the IRQ for a
296	certain GPIO line and should not be relied upon to have been called before
297	the IRQ is used.
299	So always prepare the hardware and make it ready for action in respective
300	callbacks from the GPIO and irqchip APIs. Do not rely on gpiod_to_irq() having
301	been called first.
303	This orthogonality leads to ambiguities that we need to solve: if there is
304	competition inside the subsystem which side is using the resource (a certain
305	GPIO line and register for example) it needs to deny certain operations and
306	keep track of usage inside of the gpiolib subsystem. This is why the API
307	below exists.
310	Locking IRQ usage
311	-----------------
312	Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
313	to mark the GPIO as being used as an IRQ:
315		int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset)
317	This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
318	is released:
320		void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset)
322	When implementing an irqchip inside a GPIO driver, these two functions should
323	typically be called in the .startup() and .shutdown() callbacks from the
324	irqchip.
326	Real-Time compliance for GPIO IRQ chips
327	---------------------------------------
329	Any provider of irqchips needs to be carefully tailored to support Real Time
330	preemption. It is desirable that all irqchips in the GPIO subsystem keep this
331	in mind and does the proper testing to assure they are real time-enabled.
332	So, pay attention on above " RT_FULL:" notes, please.
333	The following is a checklist to follow when preparing a driver for real
334	time-compliance:
336	- ensure spinlock_t is not used as part irq_chip implementation;
337	- ensure that sleepable APIs are not used as part irq_chip implementation.
338	  If sleepable APIs have to be used, these can be done from the .irq_bus_lock()
339	  and .irq_bus_unlock() callbacks;
340	- Chained GPIO irqchips: ensure spinlock_t or any sleepable APIs are not used
341	  from chained IRQ handler;
342	- Generic chained GPIO irqchips: take care about generic_handle_irq() calls and
343	  apply corresponding W/A;
344	- Chained GPIO irqchips: get rid of chained IRQ handler and use generic irq
345	  handler if possible :)
346	- regmap_mmio: Sry, but you are in trouble :( if MMIO regmap is used as for
347	  GPIO IRQ chip implementation;
348	- Test your driver with the appropriate in-kernel real time test cases for both
349	  level and edge IRQs.
352	Requesting self-owned GPIO pins
353	-------------------------------
355	Sometimes it is useful to allow a GPIO chip driver to request its own GPIO
356	descriptors through the gpiolib API. Using gpio_request() for this purpose
357	does not help since it pins the module to the kernel forever (it calls
358	try_module_get()). A GPIO driver can use the following functions instead
359	to request and free descriptors without being pinned to the kernel forever.
361		struct gpio_desc *gpiochip_request_own_desc(struct gpio_desc *desc,
362							    const char *label)
364		void gpiochip_free_own_desc(struct gpio_desc *desc)
366	Descriptors requested with gpiochip_request_own_desc() must be released with
367	gpiochip_free_own_desc().
369	These functions must be used with care since they do not affect module use
370	count. Do not use the functions to request gpio descriptors not owned by the
371	calling driver.
373	[1] http://www.spinics.net/lists/linux-omap/msg120425.html
374	[2] https://lkml.org/lkml/2015/9/25/494
375	[3] https://lkml.org/lkml/2015/9/25/495
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.