On 3/28/19 8:28 PM, Marek Behun wrote:
On Wed, 27 Mar 2019 23:12:09 +0100
Jacek Anaszewski <jacek.anaszewski@xxxxxxxxx> wrote:
+ buf[0] = CMD_LED_COLOR;
+ buf[1] = idx;
+ buf[2] = buf[3] = buf[4] = brightness;
If each logical LED has has three channels, then to be compatible with
current RGB LEDs in the LED subsystem, the channels must be exposed as
individual LED class devices.
I talked about this with Pavel, and decided that I will do RGB part
once multichannel/RGB LED class interface is decided. This would just
be a temporary workaround to support continuous brightness. If you
don't want it, I won't send it in next version.
I don't quite get what do you mean by "continuous" brightness in this
case. From what I see you just set the same brightness on all the
channels. Why is it called continuous?
mutex_lock(&leds->lock);
+
ret = i2c_smbus_write_byte_data(leds->client,
CMD_LED_STATE, state);
+ if (ret >= 0)
+ ret = i2c_master_send(leds->client, buf, 5);
Could you switch to using regmap for the whole driver, please?
If I read the regmap_i2c code correctly, it cannot handle this. If one
register is 1 byte wide, and other is 5 bytes, it won't work. Btw it is
regmap mechanism is very flexible and takes into account virtually
all existing use cases.
You can use regmap_bulk_write() for writing an array of bytes.
not a regmap at all, this is a command interface. You can't read
information back from the controller for each "register".
You can read it back since it will be cached in a regmap cache,
unless you mark a register volatile, then the regmap will do the
i2c readout, provided it is marked readable in the regmap config.
--
Best regards,
Jacek Anaszewski
