TODO 7.6 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193
  1. This is a place for planning the ongoing long-term work in the GPIO
  2. subsystem.
  3. GPIO descriptors
  4. Starting with commit 79a9becda894 the GPIO subsystem embarked on a journey
  5. to move away from the global GPIO numberspace and toward a descriptor-based
  6. approach. This means that GPIO consumers, drivers and machine descriptions
  7. ideally have no use or idea of the global GPIO numberspace that has/was
  8. used in the inception of the GPIO subsystem.
  9. The numberspace issue is the same as to why irq is moving away from irq
  10. numbers to IRQ descriptors.
  11. The underlying motivation for this is that the GPIO numberspace has become
  12. unmanageable: machine board files tend to become full of macros trying to
  13. establish the numberspace at compile-time, making it hard to add any numbers
  14. in the middle (such as if you missed a pin on a chip) without the numberspace
  15. breaking.
  16. Machine descriptions such as device tree or ACPI does not have a concept of the
  17. Linux GPIO number as those descriptions are external to the Linux kernel
  18. and treat GPIO lines as abstract entities.
  19. The runtime-assigned GPIO numberspace (what you get if you assign the GPIO
  20. base as -1 in struct gpio_chip) has also became unpredictable due to factors
  21. such as probe ordering and the introduction of -EPROBE_DEFER making probe
  22. ordering of independent GPIO chips essentially unpredictable, as their base
  23. number will be assigned on a first come first serve basis.
  24. The best way to get out of the problem is to make the global GPIO numbers
  25. unimportant by simply not using them. GPIO descriptors deal with this.
  26. Work items:
  27. - Convert all GPIO device drivers to only #include <linux/gpio/driver.h>
  28. - Convert all consumer drivers to only #include <linux/gpio/consumer.h>
  29. - Convert all machine descriptors in "boardfiles" to only
  30. #include <linux/gpio/machine.h>, the other option being to convert it
  31. to a machine description such as device tree, ACPI or fwnode that
  32. implicitly does not use global GPIO numbers.
  33. - When this work is complete (will require some of the items in the
  34. following ongoing work as well) we can delete the old global
  35. numberspace accessors from <linux/gpio.h> and eventually delete
  36. <linux/gpio.h> altogether.
  37. Get rid of <linux/of_gpio.h>
  38. This header and helpers appeared at one point when there was no proper
  39. driver infrastructure for doing simpler MMIO GPIO devices and there was
  40. no core support for parsing device tree GPIOs from the core library with
  41. the [devm_]gpiod_get() calls we have today that will implicitly go into
  42. the device tree back-end. It is legacy and should not be used in new code.
  43. Work items:
  44. - Get rid of struct of_mm_gpio_chip altogether: use the generic MMIO
  45. GPIO for all current users (see below). Delete struct of_mm_gpio_chip,
  46. to_of_mm_gpio_chip(), of_mm_gpiochip_add_data(), of_mm_gpiochip_add()
  47. of_mm_gpiochip_remove() from the kernel.
  48. - Change all consumer drivers that #include <linux/of_gpio.h> to
  49. #include <linux/gpio/consumer.h> and stop doing custom parsing of the
  50. GPIO lines from the device tree. This can be tricky and often ivolves
  51. changing boardfiles, etc.
  52. - Pull semantics for legacy device tree (OF) GPIO lookups into
  53. gpiolib-of.c: in some cases subsystems are doing custom flags and
  54. lookups for polarity inversion, open drain and what not. As we now
  55. handle this with generic OF bindings, pull all legacy handling into
  56. gpiolib so the library API becomes narrow and deep and handle all
  57. legacy bindings internally. (See e.g. commits 6953c57ab172,
  58. 6a537d48461d etc)
  59. - Delete <linux/of_gpio.h> when all the above is complete and everything
  60. uses <linux/gpio/consumer.h> or <linux/gpio/driver.h> instead.
  61. Get rid of <linux/gpio.h>
  62. This legacy header is a one stop shop for anything GPIO is closely tied
  63. to the global GPIO numberspace. The endgame of the above refactorings will
  64. be the removal of <linux/gpio.h> and from that point only the specialized
  65. headers under <linux/gpio/*.h> will be used. This requires all the above to
  66. be completed and is expected to take a long time.
  67. Collect drivers
  68. Collect GPIO drivers from arch/* and other places that should be placed
  69. in drivers/gpio/gpio-*. Augment platforms to create platform devices or
  70. similar and probe a proper driver in the gpiolib subsystem.
  71. In some cases it makes sense to create a GPIO chip from the local driver
  72. for a few GPIOs. Those should stay where they are.
  73. At the same time it makes sense to get rid of code duplication in existing or
  74. new coming drivers. For example, gpio-ml-ioh should be incorporated into
  75. gpio-pch. In similar way gpio-intel-mid into gpio-pxa.
  76. Generic MMIO GPIO
  77. The GPIO drivers can utilize the generic MMIO helper library in many
  78. cases, and the helper library should be as helpful as possible for MMIO
  79. drivers. (drivers/gpio/gpio-mmio.c)
  80. Work items:
  81. - Look over and identify any remaining easily converted drivers and
  82. dry-code conversions to MMIO GPIO for maintainers to test
  83. - Expand the MMIO GPIO or write a new library for regmap-based I/O
  84. helpers for GPIO drivers on regmap that simply use offsets
  85. 0..n in some register to drive GPIO lines
  86. - Expand the MMIO GPIO or write a new library for port-mapped I/O
  87. helpers (x86 inb()/outb()) and convert port-mapped I/O drivers to use
  88. this with dry-coding and sending to maintainers to test
  89. GPIOLIB irqchip
  90. The GPIOLIB irqchip is a helper irqchip for "simple cases" that should
  91. try to cover any generic kind of irqchip cascaded from a GPIO.
  92. - Convert all the GPIOLIB_IRQCHIP users to pass an irqchip template,
  93. parent and flags before calling [devm_]gpiochip_add[_data]().
  94. Currently we set up the irqchip after setting up the gpiochip
  95. using gpiochip_irqchip_add() and gpiochip_set_[chained|nested]_irqchip().
  96. This is too complex, so convert all users over to just set up
  97. the irqchip before registering the gpio_chip, typical example:
  98. /* Typical state container with dynamic irqchip */
  99. struct my_gpio {
  100. struct gpio_chip gc;
  101. struct irq_chip irq;
  102. };
  103. int irq; /* from platform etc */
  104. struct my_gpio *g;
  105. struct gpio_irq_chip *girq;
  106. /* Set up the irqchip dynamically */
  107. g->irq.name = "my_gpio_irq";
  108. g->irq.irq_ack = my_gpio_ack_irq;
  109. g->irq.irq_mask = my_gpio_mask_irq;
  110. g->irq.irq_unmask = my_gpio_unmask_irq;
  111. g->irq.irq_set_type = my_gpio_set_irq_type;
  112. /* Get a pointer to the gpio_irq_chip */
  113. girq = &g->gc.irq;
  114. girq->chip = &g->irq;
  115. girq->parent_handler = ftgpio_gpio_irq_handler;
  116. girq->num_parents = 1;
  117. girq->parents = devm_kcalloc(dev, 1, sizeof(*girq->parents),
  118. GFP_KERNEL);
  119. if (!girq->parents)
  120. return -ENOMEM;
  121. girq->default_type = IRQ_TYPE_NONE;
  122. girq->handler = handle_bad_irq;
  123. girq->parents[0] = irq;
  124. When this is done, we will delete the old APIs for instatiating
  125. GPIOLIB_IRQCHIP and simplify the code.
  126. - Look over and identify any remaining easily converted drivers and
  127. dry-code conversions to gpiolib irqchip for maintainers to test
  128. - Drop gpiochip_set_chained_irqchip() when all the chained irqchips
  129. have been converted to the above infrastructure.
  130. - Add more infrastructure to make it possible to also pass a threaded
  131. irqchip in struct gpio_irq_chip.
  132. - Drop gpiochip_irqchip_add_nested() when all the chained irqchips
  133. have been converted to the above infrastructure.
  134. Increase integration with pin control
  135. There are already ways to use pin control as back-end for GPIO and
  136. it may make sense to bring these subsystems closer. One reason for
  137. creating pin control as its own subsystem was that we could avoid any
  138. use of the global GPIO numbers. Once the above is complete, it may
  139. make sense to simply join the subsystems into one and make pin
  140. multiplexing, pin configuration, GPIO, etc selectable options in one
  141. and the same pin control and GPIO subsystem.