> The advantage is the regmap cache which allows to reduce the traffic
> on I2C bus. Especially significant in case I2C bit banging is used.
Jacek,
after reading more regmap code I have come to this conclusions (please
correct me if I am wrong):
Using regmap in my case is OK, the code is nicer that why, although
there is a reasonable argument why not to use it (at the end of this
email).
But using regcache does not make much sense in this case, here's why:
The command "register addresses" are as follows:
3: mode (sw or hw control)
4: state (enabled/disabled, only works when in sw control mode)
5: color (expects 4 bytes, led number, r, g, b)
7: set brightness
8: get brightness
(
The last two control "global brightness" for all LEDs. The resulting
brigthness of LED X channel C is (i dont know if this is really
linear, but suppose it is):
global_brightness * X_C_brightness * X_enabled
So for example the resulting brightness of the red channel of WAN
LED is
global_brightness * WAN_red_brightness * WAN_enabled
This "global brightness" can be set via command 7, or by hardware
when user presses a button (hardware cycles through 8 levels of
hardcoded values each time the button is pressed).
)
So one would say that I can enable regcache here on "addresses" 3, 4, 7
(8 is obviously volatile).
For the "addresses" 3 and 4 the regcache could make sense, but we never
need actually to read what was written there, because we remember if
led is enabled in other structure, and in the future if hw triggering
is supported, that also would be remembered in other structure.
But enabling regcache on register 7 won't work correctly, because
writing the 4 bytes on register 5 regmap_bulk_write would make regcache
think that registers 5, 6, 7, 8 were written these values. If 7 was
cached for reading, the cache would be rewritten each time color was
changed on a led.
And this "one register value overlaying another register value" is also
the reasonable argument why using regmap may be a little wrong here.
If I see regmap used, I am imagining there really are registers with
addresses on the other side, and I would never guess (the regcache code
does not either) that register values could overlap.
(If my imagination would allow registers to have different sizes with
values not overlapping with addresses, it would not be a problem. If
register 0x10 is 4 bytes, and 0x11 is 2 bytes, and they don't overlay
each other, there is no problem. But my imagination about what are
registers and addresses and values does not work this way and the
regcache does not either.)
Marek
