5f7582aa2d
Intel Moorestown and Medfield are quite old Intel Atom based
32-bit platforms, which were in limited use in some Android phones,
tablets and consumer electronics more than eight years ago.
There are no bugs or problems ever reported outside from Intel
for breaking any of that platforms for years. It seems no real
users exists who run more or less fresh kernel on it. The commit
05f4434bc1 ("ASoC: Intel: remove mfld_machine") also in align
with this theory.
Due to above and to reduce a burden of supporting outdated drivers
we remove the support of outdated platforms completely.
Moreover this code duplicates gpio-pxa since the IP has been derived
from XScale implementation. If anybody wants to resurrect this
it has to be part of gpio-pxa.c.
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
181 lines
7.3 KiB
Plaintext
181 lines
7.3 KiB
Plaintext
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 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.
|
|
|
|
The numberspace issue is the same as to why irq is moving away from irq
|
|
numbers to IRQ descriptors.
|
|
|
|
The underlying motivation for this is that the GPIO numberspace has become
|
|
unmanageable: machine board files tend to become full of macros trying to
|
|
establish the numberspace at compile-time, making it hard to add any numbers
|
|
in the middle (such as if you missed a pin on a chip) without the numberspace
|
|
breaking.
|
|
|
|
Machine descriptions such as device tree or ACPI does not have a concept of the
|
|
Linux GPIO number as those descriptions are external to the Linux kernel
|
|
and treat GPIO lines as abstract entities.
|
|
|
|
The runtime-assigned GPIO numberspace (what you get if you assign the GPIO
|
|
base as -1 in struct gpio_chip) has also became unpredictable due to factors
|
|
such as probe ordering and the introduction of -EPROBE_DEFER making probe
|
|
ordering of independent GPIO chips essentially unpredictable, as their base
|
|
number will be assigned on a first come first serve basis.
|
|
|
|
The best way to get out of the problem is to make the global GPIO numbers
|
|
unimportant by simply not using them. GPIO descriptors deal with this.
|
|
|
|
Work items:
|
|
|
|
- Convert all GPIO device drivers to only #include <linux/gpio/driver.h>
|
|
|
|
- Convert all consumer drivers to only #include <linux/gpio/consumer.h>
|
|
|
|
- Convert all machine descriptors in "boardfiles" to only
|
|
#include <linux/gpio/machine.h>, the other option being to convert it
|
|
to a machine description such as device tree, ACPI or fwnode that
|
|
implicitly does not use global GPIO numbers.
|
|
|
|
- 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>
|
|
|
|
This header and helpers appeared at one point when there was no proper
|
|
driver infrastructure for doing simpler MMIO GPIO devices and there was
|
|
no core support for parsing device tree GPIOs from the core library with
|
|
the [devm_]gpiod_get() calls we have today that will implicitly go into
|
|
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.
|
|
|
|
- Pull semantics for legacy device tree (OF) GPIO lookups into
|
|
gpiolib-of.c: in some cases subsystems are doing custom flags and
|
|
lookups for polarity inversion, open drain and what not. As we now
|
|
handle this with generic OF bindings, pull all legacy handling into
|
|
gpiolib so the library API becomes narrow and deep and handle all
|
|
legacy bindings internally. (See e.g. commits 6953c57ab172,
|
|
6a537d48461d etc)
|
|
|
|
- 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
|
|
|
|
Collect GPIO drivers from arch/* and other places that should be placed
|
|
in drivers/gpio/gpio-*. Augment platforms to create platform devices or
|
|
similar and probe a proper driver in the gpiolib subsystem.
|
|
|
|
In some cases it makes sense to create a GPIO chip from the local driver
|
|
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.
|
|
|
|
|
|
Generic MMIO GPIO
|
|
|
|
The GPIO drivers can utilize the generic MMIO helper library in many
|
|
cases, and the helper library should be as helpful as possible for MMIO
|
|
drivers. (drivers/gpio/gpio-mmio.c)
|
|
|
|
Work items:
|
|
|
|
- Look over and identify any remaining easily converted drivers and
|
|
dry-code conversions to MMIO GPIO for maintainers to test
|
|
|
|
- Expand the MMIO GPIO or write a new library for regmap-based I/O
|
|
helpers for GPIO drivers on regmap that simply use offsets
|
|
0..n in some register to drive GPIO lines
|
|
|
|
- Expand the MMIO GPIO or write a new library for port-mapped I/O
|
|
helpers (x86 inb()/outb()) and convert port-mapped I/O drivers to use
|
|
this with dry-coding and sending to maintainers to test
|
|
|
|
|
|
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.
|
|
|
|
- Look over and identify any remaining easily converted drivers and
|
|
dry-code conversions to gpiolib irqchip for maintainers to test
|
|
|
|
|
|
Increase integration with pin control
|
|
|
|
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.
|
|
|
|
|
|
Debugfs in place of sysfs
|
|
|
|
The old sysfs code that enables simple uses of GPIOs from the
|
|
command line is still popular despite the existance of the proper
|
|
character device. The reason is that it is simple to use on
|
|
root filesystems where you only have a minimal set of tools such
|
|
as "cat", "echo" etc.
|
|
|
|
The old sysfs still need to be strongly deprecated and removed
|
|
as it relies on the global GPIO numberspace that assume a strict
|
|
order of global GPIO numbers that do not change between boots
|
|
and is independent of probe order.
|
|
|
|
To solve this and provide an ABI that people can use for hacks
|
|
and development, implement a debugfs interface to manipulate
|
|
GPIO lines that can do everything that sysfs can do today: one
|
|
directory per gpiochip and one file entry per line:
|
|
|
|
/sys/kernel/debug/gpiochip/gpiochip0
|
|
/sys/kernel/debug/gpiochip/gpiochip0/gpio0
|
|
/sys/kernel/debug/gpiochip/gpiochip0/gpio1
|
|
/sys/kernel/debug/gpiochip/gpiochip0/gpio2
|
|
/sys/kernel/debug/gpiochip/gpiochip0/gpio3
|
|
...
|
|
/sys/kernel/debug/gpiochip/gpiochip1
|
|
/sys/kernel/debug/gpiochip/gpiochip1/gpio0
|
|
/sys/kernel/debug/gpiochip/gpiochip1/gpio1
|
|
...
|
|
|
|
The exact files and design of the debugfs interface can be
|
|
discussed but the idea is to provide a low-level access point
|
|
for debugging and hacking and to expose all lines without the
|
|
need of any exporting. Also provide ample ammunition to shoot
|
|
oneself in the foot, because this is debugfs after all.
|