C/C++ • Re: Driver (LKM) programming with pinctrl or userspace library

I'm trying to work with a rotary encoder and linux RT.
The more I read, the more I think the "easy" solution would be to use the libgpiod V2. But following my first idea, I would have liked writing a driver/kernel module that would catch the interrupt on the GPIO and run the short processing needed on a dedicated CPU in order to optimize the accuracy/max speed.

The events returned by libgpiod contain a timestamp as accurate as available in the kernel - captured in the interrupt handler.
And it queues events in case userspace is occasionally too slow to handle bursts of events.
How can going in-kernel make it more accurate?

It will be faster to be in-kernel, as that removes the need for kernel/userspace context switching, and locking to a CPU may reduce latency, though probably not significantly unless you have lots of other interrupts to handle.

The reason I would like to avoid userspace libraries is that I fear there are too many functions/calls/links in it for me to be sure of exactly what it does behind the scene.

If that really bothers you, and if you care to look, you can read the code, - libgpiod.

TLDR: not a lot - it makes ioctl calls to the kernel to request and control lines via the GPIO subsystem. The biggest overhead is the kernel/userspace context switch. Other than that it is very similar to being in-kernel.

My idea of "optimisation" was to use GPIO interrupts, but since there is already the "edge event" (but is it polling or irq based ?), is it worth the time rather than using libgpiod 2 that is already using device files ?

As mentioned above, it is irq based.

Probably not worth the time, given the timestamps and queuing. Try it from userspace first and see if that is good enough.
Or see if there is an existing driver that does what you need, or is close enough to use as a base.

For now (trying to write the driver), I am stuck with "how to bring all the stuff that interests me in pinctrl-bcm2835 in my driver" ? And if I do, won't I have conflicts with any userspace libraries that will be run on the "non-RT" CPUs ? (I believe it won't since the structures use pointers on the device file, but I am not sure).

in-kernel, that driver implements the irq_chip and gpio_chip interfaces, so you can request the line(s) from the corresponding subsystem (irq or gpio) and it will play nice with others, both in-kernel and in userspace.

But someone has probably had the same problem before, so it is worth a look to see if there is an existing driver...
Is this rotary encoder driver (documentation) suitable?

Statistics: Posted by warthog618 — Sun Nov 03, 2024 3:14 am

---