<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Sep 18, 2017 at 12:32 AM, Andrew Jeffery <span dir="ltr"><<a href="mailto:andrew@aj.id.au" target="_blank">andrew@aj.id.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sun, 2017-09-17 at 14:49 -0700, Patrick Venture wrote:<br>
</span><span class="">> > > Those are particulars of a board that now get factored into the<br>
> > > value.  I'm not suggesting something beyond the norms of hwmon.  It<br>
> > > would be convenient however, if the ADC driver could be programmed to<br>
> > > know that some sensor is gated by a GPIO and handled flipping,<br>
> ><br>
> > Can you reach out to Guenter or the relevant maintainer (is this an IIO<br>
> > device?) for ideas here?  I hadn't mentioned it but in the back of my<br>
> > head this whole time I've been wondering about a completely in-kernel<br>
> > solution.<br>
><br>
> I'll reach out and see if this should go into the adc driver or the<br>
> iio-hwmon.  Since those are the paths that are involved.  The sensor<br>
> itself it plugged into the aspeed adc, and then controlled by a<br>
> gpio.  My initial thought is the adc should be configured to know if<br>
> such things are required for its sensors, so that iio-hwmon wouldn't<br>
> need to know.<br>
<br>
</span>My gut feeling is the other way around. There should be some higher-<br>
level driver (i.e. still in the kernel, not in userspace) coordinating<br>
the GPIO and the ADC such that we sample values at the appropriate time<br>
after the GPIO has been set. The ADC driver should be well defined in<br>
terms of the function the ADC hardware provides - gluing in random<br>
GPIOs makes the ADC driver do things the ADC hardware itself does not<br>
do.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'm not across how the iio-hwmon bridge works so I don't know how<br>
trivial it would be to re-export the sampled ADC values from this<br>
higher-level driver as another IIO channel, but that's probably the<br>
approach I would look at to glue it into hwmon.<br>
<br>
That's all just off-the-cuff opinion though, so take it with a grain of<br>
salt. Certainly talking to the IIO and hwmon maintainers is the right<br>
approach.<br></blockquote><div><br></div><div>I'll be broaching this subject in the next few days and will report back here.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
<br>
Andrew</blockquote></div><br></div></div>