From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Message-ID: <546B776F.1080800@metafoo.de> Date: Tue, 18 Nov 2014 17:44:31 +0100 From: Lars-Peter Clausen MIME-Version: 1.0 To: Octavian Purdila , jic23@kernel.org CC: linux-iio@vger.kernel.org, Srinivas Pandruvada Subject: Re: [RFC 0/8] iio: add support for hardware fifo References: <1416246966-3083-1-git-send-email-octavian.purdila@intel.com> <20141118132405.EF30A40277@saturn.retrosnub.co.uk> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed List-ID: On 11/18/2014 04:03 PM, Octavian Purdila wrote: > On Tue, Nov 18, 2014 at 3:24 PM, 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