linux-vybrid_public/drivers/gpio/Kconfig

#
# GPIO infrastructure and expanders
#

config ARCH_WANT_OPTIONAL_GPIOLIB
	bool
	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
	help
	  Platforms select gpiolib if they use this infrastructure
	  for all their GPIOs, usually starting with ones integrated
	  into SOC processors.
	  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.

if GPIOLIB

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 "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

comment "I2C GPIO expanders:"

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.

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.

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.

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.

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.

endif