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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux