[RFC] IIO LRADC for mach-mxs

[Jonathan Cameron]

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. 

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.