Using regmaps to make Linux drivers more generic
collabora.com
Using regmaps to make Linux drivers more generic
1–10 of 13 posts
Re: Using regmaps to make Linux drivers more generic
#2This is def what smart abstractions look like.
Re: Using regmaps to make Linux drivers more generic
#3I 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?
Re: Using regmaps to make Linux drivers more generic
#4I 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.
Re: Using regmaps to make Linux drivers more generic
#5I 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 e…
There's no string matching that I can see in the linked article?
Re: Using regmaps to make Linux drivers more generic
#6How do Linux Devs manage to not accidentally break device support constantly? I imagine this stuff is close to impossible to write automated tests for.
Re: Using regmaps to make Linux drivers more generic
#7How 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.
Re: Using regmaps to make Linux drivers more generic
#8I 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 e…
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.
Re: Using regmaps to make Linux drivers more generic
#9Earlier quoted context omitted.
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.
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.Re: Using regmaps to make Linux drivers more generic
#10Earlier quoted context omitted.
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.
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.