
Using regmaps to make Linux drivers more generic - mfilion
https://www.collabora.com/news-and-blog/blog/2020/05/27/using-regmaps-to-make-linux-drivers-more-generic/
======
peter_d_sherman
Observation: Every single piece of hardware that is, or could ever exist,
could be represented generically as follows:

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...)

------
Daishiman
This is def what smart abstractions look like.

------
panpanna
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?

~~~
pjc50
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.

------
trelonid
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.

~~~
vianpl
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.

------
londons_explore
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.

~~~
akx
There's no string matching that I can see in the linked article?

~~~
londons_explore
" .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.

~~~
akx
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.

