[RFC] IIO LRADC for mach-mxs

[Marek Vasut]

> On 01/26/2012 10:30 AM, Marek Vasut wrote:
> >> 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?
> 
> There are two elements to this.  Pull devices (hwmon type - basicallyl
> polled from userspace) and push device (off trigger).
> 
> The connection infrastructure is the same either way.  A version was
> reasonably widely reviewed but picked up some last minute comments that
> I have addressed in my dev tree but not pushed out more publically
> (small issue with order of module removal causing seg faults I need to
> chase down).
> 
> Anyhow, discussion wise...
> 
> https://lkml.org/lkml/2011/10/20/103
> http://www.spinics.net/lists/linux-iio/msg03930.html
> 
> Code wise, if you want to see the latest I just tend to hide my dev
> trees under odd names on kernel.org currentlly see.
> http://git.kernel.org/?p=linux/kernel/git/jic23/iio.git;a=shortlog;h=refs/h
> eads/inkern-staging3
> 
> To outline briefly the current form (after working on Greg KHs
> comments). (pretty similar to regulators).
> 
> In board file (or device tree - not implemented yet) platform data
> describing the consumers of channels on a given iio device is
> provided as an array of
> 
> struct iio_map {
> 	const char *adc_channel_label;
> 	struct device *consumer_dev;
> 	const char *consumer_dev_name;
> 	const char *consumer_channel;
> };
> 
> The driver then passes and a pointer to the associate iio_device
> to the core.
> 
> Lets take the more complex triggered capture case.
> 
> A consumer asks the iio_core for all iio_maps that match it (can request
> individual ones of course).
> 
> This causes a new buffer to be inserted into a list that are fed
> by a demux unit into which data goes directly from the chip.
> This buffer is alongside any 'iio' buffers that are using the same
> part (and may contain some of the same channels).
> 
> It simply calls a callback function provided by the consumer passing
> in a block of data matching one set of channels as requested by the
> consumer.
> 
> Example in the tree mentioned above is a half written iio->input
> bridge.   We had some brief discussions a while back about how to
> handle the extra weirdness that touchscreen adcs use and didn't
> reach any firm conclusions IIRC.
> 
> I'd imagine you'll need to expand some elements of this to support
> your usecase.  For starters there is no inkernel control of trigger
> parameters at the moment.
> 
> All comments welcome.  I'll hopefully get a few mins to get the
> pull interface stuff out shortly then we can start hammering the
> push interface bit and for real fun how to combine the two.

Jonathan ... I'm getting seriously lost in this stuff. Basically:

1) Are there any userland utilities at all to test the IIO ? If so, where?
2) I can't do anything if I don't understand how whole this IIO works at all 
and/or how to use it with my hardware.

So I'm still trying to wrap my head around this.

Considering my hardware can do the oversampling (sum of 1 - 32 samples 12bit 
samples), where the end of sampling causes an interrupt. I need to add 
attributes to each of those four IIO devices I created to control this 
oversampling (setting how many times it should be oversampled and what's the 
delay inbetween the sampling?)

Or that's what that "trigger" stuff is for ?

Further question:
3) If I want to sample two channels continuously, is there any tool that'll 
allow me to do it ? Or do I need to write such tool? (This is complementary to 
question #1).

Thanks

M
> 
> Jonathan
> 
> > 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