drivers/gpio/TODO

   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 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
  87 - Expand the MMIO GPIO or write a new library for port-mapped I/O
  88   helpers (x86 inb()/outb()) and convert port-mapped I/O drivers to use
  89   this with dry-coding and sending to maintainers to test
  90
  91
  92 GPIOLIB irqchip
  93
  94 The GPIOLIB irqchip is a helper irqchip for "simple cases" that should
  95 try to cover any generic kind of irqchip cascaded from a GPIO.
  96
  97 - Convert all the GPIOLIB_IRQCHIP users to pass an irqchip template,
  98   parent and flags before calling [devm_]gpiochip_add[_data]().
  99   Currently we set up the irqchip after setting up the gpiochip
 100   using gpiochip_irqchip_add() and gpiochip_set_[chained|nested]_irqchip().
 101   This is too complex, so convert all users over to just set up
 102   the irqchip before registering the gpio_chip, typical example:
 103
 104   /* Typical state container with dynamic irqchip */
 105   struct my_gpio {
 106       struct gpio_chip gc;
 107       struct irq_chip irq;
 108   };
 109
 110   int irq; /* from platform etc */
 111   struct my_gpio *g;
 112   struct gpio_irq_chip *girq
 113
 114   /* Set up the irqchip dynamically */
 115   g->irq.name = "my_gpio_irq";
 116   g->irq.irq_ack = my_gpio_ack_irq;
 117   g->irq.irq_mask = my_gpio_mask_irq;
 118   g->irq.irq_unmask = my_gpio_unmask_irq;
 119   g->irq.irq_set_type = my_gpio_set_irq_type;
 120
 121   /* Get a pointer to the gpio_irq_chip */
 122   girq = &g->gc.irq;
 123   girq->chip = &g->irq;
 124   girq->parent_handler = ftgpio_gpio_irq_handler;
 125   girq->num_parents = 1;
 126   girq->parents = devm_kcalloc(dev, 1, sizeof(*girq->parents),
 127                                GFP_KERNEL);
 128   if (!girq->parents)
 129       return -ENOMEM;
 130   girq->default_type = IRQ_TYPE_NONE;
 131   girq->handler = handle_bad_irq;
 132   girq->parents[0] = irq;
 133
 134   When this is done, we will delete the old APIs for instatiating
 135   GPIOLIB_IRQCHIP and simplify the code.
 136
 137 - Look over and identify any remaining easily converted drivers and
 138   dry-code conversions to gpiolib irqchip for maintainers to test
 139
 140 - Support generic hierarchical GPIO interrupts: these are for the
 141   non-cascading case where there is one IRQ per GPIO line, there is
 142   currently no common infrastructure for this.
 143
 144
 145 Increase integration with pin control
 146
 147 There are already ways to use pin control as back-end for GPIO and
 148 it may make sense to bring these subsystems closer. One reason for
 149 creating pin control as its own subsystem was that we could avoid any
 150 use of the global GPIO numbers. Once the above is complete, it may
 151 make sense to simply join the subsystems into one and make pin
 152 multiplexing, pin configuration, GPIO, etc selectable options in one
 153 and the same pin control and GPIO subsystem.