Re: ADS1018 ADC driver

[Michael Welling <mwelling@ieee.org>]

On Wed, Sep 23, 2015 at 02:45:14AM -0500, Michael Welling wrote:
> On Wed, Sep 23, 2015 at 06:59:56AM +0100, Jonathan Cameron wrote:
> > There is a rather slow process to separate entirely the back and front end
> >  of IIO.  This would get you to what you are describing (with a bit of front end
> >  work to set up the mapping to joystick axes).  This was driven initially by the soc
> >  guys who have one multichannel ADC doing a dozen unconnected things. Mark Brown in particular.
> > 
> > Right now all IIO drivers still instantiate the userspace interface (for now users
> >  who don't care ignore it). We then had in kernel channel mappings to allow client
> >  drivers access to most OHIO hardware interfaces.  The classic example is iio-hwmon
> >  though there are other users all over the place. The input bridge (which is too
> >  simple to support you joystick example at the mo) has been languishing outside
> > Mainline for years due issues with the mapping and instantiation interfaces.
> >
>  
> This is further along than I realized.
> 
> Looking at inkern.c and drivers that use the interface should get me started.
> 
> I will also look further into the input bridge and uinput.
> 
> > Hopefully the addition of config fs support for instantiation of 'virtual'
> >  hardware in IIO will finally give us a way around that.
> > 
> > Anyhow what works now:
> > 
> > 1. polled channel value and basic property reading (eg iio-hwmon)
> >
> > 2. Pushed (historically called buffered in IIO) data flows with channel demux (so clients only get a stream of data covering what they requested.  Actually the demux is widely used by the IIO frontend as well.
> > 
> > What is missing.
> > 1. Event support for stuff like thresholds. Not hard to add but not done yet.  Could initially skip demuxing events and specify filtering must be done in the client.
> > 
> > Interface gets a little fiddly as necessary to lock which events are enabled in some
> >  cases to stop another client disabling them as a side effect. Lots of hardware
> >  has complex constraints on which events are enabled. Traditionally with only 
> > one userspace this was userspace problem to deal with!
> > 
> > 2. Property range exporting. This is useful for IIO userspace as well.
> > 
> > 3. Allowing IIO on top of iio.
> > 
> > 4. Dropping always having IIO userspace.
> > 
> > Mostly this work has stalled as I have very little time to work on it anymore.
> > If you are interested then ask for more details on any of the above.
> 
> First I will focus on constructing the new driver for the ADS1018.
>

It appears that the hardware is being revised and a different ADC is going to
be used on the revision. That mean this driver fell off of my queue.

I was kind of looking forward writing it... oh well.

Sorry for the noise.

> Which of these missing pieces would find the most use?
> 
> > 
> > >
> > >>
> > >>Guenter
> >