07 Feb, 2008
3 commits
-
This third part of an extension to support more pca953x chips updates the
logic to handle the smaller register widths used by the 4-bit and 8-bit parts,
and to use the chip type to determine how many GPIOs it provides.As long as we don't support interrupt and reset capabilities, those size
issues are the only software-visible differences between these parts.Signed-off-by: Guennadi Liakhovetski
Signed-off-by: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This second part of an extension to support more pca953x chips renames the C
and Kconfig symbols. All affected files were updated by sed, except for a
couple of obvious exceptions. It also updates the Kconfig helptext.Signed-off-by: Guennadi Liakhovetski
Signed-off-by: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
First part of an extension to let the pca9539 driver support more chips,
starting with pca9534, pca9535, pca9536, pca9537, and pca9538.This renames the files and modifies the Makefile.
Signed-off-by: Guennadi Liakhovetski
Signed-off-by: David Brownell
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
06 Feb, 2008
5 commits
-
This adds a new-style I2C driver with basic support for the sixteen bit
PCA9539 GPIO expanders. These chips have multiple registers, push-pull output
drivers, and (not supported in this patch) pin change interrupts.Board-specific code must provide "pca9539_platform_data" with each chip's
"i2c_board_info". That provides the GPIO numbers to be used by that chip, and
callbacks for board-specific setup/teardown logic.Derived from drivers/i2c/chips/pca9539.c (which has no current known users).
This is faster and simpler; it uses 16-bit register access, and cache the
OUTPUT and DIRECTION registers for fast accessSigned-off-by: eric miao
Signed-off-by: David Brownell
Acked-by: Jean Delvare
Cc: Sam Ravnborg
Cc: Haavard Skinnemoen
Cc: Philipp Zabel
Cc: Russell King
Cc: Ben Gardner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Basic driver for 8-bit SPI based MCP23S08 GPIO expander, without support for
IRQs or the shared chipselect mechanism.Signed-off-by: David Brownell
Cc: Jean Delvare
Cc: Eric Miao
Cc: Sam Ravnborg
Cc: Haavard Skinnemoen
Cc: Philipp Zabel
Cc: Russell King
Cc: Ben Gardner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
This is a new-style I2C driver for most common 8 and 16 bit I2C based
"quasi-bidirectional" GPIO expanders: pcf8574 or pcf8575, and several
compatible models (mostly faster, supporting I2C at up to 1 MHz).The driver exposes the GPIO signals using the platform-neutral GPIO
programming interface, so they are easily accessed by other kernel code. The
lack of such a flexible kernel API has been a big factor in the proliferation
of board-specific drivers for these chips... stuff that rarely makes it
upstream since it's so ugly. This driver will let such boards use standard
calls.Since it's a new-style driver, these devices must be configured as part of
board-specific init. That eliminates the need for error-prone manual
configuration of module parameters, and makes compatibility with legacy
drivers (pcf8574.c, pc8575.c) for these chips easier (there's a clear
either/or disjunction).Signed-off-by: David Brownell
Acked-by: Jean Delvare
Cc: Eric Miao
Cc: Sam Ravnborg
Cc: Haavard Skinnemoen
Cc: Philipp Zabel
Cc: Russell King
Cc: Ben Gardner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Provide new implementation infrastructure that platforms may choose to use
when implementing the GPIO programming interface. Platforms can update their
GPIO support to use this. In many cases the incremental cost to access a
non-inlined GPIO should be less than a dozen instructions, with the memory
cost being about a page (total) of extra data and code. The upside is:* Providing two features which were "want to have (but OK to defer)" when
GPIO interfaces were first discussed in November 2006:- A "struct gpio_chip" to plug in GPIOs that aren't directly supported
by SOC platforms, but come from FPGAs or other multifunction devices
using conventional device registers (like UCB-1x00 or SM501 GPIOs,
and southbridges in PCs with more open specs than usual).- Full support for message-based GPIO expanders, where registers are
accessed through sleeping I/O calls. Previous support for these
"cansleep" calls was just stubs. (One example: the widely used
pcf8574 I2C chips, with 8 GPIOs each.)* Including a non-stub implementation of the gpio_{request,free}() calls,
making those calls much more useful. The diagnostic labels are also
recorded given DEBUG_FS, so /sys/kernel/debug/gpio can show a snapshot
of all GPIOs known to this infrastructure.The driver programming interfaces introduced in 2.6.21 do not change at all;
this infrastructure is entirely below those covers.Signed-off-by: David Brownell
Cc: Sam Ravnborg
Cc: Jean Delvare
Cc: Eric Miao
Cc: Haavard Skinnemoen
Cc: Philipp Zabel
Cc: Russell King
Cc: Ben Gardner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds -
Add an empty drivers/gpio directory for gpiolib infrastructure and GPIO
expanders. It will be populated by later patches.This won't be the only place to hold such gpio_chip code. Many external chips
add a few GPIOs as secondary functionality (such as MFD drivers) and platform
code frequently needs to closely integrate GPIO and IRQ support.This is placed *early* in the build/link sequence since it's common for other
drivers to depend on GPIOs to do their work, so they must be initialized early
in the device_initcall() sequence.Signed-off-by: David Brownell
Acked-by: Jean Delvare
Cc: Eric Miao
Cc: Sam Ravnborg
Cc: Haavard Skinnemoen
Cc: Philipp Zabel
Cc: Russell King
Cc: Ben Gardner
Signed-off-by: Andrew Morton
Signed-off-by: Linus Torvalds
