[RFC] IIO LRADC for mach-mxs

[Marek Vasut]

> Marek Vasut <marek.vasut at gmail.com> wrote:
> >> 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
> 
> Yes. See the documentation directory. Your plan sounds sensible.

All right. Also, what did you mean by wiring touchscreen and such? I assume I'd 
rather think about it in the design too, but how should I go about it? Let the 
iio driver be a composite device that in turn registers another (input) device? 
Or simply put the touchscreen driver input drivers/input/ and export some calls 
from the IIO driver to allow the touchscreen driver somehow bind with it?

M