^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) This is a place for planning the ongoing long-term work in the GPIO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2) subsystem.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) GPIO descriptors
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) Starting with commit 79a9becda894 the GPIO subsystem embarked on a journey
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) to move away from the global GPIO numberspace and toward a descriptor-based
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) approach. This means that GPIO consumers, drivers and machine descriptions
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10) ideally have no use or idea of the global GPIO numberspace that has/was
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) used in the inception of the GPIO subsystem.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) The numberspace issue is the same as to why irq is moving away from irq
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) numbers to IRQ descriptors.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) The underlying motivation for this is that the GPIO numberspace has become
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) unmanageable: machine board files tend to become full of macros trying to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18) establish the numberspace at compile-time, making it hard to add any numbers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) in the middle (such as if you missed a pin on a chip) without the numberspace
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) breaking.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) Machine descriptions such as device tree or ACPI does not have a concept of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) Linux GPIO number as those descriptions are external to the Linux kernel
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) and treat GPIO lines as abstract entities.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) The runtime-assigned GPIO numberspace (what you get if you assign the GPIO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) base as -1 in struct gpio_chip) has also became unpredictable due to factors
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) such as probe ordering and the introduction of -EPROBE_DEFER making probe
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29) ordering of independent GPIO chips essentially unpredictable, as their base
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) number will be assigned on a first come first serve basis.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) The best way to get out of the problem is to make the global GPIO numbers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) unimportant by simply not using them. GPIO descriptors deal with this.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) Work items:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) - Convert all GPIO device drivers to only #include <linux/gpio/driver.h>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) - Convert all consumer drivers to only #include <linux/gpio/consumer.h>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) - Convert all machine descriptors in "boardfiles" to only
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) #include <linux/gpio/machine.h>, the other option being to convert it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43) to a machine description such as device tree, ACPI or fwnode that
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) implicitly does not use global GPIO numbers.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) - When this work is complete (will require some of the items in the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) following ongoing work as well) we can delete the old global
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) numberspace accessors from <linux/gpio.h> and eventually delete
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) <linux/gpio.h> altogether.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52) Get rid of <linux/of_gpio.h>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) This header and helpers appeared at one point when there was no proper
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) driver infrastructure for doing simpler MMIO GPIO devices and there was
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56) no core support for parsing device tree GPIOs from the core library with
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) the [devm_]gpiod_get() calls we have today that will implicitly go into
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58) the device tree back-end. It is legacy and should not be used in new code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) Work items:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) - Get rid of struct of_mm_gpio_chip altogether: use the generic MMIO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) GPIO for all current users (see below). Delete struct of_mm_gpio_chip,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) to_of_mm_gpio_chip(), of_mm_gpiochip_add_data(), of_mm_gpiochip_add()
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) of_mm_gpiochip_remove() from the kernel.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) - Change all consumer drivers that #include <linux/of_gpio.h> to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) #include <linux/gpio/consumer.h> and stop doing custom parsing of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) GPIO lines from the device tree. This can be tricky and often ivolves
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) changing boardfiles, etc.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) - Pull semantics for legacy device tree (OF) GPIO lookups into
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) gpiolib-of.c: in some cases subsystems are doing custom flags and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) lookups for polarity inversion, open drain and what not. As we now
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) handle this with generic OF bindings, pull all legacy handling into
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76) gpiolib so the library API becomes narrow and deep and handle all
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) legacy bindings internally. (See e.g. commits 6953c57ab172,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) 6a537d48461d etc)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) - Delete <linux/of_gpio.h> when all the above is complete and everything
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) uses <linux/gpio/consumer.h> or <linux/gpio/driver.h> instead.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) Get rid of <linux/gpio.h>
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) This legacy header is a one stop shop for anything GPIO is closely tied
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) to the global GPIO numberspace. The endgame of the above refactorings will
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) be the removal of <linux/gpio.h> and from that point only the specialized
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) headers under <linux/gpio/*.h> will be used. This requires all the above to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) be completed and is expected to take a long time.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93) Collect drivers
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) Collect GPIO drivers from arch/* and other places that should be placed
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) in drivers/gpio/gpio-*. Augment platforms to create platform devices or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) similar and probe a proper driver in the gpiolib subsystem.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) In some cases it makes sense to create a GPIO chip from the local driver
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) for a few GPIOs. Those should stay where they are.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) At the same time it makes sense to get rid of code duplication in existing or
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) new coming drivers. For example, gpio-ml-ioh should be incorporated into
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) gpio-pch. In similar way gpio-intel-mid into gpio-pxa.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) Generic MMIO GPIO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) The GPIO drivers can utilize the generic MMIO helper library in many
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) cases, and the helper library should be as helpful as possible for MMIO
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) drivers. (drivers/gpio/gpio-mmio.c)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113) Work items:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115) - Look over and identify any remaining easily converted drivers and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) dry-code conversions to MMIO GPIO for maintainers to test
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) - Expand the MMIO GPIO or write a new library for regmap-based I/O
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) helpers for GPIO drivers on regmap that simply use offsets
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) 0..n in some register to drive GPIO lines
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) - Expand the MMIO GPIO or write a new library for port-mapped I/O
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) helpers (x86 inb()/outb()) and convert port-mapped I/O drivers to use
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) this with dry-coding and sending to maintainers to test
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) GPIOLIB irqchip
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) The GPIOLIB irqchip is a helper irqchip for "simple cases" that should
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) try to cover any generic kind of irqchip cascaded from a GPIO.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132) - Convert all the GPIOLIB_IRQCHIP users to pass an irqchip template,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) parent and flags before calling [devm_]gpiochip_add[_data]().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) Currently we set up the irqchip after setting up the gpiochip
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135) using gpiochip_irqchip_add() and gpiochip_set_[chained|nested]_irqchip().
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) This is too complex, so convert all users over to just set up
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) the irqchip before registering the gpio_chip, typical example:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) /* Typical state container with dynamic irqchip */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) struct my_gpio {
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141) struct gpio_chip gc;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) struct irq_chip irq;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) };
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) int irq; /* from platform etc */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) struct my_gpio *g;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) struct gpio_irq_chip *girq;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) /* Set up the irqchip dynamically */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150) g->irq.name = "my_gpio_irq";
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) g->irq.irq_ack = my_gpio_ack_irq;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) g->irq.irq_mask = my_gpio_mask_irq;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) g->irq.irq_unmask = my_gpio_unmask_irq;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) g->irq.irq_set_type = my_gpio_set_irq_type;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) /* Get a pointer to the gpio_irq_chip */
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) girq = &g->gc.irq;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) girq->chip = &g->irq;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) girq->parent_handler = ftgpio_gpio_irq_handler;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160) girq->num_parents = 1;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) girq->parents = devm_kcalloc(dev, 1, sizeof(*girq->parents),
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) GFP_KERNEL);
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163) if (!girq->parents)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) return -ENOMEM;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) girq->default_type = IRQ_TYPE_NONE;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) girq->handler = handle_bad_irq;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167) girq->parents[0] = irq;
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) When this is done, we will delete the old APIs for instatiating
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) GPIOLIB_IRQCHIP and simplify the code.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) - Look over and identify any remaining easily converted drivers and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) dry-code conversions to gpiolib irqchip for maintainers to test
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175) - Drop gpiochip_set_chained_irqchip() when all the chained irqchips
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) have been converted to the above infrastructure.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) - Add more infrastructure to make it possible to also pass a threaded
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) irqchip in struct gpio_irq_chip.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) - Drop gpiochip_irqchip_add_nested() when all the chained irqchips
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182) have been converted to the above infrastructure.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185) Increase integration with pin control
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) There are already ways to use pin control as back-end for GPIO and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) it may make sense to bring these subsystems closer. One reason for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) creating pin control as its own subsystem was that we could avoid any
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) use of the global GPIO numbers. Once the above is complete, it may
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191) make sense to simply join the subsystems into one and make pin
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) multiplexing, pin configuration, GPIO, etc selectable options in one
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) and the same pin control and GPIO subsystem.
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags