Re: [PATCH v3 0/3] counter: add GPIO-based quadrature encoder driver

[Wadim Mueller]

On 2026-05-04 18:36, William Breathitt Gray wrote:
> On Fri, May 01, 2026 at 10:07:46PM +0200, Wadim Mueller wrote:
> > This series adds a new counter subsystem driver that implements
> > quadrature encoder position tracking using plain GPIO pins with
> > edge-triggered interrupts.
> > 
> > The driver is intended for low to medium speed rotary encoders where
> > hardware counter peripherals (eQEP, FTM, etc.) are unavailable or
> > already in use. It targets the same use-cases as interrupt-cnt.c but
> > provides full quadrature decoding instead of simple pulse counting.
> > 
> > Features:
> >   - X1, X2, X4 quadrature decoding and pulse-direction mode
> >   - Optional index signal for zero-reset
> >   - Configurable ceiling (position clamping)
> >   - Standard counter subsystem sysfs + chrdev interface
> >   - Enable/disable via sysfs with IRQ gating
> > 
> > Tested on TI AM64x (Cortex-A53) with a motor-driven rotary encoder
> > at up to 2 kHz quadrature edge rate.
> 
> Hello Wadim,
> 
> This is certainly a neat idea! :-) Several times I have wished for a
> convenient way to just plug in a quadrature encoder to the GPIO lines of
> my system and immediately start reading position data. However, I want
> to be sure this makes sense as a Counter subsystem driver before I
> proceed with a full review.
> 
> If I understand correctly from my brief overview, the core approach in
> the gpio-quadrature-encoder module is to take two GPIO lines (A and B),
> setup interrupt service routines for them, compare their GPIO values on
> each interrupt, and respectively update a persistent count based on the
> quadrature relationship.
> 
> From that description, I don't immediately see a need for this to occur
> in kernelspace. Couldn't the same design be accomplished effectively in
> userspace via the libgpiod API[^1]? I believe that library allows you
> to watch for GPIO edge events and request GPIO line values. (I'm CCing
> the GPIO subsystem maintainers in case I'm missing something obvious
> here.)
> 
> Although the Counter subsystem does provide an established user
> interface for counter devices, I'm not sure that alone justifies a
> kernel driver when the same can be achieved by an equivalent userspace
> application. If you can argue for why this should exist in the kernel,
> I'll feel more comfortable with accepting the Counter subsystem as the
> right home for the gpio-quadrature-encoder module.
>

Hello William,

thanks for the look -- fair question. Let me try.

Even with A and B in a single line request (so one event fd, no extra
get_value() between edges) the libgpiod path is:

  edge IRQ -> kernel edge event -> chardev fifo -> scheduler wakeup
    -> read() -> decode -> update count

The wake-to-update delay is bounded by the scheduler, not by the IRQ.
At 2 kHz X4 the inter-edge spacing is ~125 us, which is firmly inside
scheduler-jitter territory on a stock kernel under load -- and a single
missed edge is a permanent position error rather than a transient
glitch. In the kernel the same work is essentially
spin_lock_irqsave / gpiod_get_value / count update / unlock in
interrupt context, which is what gives quadrature decoding the
atomicity it needs.

To be honest I haven't put real numbers on this yet -- the argument
above is from experience, not measurement. I'm going to set up a
proper back-to-back test (libgpiod v2 decoder vs the in-kernel driver,
same hardware, deterministic edge source via eHRPWM so the generator
side doesn't pollute the result) and follow up on this thread with
the results once they're in. If userspace turns out to hold up under
load on this SoC I'll happily drop the series.

The other angle: interrupt-cnt.c is the same shape of driver -- one
GPIO IRQ feeding a Counter -- and quadrature off two GPIOs feels more
like a sibling of that than something to push out to userspace.
Keeping both behind the Counter ABI also means downstream tooling
doesn't need a parallel libgpiod path next to the existing Counter one.

> > Changes in v3:
> >   - Pick up Acked-by: Conor Dooley on the DT binding patch.
> >   - No code changes.
> 
> As an aside, you don't need to resend the patchset if there are no code
> changes, I'll make sure to pick up the tags in the mail threads when the
> patches are accepted. This helps reduce the amount the messages we need
> to parse on the mailing list.

Got it on the resend, thanks. I'll just collect tags in-thread next time.
Thanks,

Wadim

> 
> Thanks,
> 
> William Breathitt Gray
> 
> [^1] https://libgpiod.readthedocs.io/