On Sun, Mar 6, 2016 at 10:02 PM, Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > This patch is in response to that of > Gregor Boirie <gregor.boirie@xxxxxxxxxx> > 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. > Configfs part looks good to me. What happens with iio_loop_thread when changing the current trigger? I'm not sure how it will be stopped. thanks, Daniel. -- To unsubscribe from this list: send the line "unsubscribe linux-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
