diff options
Diffstat (limited to 'drivers/gpio/TODO')
| -rw-r--r-- | drivers/gpio/TODO | 153 |
1 files changed, 81 insertions, 72 deletions
diff --git a/drivers/gpio/TODO b/drivers/gpio/TODO index b989c9352da2..5acaeab029ec 100644 --- a/drivers/gpio/TODO +++ b/drivers/gpio/TODO @@ -1,11 +1,12 @@ This is a place for planning the ongoing long-term work in the GPIO subsystem. +=============================================================================== GPIO descriptors Starting with commit 79a9becda894 the GPIO subsystem embarked on a journey -to move away from the global GPIO numberspace and toward a decriptor-based +to move away from the global GPIO numberspace and toward a descriptor-based approach. This means that GPIO consumers, drivers and machine descriptions ideally have no use or idea of the global GPIO numberspace that has/was used in the inception of the GPIO subsystem. @@ -43,11 +44,19 @@ Work items: to a machine description such as device tree, ACPI or fwnode that implicitly does not use global GPIO numbers. +- Fix drivers to not read back struct gpio_chip::base. Some drivers do + that and would be broken by attempts to poison it or make it dynamic. + Example in AT91 pinctrl driver: + https://lore.kernel.org/all/1d00c056-3d61-4c22-bedd-3bae0bf1ddc4@pengutronix.de/ + This particular driver is also DT-only, so with the above fixed, the + base can be made dynamic (set to -1) if CONFIG_GPIO_SYSFS is disabled. + - When this work is complete (will require some of the items in the following ongoing work as well) we can delete the old global numberspace accessors from <linux/gpio.h> and eventually delete <linux/gpio.h> altogether. +------------------------------------------------------------------------------- Get rid of <linux/of_gpio.h> @@ -59,15 +68,10 @@ the device tree back-end. It is legacy and should not be used in new code. Work items: -- Get rid of struct of_mm_gpio_chip altogether: use the generic MMIO - GPIO for all current users (see below). Delete struct of_mm_gpio_chip, - to_of_mm_gpio_chip(), of_mm_gpiochip_add_data(), of_mm_gpiochip_add() - of_mm_gpiochip_remove() from the kernel. - - Change all consumer drivers that #include <linux/of_gpio.h> to #include <linux/gpio/consumer.h> and stop doing custom parsing of the - GPIO lines from the device tree. This can be tricky and often ivolves - changing boardfiles, etc. + GPIO lines from the device tree. This can be tricky and often involves + changing board files, etc. - Pull semantics for legacy device tree (OF) GPIO lookups into gpiolib-of.c: in some cases subsystems are doing custom flags and @@ -80,15 +84,7 @@ Work items: - Delete <linux/of_gpio.h> when all the above is complete and everything uses <linux/gpio/consumer.h> or <linux/gpio/driver.h> instead. - -Get rid of <linux/gpio.h> - -This legacy header is a one stop shop for anything GPIO is closely tied -to the global GPIO numberspace. The endgame of the above refactorings will -be the removal of <linux/gpio.h> and from that point only the specialized -headers under <linux/gpio/*.h> will be used. This requires all the above to -be completed and is expected to take a long time. - +------------------------------------------------------------------------------- Collect drivers @@ -101,8 +97,9 @@ for a few GPIOs. Those should stay where they are. At the same time it makes sense to get rid of code duplication in existing or new coming drivers. For example, gpio-ml-ioh should be incorporated into -gpio-pch. In similar way gpio-intel-mid into gpio-pxa. +gpio-pch. +------------------------------------------------------------------------------- Generic MMIO GPIO @@ -123,71 +120,83 @@ Work items: helpers (x86 inb()/outb()) and convert port-mapped I/O drivers to use this with dry-coding and sending to maintainers to test +------------------------------------------------------------------------------- + +Generic regmap GPIO + +In the very similar way to Generic MMIO GPIO convert the users which can +take advantage of using regmap over direct IO accessors. Note, even in +MMIO case the regmap MMIO with gpio-regmap.c is preferable over gpio-mmio.c. + +------------------------------------------------------------------------------- GPIOLIB irqchip The GPIOLIB irqchip is a helper irqchip for "simple cases" that should try to cover any generic kind of irqchip cascaded from a GPIO. -- Convert all the GPIOLIB_IRQCHIP users to pass an irqchip template, - parent and flags before calling [devm_]gpiochip_add[_data](). - Currently we set up the irqchip after setting up the gpiochip - using gpiochip_irqchip_add() and gpiochip_set_[chained|nested]_irqchip(). - This is too complex, so convert all users over to just set up - the irqchip before registering the gpio_chip, typical example: - - /* Typical state container with dynamic irqchip */ - struct my_gpio { - struct gpio_chip gc; - struct irq_chip irq; - }; - - int irq; /* from platform etc */ - struct my_gpio *g; - struct gpio_irq_chip *girq; - - /* Set up the irqchip dynamically */ - g->irq.name = "my_gpio_irq"; - g->irq.irq_ack = my_gpio_ack_irq; - g->irq.irq_mask = my_gpio_mask_irq; - g->irq.irq_unmask = my_gpio_unmask_irq; - g->irq.irq_set_type = my_gpio_set_irq_type; - - /* Get a pointer to the gpio_irq_chip */ - girq = &g->gc.irq; - girq->chip = &g->irq; - girq->parent_handler = ftgpio_gpio_irq_handler; - girq->num_parents = 1; - girq->parents = devm_kcalloc(dev, 1, sizeof(*girq->parents), - GFP_KERNEL); - if (!girq->parents) - return -ENOMEM; - girq->default_type = IRQ_TYPE_NONE; - girq->handler = handle_bad_irq; - girq->parents[0] = irq; - - When this is done, we will delete the old APIs for instatiating - GPIOLIB_IRQCHIP and simplify the code. - - Look over and identify any remaining easily converted drivers and dry-code conversions to gpiolib irqchip for maintainers to test -- Drop gpiochip_set_chained_irqchip() when all the chained irqchips - have been converted to the above infrastructure. +------------------------------------------------------------------------------- + +Moving over to immutable irq_chip structures + +Most of the gpio chips implementing interrupt support rely on gpiolib +intercepting some of the irq_chip callbacks, preventing the structures +from being made read-only and forcing duplication of structures that +should otherwise be unique. + +The solution is to call into the gpiolib code when needed (resource +management, enable/disable or unmask/mask callbacks), and to let the +core code know about that by exposing a flag (IRQCHIP_IMMUTABLE) in +the irq_chip structure. The irq_chip structure can then be made unique +and const. + +A small number of drivers have been converted (pl061, tegra186, msm, +amd, apple), and can be used as examples of how to proceed with this +conversion. Note that drivers using the generic irqchip framework +cannot be converted yet, but watch this space! + +------------------------------------------------------------------------------- + +Remove legacy sysfs features + +We have two parallel per-chip class devices and per-exported-line attribute +groups in sysfs. One is using the obsolete global GPIO numberspace and the +second relies on hardware offsets of pins within the chip. Remove the former +once user-space has switched to using the latter. + +------------------------------------------------------------------------------- + +Remove GPIOD_FLAGS_BIT_NONEXCLUSIVE + +GPIOs in the linux kernel are meant to be an exclusive resource. This means +that the GPIO descriptors (the software representation of the hardware concept) +are not reference counted and - in general - only one user at a time can +request a GPIO line and control its settings. The consumer API is designed +around full control of the line's state as evidenced by the fact that, for +instance, gpiod_set_value() does indeed drive the line as requested, instead +of bumping an enable counter of some sort. -- Add more infrastructure to make it possible to also pass a threaded - irqchip in struct gpio_irq_chip. +A problematic use-case for GPIOs is when two consumers want to use the same +descriptor independently. An example of such a user is the regulator subsystem +which may instantiate several struct regulator_dev instances containing +a struct device but using the same enable GPIO line. -- Drop gpiochip_irqchip_add_nested() when all the chained irqchips - have been converted to the above infrastructure. +A workaround was introduced in the form of the GPIOD_FLAGS_BIT_NONEXCLUSIVE +flag but its implementation is problematic: it does not provide any +synchronization of usage nor did it introduce any enable count meaning the +non-exclusive users of the same descriptor will in fact "fight" for the +control over it. This flag should be removed and replaced with a better +solution, possibly based on the new power sequencing subsystem. +------------------------------------------------------------------------------- -Increase integration with pin control +Remove devm_gpiod_unhinge() -There are already ways to use pin control as back-end for GPIO and -it may make sense to bring these subsystems closer. One reason for -creating pin control as its own subsystem was that we could avoid any -use of the global GPIO numbers. Once the above is complete, it may -make sense to simply join the subsystems into one and make pin -multiplexing, pin configuration, GPIO, etc selectable options in one -and the same pin control and GPIO subsystem. +devm_gpiod_unhinge() is provided as a way to transfer the ownership of managed +enable GPIOs to the regulator core. Rather than doing that however, we should +make it possible for the regulator subsystem to deal with GPIO resources the +lifetime of which it doesn't control as logically, a GPIO obtained by a caller +should also be freed by it. |