linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@cam.ac.uk>
To: linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org
Cc: broonie@opensource.wolfsonmicro.com, zdevai@gmail.com,
	linus.walleij@linaro.org, Jonathan Cameron <jic23@cam.ac.uk>
Subject: [PATCH RFC] IIO: Proof of concept in kernel interface.
Date: Tue, 11 Oct 2011 12:43:02 +0100	[thread overview]
Message-ID: <1318333383-17663-1-git-send-email-jic23@cam.ac.uk> (raw)

Hi All,

Given I keep blithely stating it would be easy to add an in kernel
interface to IIO, I thought I'd better actually prove it.

There are numerous holes / questions raised by this example.

1) We need a foolproof way of getting the right instance of
a given device.  This PoC does it by part name (unique on my
test board but far from it in general).
The snag as ever is the complexity of getting a reliable reference
to an i2c or spi part.  Basically it's the same problem fudged
over in the regulator framework.

2) Callbacks for triggered read.  Not done here and given the flexibility
of IIO triggers it's not obvious how to do it.  Most other subsystems
pretty much assume they will get a stream of data and do not control
what causes it to appear.  With IIO I we'll either need in kernel control
of this (fiddly as it really isn't that generalizable), assume
sane default settings or have a userspace daemon to set it up.

3) How much hand holding to do.  Right now it gives raw access to the device,
equivalent to what the IIO core has.  Is it worth doing error checking utility
functions such as

int iio_consumer_read_data(struct iio_dev *indio_dev, int channel, enum iio_type type);
which would do stuff like verify the channel exists and that it
is the right sort of channel. Can also use this to 'hide' the
struct iio_dev etc from the consumer drivers.

If people are happy with the general form and we nail the
association problem, I'll write a general hwmon interface
to do simple hardware monitoring from an adc channel.
For now I'd keep it completely trivial and avoid events etc.

So comments welcome,

This sits on a couple of patches that haven't gone upstream yet, so
best bet is probably

https://github.com/jic23/linux-iio/tree/inkern

which also has the dummy driver for anyone who wants to play
and doesn't have hardware.


Jonathan Cameron (1):
  staging:iio:proof of concept in kernel interface.

 drivers/staging/iio/Kconfig             |    5 ++++
 drivers/staging/iio/Makefile            |    3 ++
 drivers/staging/iio/iio.h               |    5 ++++
 drivers/staging/iio/industrialio-core.c |   38 ++++++++++++++++++++++++++++
 drivers/staging/iio/inkern.c            |   41 +++++++++++++++++++++++++++++++
 5 files changed, 92 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/iio/inkern.c

-- 
1.7.3.4

             reply	other threads:[~2011-10-11 11:43 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-11 11:43 Jonathan Cameron [this message]
2011-10-11 11:43 ` [PATCH] staging:iio:proof of concept in kernel interface Jonathan Cameron
2011-10-13 14:32   ` Mark Brown
2011-10-13 14:46     ` Jonathan Cameron
2011-10-13 20:44       ` Mark Brown
2011-10-14 15:59         ` Jonathan Cameron
2011-10-14 19:33           ` Mark Brown
2011-10-16 18:45           ` Linus Walleij
2011-10-17  9:39             ` Mark Brown
2011-10-17  9:44               ` Jonathan Cameron
2011-10-17  9:43             ` Jonathan Cameron
2011-10-17 10:19               ` Mark Brown
2011-10-17 10:32                 ` Jonathan Cameron
2011-10-17 10:46                   ` Mark Brown
2011-10-17 11:13                     ` Jonathan Cameron
2011-10-17 11:18                       ` Mark Brown
2011-10-17 11:32                         ` Jonathan Cameron
2011-10-17 12:08                           ` Mark Brown
2011-10-17 12:31                             ` Jonathan Cameron
2011-10-17 12:48                               ` Mark Brown
2011-10-17 13:03                                 ` Jonathan Cameron
2011-10-17 13:55                                   ` Mark Brown
2011-10-17 14:05                                     ` Jonathan Cameron
2011-10-17 13:55               ` Linus Walleij
2011-10-17 14:01                 ` Jonathan Cameron

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=1318333383-17663-1-git-send-email-jic23@cam.ac.uk \
    --to=jic23@cam.ac.uk \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zdevai@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).