linux-gpio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Kent Gibson <warthog618@gmail.com>
To: Helmut Grohne <helmut.grohne@intenta.de>
Cc: linux-gpio@vger.kernel.org, Linus Walleij <linus.walleij@linaro.org>
Subject: Re: Why is the /dev/gpiochip line event kfifo so small?
Date: Wed, 21 Oct 2020 19:27:18 +0800	[thread overview]
Message-ID: <20201021112718.GA26073@sol> (raw)
In-Reply-To: <20201021090938.GA13202@laureti-dev>

On Wed, Oct 21, 2020 at 11:09:40AM +0200, Helmut Grohne wrote:
> Hi,
> 
> I was looking into using the /dev/gpiochip API to detect pulses. In my
> application, the crucial bit is to precisely identify the start time of
> the pule and the API mostly helps doing that by providing high precision
> kernel timestamps. However, it stuffs them into a kfifo with 16 entries.
> When your hardware is not properly debounced (which it always should,
> but often isn't), that space can fill quickly. Is there a reason to
> limit the API to such a small number of events?
> 
> A single event is 16 bytes. So for every line, we incur 256 bytes of
> kfifo space. This space is only incurred for lines that are actually
> being watched. It seems to me that bumping up this size would not hurt
> badly. Non-realtime applications could then read events after-the-fact
> with a smaller risk of missing ones. I've encountered a full kfifo a
> number of times now.
> 

Debounce support is added in GPIO uAPI v2, as is configurable event buffer
size. And sequence numbers in events to help detect buffer overflows.

Btw, uAPI v2 is currently in train to be included in Linux v5.10.

Cheers,
Kent.


      reply	other threads:[~2020-10-21 11:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-21  9:09 Why is the /dev/gpiochip line event kfifo so small? Helmut Grohne
2020-10-21 11:27 ` Kent Gibson [this message]

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=20201021112718.GA26073@sol \
    --to=warthog618@gmail.com \
    --cc=helmut.grohne@intenta.de \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).