From: Jonathan Cameron <jic23@kernel.org>
To: linux-iio@vger.kernel.org
Cc: device-drivers-devel@blackfin.uclinux.org, greg@kroah.com,
dmitry.torokhov@gmail.com, broonie@opensource.wolfsonmicro.com,
alan@lxorguk.ukuu.org.uk, arnd@arndb.de,
linus.walleij@linaro.org, maxime.ripard@free-electrons.com,
thomas.petazzoni@free-electrons.com, zdevai@gmail.com,
w.sang@pengutronix.de, marek.vasut@gmail.com,
Jonathan Cameron <jic23@kernel.org>
Subject: [RFC PATCH 0/4 V2] Add push based interface for non userspace iio users
Date: Tue, 10 Apr 2012 21:38:10 +0100 [thread overview]
Message-ID: <1334090294-23407-1-git-send-email-jic23@kernel.org> (raw)
Changes since V1
Fixups as per Dmitry's email.
New element for the mapping to allow us to pass consumer related channel
specific data to the consumer driver. Here it's the fuzz etc bits for
input.
The input driver needs more testing, but I wanted this version out in
the hope that I would get some feedback on just how many drivers are
broken by the first patch!
That and I foolishly promissed an update earlier. Might be dependent
on something in the various trees I sent out earlier. I've been lazy
and not checked but I have it after them locally.
Jonathan
previous version text:
This set is large and relatively invasive. The first important thing
to verify is that the first patch doesn't break any of the existing
drivers.
Taking the patches in turn. Firstly this currenty should only effect
devices with software buffers so when I say buffers that is what I mean
in this description.
1) Re route all pushing to software buffers via iio_push_to_buffers.
We also need to modify drivers to make them aware of the fact that
they may well be pushing to multiple buffers. Where possible I
have done this by making use of iio_sw_buffer_preenable and adding
pre demux scan element size computation to the core (as this was
repeated quite a few times in drivers). Basically I've almost
certainly broken someone's driver so please test this one!
2) Now all drivers (that support buffers at all) should handle multiple
buffers we add a trivial call back buffer implementation. This simply
calls a callback function with new scans of data as and when they
are available.
3) A very rough and ready proof of concept for an input driver that
uses iio in a similar way to the hwmon driver that merged a few
days back. Clearly this needs more work!
One little question this 3rd patch raises is how we get board specific
details about channels into an iio consumer device. Here I thinking
things like 'fuzz' values for input.
To that end what do people think of adding a void *consumer_data
pointer to the struct iio_chan_map structure?
Other than that it's worth noting that this interface uses
exactly the same interface from the point of view of board files
as the pull interface does. (Hopefully avoiding what proved the most
controversial bit last time!).
One other practical issue post this patch set is that we can currently
only have either polled or interrupt driven clients of iio devices
but not both. I have some thoughts on how to deal with this as it
is obviously import to some SoC adc users.
Another future project will be making a cleaner break between those
buffering elements to do with the IIO direct userspace interface
and those used by other consumer drivers. If it looks like we
bolted on the in kernel users side of things that is because we
did!
Jonathan
Jonathan Cameron (4):
staging:iio: make all buffer access pass through the buffer_list
staging:iio: add a callback buffer for in kernel push interface
staging:iio:in kernel users: Add a data field for channel specific
info.
staging:iio: Proof of concept input driver.
drivers/staging/iio/Kconfig | 18 +
drivers/staging/iio/Makefile | 2 +
drivers/staging/iio/accel/adis16201_ring.c | 9 +-
drivers/staging/iio/accel/adis16203_ring.c | 11 +-
drivers/staging/iio/accel/adis16204_ring.c | 8 +-
drivers/staging/iio/accel/adis16209_ring.c | 9 +-
drivers/staging/iio/accel/adis16240_ring.c | 9 +-
drivers/staging/iio/accel/lis3l02dq_ring.c | 9 +-
drivers/staging/iio/adc/ad7192.c | 27 +-
drivers/staging/iio/adc/ad7298.h | 1 -
drivers/staging/iio/adc/ad7298_ring.c | 31 +-
drivers/staging/iio/adc/ad7476.h | 1 -
drivers/staging/iio/adc/ad7476_ring.c | 40 +-
drivers/staging/iio/adc/ad7606_ring.c | 11 +-
drivers/staging/iio/adc/ad7793.c | 26 +-
drivers/staging/iio/adc/ad7887.h | 1 -
drivers/staging/iio/adc/ad7887_ring.c | 28 +-
drivers/staging/iio/adc/ad799x.h | 1 -
drivers/staging/iio/adc/ad799x_ring.c | 27 +-
drivers/staging/iio/adc/max1363_ring.c | 6 +-
drivers/staging/iio/buffer.h | 24 +-
drivers/staging/iio/buffer_cb.c | 115 +++++
drivers/staging/iio/consumer.h | 48 ++
drivers/staging/iio/gyro/adis16260_ring.c | 8 +-
drivers/staging/iio/iio.h | 8 +
drivers/staging/iio/iio_input.c | 176 ++++++++
drivers/staging/iio/iio_input.h | 23 +
drivers/staging/iio/iio_simple_dummy_buffer.c | 16 +-
drivers/staging/iio/impedance-analyzer/ad5933.c | 14 +-
drivers/staging/iio/imu/adis16400_ring.c | 6 +-
drivers/staging/iio/industrialio-buffer.c | 553 ++++++++++++++---------
drivers/staging/iio/industrialio-core.c | 1 +
drivers/staging/iio/inkern.c | 1 +
drivers/staging/iio/machine.h | 2 +
drivers/staging/iio/meter/ade7758_ring.c | 25 +-
35 files changed, 840 insertions(+), 455 deletions(-)
create mode 100644 drivers/staging/iio/buffer_cb.c
create mode 100644 drivers/staging/iio/iio_input.c
create mode 100644 drivers/staging/iio/iio_input.h
--
1.7.9.4
next reply other threads:[~2012-04-10 20:38 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-10 20:38 Jonathan Cameron [this message]
2012-04-10 20:38 ` [PATCH 1/4] staging:iio: make all buffer access pass through the buffer_list Jonathan Cameron
2012-04-16 15:59 ` Lars-Peter Clausen
2012-04-16 20:40 ` Jonathan Cameron
2012-04-10 20:38 ` [PATCH 3/4] staging:iio:in kernel users: Add a data field for channel specific info Jonathan Cameron
2012-04-10 20:38 ` [PATCH 4/4] staging:iio: Proof of concept input driver 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=1334090294-23407-1-git-send-email-jic23@kernel.org \
--to=jic23@kernel.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arnd@arndb.de \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=device-drivers-devel@blackfin.uclinux.org \
--cc=dmitry.torokhov@gmail.com \
--cc=greg@kroah.com \
--cc=linus.walleij@linaro.org \
--cc=linux-iio@vger.kernel.org \
--cc=marek.vasut@gmail.com \
--cc=maxime.ripard@free-electrons.com \
--cc=thomas.petazzoni@free-electrons.com \
--cc=w.sang@pengutronix.de \
--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).