OMAP and gpiolib
cover OMAP and gpiolib
Yesterday I posted some new GPIO infrastructure, "gpiolib", which lets platforms support multiple plug-in GPIO providers, to LKML. And includes a pcf857x driver, which several OMAP boards could be using..
One of my test platforms for this was OMAP. Following this are two patches:
- one updating the plat-omap/gpio.c infrastructure to use this code (a quick'n'dirty update), and
- another updating the board support for the OSK5912.
I've got some H4 stuff somewhere too, exposing the debug board's FPGA support for the LEDs ... although not the other GPIO signals which it evidently provides. I'll try to refresh that.
- Dave
Quoted 8 lines · David Brownell
Yesterday I posted some new GPIO infrastructure, "gpiolib", which lets platforms support multiple plug-in GPIO providers, to LKML. And includes a pcf857x driver, which several OMAP boards could be using..
One of my test platforms for this was OMAP. Following this are two patches:
Quoted 8 lines
- one updating the
plat-omap/gpio.cinfrastructure to use this code (a quick'n'dirty update), and- another updating the board support for the OSK5912.
I've got some H4 stuff somewhere too, exposing the debug board's FPGA support for the LEDs ... although not the other GPIO signals which it evidently provides. I'll try to refresh that.
I guess we'll apply these once the raw_spinlock/performance issues with gpio_chip are solved. For anybody interested, see LKML. [1]
Tony
Quoted 2 lines · Tony Lindgren
I guess we'll apply these once the raw_spinlock/performance issues with
gpio_chipare solved. For anybody interested, see LKML. [1]
[1] http://lkml.org/lkml/2007/11/15/155
is the relevant fix, I think.
There may be some other updates, to support more dense packing of GPIO numbers through a gpio_desc structure that would be used much like an irq_desc.
- Dave