2008-02-05 01:28:17 -05:00
|
|
|
#
|
|
|
|
# GPIO infrastructure and expanders
|
|
|
|
#
|
|
|
|
|
2008-07-25 04:46:11 -04:00
|
|
|
config ARCH_WANT_OPTIONAL_GPIOLIB
|
2008-02-05 01:28:17 -05:00
|
|
|
bool
|
2008-07-25 04:46:11 -04:00
|
|
|
help
|
|
|
|
Select this config option from the architecture Kconfig, if
|
|
|
|
it is possible to use gpiolib on the architecture, but let the
|
|
|
|
user decide whether to actually build it or not.
|
|
|
|
Select this instead of ARCH_REQUIRE_GPIOLIB, if your architecture does
|
|
|
|
not depend on GPIOs being available, but rather let the user
|
|
|
|
decide whether he needs it or not.
|
|
|
|
|
|
|
|
config ARCH_REQUIRE_GPIOLIB
|
|
|
|
bool
|
|
|
|
select GPIOLIB
|
2008-02-05 01:28:17 -05:00
|
|
|
help
|
|
|
|
Platforms select gpiolib if they use this infrastructure
|
|
|
|
for all their GPIOs, usually starting with ones integrated
|
|
|
|
into SOC processors.
|
2008-07-25 04:46:11 -04:00
|
|
|
Selecting this from the architecture code will cause the gpiolib
|
|
|
|
code to always get built in.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
menuconfig GPIOLIB
|
|
|
|
bool "GPIO Support"
|
|
|
|
depends on ARCH_WANT_OPTIONAL_GPIOLIB || ARCH_REQUIRE_GPIOLIB
|
|
|
|
select GENERIC_GPIO
|
|
|
|
help
|
|
|
|
This enables GPIO support through the generic GPIO library.
|
|
|
|
You only need to enable this, if you also want to enable
|
|
|
|
one or more of the GPIO expansion card drivers below.
|
|
|
|
|
|
|
|
If unsure, say N.
|
2008-02-05 01:28:17 -05:00
|
|
|
|
2008-07-25 04:46:11 -04:00
|
|
|
if GPIOLIB
|
2008-02-05 01:28:17 -05:00
|
|
|
|
|
|
|
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.
|
2009-01-26 05:12:25 -05:00
|
|
|
These checks help ensure that GPIOs have been properly initialized
|
|
|
|
before they are used, and that sleeping calls are not made from
|
|
|
|
non-sleeping contexts. They can make bitbanged serial protocols
|
2008-02-05 01:28:17 -05:00
|
|
|
slower. The diagnostics help catch the type of setup errors
|
|
|
|
that are most common when setting up new platforms or boards.
|
|
|
|
|
gpio: sysfs interface
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>
2008-07-25 04:46:07 -04:00
|
|
|
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.
|
|
|
|
|
2008-02-05 01:28:17 -05:00
|
|
|
# put expanders in the right section, in alphabetical order
|
|
|
|
|
2008-11-12 16:25:38 -05:00
|
|
|
comment "Memory mapped GPIO expanders:"
|
|
|
|
|
|
|
|
config GPIO_XILINX
|
|
|
|
bool "Xilinx GPIO support"
|
|
|
|
depends on PPC_OF
|
|
|
|
help
|
|
|
|
Say yes here to support the Xilinx FPGA GPIO device
|
|
|
|
|
2008-02-05 01:28:17 -05:00
|
|
|
comment "I2C GPIO expanders:"
|
|
|
|
|
2008-07-25 04:46:14 -04:00
|
|
|
config GPIO_MAX732X
|
|
|
|
tristate "MAX7319, MAX7320-7327 I2C Port Expanders"
|
|
|
|
depends on I2C
|
|
|
|
help
|
|
|
|
Say yes here to support the MAX7319, MAX7320-7327 series of I2C
|
|
|
|
Port Expanders. Each IO port on these chips has a fixed role of
|
|
|
|
Input (designated by 'I'), Push-Pull Output ('O'), or Open-Drain
|
|
|
|
Input and Output (designed by 'P'). The combinations are listed
|
|
|
|
below:
|
|
|
|
|
|
|
|
8 bits: max7319 (8I), max7320 (8O), max7321 (8P),
|
|
|
|
max7322 (4I4O), max7323 (4P4O)
|
|
|
|
|
|
|
|
16 bits: max7324 (8I8O), max7325 (8P8O),
|
|
|
|
max7326 (4I12O), max7327 (4P12O)
|
|
|
|
|
|
|
|
Board setup code must specify the model to use, and the start
|
|
|
|
number for these GPIOs.
|
|
|
|
|
2008-02-06 04:39:03 -05:00
|
|
|
config GPIO_PCA953X
|
2009-01-06 17:42:27 -05:00
|
|
|
tristate "PCA953x, PCA955x, TCA64xx, and MAX7310 I/O ports"
|
2008-02-05 01:28:26 -05:00
|
|
|
depends on I2C
|
|
|
|
help
|
2008-07-04 12:59:37 -04:00
|
|
|
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
|
|
|
|
|
2009-01-06 17:42:27 -05:00
|
|
|
8 bits: max7310, pca9534, pca9538, pca9554, pca9557,
|
|
|
|
tca6408
|
2008-07-04 12:59:37 -04:00
|
|
|
|
2009-01-06 17:42:27 -05:00
|
|
|
16 bits: pca9535, pca9539, pca9555, tca6416
|
2008-02-05 01:28:26 -05:00
|
|
|
|
|
|
|
This driver can also be built as a module. If so, the module
|
2008-02-06 04:39:03 -05:00
|
|
|
will be called pca953x.
|
2008-02-05 01:28:26 -05:00
|
|
|
|
2008-02-05 01:28:24 -05:00
|
|
|
config GPIO_PCF857X
|
2008-07-21 17:21:34 -04:00
|
|
|
tristate "PCF857x, PCA{85,96}7x, and MAX732[89] I2C GPIO expanders"
|
2008-02-05 01:28:24 -05:00
|
|
|
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,
|
2008-07-21 17:21:34 -04:00
|
|
|
pca9670, pca9672, pca9674, pca9674a,
|
|
|
|
max7328, max7329
|
2008-02-05 01:28:24 -05:00
|
|
|
|
|
|
|
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.
|
|
|
|
|
2008-10-20 17:51:46 -04:00
|
|
|
config GPIO_TWL4030
|
|
|
|
tristate "TWL4030, TWL5030, and TPS659x0 GPIOs"
|
|
|
|
depends on TWL4030_CORE
|
|
|
|
help
|
|
|
|
Say yes here to access the GPIO signals of various multi-function
|
|
|
|
power management chips from Texas Instruments.
|
|
|
|
|
2008-07-25 04:46:10 -04:00
|
|
|
comment "PCI GPIO expanders:"
|
|
|
|
|
|
|
|
config GPIO_BT8XX
|
|
|
|
tristate "BT8XX GPIO abuser"
|
|
|
|
depends on PCI && VIDEO_BT848=n
|
|
|
|
help
|
|
|
|
The BT8xx frame grabber chip has 24 GPIO pins than can be abused
|
|
|
|
as a cheap PCI GPIO card.
|
|
|
|
|
|
|
|
This chip can be found on Miro, Hauppauge and STB TV-cards.
|
|
|
|
|
|
|
|
The card needs to be physically altered for using it as a
|
|
|
|
GPIO card. For more information on how to build a GPIO card
|
|
|
|
from a BT8xx TV card, see the documentation file at
|
|
|
|
Documentation/bt8xxgpio.txt
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
2008-02-05 01:28:17 -05:00
|
|
|
comment "SPI GPIO expanders:"
|
|
|
|
|
2008-07-21 17:21:34 -04:00
|
|
|
config GPIO_MAX7301
|
|
|
|
tristate "Maxim MAX7301 GPIO expander"
|
|
|
|
depends on SPI_MASTER
|
|
|
|
help
|
|
|
|
gpio driver for Maxim MAX7301 SPI GPIO expander.
|
|
|
|
|
2008-02-05 01:28:25 -05:00
|
|
|
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.
|
|
|
|
|
2008-07-25 04:46:11 -04:00
|
|
|
endif
|