GPIO Centralized Control Daemon

Patrick Venture venture at google.com
Tue Sep 19 00:52:46 AEST 2017


On Mon, Sep 18, 2017 at 12:32 AM, Andrew Jeffery <andrew at aj.id.au> wrote:

> On Sun, 2017-09-17 at 14:49 -0700, Patrick Venture wrote:
> > > > 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.
>
> My gut feeling is the other way around. There should be some higher-
> level driver (i.e. still in the kernel, not in userspace) coordinating
> the GPIO and the ADC such that we sample values at the appropriate time
> after the GPIO has been set. The ADC driver should be well defined in
> terms of the function the ADC hardware provides - gluing in random
> GPIOs makes the ADC driver do things the ADC hardware itself does not
> do.
>

Interesting.  That does make sense, however, one often sees -- some level
of "oh and this" configuration with drivers.  Which I'm in general against,
but it does have a certain cleanness to putting the value update at the
lowest point possible. -- Although, that could easily mean the earliest
place it is read, which is in the hwmon interface -- it can know do flip a
gpio and wait, whereas the ADC just keeps on doing its thing.


>
> I'm not across how the iio-hwmon bridge works so I don't know how
> trivial it would be to re-export the sampled ADC values from this
> higher-level driver as another IIO channel, but that's probably the
> approach I would look at to glue it into hwmon.
>
> That's all just off-the-cuff opinion though, so take it with a grain of
> salt. Certainly talking to the IIO and hwmon maintainers is the right
> approach.
>

I'll be broaching this subject in the next few days and will report back
here.


>
> Cheers,
>
> Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170918/c2f8ebf7/attachment.html>


More information about the openbmc mailing list