On Tue, May 31, 2016 at 8:44 PM, Jonathan Cameron <jic23@xxxxxxxxxx> wrote: > > > On 31 May 2016 15:43:54 BST, Daniel Baluta <daniel.baluta@xxxxxxxxx> wrote: >>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. > > To change trigger the buffer will be disabled ultimately calling the state > function with false. That calls kthread_stop and the loop should drop > out with the tread exiting. This makes sense. I missed the disable buffer thing. Acked-by: Daniel Baluta <daniel.baluta@xxxxxxxxx> We shouldn't forget about updating Documentation: http://lxr.free-electrons.com/source/Documentation/iio/iio_configfs.txt#L75 I should do the same for software IIO devices. 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