On 11/18/2014 04:03 PM, Octavian Purdila wrote:
On Tue, Nov 18, 2014 at 3:24 PM, <jic23@xxxxxxxxxx> wrote:
[...]
Hence we started with something that at least superficially (I haven't
had a chance to go through the implementation in detail yet)
looks similar to what you have but ended up changing the method of
signalling to and from userspace.
Hardware buffer -> Software buffer -> user space.
Userspace watershed control -> Software buffer watershed control
-> Hardware buffer watershed control.
If userspace sets the watershed to say 16 then, as well as setting
that level in the software buffer it should be passed on to the
device driver allowing the watershed there to be set appropriately.
Now things get interesting if userspace sets the watershed to a value
that makes no sense for the hardware (say 17 on a device that does
power of 2 values only) as then it will have to fall back to
grabbing every one (Watershed of 1). Perhaps we can provide 'hints'
for this?
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.
- Lars
--
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
