From: Jonathan Cameron <jic23@kernel.org>
To: linux-iio@vger.kernel.org
Cc: 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/3] Add push based interfce for non userspace iio users
Date: Sat, 3 Mar 2012 12:09:08 +0000 [thread overview]
Message-ID: <1330776551-20301-1-git-send-email-jic23@kernel.org> (raw)
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 (3):
staging:iio: make all buffer access pass through the buffer_list
staging:iio: add a callback buffer for in kernel push interface
staging:iio: Proof of concept input driver.
drivers/staging/iio/Kconfig | 16 +
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 | 46 ++
drivers/staging/iio/gyro/adis16260_ring.c | 8 +-
drivers/staging/iio/iio.h | 8 +
drivers/staging/iio/iio_input.c | 106 +++++
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/meter/ade7758_ring.c | 25 +-
32 files changed, 740 insertions(+), 455 deletions(-)
create mode 100644 drivers/staging/iio/buffer_cb.c
create mode 100644 drivers/staging/iio/iio_input.c
--
1.7.9.2
next reply other threads:[~2012-03-03 12:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-03 12:09 Jonathan Cameron [this message]
[not found] ` <1330776551-20301-4-git-send-email-jic23@kernel.org>
2012-03-04 16:11 ` [PATCH 3/3] staging:iio: Proof of concept input driver Dmitry Torokhov
2012-03-07 11:18 ` Jonathan Cameron
2012-03-07 14:57 ` Linus Walleij
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=1330776551-20301-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=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).