|| ||Jonathan Cameron <email@example.com> |
|| ||firstname.lastname@example.org, email@example.com |
|| ||[RFC PATCH 00/21] IIO: Channel registration rework, buffer chardev combining and rewrite of triggers as 'virtual' irq_chips. |
|| ||Thu, 31 Mar 2011 15:53:54 +0100|
|| ||firstname.lastname@example.org, email@example.com,
Jonathan Cameron <firstname.lastname@example.org>|
|| ||Article, Thread
I'm afraid what in many ways makes sense as three separate
series have gotten rather intertwined. I can probably unpick
them but it will involve a lot of intermediate code in
lis3l02dq (which is our fiddly example for this set) that I'd
rather avoid. Hence lets have a guide to what various people
might be interested in:
1) Channel registration rework (this has previous been in linux-iio
but really comes into it's own after we remove various special
cases later in this code).
Patches 1, 2, 3, 21
(8) - cleanups Arnd Bergmann pointed out in passing.
2) Flattening together of (some) of the chardevs (buffer related ones).
As Arnd pointed out, there is really a use case for having multiple
watershed type events from ring buffers. Much better to have a
single one (be that at a controllable point). Firstly this removes
the need for the event escalation code. Second, this single 'event'
can then be indicated to user space purely using polling on the
access chrdev. This approach does need an additional attribute to
tell user space what the poll succeeding indicates (tbd).
I haven't for now merged the ring handling with the more general
event handling as Arnd suggested. This is for two reasons
1) It's much easier to debug this done in a couple of steps
2) The approach Arnd suggested may work well, but it is rather
different to how other bits of the kernel pass event type data
to user space. It's an interesting idea, but I'd rather any
discussion of that approach was separate from the obviously
big gains seen here.
Patches 4, 5, 6, 7, 17
3) Reworking the triggering infrastructure to use 'virtual' irq_chips
This approach was suggested by Thomas Gleixner.
Before we had explicit trigger consumer lists. This made for a very
clunky implementation when we considered moving things over to
threaded interrupts. Thomas pointed out we were reinventing the
wheel and suggested more or less what we have here (I hope ;)
Patches 9 and 10 are minor rearrangements of code in the one
driver I know of where the physical interrupt line for events
is the same as that for data ready signals (though not at the
In a rare situation we have complete control of these virtual
interrupts within the subsystem. As such we want to be able to
continue to build the subsystem as a module. This requires a
couple of additional exports in the generic irq core code and
also arm (for my test board anyway).
Patches 13 and 14 make these changes. I hope they won't prove
Patch 15 adds a board info built in element to the IIO subsystem
so we have a means of platform data telling us what interrupt
numbers are available for us to play with. Does anyone have
a better way of doing this? Patch 16 is an example of what
needs to go in board files.
18, 19 move lis3l02dq over to the threaded interrupts.
20 rips out the old approach. Until this patch current drivers
using the old system should still work. I make no guarantees
about combining consumers of both types though!
Note that this series sits on top of the cleanup series:
[PATCH 0/8] staging:iio:mixed bag of fixes and cleanups
on top of staging-next (which right now might mean mainline is
There are clearly corners to be cleaned up and exact interfaces
elements to be pinned down, but I'd like to get some opinions
on what we have here.
All comments welcomed!
Note, wrt to the recent discussion on a strategy for moving IIO
out of staging, my intent is to pin down these big changes before
we attempt to move these elements out. Note that the initial
steps of that move may occur in parallel with these changes.
Some of these patches may only be applied during that move as
that is a sensible point to update and test every driver.
Thanks to Arnd and Thomas for their contributions to this.
Jonathan Cameron (21):
staging:iio: allow channels to be set up using a table of
staging:iio:lis3l02dq - experimental move to new channel_spec
staging:iio:max1363 - experimental move to channel_spec registration.
staging:iio: remove ability to escalate events.
staging:iio: Add polling of events on the ring access chrdev.
staging:iio: remove legacy event chrdev for the buffers
staging:iio: Buffer device flattening.
staging:iio:lis3l02dq: General cleanup
staging:iio: Push interrupt setup down into the drivers for event
staging:iio: lis3l02dq - separate entirely interrupt handling for
thesholds from that for the datardy signal.
staging:iio: Remove legacy event handling.
staging:iio:lis3l02dq make threshold interrupt threaded.
arm: irq: export set flags
irq: export handle_simple_irq and irq_to_desc to allow for virtual
irqs in IIO
staging:iio: Add infrastructure for irq_chip based triggers
stargate2 - add an IIO interrupt pool
staging:iio:Documentation generic_buffer.c update to new abi for
staging:iio:ring_sw add function needed for threaded irq.
staging:iio:lis3l02dq move to threaded trigger handling.
staging:iio:trigger remove legacy pollfunc elements.
staging:iio: rip out scan_el attributes. Now handled as
iio_dev_attrs like everything else.
arch/arm/kernel/irq.c | 1 +
arch/arm/mach-pxa/stargate2.c | 6 +-
drivers/staging/Makefile | 2 +-
drivers/staging/iio/Documentation/generic_buffer.c | 53 +-
drivers/staging/iio/Kconfig | 12 +
drivers/staging/iio/Makefile | 2 +
drivers/staging/iio/accel/lis3l02dq.h | 25 +-
drivers/staging/iio/accel/lis3l02dq_core.c | 700 +++++-------
drivers/staging/iio/accel/lis3l02dq_ring.c | 421 +++----
drivers/staging/iio/adc/max1363.h | 8 +-
drivers/staging/iio/adc/max1363_core.c | 1277 ++++++++------------
drivers/staging/iio/adc/max1363_ring.c | 1 -
drivers/staging/iio/chrdev.h | 33 +-
drivers/staging/iio/iio-board-info.h | 24 +
drivers/staging/iio/iio-core.h | 13 +
drivers/staging/iio/iio.h | 250 +++--
drivers/staging/iio/industrialio-board-info.c | 25 +
drivers/staging/iio/industrialio-core.c | 724 ++++++++---
drivers/staging/iio/industrialio-ring.c | 315 +++---
drivers/staging/iio/industrialio-trigger.c | 150 ++--
drivers/staging/iio/ring_generic.h | 79 +-
drivers/staging/iio/ring_sw.c | 42 +-
drivers/staging/iio/ring_sw.h | 1 +
drivers/staging/iio/sysfs.h | 152 +--
drivers/staging/iio/trigger.h | 68 +-
kernel/irq/chip.c | 1 +
kernel/irq/irqdesc.c | 1 +
27 files changed, 2116 insertions(+), 2270 deletions(-)
create mode 100644 drivers/staging/iio/iio-board-info.h
create mode 100644 drivers/staging/iio/iio-core.h
create mode 100644 drivers/staging/iio/industrialio-board-info.c
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/