Re: [RFC 0/8] iio: add support for hardware fifo

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

 



On Wed, Nov 19, 2014 at 1:48 PM, Lars-Peter Clausen <lars@xxxxxxxxxx> wrote:
> On 11/18/2014 08:35 PM, Octavian Purdila wrote:
>>
>> On Tue, Nov 18, 2014 at 7:23 PM, Lars-Peter Clausen <lars@xxxxxxxxxx>
>> wrote:
>>
>>>>>> As far as I understood, the proposed watermark implementation only
>>>>>> affects the device buffer and as I mentioned above that will not help
>>>>>> with reducing the interrupt rate.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> By setting the watershed level the userspace application tells you that
>>>>> it
>>>>> is OK with getting data with a higher latency than one sample. This
>>>>> allows
>>>>> the driver to configure the FIFO level and hence reduce the interrupt
>>>>> rate.
>>>>>
>>>>
>>>> Hi Lars,
>>>>
>>>> The implementation (as proposed in the patch by Josselin and Yannick)
>>>> does not inform the driver of changes to watermark, that is only
>>>> visible to core iio / buffer logic.
>>>
>>>
>>>
>>> That should be trivial to add though.
>>>
>>
>> True. I've actually started by implementing hardware fifo support as a
>> new type of iio buffer, but I got scared by the buffer demux stuff. I
>> can take another stab at it, if that sounds better?
>>
>>>>
>>>> Also, the watermark alone is not enough to properly support hardware
>>>> fifos: the fifo can operate in multiple modes, we need to read data
>>>> from the hardware fifo even when the watermark interrupt is not issued
>>>> (the flush operation in the current patch set).
>>>
>>>
>>>
>>> What kind of modes are there?
>>>
>>
>> Stream - new values overwrrite old values, Fifo - drop new values.
>
>
> So basically ring buffer) style (old samples are dropped and FIFO style (new
> samples are dropped). This mode should probably be aligned with the mode
> that the sw buffer is working. E.g. you wouldn't want the software buffer to
> work in FIFO mode and the hardware buffer in ring buffer mode. That would
> lead to weird effects.
>

Correct.

> We talked about adding support for ring buffer mode to the software buffer a
> while ago, but so far nobody really needed it so it hasn't been implemented
> yet.
>

This is something that would need ring buffer mode:

https://source.android.com/devices/sensors/batching.html#behavior_in_suspend_mode


Leaving the buffer mode aside, there is another piece that we need for
hardware fifo. We need the ability to flush the fifo data earlier then
the watermark trigger and / or fifo full trigger so that we can
balance power vs latency. It is probably equivalent to the timeout
parameter in the watermark patch.
--
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