driver.rst 28 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264265266267268269270271272273274275276277278279280281282283284285286287288289290291292293294295296297298299300301302303304305306307308309310311312313314315316317318319320321322323324325326327328329330331332333334335336337338339340341342343344345346347348349350351352353354355356357358359360361362363364365366367368369370371372373374375376377378379380381382383384385386387388389390391392393394395396397398399400401402403404405406407408409410411412413414415416417418419420421422423424425426427428429430431432433434435436437438439440441442443444445446447448449450451452453454455456457458459460461462463464465466467468469470471472473474475476477478479480481482483484485486487488489490491492493494495496497498499500501502503504505506507508509510511512513514515516517518519520521522523524525526527528529530531532533534535536537538539540541542543544545546547548549550551552553554555556557558559560561562563564565566567568569570571572573574575576577578579580581582583584585586587588589590591592593594595596597598599600601602603604605606607608609610611612613614615616617618619620621622623624625626627628629630631632633634635636637638639640641642643644645
  1. =====================
  2. GPIO Driver Interface
  3. =====================
  4. This document serves as a guide for writers of GPIO chip drivers.
  5. Each GPIO controller driver needs to include the following header, which defines
  6. the structures used to define a GPIO driver::
  7. #include <linux/gpio/driver.h>
  8. Internal Representation of GPIOs
  9. ================================
  10. A GPIO chip handles one or more GPIO lines. To be considered a GPIO chip, the
  11. lines must conform to the definition: General Purpose Input/Output. If the
  12. line is not general purpose, it is not GPIO and should not be handled by a
  13. GPIO chip. The use case is the indicative: certain lines in a system may be
  14. called GPIO but serve a very particular purpose thus not meeting the criteria
  15. of a general purpose I/O. On the other hand a LED driver line may be used as a
  16. GPIO and should therefore still be handled by a GPIO chip driver.
  17. Inside a GPIO driver, individual GPIO lines are identified by their hardware
  18. number, sometime also referred to as ``offset``, which is a unique number
  19. between 0 and n-1, n being the number of GPIOs managed by the chip.
  20. The hardware GPIO number should be something intuitive to the hardware, for
  21. example if a system uses a memory-mapped set of I/O-registers where 32 GPIO
  22. lines are handled by one bit per line in a 32-bit register, it makes sense to
  23. use hardware offsets 0..31 for these, corresponding to bits 0..31 in the
  24. register.
  25. This number is purely internal: the hardware number of a particular GPIO
  26. line is never made visible outside of the driver.
  27. On top of this internal number, each GPIO line also needs to have a global
  28. number in the integer GPIO namespace so that it can be used with the legacy GPIO
  29. interface. Each chip must thus have a "base" number (which can be automatically
  30. assigned), and for each GPIO line the global number will be (base + hardware
  31. number). Although the integer representation is considered deprecated, it still
  32. has many users and thus needs to be maintained.
  33. So for example one platform could use global numbers 32-159 for GPIOs, with a
  34. controller defining 128 GPIOs at a "base" of 32 ; while another platform uses
  35. global numbers 0..63 with one set of GPIO controllers, 64-79 with another type
  36. of GPIO controller, and on one particular board 80-95 with an FPGA. The legacy
  37. numbers need not be contiguous; either of those platforms could also use numbers
  38. 2000-2063 to identify GPIO lines in a bank of I2C GPIO expanders.
  39. Controller Drivers: gpio_chip
  40. =============================
  41. In the gpiolib framework each GPIO controller is packaged as a "struct
  42. gpio_chip" (see <linux/gpio/driver.h> for its complete definition) with members
  43. common to each controller of that type, these should be assigned by the
  44. driver code:
  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 information)
  52. - optional base number (will be automatically assigned if omitted)
  53. - optional label for diagnostics and GPIO chip mapping using platform data
  54. The code implementing a gpio_chip should support multiple instances of the
  55. controller, preferably using the driver model. That code will configure each
  56. gpio_chip and issue gpiochip_add(), gpiochip_add_data(), or
  57. devm_gpiochip_add_data(). Removing a GPIO controller should be rare; use
  58. gpiochip_remove() when it is unavoidable.
  59. Often a gpio_chip is part of an instance-specific structure with states not
  60. exposed by the GPIO interfaces, such as addressing, power management, and more.
  61. Chips such as audio codecs will have complex non-GPIO states.
  62. Any debugfs dump method should normally ignore lines which haven't been
  63. requested. They can use gpiochip_is_requested(), which returns either
  64. NULL or the label associated with that GPIO line when it was requested.
  65. Realtime considerations: the GPIO driver should not use spinlock_t or any
  66. sleepable APIs (like PM runtime) in its gpio_chip implementation (.get/.set
  67. and direction control callbacks) if it is expected to call GPIO APIs from
  68. atomic context on realtime kernels (inside hard IRQ handlers and similar
  69. contexts). Normally this should not be required.
  70. GPIO electrical configuration
  71. -----------------------------
  72. GPIO lines can be configured for several electrical modes of operation by using
  73. the .set_config() callback. Currently this API supports setting:
  74. - Debouncing
  75. - Single-ended modes (open drain/open source)
  76. - Pull up and pull down resistor enablement
  77. These settings are described below.
  78. The .set_config() callback uses the same enumerators and configuration
  79. semantics as the generic pin control drivers. This is not a coincidence: it is
  80. possible to assign the .set_config() to the function gpiochip_generic_config()
  81. which will result in pinctrl_gpio_set_config() being called and eventually
  82. ending up in the pin control back-end "behind" the GPIO controller, usually
  83. closer to the actual pins. This way the pin controller can manage the below
  84. listed GPIO configurations.
  85. If a pin controller back-end is used, the GPIO controller or hardware
  86. description needs to provide "GPIO ranges" mapping the GPIO line offsets to pin
  87. numbers on the pin controller so they can properly cross-reference each other.
  88. GPIO lines with debounce support
  89. --------------------------------
  90. Debouncing is a configuration set to a pin indicating that it is connected to
  91. a mechanical switch or button, or similar that may bounce. Bouncing means the
  92. line is pulled high/low quickly at very short intervals for mechanical
  93. reasons. This can result in the value being unstable or irqs fireing repeatedly
  94. unless the line is debounced.
  95. Debouncing in practice involves setting up a timer when something happens on
  96. the line, wait a little while and then sample the line again, so see if it
  97. still has the same value (low or high). This could also be repeated by a clever
  98. state machine, waiting for a line to become stable. In either case, it sets
  99. a certain number of milliseconds for debouncing, or just "on/off" if that time
  100. is not configurable.
  101. GPIO lines with open drain/source support
  102. -----------------------------------------
  103. Open drain (CMOS) or open collector (TTL) means the line is not actively driven
  104. high: instead you provide the drain/collector as output, so when the transistor
  105. is not open, it will present a high-impedance (tristate) to the external rail::
  106. CMOS CONFIGURATION TTL CONFIGURATION
  107. ||--- out +--- out
  108. in ----|| |/
  109. ||--+ in ----|
  110. | |\
  111. GND GND
  112. This configuration is normally used as a way to achieve one of two things:
  113. - Level-shifting: to reach a logical level higher than that of the silicon
  114. where the output resides.
  115. - Inverse wire-OR on an I/O line, for example a GPIO line, making it possible
  116. for any driving stage on the line to drive it low even if any other output
  117. to the same line is simultaneously driving it high. A special case of this
  118. is driving the SCL and SDA lines of an I2C bus, which is by definition a
  119. wire-OR bus.
  120. Both use cases require that the line be equipped with a pull-up resistor. This
  121. resistor will make the line tend to high level unless one of the transistors on
  122. the rail actively pulls it down.
  123. The level on the line will go as high as the VDD on the pull-up resistor, which
  124. may be higher than the level supported by the transistor, achieving a
  125. level-shift to the higher VDD.
  126. Integrated electronics often have an output driver stage in the form of a CMOS
  127. "totem-pole" with one N-MOS and one P-MOS transistor where one of them drives
  128. the line high and one of them drives the line low. This is called a push-pull
  129. output. The "totem-pole" looks like so::
  130. VDD
  131. |
  132. OD ||--+
  133. +--/ ---o|| P-MOS-FET
  134. | ||--+
  135. IN --+ +----- out
  136. | ||--+
  137. +--/ ----|| N-MOS-FET
  138. OS ||--+
  139. |
  140. GND
  141. The desired output signal (e.g. coming directly from some GPIO output register)
  142. arrives at IN. The switches named "OD" and "OS" are normally closed, creating
  143. a push-pull circuit.
  144. Consider the little "switches" named "OD" and "OS" that enable/disable the
  145. P-MOS or N-MOS transistor right after the split of the input. As you can see,
  146. either transistor will go totally numb if this switch is open. The totem-pole
  147. is then halved and give high impedance instead of actively driving the line
  148. high or low respectively. That is usually how software-controlled open
  149. drain/source works.
  150. Some GPIO hardware come in open drain / open source configuration. Some are
  151. hard-wired lines that will only support open drain or open source no matter
  152. what: there is only one transistor there. Some are software-configurable:
  153. by flipping a bit in a register the output can be configured as open drain
  154. or open source, in practice by flicking open the switches labeled "OD" and "OS"
  155. in the drawing above.
  156. By disabling the P-MOS transistor, the output can be driven between GND and
  157. high impedance (open drain), and by disabling the N-MOS transistor, the output
  158. can be driven between VDD and high impedance (open source). In the first case,
  159. a pull-up resistor is needed on the outgoing rail to complete the circuit, and
  160. in the second case, a pull-down resistor is needed on the rail.
  161. Hardware that supports open drain or open source or both, can implement a
  162. special callback in the gpio_chip: .set_config() that takes a generic
  163. pinconf packed value telling whether to configure the line as open drain,
  164. open source or push-pull. This will happen in response to the
  165. GPIO_OPEN_DRAIN or GPIO_OPEN_SOURCE flag set in the machine file, or coming
  166. from other hardware descriptions.
  167. If this state can not be configured in hardware, i.e. if the GPIO hardware does
  168. not support open drain/open source in hardware, the GPIO library will instead
  169. use a trick: when a line is set as output, if the line is flagged as open
  170. drain, and the IN output value is low, it will be driven low as usual. But
  171. if the IN output value is set to high, it will instead *NOT* be driven high,
  172. instead it will be switched to input, as input mode is high impedance, thus
  173. achieveing an "open drain emulation" of sorts: electrically the behaviour will
  174. be identical, with the exception of possible hardware glitches when switching
  175. the mode of the line.
  176. For open source configuration the same principle is used, just that instead
  177. of actively driving the line low, it is set to input.
  178. GPIO lines with pull up/down resistor support
  179. ---------------------------------------------
  180. A GPIO line can support pull-up/down using the .set_config() callback. This
  181. means that a pull up or pull-down resistor is available on the output of the
  182. GPIO line, and this resistor is software controlled.
  183. In discrete designs, a pull-up or pull-down resistor is simply soldered on
  184. the circuit board. This is not something we deal with or model in software. The
  185. most you will think about these lines is that they will very likely be
  186. configured as open drain or open source (see the section above).
  187. The .set_config() callback can only turn pull up or down on and off, and will
  188. no have any semantic knowledge about the resistance used. It will only say
  189. switch a bit in a register enabling or disabling pull-up or pull-down.
  190. If the GPIO line supports shunting in different resistance values for the
  191. pull-up or pull-down resistor, the GPIO chip callback .set_config() will not
  192. suffice. For these complex use cases, a combined GPIO chip and pin controller
  193. need to be implemented, as the pin config interface of a pin controller
  194. supports more versatile control over electrical properties and can handle
  195. different pull-up or pull-down resistance values.
  196. GPIO drivers providing IRQs
  197. ===========================
  198. It is custom that GPIO drivers (GPIO chips) are also providing interrupts,
  199. most often cascaded off a parent interrupt controller, and in some special
  200. cases the GPIO logic is melded with a SoC's primary interrupt controller.
  201. The IRQ portions of the GPIO block are implemented using an irq_chip, using
  202. the header <linux/irq.h>. So this combined driver is utilizing two sub-
  203. systems simultaneously: gpio and irq.
  204. It is legal for any IRQ consumer to request an IRQ from any irqchip even if it
  205. is a combined GPIO+IRQ driver. The basic premise is that gpio_chip and
  206. irq_chip are orthogonal, and offering their services independent of each
  207. other.
  208. gpiod_to_irq() is just a convenience function to figure out the IRQ for a
  209. certain GPIO line and should not be relied upon to have been called before
  210. the IRQ is used.
  211. Always prepare the hardware and make it ready for action in respective
  212. callbacks from the GPIO and irq_chip APIs. Do not rely on gpiod_to_irq() having
  213. been called first.
  214. We can divide GPIO irqchips in two broad categories:
  215. - CASCADED INTERRUPT CHIPS: this means that the GPIO chip has one common
  216. interrupt output line, which is triggered by any enabled GPIO line on that
  217. chip. The interrupt output line will then be routed to an parent interrupt
  218. controller one level up, in the most simple case the systems primary
  219. interrupt controller. This is modeled by an irqchip that will inspect bits
  220. inside the GPIO controller to figure out which line fired it. The irqchip
  221. part of the driver needs to inspect registers to figure this out and it
  222. will likely also need to acknowledge that it is handling the interrupt
  223. by clearing some bit (sometime implicitly, by just reading a status
  224. register) and it will often need to set up the configuration such as
  225. edge sensitivity (rising or falling edge, or high/low level interrupt for
  226. example).
  227. - HIERARCHICAL INTERRUPT CHIPS: this means that each GPIO line has a dedicated
  228. irq line to a parent interrupt controller one level up. There is no need
  229. to inquire the GPIO hardware to figure out which line has fired, but it
  230. may still be necessary to acknowledge the interrupt and set up configuration
  231. such as edge sensitivity.
  232. Realtime considerations: a realtime compliant GPIO driver should not use
  233. spinlock_t or any sleepable APIs (like PM runtime) as part of its irqchip
  234. implementation.
  235. - spinlock_t should be replaced with raw_spinlock_t.[1]
  236. - If sleepable APIs have to be used, these can be done from the .irq_bus_lock()
  237. and .irq_bus_unlock() callbacks, as these are the only slowpath callbacks
  238. on an irqchip. Create the callbacks if needed.[2]
  239. Cascaded GPIO irqchips
  240. ----------------------
  241. Cascaded GPIO irqchips usually fall in one of three categories:
  242. - CHAINED CASCADED GPIO IRQCHIPS: these are usually the type that is embedded on
  243. an SoC. This means that there is a fast IRQ flow handler for the GPIOs that
  244. gets called in a chain from the parent IRQ handler, most typically the
  245. system interrupt controller. This means that the GPIO irqchip handler will
  246. be called immediately from the parent irqchip, while holding the IRQs
  247. disabled. The GPIO irqchip will then end up calling something like this
  248. sequence in its interrupt handler::
  249. static irqreturn_t foo_gpio_irq(int irq, void *data)
  250. chained_irq_enter(...);
  251. generic_handle_irq(...);
  252. chained_irq_exit(...);
  253. Chained GPIO irqchips typically can NOT set the .can_sleep flag on
  254. struct gpio_chip, as everything happens directly in the callbacks: no
  255. slow bus traffic like I2C can be used.
  256. Realtime considerations: Note that chained IRQ handlers will not be forced
  257. threaded on -RT. As a result, spinlock_t or any sleepable APIs (like PM
  258. runtime) can't be used in a chained IRQ handler.
  259. If required (and if it can't be converted to the nested threaded GPIO irqchip,
  260. see below) a chained IRQ handler can be converted to generic irq handler and
  261. this way it will become a threaded IRQ handler on -RT and a hard IRQ handler
  262. on non-RT (for example, see [3]).
  263. The generic_handle_irq() is expected to be called with IRQ disabled,
  264. so the IRQ core will complain if it is called from an IRQ handler which is
  265. forced to a thread. The "fake?" raw lock can be used to work around this
  266. problem::
  267. raw_spinlock_t wa_lock;
  268. static irqreturn_t omap_gpio_irq_handler(int irq, void *gpiobank)
  269. unsigned long wa_lock_flags;
  270. raw_spin_lock_irqsave(&bank->wa_lock, wa_lock_flags);
  271. generic_handle_irq(irq_find_mapping(bank->chip.irq.domain, bit));
  272. raw_spin_unlock_irqrestore(&bank->wa_lock, wa_lock_flags);
  273. - GENERIC CHAINED GPIO IRQCHIPS: these are the same as "CHAINED GPIO irqchips",
  274. but chained IRQ handlers are not used. Instead GPIO IRQs dispatching is
  275. performed by generic IRQ handler which is configured using request_irq().
  276. The GPIO irqchip will then end up calling something like this sequence in
  277. its interrupt handler::
  278. static irqreturn_t gpio_rcar_irq_handler(int irq, void *dev_id)
  279. for each detected GPIO IRQ
  280. generic_handle_irq(...);
  281. Realtime considerations: this kind of handlers will be forced threaded on -RT,
  282. and as result the IRQ core will complain that generic_handle_irq() is called
  283. with IRQ enabled and the same work-around as for "CHAINED GPIO irqchips" can
  284. be applied.
  285. - NESTED THREADED GPIO IRQCHIPS: these are off-chip GPIO expanders and any
  286. other GPIO irqchip residing on the other side of a sleeping bus such as I2C
  287. or SPI.
  288. Of course such drivers that need slow bus traffic to read out IRQ status and
  289. similar, traffic which may in turn incur other IRQs to happen, cannot be
  290. handled in a quick IRQ handler with IRQs disabled. Instead they need to spawn
  291. a thread and then mask the parent IRQ line until the interrupt is handled
  292. by the driver. The hallmark of this driver is to call something like
  293. this in its interrupt handler::
  294. static irqreturn_t foo_gpio_irq(int irq, void *data)
  295. ...
  296. handle_nested_irq(irq);
  297. The hallmark of threaded GPIO irqchips is that they set the .can_sleep
  298. flag on struct gpio_chip to true, indicating that this chip may sleep
  299. when accessing the GPIOs.
  300. These kinds of irqchips are inherently realtime tolerant as they are
  301. already set up to handle sleeping contexts.
  302. Infrastructure helpers for GPIO irqchips
  303. ----------------------------------------
  304. To help out in handling the set-up and management of GPIO irqchips and the
  305. associated irqdomain and resource allocation callbacks. These are activated
  306. by selecting the Kconfig symbol GPIOLIB_IRQCHIP. If the symbol
  307. IRQ_DOMAIN_HIERARCHY is also selected, hierarchical helpers will also be
  308. provided. A big portion of overhead code will be managed by gpiolib,
  309. under the assumption that your interrupts are 1-to-1-mapped to the
  310. GPIO line index:
  311. .. csv-table::
  312. :header: GPIO line offset, Hardware IRQ
  313. 0,0
  314. 1,1
  315. 2,2
  316. ...,...
  317. ngpio-1, ngpio-1
  318. If some GPIO lines do not have corresponding IRQs, the bitmask valid_mask
  319. and the flag need_valid_mask in gpio_irq_chip can be used to mask off some
  320. lines as invalid for associating with IRQs.
  321. The preferred way to set up the helpers is to fill in the
  322. struct gpio_irq_chip inside struct gpio_chip before adding the gpio_chip.
  323. If you do this, the additional irq_chip will be set up by gpiolib at the
  324. same time as setting up the rest of the GPIO functionality. The following
  325. is a typical example of a cascaded interrupt handler using gpio_irq_chip:
  326. .. code-block:: c
  327. /* Typical state container with dynamic irqchip */
  328. struct my_gpio {
  329. struct gpio_chip gc;
  330. struct irq_chip irq;
  331. };
  332. int irq; /* from platform etc */
  333. struct my_gpio *g;
  334. struct gpio_irq_chip *girq;
  335. /* Set up the irqchip dynamically */
  336. g->irq.name = "my_gpio_irq";
  337. g->irq.irq_ack = my_gpio_ack_irq;
  338. g->irq.irq_mask = my_gpio_mask_irq;
  339. g->irq.irq_unmask = my_gpio_unmask_irq;
  340. g->irq.irq_set_type = my_gpio_set_irq_type;
  341. /* Get a pointer to the gpio_irq_chip */
  342. girq = &g->gc.irq;
  343. girq->chip = &g->irq;
  344. girq->parent_handler = ftgpio_gpio_irq_handler;
  345. girq->num_parents = 1;
  346. girq->parents = devm_kcalloc(dev, 1, sizeof(*girq->parents),
  347. GFP_KERNEL);
  348. if (!girq->parents)
  349. return -ENOMEM;
  350. girq->default_type = IRQ_TYPE_NONE;
  351. girq->handler = handle_bad_irq;
  352. girq->parents[0] = irq;
  353. return devm_gpiochip_add_data(dev, &g->gc, g);
  354. The helper support using hierarchical interrupt controllers as well.
  355. In this case the typical set-up will look like this:
  356. .. code-block:: c
  357. /* Typical state container with dynamic irqchip */
  358. struct my_gpio {
  359. struct gpio_chip gc;
  360. struct irq_chip irq;
  361. struct fwnode_handle *fwnode;
  362. };
  363. int irq; /* from platform etc */
  364. struct my_gpio *g;
  365. struct gpio_irq_chip *girq;
  366. /* Set up the irqchip dynamically */
  367. g->irq.name = "my_gpio_irq";
  368. g->irq.irq_ack = my_gpio_ack_irq;
  369. g->irq.irq_mask = my_gpio_mask_irq;
  370. g->irq.irq_unmask = my_gpio_unmask_irq;
  371. g->irq.irq_set_type = my_gpio_set_irq_type;
  372. /* Get a pointer to the gpio_irq_chip */
  373. girq = &g->gc.irq;
  374. girq->chip = &g->irq;
  375. girq->default_type = IRQ_TYPE_NONE;
  376. girq->handler = handle_bad_irq;
  377. girq->fwnode = g->fwnode;
  378. girq->parent_domain = parent;
  379. girq->child_to_parent_hwirq = my_gpio_child_to_parent_hwirq;
  380. return devm_gpiochip_add_data(dev, &g->gc, g);
  381. As you can see pretty similar, but you do not supply a parent handler for
  382. the IRQ, instead a parent irqdomain, an fwnode for the hardware and
  383. a funcion .child_to_parent_hwirq() that has the purpose of looking up
  384. the parent hardware irq from a child (i.e. this gpio chip) hardware irq.
  385. As always it is good to look at examples in the kernel tree for advice
  386. on how to find the required pieces.
  387. The old way of adding irqchips to gpiochips after registration is also still
  388. available but we try to move away from this:
  389. - DEPRECATED: gpiochip_irqchip_add(): adds a chained cascaded irqchip to a
  390. gpiochip. It will pass the struct gpio_chip* for the chip to all IRQ
  391. callbacks, so the callbacks need to embed the gpio_chip in its state
  392. container and obtain a pointer to the container using container_of().
  393. (See Documentation/driver-api/driver-model/design-patterns.rst)
  394. - gpiochip_irqchip_add_nested(): adds a nested cascaded irqchip to a gpiochip,
  395. as discussed above regarding different types of cascaded irqchips. The
  396. cascaded irq has to be handled by a threaded interrupt handler.
  397. Apart from that it works exactly like the chained irqchip.
  398. - gpiochip_set_nested_irqchip(): sets up a nested cascaded irq handler for a
  399. gpio_chip from a parent IRQ. As the parent IRQ has usually been
  400. explicitly requested by the driver, this does very little more than
  401. mark all the child IRQs as having the other IRQ as parent.
  402. If there is a need to exclude certain GPIO lines from the IRQ domain handled by
  403. these helpers, we can set .irq.need_valid_mask of the gpiochip before
  404. devm_gpiochip_add_data() or gpiochip_add_data() is called. This allocates an
  405. .irq.valid_mask with as many bits set as there are GPIO lines in the chip, each
  406. bit representing line 0..n-1. Drivers can exclude GPIO lines by clearing bits
  407. from this mask. The mask must be filled in before gpiochip_irqchip_add() or
  408. gpiochip_irqchip_add_nested() is called.
  409. To use the helpers please keep the following in mind:
  410. - Make sure to assign all relevant members of the struct gpio_chip so that
  411. the irqchip can initialize. E.g. .dev and .can_sleep shall be set up
  412. properly.
  413. - Nominally set all handlers to handle_bad_irq() in the setup call and pass
  414. handle_bad_irq() as flow handler parameter in gpiochip_irqchip_add() if it is
  415. expected for GPIO driver that irqchip .set_type() callback will be called
  416. before using/enabling each GPIO IRQ. Then set the handler to
  417. handle_level_irq() and/or handle_edge_irq() in the irqchip .set_type()
  418. callback depending on what your controller supports and what is requested
  419. by the consumer.
  420. Locking IRQ usage
  421. -----------------
  422. Since GPIO and irq_chip are orthogonal, we can get conflicts between different
  423. use cases. For example a GPIO line used for IRQs should be an input line,
  424. it does not make sense to fire interrupts on an output GPIO.
  425. If there is competition inside the subsystem which side is using the
  426. resource (a certain GPIO line and register for example) it needs to deny
  427. certain operations and keep track of usage inside of the gpiolib subsystem.
  428. Input GPIOs can be used as IRQ signals. When this happens, a driver is requested
  429. to mark the GPIO as being used as an IRQ::
  430. int gpiochip_lock_as_irq(struct gpio_chip *chip, unsigned int offset)
  431. This will prevent the use of non-irq related GPIO APIs until the GPIO IRQ lock
  432. is released::
  433. void gpiochip_unlock_as_irq(struct gpio_chip *chip, unsigned int offset)
  434. When implementing an irqchip inside a GPIO driver, these two functions should
  435. typically be called in the .startup() and .shutdown() callbacks from the
  436. irqchip.
  437. When using the gpiolib irqchip helpers, these callbacks are automatically
  438. assigned.
  439. Disabling and enabling IRQs
  440. ---------------------------
  441. In some (fringe) use cases, a driver may be using a GPIO line as input for IRQs,
  442. but occasionally switch that line over to drive output and then back to being
  443. an input with interrupts again. This happens on things like CEC (Consumer
  444. Electronics Control).
  445. When a GPIO is used as an IRQ signal, then gpiolib also needs to know if
  446. the IRQ is enabled or disabled. In order to inform gpiolib about this,
  447. the irqchip driver should call::
  448. void gpiochip_disable_irq(struct gpio_chip *chip, unsigned int offset)
  449. This allows drivers to drive the GPIO as an output while the IRQ is
  450. disabled. When the IRQ is enabled again, a driver should call::
  451. void gpiochip_enable_irq(struct gpio_chip *chip, unsigned int offset)
  452. When implementing an irqchip inside a GPIO driver, these two functions should
  453. typically be called in the .irq_disable() and .irq_enable() callbacks from the
  454. irqchip.
  455. When using the gpiolib irqchip helpers, these callbacks are automatically
  456. assigned.
  457. Real-Time compliance for GPIO IRQ chips
  458. ---------------------------------------
  459. Any provider of irqchips needs to be carefully tailored to support Real-Time
  460. preemption. It is desirable that all irqchips in the GPIO subsystem keep this
  461. in mind and do the proper testing to assure they are real time-enabled.
  462. So, pay attention on above realtime considerations in the documentation.
  463. The following is a checklist to follow when preparing a driver for real-time
  464. compliance:
  465. - ensure spinlock_t is not used as part irq_chip implementation
  466. - ensure that sleepable APIs are not used as part irq_chip implementation
  467. If sleepable APIs have to be used, these can be done from the .irq_bus_lock()
  468. and .irq_bus_unlock() callbacks
  469. - Chained GPIO irqchips: ensure spinlock_t or any sleepable APIs are not used
  470. from the chained IRQ handler
  471. - Generic chained GPIO irqchips: take care about generic_handle_irq() calls and
  472. apply corresponding work-around
  473. - Chained GPIO irqchips: get rid of the chained IRQ handler and use generic irq
  474. handler if possible
  475. - regmap_mmio: it is possible to disable internal locking in regmap by setting
  476. .disable_locking and handling the locking in the GPIO driver
  477. - Test your driver with the appropriate in-kernel real-time test cases for both
  478. level and edge IRQs
  479. * [1] http://www.spinics.net/lists/linux-omap/msg120425.html
  480. * [2] https://lkml.org/lkml/2015/9/25/494
  481. * [3] https://lkml.org/lkml/2015/9/25/495
  482. Requesting self-owned GPIO pins
  483. ===============================
  484. Sometimes it is useful to allow a GPIO chip driver to request its own GPIO
  485. descriptors through the gpiolib API. A GPIO driver can use the following
  486. functions to request and free descriptors::
  487. struct gpio_desc *gpiochip_request_own_desc(struct gpio_desc *desc,
  488. u16 hwnum,
  489. const char *label,
  490. enum gpiod_flags flags)
  491. void gpiochip_free_own_desc(struct gpio_desc *desc)
  492. Descriptors requested with gpiochip_request_own_desc() must be released with
  493. gpiochip_free_own_desc().
  494. These functions must be used with care since they do not affect module use
  495. count. Do not use the functions to request gpio descriptors not owned by the
  496. calling driver.