| Linus Walleij | 2646b90 | 2018-10-26 10:41:22 +0200 | [diff] [blame] | 1 | This is a place for planning the ongoing long-term work in the GPIO |
| 2 | subsystem. |
| 3 | |
| 4 | |
| 5 | GPIO descriptors |
| 6 | |
| 7 | Starting with commit 79a9becda894 the GPIO subsystem embarked on a journey |
| 8 | to move away from the global GPIO numberspace and toward a decriptor-based |
| 9 | approach. This means that GPIO consumers, drivers and machine descriptions |
| 10 | ideally have no use or idea of the global GPIO numberspace that has/was |
| 11 | used in the inception of the GPIO subsystem. |
| 12 | |
| 13 | Work items: |
| 14 | |
| 15 | - Convert all GPIO device drivers to only #include <linux/gpio/driver.h> |
| 16 | |
| 17 | - Convert all consumer drivers to only #include <linux/gpio/consumer.h> |
| 18 | |
| 19 | - Convert all machine descriptors in "boardfiles" to only |
| 20 | #include <linux/gpio/machine.h>, the other option being to convert it |
| 21 | to a machine description such as device tree, ACPI or fwnode that |
| 22 | implicitly does not use global GPIO numbers. |
| 23 | |
| 24 | - When this work is complete (will require some of the items in the |
| 25 | following ongoing work as well) we can delete the old global |
| 26 | numberspace accessors from <linux/gpio.h> and eventually delete |
| 27 | <linux/gpio.h> altogether. |
| 28 | |
| 29 | |
| 30 | Get rid of <linux/of_gpio.h> |
| 31 | |
| 32 | This header and helpers appeared at one point when there was no proper |
| 33 | driver infrastructure for doing simpler MMIO GPIO devices and there was |
| 34 | no core support for parsing device tree GPIOs from the core library with |
| 35 | the [devm_]gpiod_get() calls we have today that will implicitly go into |
| 36 | the device tree back-end. |
| 37 | |
| 38 | Work items: |
| 39 | |
| 40 | - Get rid of struct of_mm_gpio_chip altogether: use the generic MMIO |
| 41 | GPIO for all current users (see below). Delete struct of_mm_gpio_chip, |
| 42 | to_of_mm_gpio_chip(), of_mm_gpiochip_add_data(), of_mm_gpiochip_add() |
| 43 | of_mm_gpiochip_remove() from the kernel. |
| 44 | |
| 45 | - Change all consumer drivers that #include <linux/of_gpio.h> to |
| 46 | #include <linux/gpio/consumer.h> and stop doing custom parsing of the |
| 47 | GPIO lines from the device tree. This can be tricky and often ivolves |
| 48 | changing boardfiles, etc. |
| 49 | |
| 50 | - Pull semantics for legacy device tree (OF) GPIO lookups into |
| 51 | gpiolib-of.c: in some cases subsystems are doing custom flags and |
| 52 | lookups for polarity inversion, open drain and what not. As we now |
| 53 | handle this with generic OF bindings, pull all legacy handling into |
| 54 | gpiolib so the library API becomes narrow and deep and handle all |
| 55 | legacy bindings internally. (See e.g. commits 6953c57ab172, |
| 56 | 6a537d48461d etc) |
| 57 | |
| 58 | - Delete <linux/of_gpio.h> when all the above is complete and everything |
| 59 | uses <linux/gpio/consumer.h> or <linux/gpio/driver.h> instead. |
| 60 | |
| 61 | |
| 62 | Collect drivers |
| 63 | |
| 64 | Collect GPIO drivers from arch/* and other places that should be placed |
| 65 | in drivers/gpio/gpio-*. Augment platforms to create platform devices or |
| 66 | similar and probe a proper driver in the gpiolib subsystem. |
| 67 | |
| 68 | In some cases it makes sense to create a GPIO chip from the local driver |
| 69 | for a few GPIOs. Those should stay where they are. |
| 70 | |
| 71 | |
| 72 | Generic MMIO GPIO |
| 73 | |
| 74 | The GPIO drivers can utilize the generic MMIO helper library in many |
| 75 | cases, and the helper library should be as helpful as possible for MMIO |
| 76 | drivers. (drivers/gpio/gpio-mmio.c) |
| 77 | |
| 78 | Work items: |
| 79 | |
| 80 | - Look over and identify any remaining easily converted drivers and |
| 81 | dry-code conversions to MMIO GPIO for maintainers to test |
| 82 | |
| 83 | - Expand the MMIO GPIO or write a new library for port-mapped I/O |
| 84 | helpers (x86 inb()/outb()) and convert port-mapped I/O drivers to use |
| 85 | this with dry-coding and sending to maintainers to test |
| 86 | |
| 87 | |
| 88 | GPIOLIB irqchip |
| 89 | |
| 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 | |
| 93 | - Look over and identify any remaining easily converted drivers and |
| 94 | dry-code conversions to gpiolib irqchip for maintainers to test |
| 95 | |
| 96 | - Support generic hierarchical GPIO interrupts: these are for the |
| 97 | non-cascading case where there is one IRQ per GPIO line, there is |
| 98 | currently no common infrastructure for this. |
| 99 | |
| 100 | |
| 101 | Increase integration with pin control |
| 102 | |
| 103 | There are already ways to use pin control as back-end for GPIO and |
| 104 | it may make sense to bring these subsystems closer. One reason for |
| 105 | creating pin control as its own subsystem was that we could avoid any |
| 106 | use of the global GPIO numbers. Once the above is complete, it may |
| 107 | make sense to simply join the subsystems into one and make pin |
| 108 | multiplexing, pin configuration, GPIO, etc selectable options in one |
| 109 | and the same pin control and GPIO subsystem. |