Lines Matching +full:tegra186 +full:- +full:gpio
1 This is a place for planning the ongoing long-term work in the GPIO
6 GPIO descriptors
8 Starting with commit 79a9becda894 the GPIO subsystem embarked on a journey
9 to move away from the global GPIO numberspace and toward a descriptor-based
10 approach. This means that GPIO consumers, drivers and machine descriptions
11 ideally have no use or idea of the global GPIO numberspace that has/was
12 used in the inception of the GPIO subsystem.
17 The underlying motivation for this is that the GPIO numberspace has become
19 establish the numberspace at compile-time, making it hard to add any numbers
24 Linux GPIO number as those descriptions are external to the Linux kernel
25 and treat GPIO lines as abstract entities.
27 The runtime-assigned GPIO numberspace (what you get if you assign the GPIO
28 base as -1 in struct gpio_chip) has also became unpredictable due to factors
29 such as probe ordering and the introduction of -EPROBE_DEFER making probe
30 ordering of independent GPIO chips essentially unpredictable, as their base
33 The best way to get out of the problem is to make the global GPIO numbers
34 unimportant by simply not using them. GPIO descriptors deal with this.
38 - Convert all GPIO device drivers to only #include <linux/gpio/driver.h>
40 - Convert all consumer drivers to only #include <linux/gpio/consumer.h>
42 - Convert all machine descriptors in "boardfiles" to only
43 #include <linux/gpio/machine.h>, the other option being to convert it
45 implicitly does not use global GPIO numbers.
47 - Fix drivers to not read back struct gpio_chip::base. Some drivers do
50 https://lore.kernel.org/all/1d00c056-3d61-4c22-bedd-3bae0bf1ddc4@pengutronix.de/
51 This particular driver is also DT-only, so with the above fixed, the
52 base can be made dynamic (set to -1) if CONFIG_GPIO_SYSFS is disabled.
54 - When this work is complete (will require some of the items in the
56 numberspace accessors from <linux/gpio.h> and eventually delete
57 <linux/gpio.h> altogether.
59 -------------------------------------------------------------------------------
64 driver infrastructure for doing simpler MMIO GPIO devices and there was
67 the device tree back-end. It is legacy and should not be used in new code.
71 - Change all consumer drivers that #include <linux/of_gpio.h> to
72 #include <linux/gpio/consumer.h> and stop doing custom parsing of the
73 GPIO lines from the device tree. This can be tricky and often involves
76 - Pull semantics for legacy device tree (OF) GPIO lookups into
77 gpiolib-of.c: in some cases subsystems are doing custom flags and
84 - Delete <linux/of_gpio.h> when all the above is complete and everything
85 uses <linux/gpio/consumer.h> or <linux/gpio/driver.h> instead.
87 -------------------------------------------------------------------------------
89 Get rid of <linux/gpio/legacy-of-mm-gpiochip.h>
93 - Get rid of struct of_mm_gpio_chip altogether: use the generic MMIO
94 GPIO for all current users (see below). Delete struct of_mm_gpio_chip,
98 -------------------------------------------------------------------------------
102 Collect GPIO drivers from arch/* and other places that should be placed
103 in drivers/gpio/gpio-*. Augment platforms to create platform devices or
106 In some cases it makes sense to create a GPIO chip from the local driver
110 new coming drivers. For example, gpio-ml-ioh should be incorporated into
111 gpio-pch.
113 -------------------------------------------------------------------------------
115 Generic MMIO GPIO
117 The GPIO drivers can utilize the generic MMIO helper library in many
119 drivers. (drivers/gpio/gpio-mmio.c)
123 - Look over and identify any remaining easily converted drivers and
124 dry-code conversions to MMIO GPIO for maintainers to test
126 - Expand the MMIO GPIO or write a new library for regmap-based I/O
127 helpers for GPIO drivers on regmap that simply use offsets
128 0..n in some register to drive GPIO lines
130 - Expand the MMIO GPIO or write a new library for port-mapped I/O
131 helpers (x86 inb()/outb()) and convert port-mapped I/O drivers to use
132 this with dry-coding and sending to maintainers to test
134 - Move the MMIO GPIO specific fields out of struct gpio_chip into a
135 dedicated structure. Currently every GPIO chip has them if gpio-mmio is
139 -------------------------------------------------------------------------------
141 Generic regmap GPIO
143 In the very similar way to Generic MMIO GPIO convert the users which can
145 MMIO case the regmap MMIO with gpio-regmap.c is preferable over gpio-mmio.c.
147 -------------------------------------------------------------------------------
152 try to cover any generic kind of irqchip cascaded from a GPIO.
154 - Look over and identify any remaining easily converted drivers and
155 dry-code conversions to gpiolib irqchip for maintainers to test
157 -------------------------------------------------------------------------------
161 Most of the gpio chips implementing interrupt support rely on gpiolib
163 from being made read-only and forcing duplication of structures that
172 A small number of drivers have been converted (pl061, tegra186, msm,
177 -------------------------------------------------------------------------------
179 Convert all GPIO chips to using the new, value returning line setters
185 We've now added new variants - set_rv() and set_multiple_rv() that return an
186 integer. Let's convert all GPIO drivers treewide to use the new callbacks,
189 -------------------------------------------------------------------------------
193 We have two parallel per-chip class devices and per-exported-line attribute
194 groups in sysfs. One is using the obsolete global GPIO numberspace and the
196 once user-space has switched to using the latter.
198 -------------------------------------------------------------------------------
203 that the GPIO descriptors (the software representation of the hardware concept)
204 are not reference counted and - in general - only one user at a time can
205 request a GPIO line and control its settings. The consumer API is designed
210 A problematic use-case for GPIOs is when two consumers want to use the same
213 a struct device but using the same enable GPIO line.
218 non-exclusive users of the same descriptor will in fact "fight" for the
222 -------------------------------------------------------------------------------
228 make it possible for the regulator subsystem to deal with GPIO resources the
229 lifetime of which it doesn't control as logically, a GPIO obtained by a caller