On 19/11/14 12:33, Octavian Purdila wrote: > 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 > Hmm.. This gets ugly if we have a hardware ring buffer feeding a software ring buffer. For remotely consistent data I guess we'd have to dump the software buffer whenever we grab data from the hardware buffer that has overflowed. > > 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. Not really as the timeout could be trivially implemented in userspace and didn't cause a flush. The suggestion I made earlier of flushing the buffer if an attempt to read more from the software buffer than it contains is made. This wouldn't happen in our 'normal' e.g. current usage. > -- 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
