Hi Marek, On 3/29/19 3:19 AM, Marek Behun wrote:
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.)
Thank you for your thorough analysis. It indeed seems that use of regmap for this device would be problematic. Let's stay by your current implementation then. -- Best regards, Jacek Anaszewski
