From: Alexandre Belloni <email@example.com>
To: William Breathitt Gray <firstname.lastname@example.org>
Cc: Mark Rutland <email@example.com>,
Kamel Bouhara <firstname.lastname@example.org>,
Dmitry Torokhov <email@example.com>,
Ludovic Desroches <firstname.lastname@example.org>,
Rob Herring <email@example.com>,
Thomas Petazzoni <firstname.lastname@example.org>,
Subject: Re: [PATCH 0/3] Introduce a counter inkernel API
Date: Sun, 12 Apr 2020 01:31:45 +0200 [thread overview]
Message-ID: <20200411233145.GC3628@piout.net> (raw)
On 11/04/2020 13:22:59-0400, William Breathitt Gray wrote:
> I'm not inherently opposed to adding an in-kernel API for the Counter
> subsystem, but I'm not sure yet if it's necessary for this particular
> Is the purpose of this driver to allow users to poll on the rotary
> encoder position value? If so, perhaps instead of an in-kernel API, the
> polling functionality should be added as part of the Counter subsystem;
> I can see this being a useful feature for many counter devices, and
> it'll keep the code contained to a single subsystem.
> By the way, I'm going to be submitting a major update to the Counter
> subsystem code in the next couple weeks that isolates the sysfs code
> from the rest of the subsystem -- it'll likely affect the interface and
> code here -- so I'll probably wait to decide for certain until that
> patch lands; I anticipate it making things easier for you here after
> it's merged.
> For now, I want to get a better high-level understanding about how users
> would interact with this driver to use the device (input_setup_polling
> is a new call for me). That should help me understand whether an
> in-kernel API is the best choice here.
Well, the goal is not really polling the counters but mainly exposing
the correct userspace interface for the rotary encoders that are
connected to quadrature decoders.
The input driver is using polling because this reduces the complexity of
the patches but the ultimate goal is to also have interrupts working.
I'm pretty sure the in-kernel interface can also have other usages like
for example iio triggers. I could envision having to read an ADC after x
turns of a motor to check for the torque.
I also think that having the sysfs code separate would help as it could
be considered as one of the in-kernel interface user.
BTW, do you have plans to add a character device interface?
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
linux-arm-kernel mailing list
next prev parent reply other threads:[~2020-04-11 23:31 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-06 15:58 [PATCH 0/3] Introduce a counter inkernel API Kamel Bouhara
2020-04-06 15:58 ` [PATCH 1/3] counter: add an " Kamel Bouhara
2020-04-10 17:34 ` Randy Dunlap
2020-04-11 9:58 ` Kamel Bouhara
2020-04-06 15:58 ` [PATCH 2/3] Input: rotary-encoder-counter: add DT bindings Kamel Bouhara
2020-04-07 9:41 ` Maxime Ripard
2020-04-07 11:03 ` Kamel Bouhara
2020-04-07 14:22 ` Maxime Ripard
2020-04-07 14:55 ` Kamel Bouhara
2020-04-09 22:21 ` Dmitry Torokhov
2020-04-09 22:39 ` Alexandre Belloni
2020-04-09 23:46 ` Dmitry Torokhov
2020-04-11 10:43 ` Kamel Bouhara
2020-04-06 15:58 ` [PATCH 3/3] Input: add a rotary encoders based on counter devices Kamel Bouhara
2020-04-11 17:22 ` [PATCH 0/3] Introduce a counter inkernel API William Breathitt Gray
2020-04-11 23:31 ` Alexandre Belloni [this message]
2020-04-12 1:48 ` William Breathitt Gray
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).