mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [patch/rfc 0/4] GPIO implementation framework
@ 2007-10-30  1:50 David Brownell
  0 siblings, 0 replies; only message in thread
From: David Brownell @ 2007-10-30  1:50 UTC (permalink / raw)
  To: Linux Kernel list
  Cc: Felipe Balbi, Bill Gatliff, Haavard Skinnemoen, Andrew Victor,
	Tony Lindgren, Jean Delvare, eric miao, Kevin Hilman, Paul Mundt,
	Ben Dooks

When we hashed out the Documentation/gpio.txt GPIO programming
interfaces last year, there were a few features in the "we want
this eventually, but can live without it for now" category.
Following this post are patches adding some of those features.

Two core patches are:

 - Implementation framework in lib/gpiolib.c ... the interface
   provided to GPIO _users_ is unchanged, but providers can now
   hook up through a "gpio_chip" that lets multiple types of
   GPIO provider coexist.  Examples:  SOC-native GPIOs, ones
   provided by an FPGA, I2C or SPI GPIO expanders, etc.

   (I'm thinking this is pretty much ready to merge into MM,
   unless someone turns up a blocking issue...)

 - I2C driver for common pcf8574/8575 GPIO expanders ... these
   are pretty common on embedded hardware, and it's routine for
   external trees to have ugly board-specific hacks exposing
   those GPIOs to drivers.  Unlike such hacks, I think support
   using standard GPIO calls should be mergable upstream.

   (IMO this is ready to merge too, although I know Jean would
   like additional infrastructure which could let us obsolete
   existing drivers, instead of just offering an alternative for
   systems that need kernel access instead of userspace access.)

Two more patches show how they can be used:

 - Platform conversion for DaVinci ... making the SOC-native
   GPIOs plug in through gpiolib instead of directly, except
   when callers can leverage the inline optimization.

 - Board conversion (partial) for DaVinci EVM ... exposing
   the LEDs hooked up to one pcf8574a chip using leds-gpio,
   along with the A/V clocks (and a random user switch) on
   another pcf chip.  A third pcf chip isn't converted; it'd
   mean changing half a dozen drivers, none of which are yet
   upstream.

If the gpiolib patch merges into MM, then I think it'd be
realistic to expect some platforms and boards to be using
this new infrastructure in 2.6.25 ...

- Dave


^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2007-10-30  1:55 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-10-30  1:50 [patch/rfc 0/4] GPIO implementation framework David Brownell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®