GPIO expander user space access(ie. pca9552)

GPIO expander user space access(ie. pca9552)

[Matt Barth]

Is there a defined process/interface to access GPIO expanders from user 
space to be able to determine when the state changes? Possibly polling a 
fd or getting notified on the state change?

Previously this was an i2c device that was accessed over i2c and the set 
of interested bits were simply read into the application. An example is 
the use of a pca9552 for presence detection on chassis fans.

Thanks,

Matt

Re: GPIO expander user space access(ie. pca9552)

[Andrew Jeffery]

[-- Attachment #1: Type: text/plain, Size: 673 bytes --]

On Mon, 2017-01-23 at 09:58 -0600, Matt Barth wrote:
> Is there a defined process/interface to access GPIO expanders from user 
> space to be able to determine when the state changes? Possibly polling a 
> fd or getting notified on the state change?
> 
> Previously this was an i2c device that was accessed over i2c and the set 
> of interested bits were simply read into the application. An example is 
> the use of a pca9552 for presence detection on chassis fans.

I expect it should be implemented as a gpiochip driver in the kernel
and exposed via the usual methods to userspace (GPIO chardev and sysfs,
though sysfs is considered deprecated).

Andrew

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: GPIO expander user space access(ie. pca9552)

[Joel Stanley]

On Tue, Jan 24, 2017 at 2:28 AM, Matt Barth <msbarth@linux.vnet.ibm.com> wrote:
> Is there a defined process/interface to access GPIO expanders from user
> space to be able to determine when the state changes? Possibly polling a fd
> or getting notified on the state change?

From the GPIO documentation:

 "value" ... reads as either 0 (low) or 1 (high). If the GPIO
 is configured as an output, this value may be written;
 any nonzero value is treated as high.

 If the pin can be configured as interrupt-generating interrupt
 and if it has been configured to generate interrupts (see the
 description of "edge"), you can poll(2) on that file and
 poll(2) will return whenever the interrupt was triggered. If
 you use poll(2), set the events POLLPRI and POLLERR. If you
 use select(2), set the file descriptor in exceptfds. After
 poll(2) returns, either lseek(2) to the beginning of the sysfs
 file and read the new value or close the file and re-open it
 to read the value.

Is this what you are after?

What action do you need to take when the interrupt fires?

Cheers,

Joel

>
> Previously this was an i2c device that was accessed over i2c and the set of
> interested bits were simply read into the application. An example is the use
> of a pca9552 for presence detection on chassis fans.

Re: GPIO expander user space access(ie. pca9552)

[Patrick Williams]

[-- Attachment #1: Type: text/plain, Size: 1937 bytes --]

On Tue, Jan 24, 2017 at 10:39:25AM +1030, Andrew Jeffery wrote:
> On Mon, 2017-01-23 at 09:58 -0600, Matt Barth wrote:
> > Is there a defined process/interface to access GPIO expanders from user 
> > space to be able to determine when the state changes? Possibly polling a 
> > fd or getting notified on the state change?
> > 
> > Previously this was an i2c device that was accessed over i2c and the set 
> > of interested bits were simply read into the application. An example is 
> > the use of a pca9552 for presence detection on chassis fans.
> 
> I expect it should be implemented as a gpiochip driver in the kernel
> and exposed via the usual methods to userspace (GPIO chardev and sysfs,
> though sysfs is considered deprecated).
> 
> Andrew

There is already leds-pca955x for manipulating a 9552 as an LED
controller.  That chip can also be used as a GPIO expander (moreover, 
individual bits can be configured as a GPIO).  I don't see anything
obvious in the leds-pca955x that allows manipulating the GPIO aspects.

The leds-pca955x also supports 9553 and 9554.  There is also a gpio-pca953x,
which supports the 9554, 9555, and 9556.  There does not currently
appear to be any mechanism, either using leds-... or gpio-... to
manipulate the GPIO settings of a 9552.

The 955[456] chips have an interrupt line that would typically be wired
back to the BMC.  This allow the normal GPIO interrupt to be waited on
(per Joel's email in this stream).  For chips that do not have the
interrupt line, the gpio-pca953x driver gives a 'dev_warn' if you
attempt to register an interrupt.

It isn't typical to have the same i2c chip registered in two subsystems
(leds and gpio) at the same time, is it?  So we would need to get the leds
driver enhanced to also support gpio manipulation?  Since the chip
doesn't support an interrupt line we are also stuck with polling,
correct?

-- 
Patrick Williams

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: GPIO expander user space access(ie. pca9552)

[Andrew Jeffery]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

On Tue, 2017-01-31 at 12:48 -0600, Patrick Williams wrote:
> It isn't typical to have the same i2c chip registered in two subsystems
> (leds and gpio) at the same time, is it?

I wouldn't think so.

>   So we would need to get the leds
> driver enhanced to also support gpio manipulation? 

I would have to take a deeper look.

>  Since the chip
> doesn't support an interrupt line we are also stuck with polling,
> correct?

Yes.

Andrew

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]