On 01/06/16 15:59, Daniel Baluta wrote: > 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> Thanks, Applied to the togreg branch of iio.git. > > 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. > Good point - please kick me if I don't get to the is sometime in the next week or two. Jonathan > 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
