GPIO Centralized Control Daemon

[Patrick Venture]

On Sun, Sep 17, 2017 at 2:38 PM, Brad Bishop <bradleyb at fuzziesquirrel.com>
wrote:

>
> > > 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.
>
> Aha!  Now I understand the motivation.  And yes the approach I've
> outlined is quite painful.  In my defense I would not have suggested
> that had I known :-)
>

Ahh - yeah, sorry, I didn't explain the entire use-case path initially.  I
assumed gpio-gated sensors were just a normal thing.

>
> > >
> > > 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 feel different to me.  They are needed for thermistor type
> sensors regardless of board wiring.
>
> > 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,
>
> Can you reach out to Guenter or the relevant maintainer (is this an IIO
> device?) for ideas here?  I hadn't mentioned it but in the back of my
> head this whole time I've been wondering about a completely in-kernel
> solution.
>

I'll reach out and see if this should go into the adc driver or the
iio-hwmon.  Since those are the paths that are involved.  The sensor itself
it plugged into the aspeed adc, and then controlled by a gpio.  My initial
thought is the adc should be configured to know if such things are required
for its sensors, so that iio-hwmon wouldn't need to know.

>
> > 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
>
> It has to be done in one place or the other, does it not?  You mention
> i2c muxes - managing those isn't delegated to userspace (there are
> drivers for i2c muxes) so maybe this situation need not be any
> different?
>

That's what I'm thinking, if I can put it in the driver as something that
can be configured - then perhaps that'll be a neater solution.  Although,
depending on how it gets added, it might be too platform specific.  I'm
using an Aspeed part, but I know there are other manufacturers, and if this
type of arrangement exists elsewhere, more drivers will need modification
in-lieu of a solution at the highest level.  I see the value in both
approaches.

Downstream I have a gpio addition to phosphor-hwmon -- that I'll hold off
on submitting.  I'm going to pursue the modifications to the ADC, I think
they might be appropriate at that level, and if I recall I known the author
and may be able to rapidly implement the necessary modification myself.

>
> > 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
>
> In the very near future I intend to make all the wait/delay/retry
> intervals runtime configurable to handle exactly these kinds of nuances
> between devices and their drivers.
>
> > 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/c84ed221/attachment-0001.html>