[RFC] IIO LRADC for mach-mxs

[Marek Vasut]

> On Jan 24 2012, J.I. Cameron wrote:
> >On Jan 24 2012, Wolfram Sang wrote:
> >>On Tue, Jan 24, 2012 at 02:08:07PM +0100, Marek Vasut wrote:
> >>> Hi guys,
> >>> 
> >>> I've been playing with a custom mxs board recently and I'd like to
> >>> tinker with ADC. Well, apparently there was some effort but it died
> >>> silently.
> >>> 
> >>> Now, there are two approaches how to go about the MXS IIO LRADC.
> >>> Firstly though, here are some hw details:
> >>> 
> >>> 1) The ADC has 16 channels in total, some dedicated to particular
> >>> function 2) The ADC can sample only up to 8 channels at the same time
> >>> 3) The ADC delay triggers can trigger only up to 4 kinds of sampling
> >>> for those up to 8 selected channel
> >>> 
> >>> So how should we go about this:
> >>> 
> >>> A) Implement functions, to configure and select a channel at probe-time
> >>> and then never allow (at runtime) different channel to be selected.
> >>> 
> >>> + Channel configuration is static, passed via plat_data
> >>> + The channels don't need to be reconfigured => when data are demanded,
> >>> the channel doesn't need to be reconfigured (if it's not configured in
> >>> one of those 8 options) and the user doesn't need to wait for data.
> >>> - Only 8 channels can be used
> >>> 
> >>> B) Allow channel to be configured on-demand -- when it's value is
> >>> requested, it is configured (if it's not already) for the particular
> >>> function.
> >>> 
> >>> + All 16 channels can be used
> >>> - It's clunky and fragile to breakage
> >>> - It's hard to implement good channel replacement algo (replacement as
> >>> on the delay triggers and on those 8 slots)
> >>> 
> >>> Which way do you consider better ?
> >>
> >>CCing Jonathan and the iio-list (as found in MAINTAINERS). They probably
> >>have more experience regardings those scenarios?
> >
> >Thanks Wolfram,
> >
> >My instinct is always to make anything configurable at runtime where we
> >can even vaguely conceive of a reason it might be useful.
> >
> >Having said that, right now special function (e.g. input, hwmon directed
> >channels) are currently set up via board files (will be device tree the
> >moment anyone has a need).  I doubt there are many usecases where you'd
> >want to change these functional elements.
> >
> >For your channel replacement strategy these special function channels will
> >be in use if the client is reading form them (e.g. triggered usage). In
> >IIO we only allow for triggering a whole set of channels off a given
> >trigger.  It's going to get really ugly otherwise.  Perhaps the following
> >will work? (I am assuming 0-8 channels can be associated with any of the
> >4 triggers subject to the condition that the total number of channels
> >being captured is less than 8).
> >
> >Register 4 iio devices, each with all 16 channels.  Associate one with
> >each of the triggers.  Driver then maintains a count on channels enabled
> >and refuses to enable more than 8 whatever happens.  You don't have a
> >replacement strategy, you simply refuse to have too many.  We already do
> >this for some of the devices with strange possible channel sets.
> >
> >Any in kernel users (hwmon, input etc) will have to be configured to use
> >the iio device associated with the right trigger.
> >
> >Does that do the job for you?
> >
> >The reason for associating the triggers with different iio devices is that
> >a given iio device can only feed a fixed width scan to the demux unit. 
> >Hence if we have some channels triggering at one time and others at
> >another, there is no way of handling the data stream.  Whilst they are on
> >the same hardware they are really acting as separate devices that just
> >happen to share some pins and control hardware.
> >
> >(Note I'm being useless and not pushing out the new version of in kernel
> >IIO stuff, but I should get to that at the weekend if not before - one
> >fiddly issue with preventing removal of in use devices still to work
> >out.).
> 
> Yikes. This device is more complex than I thought.  The 'triggers' as above
> can also trigger each other alongside causing a set of channels to be
> captured.
> 
> I don't think this changes the logic behind my above answer, but it does
> mean you are going to have some trouble coming up with a control interface
> for the triggers. This may need some core changes to allow for a graph of
> triggers setup (it's not even restricted to a tree).  To illustrate.
> Trigger 1 can fire after T1 secs.  That can then start any other trigger
> (including restarting it's own count down) and/or cause channels to be
> sampled.  Lets say it starts trigger 2 and not itself.  Trigger 2 then
> fires after T2 seconds and starts up Triggers 1 and 3. etc...
> 
> sometimes I think hardware designers go out of their way to make general
> purpose software design really really tricky...

Hi Jonathan,

let's not overcomplicate things. Let's do it like this:

1) Register 4 IIO devices
2) Each device has one delay trigger
3) Each delay trigger can be reconfigured only if it is not used by any channel 
(meaning that on that particular IIO, no channel is opened)
4) We well allow only 8 channels in total
5) Each IIO will have to have attributes -- how many samples it should do, how 
long between them

Are there some utils to test the IIO? Other than sysfs, which won't allow me to 
try continuous sampling of multiple channels.

M