Location for a kind of GPIO bus driver

Location for a kind of GPIO bus driver

[Simon Guinot]

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 ?

Also from a DT point, it not clear to me how the resulting bus and LEDs
driver are going to work together.

Any advice is welcome. Thanks in advance.

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/20130723/14d4cf33/attachment.sig>

Location for a kind of GPIO bus driver

[Jason Cooper]

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 ?

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?

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

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

thx,

Jason.

Location for a kind of GPIO bus driver

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

Location for a kind of GPIO bus driver

[Jason Cooper]

On Thu, Jul 25, 2013 at 05:49:32PM +0200, Simon Guinot wrote:
> 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.

Agreed.

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

right, but the end result of what the library would do is expose a
series of LEDs and PM 'virtual gpios'.  So, even though it's not a gpio
expander per-se, it's still filling that role.  Or am I still missing
something?

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

It may be simpler to combine it into one driver and place it under
drivers/mfd as it's certainly a multi-function device.  I don't think
anyone outside of Lacie is going to be adopting this 'bus'...

thx,

Jason.

Location for a kind of GPIO bus driver

[Simon Guinot]

On Thu, Jul 25, 2013 at 12:03:24PM -0400, Jason Cooper wrote:
> On Thu, Jul 25, 2013 at 05:49:32PM +0200, Simon Guinot wrote:
> > 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.
> 
> Agreed.
> 
> > 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.
> 
> right, but the end result of what the library would do is expose a
> series of LEDs and PM 'virtual gpios'.  So, even though it's not a gpio
> expander per-se, it's still filling that role.  Or am I still missing
> something?

The library could expose a function allowing to set the address and data
registers: gpio_ext_set_value(int addr, int value).

Actually, it is how it works inside leds-netxbig. Simply this function
would be also accessible by other drivers.

> 
> > > 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.
> 
> It may be simpler to combine it into one driver and place it under
> drivers/mfd as it's certainly a multi-function device.  I don't think
> anyone outside of Lacie is going to be adopting this 'bus'...

I will definitively have a closer look at mfd. But as I understand, mfd
is more oriented platform device and resources. Here, the device don't
expose some memory regions but rather methods to configure a CPLD
through GPIOs. I am not sure how it can work with the mfd framework.

Thanks,

Simon

> 
> thx,
> 
> Jason.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
-------------- 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/20130726/e2ae24b0/attachment.sig>

Location for a kind of GPIO bus driver

[Jason Cooper]

On Fri, Jul 26, 2013 at 10:56:23AM +0200, Simon Guinot wrote:
> On Thu, Jul 25, 2013 at 12:03:24PM -0400, Jason Cooper wrote:
> > On Thu, Jul 25, 2013 at 05:49:32PM +0200, Simon Guinot wrote:
> > > 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.
> > 
> > Agreed.
> > 
> > > 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.
> > 
> > right, but the end result of what the library would do is expose a
> > series of LEDs and PM 'virtual gpios'.  So, even though it's not a gpio
> > expander per-se, it's still filling that role.  Or am I still missing
> > something?
> 
> The library could expose a function allowing to set the address and data
> registers: gpio_ext_set_value(int addr, int value).
> 
> Actually, it is how it works inside leds-netxbig. Simply this function
> would be also accessible by other drivers.

hmmm, at this point I'm inclined to say "post the code RFC" :-)  We can
bikeshed it all day long, and not get any further.  And to answer your
original question, put the library under drivers/bus.  Maybe something
like lacie_gpio?

thx,

Jason.

Location for a kind of GPIO bus driver

[Arnd Bergmann]

On Friday 26 July 2013, Simon Guinot wrote:
> On Thu, Jul 25, 2013 at 12:03:24PM -0400, Jason Cooper wrote:
> > On Thu, Jul 25, 2013 at 05:49:32PM +0200, Simon Guinot wrote:

> > > > 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.
> > 
> > right, but the end result of what the library would do is expose a
> > series of LEDs and PM 'virtual gpios'.  So, even though it's not a gpio
> > expander per-se, it's still filling that role.  Or am I still missing
> > something?
> 
> The library could expose a function allowing to set the address and data
> registers: gpio_ext_set_value(int addr, int value).
> 
> Actually, it is how it works inside leds-netxbig. Simply this function
> would be also accessible by other drivers.

With that prototype it still sounds like a regular gpiochip driver would
fit that role well, since the function you describe is just like
gpio_set_value().

Maybe you can post the driver to let others understand what you are
trying to do if it's not just a gpio expander.

	Arnd

Location for a kind of GPIO bus driver

[Linus Walleij]

On Tue, Jul 23, 2013 at 5:18 PM, Simon Guinot <simon.guinot@sequanux.org> wrote:

> (...)  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 ?

This is a question to Greg, the device core maintainer.
AFAICT they go into drivers/base/foo-bus.c

In this case I would first consider using MFD though,
please make a case for why this is not simply a multi
function device with a few cells (== platform devices).

> Also from a DT point, it not clear to me how the resulting bus and LEDs
> driver are going to work together.

Buses are nodes in the device tree and subdevices are
subnodes.

Yours,
Linus Walleij

Location for a kind of GPIO bus driver

[Greg KH]

On Thu, Jul 25, 2013 at 11:46:42PM +0200, Linus Walleij wrote:
> On Tue, Jul 23, 2013 at 5:18 PM, Simon Guinot <simon.guinot@sequanux.org> wrote:
> 
> > (...)  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 ?
> 
> This is a question to Greg, the device core maintainer.
> AFAICT they go into drivers/base/foo-bus.c

No, specific bus code does not go in drivers/base/ it goes where the
rest of the subsystem lives.

> In this case I would first consider using MFD though,
> please make a case for why this is not simply a multi
> function device with a few cells (== platform devices).

I agree with this as well.

thanks,

greg k-h

Location for a kind of GPIO bus driver

[Jason Cooper]

On Thu, Jul 25, 2013 at 03:16:15PM -0700, Greg KH wrote:
> On Thu, Jul 25, 2013 at 11:46:42PM +0200, Linus Walleij wrote:
> > On Tue, Jul 23, 2013 at 5:18 PM, Simon Guinot <simon.guinot@sequanux.org> wrote:
> > 
> > > (...)  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 ?
> > 
> > This is a question to Greg, the device core maintainer.
> > AFAICT they go into drivers/base/foo-bus.c
> 
> No, specific bus code does not go in drivers/base/ it goes where the
> rest of the subsystem lives.

We were thinking drivers/bus since it is addressable and has multiple
devices hanging off of it (leds, power management).

However, since each device is essentially an external gpio, drivers/gpio
might be more appropriate.  It's not a gpio expander, more of an
enhanced gpio controller (led 1, brightness 7)

> > In this case I would first consider using MFD though,
> > please make a case for why this is not simply a multi
> > function device with a few cells (== platform devices).
> 
> I agree with this as well.

To quote Simon from a different response:
> I will definitively have a closer look at mfd. But as I understand,
> mfd is more oriented platform device and resources. Here, the device
> don't expose some memory regions but rather methods to configure a
> CPLD through GPIOs. I am not sure how it can work with the mfd
> framework.

thx,

Jason.