All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lars-Peter Clausen <lars@metafoo.de>
To: Octavian Purdila <octavian.purdila@intel.com>, jic23@kernel.org
Cc: linux-iio@vger.kernel.org,
	Srinivas Pandruvada <srinivas.pandruvada@intel.com>
Subject: Re: [RFC 0/8] iio: add support for hardware fifo
Date: Tue, 18 Nov 2014 17:44:31 +0100	[thread overview]
Message-ID: <546B776F.1080800@metafoo.de> (raw)
In-Reply-To: <CAE1zotJny3-Zcd81HUYNpNZJHkt=t6e2TANzVQ=-FU239MLarw@mail.gmail.com>

On 11/18/2014 04:03 PM, Octavian Purdila wrote:
> On Tue, Nov 18, 2014 at 3:24 PM, <jic23@kernel.org> 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

  reply	other threads:[~2014-11-18 16:44 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-17 17:55 [RFC 0/8] iio: add support for hardware fifo Octavian Purdila
2014-11-17 17:55 ` [RFC 1/8] " Octavian Purdila
2014-11-18 13:37   ` jic23
2014-11-18 15:21     ` Octavian Purdila
2014-11-17 17:56 ` [RFC 2/8] iio: bmc150: refactor slope duration and threshold update Octavian Purdila
2014-11-23 21:58   ` Hartmut Knaack
2014-11-23 22:16     ` Octavian Purdila
2014-11-17 17:56 ` [RFC 3/8] iio: bmc150: refactor interrupt enabling Octavian Purdila
2014-11-23 22:02   ` Hartmut Knaack
2014-11-23 22:24     ` Octavian Purdila
2014-11-17 17:56 ` [RFC 4/8] iio: bmc150: exit early if event / trigger state is not changed Octavian Purdila
2014-11-17 17:56 ` [RFC 5/8] iio: bmc150: introduce bmc150_accel_interrupt Octavian Purdila
2014-11-17 17:56 ` [RFC 6/8] iio: bmc150: introduce bmc150_accel_trigger Octavian Purdila
2014-11-23 23:06   ` Hartmut Knaack
2014-11-24 10:42     ` Octavian Purdila
2014-11-24 20:26       ` Hartmut Knaack
2014-11-25 16:06         ` Octavian Purdila
2014-11-17 17:56 ` [RFC 7/8] iio: bmc150: introduce bmc150_accel_event Octavian Purdila
2014-11-17 17:56 ` [RFC 8/8] iio: bmc150: add support for hardware fifo Octavian Purdila
2014-11-18 13:49   ` jic23
2014-11-18 15:31     ` Octavian Purdila
2014-11-24 10:37   ` Hartmut Knaack
2014-11-18 13:24 ` [RFC 0/8] iio: " jic23
2014-11-18 15:03   ` Octavian Purdila
2014-11-18 16:44     ` Lars-Peter Clausen [this message]
2014-11-18 17:04       ` Octavian Purdila
2014-11-18 17:23         ` Lars-Peter Clausen
2014-11-18 19:35           ` Octavian Purdila
2014-11-19 11:48             ` Lars-Peter Clausen
2014-11-19 12:33               ` Octavian Purdila
2014-12-12 12:57                 ` Jonathan Cameron
2014-11-19 13:32             ` Octavian Purdila
2014-11-26 13:06               ` Octavian Purdila
2014-12-01 21:19                 ` Lars-Peter Clausen
2014-12-02  9:13                   ` Octavian Purdila
2014-12-12 13:10                     ` Jonathan Cameron
2014-12-12 13:04               ` Jonathan Cameron
2014-12-12 12:52     ` Jonathan Cameron
2014-11-18 15:35   ` Pandruvada, Srinivas
2014-11-18 16:41   ` Lars-Peter Clausen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=546B776F.1080800@metafoo.de \
    --to=lars@metafoo.de \
    --cc=jic23@kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=octavian.purdila@intel.com \
    --cc=srinivas.pandruvada@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.