Re: GPIO Centralized Control Daemon

[Brad Bishop <bradleyb@fuzziesquirrel.com>]

On Sat, 2017-09-16 at 21:22 -0700, Patrick Venture wrote:
> On Sat, Sep 16, 2017 at 3:12 PM, Brad Bishop
> <bradleyb@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.
2 - An application other than phosphor-hwmon monitors this gpio and
      binds the driver to it (or unbinds).
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 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'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
> > 
> 
>