212 lines · plain
1This is a place for planning the ongoing long-term work in the GPIO2subsystem.3 4 5GPIO descriptors6 7Starting with commit 79a9becda894 the GPIO subsystem embarked on a journey8to move away from the global GPIO numberspace and toward a descriptor-based9approach. This means that GPIO consumers, drivers and machine descriptions10ideally have no use or idea of the global GPIO numberspace that has/was11used in the inception of the GPIO subsystem.12 13The numberspace issue is the same as to why irq is moving away from irq14numbers to IRQ descriptors.15 16The underlying motivation for this is that the GPIO numberspace has become17unmanageable: machine board files tend to become full of macros trying to18establish the numberspace at compile-time, making it hard to add any numbers19in the middle (such as if you missed a pin on a chip) without the numberspace20breaking.21 22Machine descriptions such as device tree or ACPI does not have a concept of the23Linux GPIO number as those descriptions are external to the Linux kernel24and treat GPIO lines as abstract entities.25 26The runtime-assigned GPIO numberspace (what you get if you assign the GPIO27base as -1 in struct gpio_chip) has also became unpredictable due to factors28such as probe ordering and the introduction of -EPROBE_DEFER making probe29ordering of independent GPIO chips essentially unpredictable, as their base30number will be assigned on a first come first serve basis.31 32The best way to get out of the problem is to make the global GPIO numbers33unimportant by simply not using them. GPIO descriptors deal with this.34 35Work items:36 37- Convert all GPIO device drivers to only #include <linux/gpio/driver.h>38 39- Convert all consumer drivers to only #include <linux/gpio/consumer.h>40 41- Convert all machine descriptors in "boardfiles" to only42 #include <linux/gpio/machine.h>, the other option being to convert it43 to a machine description such as device tree, ACPI or fwnode that44 implicitly does not use global GPIO numbers.45 46- When this work is complete (will require some of the items in the47 following ongoing work as well) we can delete the old global48 numberspace accessors from <linux/gpio.h> and eventually delete49 <linux/gpio.h> altogether.50 51 52Get rid of <linux/of_gpio.h>53 54This header and helpers appeared at one point when there was no proper55driver infrastructure for doing simpler MMIO GPIO devices and there was56no core support for parsing device tree GPIOs from the core library with57the [devm_]gpiod_get() calls we have today that will implicitly go into58the device tree back-end. It is legacy and should not be used in new code.59 60Work items:61 62- Change all consumer drivers that #include <linux/of_gpio.h> to63 #include <linux/gpio/consumer.h> and stop doing custom parsing of the64 GPIO lines from the device tree. This can be tricky and often ivolves65 changing boardfiles, etc.66 67- Pull semantics for legacy device tree (OF) GPIO lookups into68 gpiolib-of.c: in some cases subsystems are doing custom flags and69 lookups for polarity inversion, open drain and what not. As we now70 handle this with generic OF bindings, pull all legacy handling into71 gpiolib so the library API becomes narrow and deep and handle all72 legacy bindings internally. (See e.g. commits 6953c57ab172,73 6a537d48461d etc)74 75- Delete <linux/of_gpio.h> when all the above is complete and everything76 uses <linux/gpio/consumer.h> or <linux/gpio/driver.h> instead.77 78 79Get rid of <linux/gpio/legacy-of-mm-gpiochip.h>80 81Work items:82 83- Get rid of struct of_mm_gpio_chip altogether: use the generic MMIO84 GPIO for all current users (see below). Delete struct of_mm_gpio_chip,85 to_of_mm_gpio_chip(), of_mm_gpiochip_add_data(), of_mm_gpiochip_remove(),86 CONFIG_OF_GPIO_MM_GPIOCHIP from the kernel.87 88 89Get rid of <linux/gpio.h>90 91This legacy header is a one stop shop for anything GPIO is closely tied92to the global GPIO numberspace. The endgame of the above refactorings will93be the removal of <linux/gpio.h> and from that point only the specialized94headers under <linux/gpio/*.h> will be used. This requires all the above to95be completed and is expected to take a long time.96 97 98Collect drivers99 100Collect GPIO drivers from arch/* and other places that should be placed101in drivers/gpio/gpio-*. Augment platforms to create platform devices or102similar and probe a proper driver in the gpiolib subsystem.103 104In some cases it makes sense to create a GPIO chip from the local driver105for a few GPIOs. Those should stay where they are.106 107At the same time it makes sense to get rid of code duplication in existing or108new coming drivers. For example, gpio-ml-ioh should be incorporated into109gpio-pch.110 111 112Generic MMIO GPIO113 114The GPIO drivers can utilize the generic MMIO helper library in many115cases, and the helper library should be as helpful as possible for MMIO116drivers. (drivers/gpio/gpio-mmio.c)117 118Work items:119 120- Look over and identify any remaining easily converted drivers and121 dry-code conversions to MMIO GPIO for maintainers to test122 123- Expand the MMIO GPIO or write a new library for regmap-based I/O124 helpers for GPIO drivers on regmap that simply use offsets125 0..n in some register to drive GPIO lines126 127- Expand the MMIO GPIO or write a new library for port-mapped I/O128 helpers (x86 inb()/outb()) and convert port-mapped I/O drivers to use129 this with dry-coding and sending to maintainers to test130 131 132Generic regmap GPIO133 134In the very similar way to Generic MMIO GPIO convert the users which can135take advantage of using regmap over direct IO accessors. Note, even in136MMIO case the regmap MMIO with gpio-regmap.c is preferable over gpio-mmio.c.137 138 139GPIOLIB irqchip140 141The GPIOLIB irqchip is a helper irqchip for "simple cases" that should142try to cover any generic kind of irqchip cascaded from a GPIO.143 144- Look over and identify any remaining easily converted drivers and145 dry-code conversions to gpiolib irqchip for maintainers to test146 147 148Increase integration with pin control149 150There are already ways to use pin control as back-end for GPIO and151it may make sense to bring these subsystems closer. One reason for152creating pin control as its own subsystem was that we could avoid any153use of the global GPIO numbers. Once the above is complete, it may154make sense to simply join the subsystems into one and make pin155multiplexing, pin configuration, GPIO, etc selectable options in one156and the same pin control and GPIO subsystem.157 158 159Debugfs in place of sysfs160 161The old sysfs code that enables simple uses of GPIOs from the162command line is still popular despite the existance of the proper163character device. The reason is that it is simple to use on164root filesystems where you only have a minimal set of tools such165as "cat", "echo" etc.166 167The old sysfs still need to be strongly deprecated and removed168as it relies on the global GPIO numberspace that assume a strict169order of global GPIO numbers that do not change between boots170and is independent of probe order.171 172To solve this and provide an ABI that people can use for hacks173and development, implement a debugfs interface to manipulate174GPIO lines that can do everything that sysfs can do today: one175directory per gpiochip and one file entry per line:176 177/sys/kernel/debug/gpiochip/gpiochip0178/sys/kernel/debug/gpiochip/gpiochip0/gpio0179/sys/kernel/debug/gpiochip/gpiochip0/gpio1180/sys/kernel/debug/gpiochip/gpiochip0/gpio2181/sys/kernel/debug/gpiochip/gpiochip0/gpio3182...183/sys/kernel/debug/gpiochip/gpiochip1184/sys/kernel/debug/gpiochip/gpiochip1/gpio0185/sys/kernel/debug/gpiochip/gpiochip1/gpio1186...187 188The exact files and design of the debugfs interface can be189discussed but the idea is to provide a low-level access point190for debugging and hacking and to expose all lines without the191need of any exporting. Also provide ample ammunition to shoot192oneself in the foot, because this is debugfs after all.193 194 195Moving over to immutable irq_chip structures196 197Most of the gpio chips implementing interrupt support rely on gpiolib198intercepting some of the irq_chip callbacks, preventing the structures199from being made read-only and forcing duplication of structures that200should otherwise be unique.201 202The solution is to call into the gpiolib code when needed (resource203management, enable/disable or unmask/mask callbacks), and to let the204core code know about that by exposing a flag (IRQCHIP_IMMUTABLE) in205the irq_chip structure. The irq_chip structure can then be made unique206and const.207 208A small number of drivers have been converted (pl061, tegra186, msm,209amd, apple), and can be used as examples of how to proceed with this210conversion. Note that drivers using the generic irqchip framework211cannot be converted yet, but watch this space!212