GPIO Centralized Control Daemon

[Patrick Venture]

On Sun, Sep 17, 2017 at 9:26 AM, Brad Bishop <bradleyb at fuzziesquirrel.com>
wrote:

> On Sat, 2017-09-16 at 21:22 -0700, Patrick Venture wrote:
> > 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
>
> A good goal.
>
> > 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.
>
> I think if you implement a library with API it becomes a wash.  There
> is also polling to consider - we have a number of applications using
> gpio-keys + libevdev.
>
> >
> > > >
> > > > 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.
>
> We have run into situations like this multiple times.  What we did was
> bind/unbind the driver in question when the hardware behind it becomes
> available.
>
> What do you think of this?
>
> 1 - You simply wiggle the gpio from a script or small application at
>       the appropriate time.
>

My thought here is -- the appropriate time is, right before phosphor-hwmon
wants to read it.


> 2 - An application other than phosphor-hwmon monitors this gpio and
>       binds the driver to it (or unbinds).
>

In this case, won't the device be removed/added to the hwmon sysfs on
demand?  I don't believe phosphor-hwmon picks up new devices automatically.


> 3 - phosphor-hwmon works without modification.
>
> In fact, #2 is already done - Matt Spinler recently added code to
> phosphor-gpio-monitor to do exactly this.
>

I haven't looked at gpio-monitor.


>
> I prefer something like this for two reasons:
>
> 1 - Consistency in how we handle things.  It becomes easier to write
> howtos or cookbooks to provide guidance in the future.
>


> 2 - We avoid one-offs in phosphor-hwmon.
>

I wouldn't necessarily consider it a one-off, as I can immediately think of
at least one other motherboard that would benefit from such an
opportunity.  Also, in this case it would all fit into one nice package --
one thing to configure by adding the corresponding line to a configuration
file.


>
>
> >
> > 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/20170917/37b81d03/attachment-0001.html>