Commit | Line | Data |
---|---|---|
2646b90d LW |
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. |