Question about differential muxing

Question about differential muxing

[Andrew F. Davis]

Hello all,

I am currently working on a driver for a part similar to the AFE4300. I
was hoping to get some information on the recommended way to handle a
mux such as the one in the AFE4300 BCM front-end (page 13 of
http://www.ti.com/lit/ds/symlink/afe4300.pdf has a good image).

The top several pins are outputs that can be routed to the OP-AMP, but
only one at a time, because of this I'm not sure if they should be
exposed as output channels, or sysfs switches.

The other issue is with the input pins, I believe the standard way to
handle this is by exposing every mux setting as a separate channel, then
only allowing one bit set in the scan mask, but for this part, when all
differential combinations are exposed we have more than 100 channels,
and the other part I'm working on makes this several times worse.

Could someone point to any information, or an existing driver, that
explains the preferred way to handle this?

Thanks,
Andrew

Re: Question about differential muxing

[Jonathan Cameron]

On 15/04/16 19:42, Andrew F. Davis wrote:
> Hello all,
> 
> I am currently working on a driver for a part similar to the AFE4300. I
> was hoping to get some information on the recommended way to handle a
> mux such as the one in the AFE4300 BCM front-end (page 13 of
> http://www.ti.com/lit/ds/symlink/afe4300.pdf has a good image).
That's marginally bonkers..

You do seem to get the weird and wonderful ;)  I'd never appreciated
some of these weird devices existed!  Much more interesting than
the average ADC.
> 
> The top several pins are outputs that can be routed to the OP-AMP, but
> only one at a time, because of this I'm not sure if they should be
> exposed as output channels, or sysfs switches.
So they are outputs the whole time?  But sometime internally fed back
in to that amplifier.. both connecting to the input and output...

Is there a finite list of what the outputs can actually be at any time?
I'm not sure if we can map this onto standard output channels or not.

It's described in the text as selecting between 6 contact points and
4 impedances so I'll pretend I can see exactly how the circuit is doing that
as this is far too much thinking for a Saturday afternoon.

If treated as output channels it would have to be done on a last come
basis with the others all being set to 0.  That's fine under the ABI that
allows for any value to result in a change to any other but clunky.

Hmm. Treating it as output channels does kind of match with how the device
is used I think?  Fire a current out of pointN and read the resulting
voltage between 2 points (one of which might be a reference)...

It's all channels, there is just a lot of restrictions on what can happen
at a time.

> 
> The other issue is with the input pins, I believe the standard way to
> handle this is by exposing every mux setting as a separate channel, then
> only allowing one bit set in the scan mask, but for this part, when all
> differential combinations are exposed we have more than 100 channels,
> and the other part I'm working on makes this several times worse.
> 
> Could someone point to any information, or an existing driver, that
> explains the preferred way to handle this?
You have it correct above.  At the end of the day there isn't much we can
do to provide a compact yet general interface and occasionally we do end
up with an awful lot of channels.  There are some analog devices battery
chargers for example that end up as a cascade resulting in similar numbers
of channels.

Each channel doesn't cost us that much other than making for a big set of
files. 

Doing it as mux switches would work, but be extremely difficult to describe
simply to userspace in any way that would generalize.  The resulting programs
would have to know too much about the sensor routing or to have a lot
of complexity decoding how to set up the channel combinations they actually
want.

As for existing drivers... Hmm. any of the differential ADC drivers provide a
reference of sorts. For high channel counts, the ad7280a driver is still in
staging but the principles are fine...

Lars, any input on this sort of highly complex device?  Looks a bit like some
of the more nuts audio chips in some ways.

Jonathan
> 
> Thanks,
> Andrew
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: Question about differential muxing

[Andrew F. Davis]

On 04/16/2016 08:18 AM, Jonathan Cameron wrote:
> On 15/04/16 19:42, Andrew F. Davis wrote:
>> Hello all,
>>
>> I am currently working on a driver for a part similar to the AFE4300. I
>> was hoping to get some information on the recommended way to handle a
>> mux such as the one in the AFE4300 BCM front-end (page 13 of
>> http://www.ti.com/lit/ds/symlink/afe4300.pdf has a good image).
> That's marginally bonkers..
> 
> You do seem to get the weird and wonderful ;)  I'd never appreciated
> some of these weird devices existed!  Much more interesting than
> the average ADC.

I do wish one of these days they put a regular ADC on my desk, but what
fun would that be :)

>>
>> The top several pins are outputs that can be routed to the OP-AMP, but
>> only one at a time, because of this I'm not sure if they should be
>> exposed as output channels, or sysfs switches.
> So they are outputs the whole time?  But sometime internally fed back
> in to that amplifier.. both connecting to the input and output...
> 
> Is there a finite list of what the outputs can actually be at any time?
> I'm not sure if we can map this onto standard output channels or not.
> 

Yes, the list is technically finite, but any combination of one pin for
output and one for feedback is valid.

> It's described in the text as selecting between 6 contact points and
> 4 impedances so I'll pretend I can see exactly how the circuit is doing that
> as this is far too much thinking for a Saturday afternoon.
> 

It's been far to much thinking for my work-week too :) I think in the
data sheet they make the assumption that the PR0/1 and RN0/1 will be
connected external to a reference load, then any 2 pin combo of IOUTx
pins will be used to actually transmit. But this is not a hard
requirement so I don't really want to limit the device by not providing
a way to connect the combo IOUT3 and RN1, for instance.

> If treated as output channels it would have to be done on a last come
> basis with the others all being set to 0.  That's fine under the ABI that
> allows for any value to result in a change to any other but clunky.
> 

This was my concern, it seems kinda odd to automatically disable an
output when enabling another, but if it's explicitly allowed I'll do it.

> Hmm. Treating it as output channels does kind of match with how the device
> is used I think?  Fire a current out of pointN and read the resulting
> voltage between 2 points (one of which might be a reference)...
> 

I really don't know myself about all this, but the way it was explained
to me is that the user will connect a transmitter (for testing they gave
me simple resistors, so some kind of resistive load) between the output
pins, then they will read the value across a receiver (again probably
just some contacts with the subjects skin tied to a pair of input pins),
by switching between different transmit/receiver pairs placed at
different points and frequencies (and polarities I believe) you can get
a map of body impedance.

So I would like every combination of pins exposed in some way if I can.

> It's all channels, there is just a lot of restrictions on what can happen
> at a time.
> 

Yeah, I also like them as channels as you can set the frequency sent to
the output pins using the standard IIO_CHAN_INFO_FREQUENCY.

>>
>> The other issue is with the input pins, I believe the standard way to
>> handle this is by exposing every mux setting as a separate channel, then
>> only allowing one bit set in the scan mask, but for this part, when all
>> differential combinations are exposed we have more than 100 channels,
>> and the other part I'm working on makes this several times worse.
>>
>> Could someone point to any information, or an existing driver, that
>> explains the preferred way to handle this?
> You have it correct above.  At the end of the day there isn't much we can
> do to provide a compact yet general interface and occasionally we do end
> up with an awful lot of channels.  There are some analog devices battery
> chargers for example that end up as a cascade resulting in similar numbers
> of channels.
> 
> Each channel doesn't cost us that much other than making for a big set of
> files. 
> 

What about for buffered reads, active_scan_mask seems to be sent as bits
in a 64bit variable, does this then lead to a hard limitation of 64
channels?

> Doing it as mux switches would work, but be extremely difficult to describe
> simply to userspace in any way that would generalize.  The resulting programs
> would have to know too much about the sensor routing or to have a lot
> of complexity decoding how to set up the channel combinations they actually
> want.
> 

Maybe:

#cat in_voltage3_mux_available
VSENSE0
VSENSERP1
etc..
#echo VSENCE4 > in_voltage3_mux

or such for each real ADC channel with a mux in-front of it?

> As for existing drivers... Hmm. any of the differential ADC drivers provide a
> reference of sorts. For high channel counts, the ad7280a driver is still in
> staging but the principles are fine...
> 

Okay, I'll give that a look.

Thanks,
Andrew

> Lars, any input on this sort of highly complex device?  Looks a bit like some
> of the more nuts audio chips in some ways.
> 
> Jonathan

Re: Question about differential muxing

[Lars-Peter Clausen]

On 04/16/2016 03:18 PM, Jonathan Cameron wrote:
[...]
>> The other issue is with the input pins, I believe the standard way to
>> handle this is by exposing every mux setting as a separate channel, then
>> only allowing one bit set in the scan mask, but for this part, when all
>> differential combinations are exposed we have more than 100 channels,
>> and the other part I'm working on makes this several times worse.
>>
>> Could someone point to any information, or an existing driver, that
>> explains the preferred way to handle this?
> You have it correct above.  At the end of the day there isn't much we can
> do to provide a compact yet general interface and occasionally we do end
> up with an awful lot of channels.  There are some analog devices battery
> chargers for example that end up as a cascade resulting in similar numbers
> of channels.
> 
> Each channel doesn't cost us that much other than making for a big set of
> files. 
> 
> Doing it as mux switches would work, but be extremely difficult to describe
> simply to userspace in any way that would generalize.  The resulting programs
> would have to know too much about the sensor routing or to have a lot
> of complexity decoding how to set up the channel combinations they actually
> want.
> 
> As for existing drivers... Hmm. any of the differential ADC drivers provide a
> reference of sorts. For high channel counts, the ad7280a driver is still in
> staging but the principles are fine...
> 
> Lars, any input on this sort of highly complex device?  Looks a bit like some
> of the more nuts audio chips in some ways.

In my opinion we need to model MUXs and assorted sequencers properly in IIO
and not hide the real hardware topology behind a simplified view. It causes
all kinds of trouble since it obfuscates the real behavior of the device and
makes it very hard for generic applications to understand what is going on.

It worked somewhat OK, when we had a simple hardware with a single fixed
sequencer where you could easily expose the sequencer settings as multiple
channels. But even for those what we expose to userspace is wrong. We only
get a single scan set for all enabled channels with a single timestamp, even
though when you use a sequencer these measurements are not taken at the same
time.

More recent hardware usually has a completely freely programmable sequencer,
this means it is possible to e.g. have a sample sequence like 1,2,1,3,...
this can currently not be modeled. We can't model sequences where one
channel is sampled more often than other and we can't model sequences where
the channel order is different from the default. Both are valid use cases
and not being able to support them hurts framework adoption. And even if
we'd model all the possible combinations we get a combinatorial explosion of
channels where only a subset can be selected at the same time which requires
complex validation routines.

There is also hardware with multiple ADCs, where each ADC has it's own MUX
and own sequencer and the ADCs do synchronous conversion. This is a
extension of the above case, which we can't model for similar reasons.

And then you have the case where you have external MUXs. These can either be
used together with internal sequencer or a external sequencer (e.g. just
some GPIOs). We can't model these either with the current approach since the
driver for the ADC would need to have support for the specific external MUX,
which doesn't really scale if you want to support different types of MUXs.

While this part only has a single ADC, it has multiple chained MUXs. Since
they are all internal you could model them as a single MUX and then by
extension the single ADC as multiple channels, but as Andrew said that leads
to state explosion, especially with the feedback paths.

Btw. I found the Comedi approach quite interesting:
http://www.comedi.org/doc/index.html#acquisitionterminology

Looking back I think this was one of the biggest mistakes we made in the IIO
ABI design, thinking that it was OK to hide the hardware complexities behind
a simplified view (Part of the problem is that the scope of IIO has grown
and back then we didn't really thing about the more complex usecases). If
you simplify at the lowest level there it is not possible to get the more
complex hardware representation which might be required for certain
applications. And to workaround the limitations you end up with all kind of
hacks and heuristics and hardware specific interfaces. On the other hand if
you adequately describe the hardware itself at the lowest level you can get
the information to those applications which need it and for those who don't
need it you can built simplified views on top.

Similar approaches can be seen in the e.g. the audio world, where ALSA
exposed the raw hardware capabilities and pulseaudio provides a simplified
view for simple applications. Or e.g. in the video world you now have the
new Vulcan API which exposes the raw hardware capabilities and simplified
APIs like OpenGL and DirectX are being built on top of it rather than being
at the lowest level themselves.

- Lars

Re: Question about differential muxing

[Lars-Peter Clausen]

On 04/17/2016 08:44 PM, Andrew F. Davis wrote:
[...]
> 
> What about for buffered reads, active_scan_mask seems to be sent as bits
> in a 64bit variable, does this then lead to a hard limitation of 64
> channels?

It's a bitmask constructed from an array of 64-bit words. It's only limited
by the memory your system has.

Re: Question about differential muxing

[jic23]

On 18.04.2016 13:05, Lars-Peter Clausen wrote:
> On 04/16/2016 03:18 PM, Jonathan Cameron wrote:
> [...]
>>> The other issue is with the input pins, I believe the standard way to
>>> handle this is by exposing every mux setting as a separate channel, 
>>> then
>>> only allowing one bit set in the scan mask, but for this part, when 
>>> all
>>> differential combinations are exposed we have more than 100 channels,
>>> and the other part I'm working on makes this several times worse.
>>> 
>>> Could someone point to any information, or an existing driver, that
>>> explains the preferred way to handle this?
>> You have it correct above.  At the end of the day there isn't much we 
>> can
>> do to provide a compact yet general interface and occasionally we do 
>> end
>> up with an awful lot of channels.  There are some analog devices 
>> battery
>> chargers for example that end up as a cascade resulting in similar 
>> numbers
>> of channels.
>> 
>> Each channel doesn't cost us that much other than making for a big set 
>> of
>> files.
>> 
>> Doing it as mux switches would work, but be extremely difficult to 
>> describe
>> simply to userspace in any way that would generalize.  The resulting 
>> programs
>> would have to know too much about the sensor routing or to have a lot
>> of complexity decoding how to set up the channel combinations they 
>> actually
>> want.
>> 
>> As for existing drivers... Hmm. any of the differential ADC drivers 
>> provide a
>> reference of sorts. For high channel counts, the ad7280a driver is 
>> still in
>> staging but the principles are fine...
>> 
>> Lars, any input on this sort of highly complex device?  Looks a bit 
>> like some
>> of the more nuts audio chips in some ways.
> 
> In my opinion we need to model MUXs and assorted sequencers properly in 
> IIO
> and not hide the real hardware topology behind a simplified view. It 
> causes
> all kinds of trouble since it obfuscates the real behavior of the 
> device and
> makes it very hard for generic applications to understand what is going 
> on.
Conversely it makes for an interface that is simple to use.  I'd like to 
maintain
that simplicity (but allow for the complexity as well!) Just to make 
life
harder ;)
> 
> It worked somewhat OK, when we had a simple hardware with a single 
> fixed
> sequencer where you could easily expose the sequencer settings as 
> multiple
> channels. But even for those what we expose to userspace is wrong. We 
> only
> get a single scan set for all enabled channels with a single timestamp, 
> even
> though when you use a sequencer these measurements are not taken at the 
> same
> time.
The intent there was always to support description of the relative 
timings - we'd
need to do that for any sequencer description anyway.  The comedi stuff 
does
precisely that sort of description for example (and includes the various 
elements
that we would need).  It got discussed at various times, but hasn't 
actually
gotten implemented yet.  Worth keeping in mind that the description of 
this
stuff can obviously get very complex.  Setup times can vary depending on 
the
exact sequence for example.
> 
> More recent hardware usually has a completely freely programmable 
> sequencer,
> this means it is possible to e.g. have a sample sequence like 
> 1,2,1,3,...
> this can currently not be modeled. We can't model sequences where one
> channel is sampled more often than other and we can't model sequences 
> where
> the channel order is different from the default. Both are valid use 
> cases
> and not being able to support them hurts framework adoption. And even 
> if
> we'd model all the possible combinations we get a combinatorial 
> explosion of
> channels where only a subset can be selected at the same time which 
> requires
> complex validation routines.
The complex sequencer is indeed a case we currently dodge around at the 
moment.
It's actually worse than you describe as we can also have interleved 
multiple
sequences on different clocks that interact with each other and have 
priority
levels... The sort of hardware that I'm not sure can be described in 
less than
a few pages of big diagrams.

I have no problem with proposals to support this sort of complexity - 
even a
wholesale replacement for the scan_elements stuff is fine - though 
ideally any
such new framework would allow that also to work as it does cover the 
most common
case (or would with a little extra description).

There are devices out there that support effectively unlimited sequencer 
lengths
- how do we support those?  They stop being a scan in any sense - but 
become an
arbitrary stream of readings.  The meta data itself becomes complex 
enough that
you can't really put it in the buffers either.  Perhaps if we restrict 
things to
a 'short' length then things can remain manageable.  This stuff gets 
really hard
to describe really quickly - even when you describe the muxes 
explicitly.

Funnily enough the other really nasty cases to describe generically are 
internal
sequencers.  Often, though there is a general MUX in the part supporting 
any
combination, the sequencer only supports a random (complicated) subset 
of
possible sequences.  Those would need describing as well... Or we are 
back to
the complex validation logic that currently causes us trouble.  That's 
what drove
the available_scan_masks approach in the first place (good old max1363 
and
friends)
> 
> There is also hardware with multiple ADCs, where each ADC has it's own 
> MUX
> and own sequencer and the ADCs do synchronous conversion. This is a
> extension of the above case, which we can't model for similar reasons.

This is also reasonable to want to fully support, but how do you 
describe it?
As you've highlighted the simple read one channel with a given mux setup 
is
straight forward.  How do you provide sane meta data to set up a 
sequence of
such readings with multiple muxes switching (possibly several levels 
deep) to
multiple ADCs?

I think you'd have to apply some sort of model that limits what can 
happen if
you want a userspace interface (even via a library) that can describe 
such muxes.
That's kind of where we ended up with a description based on what was 
actually
read, rather than how it was done.

Perhaps step one in any work on this is to define the model we are going 
to
apply.  I'm not sure we can make it arbitrary. Even Vulkan defines a 
fairly
strict model it seems.
> 
> And then you have the case where you have external MUXs. These can 
> either be
> used together with internal sequencer or a external sequencer (e.g. 
> just
> some GPIOs). We can't model these either with the current approach 
> since the
> driver for the ADC would need to have support for the specific external 
> MUX,
> which doesn't really scale if you want to support different types of 
> MUXs.

Sure - this one has been bothering me for a while.  Conceptually we 
could handle
this as the mux being a client device of the IIO ADC, effectively 
reformatting
the buffered data as it passes through (In fact I think we may 
ultimately do
it this way, even if we have a better description of muxes in general)

The same is true for any front end device - we ultimately need to invert 
whatever
the front end has done to establish what the original input is.  This 
could be
as simple as a potential divider halving the voltage.  That could be 
done as
a simple consumer driver that pushes the data straight through but 
adjusts the
reported scale.  An external MUX (not driven by a device based 
sequencer) is much
the same. Synchronizing could get a little 'exciting', but shouldn't be 
impossible
using input and output buffers running off the same triggers.

A device driven external sequencer is to my mind the same as one inside 
the device.
It might need a little more description of course and there may be 
places
to sensibly use library code to help handle it (some of which may be 
shared with
the external muxes support).

> 
> While this part only has a single ADC, it has multiple chained MUXs. 
> Since
> they are all internal you could model them as a single MUX and then by
> extension the single ADC as multiple channels, but as Andrew said that 
> leads
> to state explosion, especially with the feedback paths.
> 
> Btw. I found the Comedi approach quite interesting:
> http://www.comedi.org/doc/index.html#acquisitionterminology
> 
> Looking back I think this was one of the biggest mistakes we made in 
> the IIO
> ABI design, thinking that it was OK to hide the hardware complexities 
> behind
> a simplified view (Part of the problem is that the scope of IIO has 
> grown
> and back then we didn't really thing about the more complex usecases). 
> If
> you simplify at the lowest level there it is not possible to get the 
> more
> complex hardware representation which might be required for certain
> applications. And to workaround the limitations you end up with all 
> kind of
> hacks and heuristics and hardware specific interfaces. On the other 
> hand if
> you adequately describe the hardware itself at the lowest level you can 
> get
> the information to those applications which need it and for those who 
> don't
> need it you can built simplified views on top.

I still think we need that simple view, even at the kernel boundary.  I 
think
that if we'd gone straight for the most complex option we would have 
ended up
with poor adoption due to the barrier to entry that would provide.

The intent was always to fall back to an interface no more complex than
hwmon and I think having that was and is vital to the subsystem.  When a 
device
is simple, it should look simple.

> 
> Similar approaches can be seen in the e.g. the audio world, where ALSA
> exposed the raw hardware capabilities and pulseaudio provides a 
> simplified
> view for simple applications. Or e.g. in the video world you now have 
> the
> new Vulcan API which exposes the raw hardware capabilities and 
> simplified
> APIs like OpenGL and DirectX are being built on top of it rather than 
> being
> at the lowest level themselves.
> 
It's an interesting balance for where you provide the exposure of this 
complexity.

I have no objection at all to providing a means to describe this 
complexity.
We certainly aren't limited to what we currently have in the way of 
interface.

However, we are dealing with a nasty case - you could I suppose compare 
it to an
alsa system with dozens of parallel channels - each with a mux / 
processing
description that could be a large number levels deep. Each of which has 
a variable
timing offset wrt to the others. Every element in a scan needs it's own 
description
of how it is muxed... At least in ALSA type devices you tend to have 
only a few
paths going on at a time.

It's fiddly and I'm not certain we can get to an ultimate answer to 
everything
in one go (we certainly haven't so far!).
In the meantime we have to work with what we have.  If we have 
oversimplified a
particular device description to make it work with current frameworks, 
then as long
as the defaults are right, nothing stops us adding more interface to 
describe it
better in the future!

Jonathan

Re: Question about differential muxing

[Daniel Baluta]

On Mon, Apr 18, 2016 at 3:05 PM, Lars-Peter Clausen <lars@metafoo.de> wrote:
> On 04/16/2016 03:18 PM, Jonathan Cameron wrote:
> [...]
>>> The other issue is with the input pins, I believe the standard way to
>>> handle this is by exposing every mux setting as a separate channel, then
>>> only allowing one bit set in the scan mask, but for this part, when all
>>> differential combinations are exposed we have more than 100 channels,
>>> and the other part I'm working on makes this several times worse.
>>>
>>> Could someone point to any information, or an existing driver, that
>>> explains the preferred way to handle this?
>> You have it correct above.  At the end of the day there isn't much we can
>> do to provide a compact yet general interface and occasionally we do end
>> up with an awful lot of channels.  There are some analog devices battery
>> chargers for example that end up as a cascade resulting in similar numbers
>> of channels.
>>
>> Each channel doesn't cost us that much other than making for a big set of
>> files.
>>
>> Doing it as mux switches would work, but be extremely difficult to describe
>> simply to userspace in any way that would generalize.  The resulting programs
>> would have to know too much about the sensor routing or to have a lot
>> of complexity decoding how to set up the channel combinations they actually
>> want.
>>
>> As for existing drivers... Hmm. any of the differential ADC drivers provide a
>> reference of sorts. For high channel counts, the ad7280a driver is still in
>> staging but the principles are fine...
>>
>> Lars, any input on this sort of highly complex device?  Looks a bit like some
>> of the more nuts audio chips in some ways.
>
> In my opinion we need to model MUXs and assorted sequencers properly in IIO
> and not hide the real hardware topology behind a simplified view. It causes
> all kinds of trouble since it obfuscates the real behavior of the device and
> makes it very hard for generic applications to understand what is going on.
>
> It worked somewhat OK, when we had a simple hardware with a single fixed
> sequencer where you could easily expose the sequencer settings as multiple
> channels. But even for those what we expose to userspace is wrong. We only
> get a single scan set for all enabled channels with a single timestamp, even
> though when you use a sequencer these measurements are not taken at the same
> time.
>
> More recent hardware usually has a completely freely programmable sequencer,
> this means it is possible to e.g. have a sample sequence like 1,2,1,3,...
> this can currently not be modeled. We can't model sequences where one
> channel is sampled more often than other and we can't model sequences where
> the channel order is different from the default. Both are valid use cases

I'm particularly interested in this and working on a proposal to allow some sort
of metadata attached with the buffer elements.

For example, this would be very useful with IMU drivers where sampling frequency
is different for separate sensors. With the current implementation we
either create
different IIO devices for IMU subsensors or use one IIO device with
the limitation
that we cannot use different sampling frequencies.


> and not being able to support them hurts framework adoption. And even if
> we'd model all the possible combinations we get a combinatorial explosion of
> channels where only a subset can be selected at the same time which requires
> complex validation routines.
>
> There is also hardware with multiple ADCs, where each ADC has it's own MUX
> and own sequencer and the ADCs do synchronous conversion. This is a
> extension of the above case, which we can't model for similar reasons.
>
> And then you have the case where you have external MUXs. These can either be
> used together with internal sequencer or a external sequencer (e.g. just
> some GPIOs). We can't model these either with the current approach since the
> driver for the ADC would need to have support for the specific external MUX,
> which doesn't really scale if you want to support different types of MUXs.
>
> While this part only has a single ADC, it has multiple chained MUXs. Since
> they are all internal you could model them as a single MUX and then by
> extension the single ADC as multiple channels, but as Andrew said that leads
> to state explosion, especially with the feedback paths.
>
> Btw. I found the Comedi approach quite interesting:
> http://www.comedi.org/doc/index.html#acquisitionterminology
>
> Looking back I think this was one of the biggest mistakes we made in the IIO
> ABI design, thinking that it was OK to hide the hardware complexities behind
> a simplified view (Part of the problem is that the scope of IIO has grown
> and back then we didn't really thing about the more complex usecases). If
> you simplify at the lowest level there it is not possible to get the more
> complex hardware representation which might be required for certain
> applications. And to workaround the limitations you end up with all kind of
> hacks and heuristics and hardware specific interfaces. On the other hand if
> you adequately describe the hardware itself at the lowest level you can get
> the information to those applications which need it and for those who don't
> need it you can built simplified views on top.
>
> Similar approaches can be seen in the e.g. the audio world, where ALSA
> exposed the raw hardware capabilities and pulseaudio provides a simplified
> view for simple applications. Or e.g. in the video world you now have the
> new Vulcan API which exposes the raw hardware capabilities and simplified
> APIs like OpenGL and DirectX are being built on top of it rather than being
> at the lowest level themselves.

Agree with all of these. Let's hope we can make some improvements without
increasing the complexity.

Daniel.