Re: [RFC PATCH V2] iio:trigger: Experimental kthread tight loop trigger (thread only)

[Jonathan Cameron <jic23@kernel.org>]

On 01/06/16 15:59, Daniel Baluta wrote:
> On Tue, May 31, 2016 at 8:44 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>>
>>
>> On 31 May 2016 15:43:54 BST, Daniel Baluta <daniel.baluta@intel.com> wrote:
>>> On Sun, Mar 6, 2016 at 10:02 PM, Jonathan Cameron <jic23@kernel.org>
>>> wrote:
>>>> 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.
>>>>
>>>
>>> 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@intel.com>
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.
>