On Tue, Nov 18, 2014 at 9:35 PM, Octavian Purdila <octavian.purdila@xxxxxxxxx> 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? > OK, I remembered why I bailed on that approach: it would break the callback buffer. It looks like the buffer cb infrastructure relies on a push model and for a hardware fifo implemented as a iio buffer we would need a pull model. While there is one driver that takes this approach (sca3000_ring.c) it is in staging and the hardware buffer part seems to be marked as RFC. BTW, I didn't find any users for the buffer cb infrastructure, what is it used for? -- 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
