Hi Marek,
On 5/1/19 2:41 AM, Marek Behun wrote:
On Wed, 1 May 2019 01:02:15 +0200
Pavel Machek <pavel@xxxxxx> wrote:
Hi!
@@ -166,10 +174,19 @@ static int omnia_leds_probe(struct i2c_client *client,
static int omnia_leds_remove(struct i2c_client *client)
{
+ u8 buf[5];
+
/* put all LEDs into default (HW triggered) mode */
i2c_smbus_write_byte_data(client, CMD_LED_MODE,
CMD_LED_MODE_LED(OMNIA_BOARD_LEDS));
+ /* set all LEDs color to [255, 255, 255] */
+ buf[0] = CMD_LED_COLOR;
+ buf[1] = OMNIA_BOARD_LEDS;
+ buf[2] = buf[3] = buf[4] = 255;
+
+ i2c_master_send(client, buf, 5);
+
return 0;
}
I wonder if we're doing right merging this driver in this form.
We break the rule one-led-class-device-per-one-channel.
We don't have LED multi color support yet, so this should support
RGB LEDs in the old manner. Or switch to using LED multi color
class.
Fair point.
We treat it as a white LED instead of RGB LED at this
point. One-led-per-channel would be problematic, as hardware
"triggers" are common for all three channels.
So I thought we could go from "white" led to multicolor, when it
becomes available, without going through One-led-per-channel...
I agree this is not quite standard.
Pavel
Hi,
I am aware of this issue. I plan to change the driver to multicolor led
class as soon as it is available. But from the discussions I have read
it does not seem it will be available in the next kernel release. I
would like at least full brigthness for the next release and maybe hw
triggering, for which the first version I plan to send this week...
If you used led-sources property in your DT bindings it would be all
fine. It will justify having three channels controlled by single LED
class device.
--
Best regards,
Jacek Anaszewski
