d8f388d8dc
This adds a simple sysfs interface for GPIOs.
/sys/class/gpio
/export ... asks the kernel to export a GPIO to userspace
/unexport ... to return a GPIO to the kernel
/gpioN ... for each exported GPIO #N
/value ... always readable, writes fail for input GPIOs
/direction ... r/w as: in, out (default low); write high, low
/gpiochipN ... for each gpiochip; #N is its first GPIO
/base ... (r/o) same as N
/label ... (r/o) descriptive, not necessarily unique
/ngpio ... (r/o) number of GPIOs; numbered N .. N+(ngpio - 1)
GPIOs claimed by kernel code may be exported by its owner using a new
gpio_export() call, which should be most useful for driver debugging.
Such exports may optionally be done without a "direction" attribute.
Userspace may ask to take over a GPIO by writing to a sysfs control file,
helping to cope with incomplete board support or other "one-off"
requirements that don't merit full kernel support:
echo 23 > /sys/class/gpio/export
... will gpio_request(23, "sysfs") and gpio_export(23);
use /sys/class/gpio/gpio-23/direction to (re)configure it,
when that GPIO can be used as both input and output.
echo 23 > /sys/class/gpio/unexport
... will gpio_free(23), when it was exported as above
The extra D-space footprint is a few hundred bytes, except for the sysfs
resources associated with each exported GPIO. The additional I-space
footprint is about two thirds of the current size of gpiolib (!). Since
no /dev node creation is involved, no "udev" support is needed.
Related changes:
* This adds a device pointer to "struct gpio_chip". When GPIO
providers initialize that, sysfs gpio class devices become children of
that device instead of being "virtual" devices.
* The (few) gpio_chip providers which have such a device node have
been updated.
* Some gpio_chip drivers also needed to update their module "owner"
field ... for which missing kerneldoc was added.
* Some gpio_chips don't support input GPIOs. Those GPIOs are now
flagged appropriately when the chip is registered.
Based on previous patches, and discussion both on and off LKML.
A Documentation/ABI/testing/sysfs-gpio update is ready to submit once this
merges to mainline.
[akpm@linux-foundation.org: a few maintenance build fixes]
Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Cc: Guennadi Liakhovetski <g.liakhovetski@pengutronix.de>
Cc: Greg KH <greg@kroah.com>
Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
101 lines
3.1 KiB
Text
101 lines
3.1 KiB
Text
#
|
|
# GPIO infrastructure and expanders
|
|
#
|
|
|
|
config HAVE_GPIO_LIB
|
|
bool
|
|
help
|
|
Platforms select gpiolib if they use this infrastructure
|
|
for all their GPIOs, usually starting with ones integrated
|
|
into SOC processors.
|
|
|
|
menu "GPIO Support"
|
|
depends on HAVE_GPIO_LIB
|
|
|
|
config DEBUG_GPIO
|
|
bool "Debug GPIO calls"
|
|
depends on DEBUG_KERNEL
|
|
help
|
|
Say Y here to add some extra checks and diagnostics to GPIO calls.
|
|
The checks help ensure that GPIOs have been properly initialized
|
|
before they are used and that sleeping calls aren not made from
|
|
nonsleeping contexts. They can make bitbanged serial protocols
|
|
slower. The diagnostics help catch the type of setup errors
|
|
that are most common when setting up new platforms or boards.
|
|
|
|
config GPIO_SYSFS
|
|
bool "/sys/class/gpio/... (sysfs interface)"
|
|
depends on SYSFS && EXPERIMENTAL
|
|
help
|
|
Say Y here to add a sysfs interface for GPIOs.
|
|
|
|
This is mostly useful to work around omissions in a system's
|
|
kernel support. Those are common in custom and semicustom
|
|
hardware assembled using standard kernels with a minimum of
|
|
custom patches. In those cases, userspace code may import
|
|
a given GPIO from the kernel, if no kernel driver requested it.
|
|
|
|
Kernel drivers may also request that a particular GPIO be
|
|
exported to userspace; this can be useful when debugging.
|
|
|
|
# put expanders in the right section, in alphabetical order
|
|
|
|
comment "I2C GPIO expanders:"
|
|
|
|
config GPIO_PCA953X
|
|
tristate "PCA953x, PCA955x, and MAX7310 I/O ports"
|
|
depends on I2C
|
|
help
|
|
Say yes here to provide access to several register-oriented
|
|
SMBus I/O expanders, made mostly by NXP or TI. Compatible
|
|
models include:
|
|
|
|
4 bits: pca9536, pca9537
|
|
|
|
8 bits: max7310, pca9534, pca9538, pca9554, pca9557
|
|
|
|
16 bits: pca9535, pca9539, pca9555
|
|
|
|
This driver can also be built as a module. If so, the module
|
|
will be called pca953x.
|
|
|
|
config GPIO_PCF857X
|
|
tristate "PCF857x, PCA{85,96}7x, and MAX732[89] I2C GPIO expanders"
|
|
depends on I2C
|
|
help
|
|
Say yes here to provide access to most "quasi-bidirectional" I2C
|
|
GPIO expanders used for additional digital outputs or inputs.
|
|
Most of these parts are from NXP, though TI is a second source for
|
|
some of them. Compatible models include:
|
|
|
|
8 bits: pcf8574, pcf8574a, pca8574, pca8574a,
|
|
pca9670, pca9672, pca9674, pca9674a,
|
|
max7328, max7329
|
|
|
|
16 bits: pcf8575, pcf8575c, pca8575,
|
|
pca9671, pca9673, pca9675
|
|
|
|
Your board setup code will need to declare the expanders in
|
|
use, and assign numbers to the GPIOs they expose. Those GPIOs
|
|
can then be used from drivers and other kernel code, just like
|
|
other GPIOs, but only accessible from task contexts.
|
|
|
|
This driver provides an in-kernel interface to those GPIOs using
|
|
platform-neutral GPIO calls.
|
|
|
|
comment "SPI GPIO expanders:"
|
|
|
|
config GPIO_MAX7301
|
|
tristate "Maxim MAX7301 GPIO expander"
|
|
depends on SPI_MASTER
|
|
help
|
|
gpio driver for Maxim MAX7301 SPI GPIO expander.
|
|
|
|
config GPIO_MCP23S08
|
|
tristate "Microchip MCP23S08 I/O expander"
|
|
depends on SPI_MASTER
|
|
help
|
|
SPI driver for Microchip MCP23S08 I/O expander. This provides
|
|
a GPIO interface supporting inputs and outputs.
|
|
|
|
endmenu
|