* Re: Question about differential muxing
2016-04-18 12:05 ` Lars-Peter Clausen
@ 2016-04-18 13:42 ` jic23
2016-04-18 14:25 ` Daniel Baluta
1 sibling, 0 replies; 7+ messages in thread
From: jic23 @ 2016-04-18 13:42 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Jonathan Cameron, Andrew F. Davis, linux-iio, linux-iio-owner
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Question about differential muxing
2016-04-18 12:05 ` Lars-Peter Clausen
2016-04-18 13:42 ` jic23
@ 2016-04-18 14:25 ` Daniel Baluta
1 sibling, 0 replies; 7+ messages in thread
From: Daniel Baluta @ 2016-04-18 14:25 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: Jonathan Cameron, Andrew F. Davis, linux-iio@vger.kernel.org
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.
^ permalink raw reply [flat|nested] 7+ messages in thread