GPIO Centralized Control Daemon

[Patrick Venture]

On Sat, Sep 16, 2017 at 3:12 PM, Brad Bishop <bradleyb at fuzziesquirrel.com>
wrote:

> Hi Patrick
>
> On Thu, 2017-09-14 at 15:02 -0700, Patrick Venture wrote:
> > I apologize if this already exists or is in the works.
> >
> > I propose we create a daemon that centralizes userspace GPIO access.
> >
> > From a high level, the daemon will implement interfaces to export or
> > unexport GPIOs.  Each GPIO exported will exist on the dbus:
> >
> > /xyz/openbmc_project/gpio/53 and implement an interface with the
> > following properties:
> > value, direction, active_low, etc.
>
> Just thinking out loud...are we sure a gpio is a useful abstraction?
> If applications all just use the chardev API what is the benefit of
> having a dbus object, at the cost of API complexity.
>

As an alternative, perhaps a library would suffice.  My goal is to avoid
multiple in-application implementations.  However, I felt it might be
helpful to have some centralized daemon serving this information -- a
simple dbus property access may be simpler than either implementing the
ioctl in each application.  However, a library may also provide the
necessary abstraction.


>
> >
> > Some doubts, should the gpio name on the dbus be the relative name
> > (53), should it be the system specific name (G5) or the absolute
> > name?  I'm thinking the relative name and let the daemon handle
> > internalizing the adjustment from relative to absolute.
> >
> > I'm working on adding GPIO support within phosphor-hwmon so that I
> > can access a voltage sensor that's gated by a GPIO, and I know there
>
> Can you elaborate on what gated means?  Is it you have to wiggle a GPIO
> before the hwmon driver for this voltage sensor can actually access the
> sensor hardware?
>
> There is a GPIO that controls whether the battery sensor on the quanta
board (and I've heard of similar configurations on others) that needs to be
set high for the sensor to work.  I implemented a bit of a hack in
phosphor-hwmon to allow one to specify a GPIO that needs to be flipped in
this type of configuration.  I'd consider submitting the patch, however it
uses the sysfs interface -- as this saved a little implementation time.

I'd be willing to fix it up to use the proper interface and submit it
upstream if that's something helpful -- or seek out a good library for us
to use -- I'm also open to suggestions on this.

>
> > have been conversations and implementations of this for IPMI OEM --
> > and I think it could easily be centralized.
> >
> > Thoughts?
> >
> > Patrick
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170916/ee3fdde7/attachment.html>