On 11.03.21 16:45, Lars-Peter Clausen wrote:
For simple ADCs, I've also got yet another(more complex) idea:
Create some 'simple-ADC' subsys, which gives a *simple* API for the
*simple* cases that's bridged to iio and hwmon (maybe even other
subsys's). The idea is getting actual hw drivers for those devices very
simple and small, make them usable in IIO as well as hwmon.
Not to forget ALSA. Some ADCs are multi-purpose so that they can be used
for monitoring, but also audio applications.
Oh, how could I forget that ;-)
I did propose such a ADC subsystem maybe 10 years ago. The conclusions
back then was that we shouldn't create a subsystem for every sensor type
and instead use IIO.
I don't think, IIO is a good place here. IIO seems to be kinda catchall
for anything that delivers samples of potentially multiple channels.
That's okay for generic data acquisition, where the OS really can't know
whats behind those IOs right know, and an specific application needs
to take care of that. But it's a bad idea, if the IO has some specific
and fixed purpose, eg. audio input, battery monitoring, etc.
Yes, some of these device classes are already handled by IIO (different
channel types, conversions, ...), but still that needs to be customized
for each use case (the same ADC can be used for many different things),
and often special userland code (eg. in the audio case).
Maybe we need some kind of "policy layer" which tells what some physical
device is used for ...
An interesting question here, that needs some deeper thoughs, is the
driver instantiation into the actual subsystems.
For example, if some DT says, there's some "ti,adcXYZABC" on the board,
what does that actually mean for us ? Where (eg. in which subsys) shall
it appear ? Is it an IIO or hwmon device ? Shall that decision even be
made only by DT, or do we rely on some other configuration layer ?
Yes, that is a really complicated question. DT is not supposed to
describe the software (sub-)systems that are used.
Nore sure, whether that belongs into category "software". Probably a
different one describing the actual use in the greater context of a
complete machine (which might be more than just the mainboard). In the
audio example, it indeed is about hardware, but one that's only
partially reflected in DT.
Maybe should introduce the idea of "composite devices". For DT that
would introduce additional information what that particular ADC is
used for. Could be an extra device_node that describes the audio output,
which just happens to use the ADC as a component:
audio0 {
compatible = "composite,simple-audio";
adc = <&adc1>;
headphone-detect-gpio = <&gpio77>;
...
};
Same could be done w/ other things like battery monitoring, etc.
--mtx
--
---
Hinweis: unverschlüsselte E-Mails können leicht abgehört und manipuliert
werden ! Für eine vertrauliche Kommunikation senden Sie bitte ihren
GPG/PGP-Schlüssel zu.
---
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@xxxxxxxxx -- +49-151-27565287
