Just note that wrt the Linux GPIO there are two Linuses at play - Torvalds and Walleij. Who knew Linus was such a common name?Left me scratching my head as well. When you get old enough that your vision starts to go -- you just chuckle at those responses. I was surprised when diving into the example - which usually ends up with me reading the header files - to find that Linus had even been digging around in the gpio peripheral code to come up with different versions. But it makes sense. There has been a great deal of demand for Linux on microcomputers, not just the Pi, so all the hardware peripheral code has undergone review and update in the past few years.
The GPIO subsystem was originally Walleij's, but he has since passed it on to another maintainer, though he is still involved and is still the maintainer of the the pinctrl subsystem.
I have no idea if Torvalds is directly aware of the recent GPIO changes, but there have been a lot of improvements in the last few years, both in the uAPI and the internals. Of course only the uAPI changes are visible to userspace.
Wrt GPIO, the primary customer for the kernel is companies developing embedded systems, not the hoard of Pi users. While many of them think the world should service them, sadly that isn't the case. They are more than welcome to contribute, ideally via the linux-gpio mailing list. Just venting in various forums isn't terribly effective - kernel developers generally have too much to be doing to frequent forums. So if any of you out there want something from the kernel developers then try opening a dialogue rather than shouting into the void. The goes for Pi engineers too.
It is all in there - v2 is a strict super-set of v1. v1 grew organically and when I came along wanting to add debounce there was nowhere in the existing ioctls to put it. As new ioctls were in order it seemed like a good time to do a clean sweep and fix a bunch of other problems - like the odd object model that v1 had developed, e.g. edge detection requiring a separate request, and that only supporting a single line.The irony was originally moving from the deprecated WiringPi -- only to find a deprecated part of the gpio ioctl code (which I'd wager probably had something to do with interest in maintaining WiringPi waning). I first found the GPIO V2 interface a bit daunting -- where did they hide all the pieces of V1 and what changes do I need to make to use it? Then having taken the time to wade through V2, I actually like. Specifically the gpio_v2_line_values .bits and .mask bitmaps used to set one or more of multiple gpio lines configured for access. Quite a bit more flexible than the V1 gpiohandle_data array.
The v2 ioctls could be considered a bit convoluted, particularly as we've tried to allow for future features without breaking ABI compatibility (from now on), but the new object model and ioctls are much more flexible than v1. Some would argue too flexible. Hopefully the kernel documentation that I added recently will help clear up how to use them. There are docs for the v1 as well - if you want to compare.
Statistics: Posted by warthog618 — Wed May 08, 2024 2:05 am