All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Welling <mwelling@ieee.org>
To: Jonathan Cameron <jic23@jic23.retrosnub.co.uk>
Cc: Guenter Roeck <linux@roeck-us.net>, linux-iio@vger.kernel.org
Subject: Re: ADS1018 ADC driver
Date: Wed, 23 Sep 2015 02:45:14 -0500	[thread overview]
Message-ID: <20150923071958.GA30278@deathstar> (raw)
In-Reply-To: <131939B9-E3B7-4E98-B0E2-7DF8F2C081BC@jic23.retrosnub.co.uk>

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.

Which of these missing pieces would find the most use?

> 
> >
> >>
> >>Guenter
>

  parent reply	other threads:[~2015-09-23  7:45 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-21 22:06 ADS1018 ADC driver Michael Welling
2015-09-22  1:04 ` Guenter Roeck
2015-09-22  1:27   ` Michael Welling
2015-09-22  2:04     ` Guenter Roeck
2015-09-22  2:57       ` mwelling
     [not found]         ` <131939B9-E3B7-4E98-B0E2-7DF8F2C081BC@jic23.retrosnub.co.uk>
2015-09-23  7:45           ` Michael Welling [this message]
2015-10-20 17:16             ` Michael Welling

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150923071958.GA30278@deathstar \
    --to=mwelling@ieee.org \
    --cc=jic23@jic23.retrosnub.co.uk \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux@roeck-us.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.