11–13 of 13 posts
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?
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 e…
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...)