]> git.kernelconcepts.de Git - karo-tx-linux.git/commit
iio:trigger: Experimental kthread tight loop trigger (thread only)
authorJonathan Cameron <jic23@kernel.org>
Sun, 6 Mar 2016 20:02:56 +0000 (20:02 +0000)
committerJonathan Cameron <jic23@kernel.org>
Fri, 3 Jun 2016 12:18:44 +0000 (13:18 +0100)
commitbc2e1126eccb47517b9d1c685020c38600f99a3d
tree32cf77c8edd41b1925e3e328ef10e580f9bf4e24
parent27aa832d1882da4b6595abe99e287f46b2d54f45
iio:trigger: Experimental kthread tight loop trigger (thread only)

This patch is in response to that of
Gregor Boirie <gregor.boirie@parrot.com>
who proposed using a tight kthread within a device driver (be it with the
support factored out into a helper library) in order to basically spin as
fast as possible.

It is meant as a talking point rather than a formal proposal of the code
(though we are heading towards that I think).
Also gives people some working code to mess around with.

I proposed that this could be done with a trigger with a few constraints
and this is the proof (be it ugly) of that.

There are some constraints though, some of which we would want to relax
if this were to move forward.

* Will only run the thread part of the registered pollfunc.  This is to
  avoid the overhead of jumping in and out of interrupt context.  Is the
  overhead significant?  Not certain but feels like it should be!

* This limitation precludes any device that 'must' do some work in
  interrupt context.  However, that is true of few if any drivers and
  I suspect that any that do will be restricted to using triggers they
  provide themselves.  Usually we have a top half mainly to grab a
  timestamp as soon after the dataready type signal as possible.

Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Acked-by: Daniel Baluta <daniel.baluta@intel.com>
drivers/iio/trigger/Kconfig
drivers/iio/trigger/Makefile
drivers/iio/trigger/iio-trig-loop.c [new file with mode: 0644]