+linux-iio On Mon, Sep 18, 2017 at 10:45 PM, Joel Stanley <joel@xxxxxxxxx> wrote: > > Hey Patrick, > > On Tue, Sep 19, 2017 at 2:55 AM, Patrick Venture <venture@xxxxxxxxxx> wrote: > > I have a system where there is a GPIO gating whether a line to the ADC is > > active. I'm routing the ADC channels through iio-hwmon. > > > > I'm considering that it might be prudent to tell iio-hwmon that it needs to > > set the GPIO and wait some configurable amount of time before trying to read > > that channel. > > > > https://github.com/torvalds/linux/blob/master/drivers/hwmon/iio_hwmon.c#L43 > > > > I'm curious if there are strong thoughts about whether that kind of thing > > belongs in that level or whether it should be pushed to the aspeed_adc > > driver. > > That's a tricky one. > > I'd suggest the code to flip the GPIO should go in the aspeed_adc.c, > and failing that in the iio subsystem, not in the hwmon bridge. Ok, so I can extend the properties of the aspeed_adc to support specifying a GPIO per channel, and then add the logic to handle this possible per channel configuration. I had to ask, but I assume there's some standard to how these things are specifying in the device-tree. For instance, each fan has its own configuration under the aspeed-pwm-tacho driver, so arguably it could be channel@{index} to specify for whichever have such a requirement. > > I assume this GPIO needs to be switched at runtime (ie, it's not > something that is muxed one way or the other at boottime and left > static)? Correct. > > Is it a case that the GPIO should be asserted while the ADC is > sampling, and then deasserted afterwards? That is also correct. > > > Also, please let me know if I'm not reaching the correct people for this > > particular discussion. > > You could instead go to the iio list. > > Cheers, > > Joel -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
