On 04/06/10 19:19, Mark Brown wrote: > On 6 Apr 2010, at 17:25, Jonathan Cameron <jic23@xxxxxxxxx> wrote: > >> On 04/06/10 16:27, Liam Girdwood wrote: >>>> >>>> >>>> >>> >>> I suppose this is something we may look into more when we have more >>> clients. >> Makes sense. There will probably be quite a few IIO drivers over the >> next >> few months doing much the same as sht15, where the voltage ref for >> devices >> may well be fed by a regulator. In that case, we may only offer the >> option >> of using an external v_ref if the regulator is available. Many >> devices have >> an internal regulator to provide it so typically we'll start them up >> using that >> and provide an interface to switch to external regulator if one is >> available. >> I haven't thought through exactly how this will work as yet. I'll cc >> people in >> when this comes up. > > TBH this seems like a very vanilla use case - there may be some small > advantage to representing the internal regulator via the regulator API > but that's about the only thing I can think might be a bit odd. > I wasn't thinking of representing the internal regulator using the regulator framework (though if it is externally available I guess that would make sense though probably only if anyone is actually using this to supply something else - most likely case I can think of is daisy chaining multiple adc's and ensuring they have the same reference value). The case I'm interested in is the externally supplied voltage reference. This typically comes off a fixed regulator or a spare regulator on a pmic. The use case is getting this voltage (and indeed buffering it using the same notifier approach as in sht15). This is needed to provide api compliant info to userspace (which needs sufficient info to work out what the actual value is). I'd imagine similar cases occur in some hwmon devices. Basically all these uses look just like that in sht15. Nothing new here, but there will be a number of consumers that care about changes in voltage (rather than typically controlling it.) Hence I'm welcoming the change just agreed upon. Thanks, Jonathan _______________________________________________ lm-sensors mailing list lm-sensors@xxxxxxxxxxxxxx http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
