GPIO Centralized Control Daemon

[Patrick Venture]

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

>
> > >
> > > 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.
>
> phosphor-hwmon shouldn't be providing an interface for something
> that isn't accessible.  And it shouldn't concern itself with
> making something accessible because there could be any number of
> ways to do that, based on the wiring of the board.
>
> What I meant was why is the sensor gated by a gpio?  For example, is it
> because the sensor is only available when some power domain is actually
> powered on?  In that example, the appropriate time would be when
> the power domain is turned on and off.
>
> Is it just stuck behind a gpio for no reason?  If that is the case, I
> would think you just wiggle the gpio when the bmc boots.
>

In this particular case, it's behind a GPIO so it doesn't drain the battery
-- or at least that's my understanding of the design.

The appropriate time would be -- when someone tries to read it from the
host.  What you're suggesting is that, the ipmi daemon, when it receives a
request for this sensor - that is then launches something that sets the
gpio, and then waits for the dbus objects to exist from the launched
phosphor-hwmon, before then requesting the sensor value in its normal
course of action.  Because it's my understanding it's a gated sensor so
that it doesn't drain the battery, which means leaving it open effectively
permanently isn't an option.  If I'm misunderstanding the goal of the
design, then obviously just unlocking the GPIO effectively permanently is a
solution.


>
> >
> > > 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.
>
> Yes, on demand, but he phosphor-layer has a udev rule that launches
> (and terminates) a phosphor-hwmon instance along with it.
>
> >
> > > 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'm not arguing that there aren't several board setups where this is
> the case.  Rather, board designers are free to do whatever they want,
> and if we start putting the board specific logic in phosphor-hwmon you
> won't have "one nice package" for very long....
>

True-ish.  This is quite similar to dealing with GAIN and OFFSET.  Those
are particulars of a board that now get factored into the value.  I'm not
suggesting something beyond the norms of hwmon.  It would be convenient
however, if the ADC driver could be programmed to know that some sensor is
gated by a GPIO and handled flipping, waiting, reading, and flipping-back
for someone -- quasi-similarly to i2c muxes that use gpios.  Except,
obviously, the waiting and setting it back part are ... a bad plan to build
into a driver, in that it could delay returning a value.  Although -- one
could argue the fan speed controller driver does that -- takes time to
respond.  It's just, one would then also want to configure the wait time,
because some configurations will take longer for a sensor value to
stabilize.

Patrick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170917/033d7105/attachment.html>