Using regmaps to make Linux drivers more generic(collabora.com)
collabora.com
Using regmaps to make Linux drivers more generic
https://www.collabora.com/news-and-blog/blog/2020/05/27/using-regmaps-to-make-linux-drivers-more-generic/
12 comments
This is def what smart abstractions look like.
I see how this is an abstraction of register memory. but how does it help against a constantly moving kernel?
Also, wouldn't this make an otherwise simple code much harder to read and understand?
Also, wouldn't this make an otherwise simple code much harder to read and understand?
It's not the kernel that's constantly moving, it's the hardware. The idea of regmaps is that when you get a device revision B, rather than having to sprinkle "if(revision == ...)" all over your code you just look it up in a table.
How do Linux Devs manage to not accidentally break device support constantly? I imagine this stuff is close to impossible to write automated tests for.
Generally/Ideally things break early in the release cycle, bug reports show up on the mailing lists, and fixes are applied. They are marked with a Fixes tag so as for stable releases to pick them up if relevant.
For basic stuff (as in checking if boards still boot) you have projects like kernelci.org that detect regressions on a huge variety of boards. That said, if you need to support a touchscreen, or say, an uncommon USB device, it's up to you to take care of keeping up with the releases.
For basic stuff (as in checking if boards still boot) you have projects like kernelci.org that detect regressions on a huge variety of boards. That said, if you need to support a touchscreen, or say, an uncommon USB device, it's up to you to take care of keeping up with the releases.
I could see this introducing a performance hit...
Previously a register address was a hardcoded constant. Very small,very fast.
Now, looking up a register ina map involves string matching on the name across every possible register in the map till you find a match. That is much slower, but also makes the kernel quite a lot larger, because you're effectively shipping half the device datasheet in the form of names for every flag bit.
Previously a register address was a hardcoded constant. Very small,very fast.
Now, looking up a register ina map involves string matching on the name across every possible register in the map till you find a match. That is much slower, but also makes the kernel quite a lot larger, because you're effectively shipping half the device datasheet in the form of names for every flag bit.
There's no string matching that I can see in the linked article?
" .name = "dw-mipi-dsi","
Looks like a string in the structure to me. And when you have an array of such structures, you end up scanning through them checking for the name you need.
Looks like a string in the structure to me. And when you have an array of such structures, you end up scanning through them checking for the name you need.
That's the name of the regmap. Clicking through to the definition of the structure says it's optional and thus there for descriptive purposes.
*
* @name: Optional name of the regmap. Useful when a device has multiple
* register regions.Look at the usage example a couple of lines below; it's passing a pointer to that structure. There's no scanning necessary, it already knows where the structure is.
At runtime this is all just a couple of pointer indirections so the impact is minimal. There are also special functions for bulk transfer so regmap shouldn't be called in tight loops.
1) One or more "meta-registers", that is, hardware registers for the purpose of reading and writing all of the other hardware registers.
2) Some form of standard callback/interrupt from the hardware indicating that registers have changed and need to be re-read.
3) Once #1 and #2 are defined, then a "linux-memory-region as readable/writable hardware-device registers" (such as regmap), can be easily and generically implemented.
regmap, while it implements a generic device abstraction, is itself not generically implemented, and can't be, until hardware designers implement #1 and #2, which first requires the creation of a standard, and then requires a consensus to use that standard for their hardware devices...
(Of course, DMA, as it exists currently, is still part of the model... what we're looking at here is the non-generic nature of hardware registers, from one hardware device to a different hardware device... that's still OK, but there should be one (or more) "meta-register(s)" to read/write all of the others, and some interrupt-driven way of being notified of changes... you know, in J.R.R. Tolkien terms "one register to bind them"... but maybe two or more meta-registers, for this purpose, make sense... I'm not a hardware engineer, I wouldn't know the optimal configuration...)