Location for a kind of GPIO bus driver

[simon.guinot@sequanux.org (Simon Guinot)]

On Wed, Jul 24, 2013 at 02:19:24PM -0400, Jason Cooper wrote:
> On Tue, Jul 23, 2013 at 05:18:34PM +0200, Simon Guinot wrote:
> > Hi,
> > 
> > I am currently working on converting the LED driver leds-netxbig to DT.
> > Doing so, I am also considering to move the GPIO extension bus functions
> > (which are currently parts of leds-netxbig) into a separate driver.
> > 
> > On the LaCie "Big Network" board family (netxbig), the LEDs are
> > controlled by a CPLD. In turn, the CPLD can be configured (mostly the
> > LEDs modes) through a kind of parallel GPIO bus, called GPIO extension
> > bus. Two registers (address and data) are exposed. Each of them is made
> > up of several GPIOs. An extra GPIO is used to notify the CPLD that the
> > registers have been updated. The leds-netxbig driver uses some dedicated
> > functions (prefixed by "gpio_ext_") to handle the GPIO bus extension.
> > 
> > On the latest "Big Network" boards, this bus is also used to enable the
> > PM wakeup sources: the CPLD can be asked to keep powered some devices
> > (as the RTC or the Ethernet PHY) while the board is down. I think it
> > could be nice to expose this feature to the userland. That's why I am
> > thinking about moving the GPIO extension bus support into a separate
> > driver. The problem is that I can't find a proper location for a such
> > driver. AFAIK, it doesn't fit with anything existing supported by Linux.
> > Maybe I should consider drivers/bus ? Or even drivers/misc ?

Hi Jason,

Thanks for your answer.

> 
> iiuc, the CPLD is more of gpio multiplexer/expander.  Have you seen
> 
>   66bcb58 arm: mvebu: enable gpio expander over i2c on Mirabox platform
> 
> ?  And the corresponding driver, drivers/gpio/gpio-pca953x.c?

All the drivers under drivers/gpio are registering some GPIO chips.
It is a big difference with the LaCie "GPIO extension bus". This last
is more an extension mechanism on the top of GPIOs already existing
(eventually provided by a SoC or a Super-I/O on x86 boards). No new
GPIOs are added. I think that the name "extension" is quite confusing.

The idea behind this "bus" is to allow to configure a lot of LEDs (in
various modes) using only few GPIOs and a CPLD (which is already
available on the board for other purposes). This cheap solution allows
precisely to save the cost of a GPIO expander :)

As an example, you can see the "GPIO extension bus" configuration for
the Kirkwood "Big Network" boards in:
arch/arm/mach-kirkwood/netxbig_v2-setup.c:132.

> 
> I would try drivers/gpio.  If there are complaints, it should be trivial
> to move it in a new version of the series.

Why not, as long it is clear that the resulting driver will not provide
a GPIO chip but rather functions as a library.

> 
> Is there any reason why the new capabilities in the "Big Network" boards
> couldn't be covered by gpio-regulator?

I don't have looked at the details but I think that gpio-regulator
could be able to configure the PM modes through the GPIO extension bus.

But a problem remains. The same GPIOs would be used by two different
drivers: leds-netxbig and gpio-regulator. This would lead to some
conflicts. That's why I think that at some level a driver is needed to
handle the GPIO extension bus.

Regards,

Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130725/c2ada4ec/attachment.sig>