| Message ID | 20230714085253.13544-2-kabel@kernel.org |
|---|---|
| State | New |
| Headers | show |
| Series | leds: turris-omnia: updates | expand |
Hi! > Using binary brightness makes more sense for this controller, because > internally in the MCU it works that way: the LED has a color, and a > state whether it is ON or OFF. So, controller can do (1, 3, 5) but not (3, 3, 3)? > The resulting brightness computation with led_mc_calc_color_components() > will now always result in either (0, 0, 0) or the multi_intensity value. Won't that limit you to 8 colors total? I guess I`m confused how this hw works... Best regards, Pavel > init_data.fwnode = &np->fwnode; > > cdev = &led->mc_cdev.led_cdev; > - cdev->max_brightness = 255; > + cdev->max_brightness = 1; > cdev->brightness_set_blocking = omnia_led_brightness_set_blocking; > > /* put the LED into software mode */
On Sun, 16 Jul 2023 11:19:30 +0200 Pavel Machek <pavel@ucw.cz> wrote: > Hi! > > > Using binary brightness makes more sense for this controller, because > > internally in the MCU it works that way: the LED has a color, and a > > state whether it is ON or OFF. > > So, controller can do (1, 3, 5) but not (3, 3, 3)? > > > The resulting brightness computation with led_mc_calc_color_components() > > will now always result in either (0, 0, 0) or the multi_intensity value. > > Won't that limit you to 8 colors total? > > I guess I`m confused how this hw works... Hi Pavel. No no no. That's not how it is. The HW exposes color control for three channels (RGB), each channel with range 0-255 (so 16M colors). The driver exposes this via the multi_intensity sysfs file. This is communicated to the HW via LED_SET_COLOR I2C command. HW also exposes setting the LED ON and OFF, via the LED_SET_STATE I2C command. We currently have the following sysfs files via which we set LED state and color: brightness multi_intensity Because currently the driver sets max_brightness to 255, the actual color that is sent to HW is recalculated via led_mc_calc_color_components(). For example with $ echo 255 255 100 >multi_intensity $ echo 150 >brightness the led_mc_calc_color_components() function recalculates the channel intensities with formula brightness * channel_intensity / max_brightness and so the (255, 255, 100) tuple is converted to (150, 150, 58) before sending to HW. What I think would make more sense is to make the two sysfs files brightness multi_intensity correspond 1-to-1 with I2C commands LED_SET_STATE and LED_SET_COLOR. This can be simply done by setting max_brightness to 1. The brightness sysfs file then can simply control whether the LED is ON or OFF. The multi_intensity file control the color. I realize now that in the patch I should also make away with the call to led_mc_calc_color_components()... Marek
On Sun, 16 Jul 2023, Marek Behún wrote: > On Sun, 16 Jul 2023 11:19:30 +0200 > Pavel Machek <pavel@ucw.cz> wrote: > > > Hi! > > > > > Using binary brightness makes more sense for this controller, because > > > internally in the MCU it works that way: the LED has a color, and a > > > state whether it is ON or OFF. > > > > So, controller can do (1, 3, 5) but not (3, 3, 3)? > > > > > The resulting brightness computation with led_mc_calc_color_components() > > > will now always result in either (0, 0, 0) or the multi_intensity value. > > > > Won't that limit you to 8 colors total? > > > > I guess I`m confused how this hw works... > > Hi Pavel. > > No no no. That's not how it is. > > The HW exposes color control for three channels (RGB), each channel with > range 0-255 (so 16M colors). The driver exposes this via the > multi_intensity sysfs file. This is communicated to the HW via > LED_SET_COLOR I2C command. > > HW also exposes setting the LED ON and OFF, via the LED_SET_STATE > I2C command. > > We currently have the following sysfs files via which we set LED state > and color: > brightness > multi_intensity > > Because currently the driver sets max_brightness to 255, the actual > color that is sent to HW is recalculated via > led_mc_calc_color_components(). For example with > > $ echo 255 255 100 >multi_intensity > $ echo 150 >brightness > > the led_mc_calc_color_components() function recalculates the channel > intensities with formula > brightness * channel_intensity / max_brightness > and so the (255, 255, 100) tuple is converted to (150, 150, 58) before > sending to HW. > > What I think would make more sense is to make the two sysfs files > brightness > multi_intensity > correspond 1-to-1 with I2C commands LED_SET_STATE and LED_SET_COLOR. > > This can be simply done by setting max_brightness to 1. The brightness > sysfs file then can simply control whether the LED is ON or OFF. The > multi_intensity file control the color. > > I realize now that in the patch I should also make away with the call > to led_mc_calc_color_components()... FYI, due to the revelations above, I'm dropping this from my queue.
Hi! > The HW exposes color control for three channels (RGB), each channel with > range 0-255 (so 16M colors). The driver exposes this via the > multi_intensity sysfs file. This is communicated to the HW via > LED_SET_COLOR I2C command. > > HW also exposes setting the LED ON and OFF, via the LED_SET_STATE > I2C command. > > We currently have the following sysfs files via which we set LED state > and color: > brightness > multi_intensity > > Because currently the driver sets max_brightness to 255, the actual > color that is sent to HW is recalculated via > led_mc_calc_color_components(). For example with > > $ echo 255 255 100 >multi_intensity > $ echo 150 >brightness > > the led_mc_calc_color_components() function recalculates the channel > intensities with formula > brightness * channel_intensity / max_brightness > and so the (255, 255, 100) tuple is converted to (150, 150, 58) before > sending to HW. And this seems ok. > What I think would make more sense is to make the two sysfs files > brightness > multi_intensity > correspond 1-to-1 with I2C commands LED_SET_STATE and LED_SET_COLOR. We want your driver to be have same API as other drivers, 1-to-1 correspondence with I2c commands is not important. NAK-ed-by: Pavel Best regards, Pavel
On Fri, 28 Jul 2023 12:10:44 +0200 Pavel Machek <pavel@ucw.cz> wrote: > Hi! > > > The HW exposes color control for three channels (RGB), each channel with > > range 0-255 (so 16M colors). The driver exposes this via the > > multi_intensity sysfs file. This is communicated to the HW via > > LED_SET_COLOR I2C command. > > > > HW also exposes setting the LED ON and OFF, via the LED_SET_STATE > > I2C command. > > > > We currently have the following sysfs files via which we set LED state > > and color: > > brightness > > multi_intensity > > > > Because currently the driver sets max_brightness to 255, the actual > > color that is sent to HW is recalculated via > > led_mc_calc_color_components(). For example with > > > > $ echo 255 255 100 >multi_intensity > > $ echo 150 >brightness > > > > the led_mc_calc_color_components() function recalculates the channel > > intensities with formula > > brightness * channel_intensity / max_brightness > > and so the (255, 255, 100) tuple is converted to (150, 150, 58) before > > sending to HW. > > And this seems ok. > > > What I think would make more sense is to make the two sysfs files > > brightness > > multi_intensity > > correspond 1-to-1 with I2C commands LED_SET_STATE and LED_SET_COLOR. > > We want your driver to be have same API as other drivers, 1-to-1 > correspondence with I2c commands is not important. > > NAK-ed-by: Pavel > > Best regards, > Pavel Hmm, thinking more about it I guess you are right. And I thought of what I think is better change anyway. I shall send patch for review, let's see what you think about that one :) Marek
diff --git a/drivers/leds/leds-turris-omnia.c b/drivers/leds/leds-turris-omnia.c index 64b2d7b6d3f3..c063b6b710f9 100644 --- a/drivers/leds/leds-turris-omnia.c +++ b/drivers/leds/leds-turris-omnia.c @@ -110,7 +110,7 @@ static int omnia_led_register(struct i2c_client *client, struct omnia_led *led, init_data.fwnode = &np->fwnode; cdev = &led->mc_cdev.led_cdev; - cdev->max_brightness = 255; + cdev->max_brightness = 1; cdev->brightness_set_blocking = omnia_led_brightness_set_blocking; /* put the LED into software mode */
Using binary brightness makes more sense for this controller, because internally in the MCU it works that way: the LED has a color, and a state whether it is ON or OFF. The resulting brightness computation with led_mc_calc_color_components() will now always result in either (0, 0, 0) or the multi_intensity value. Signed-off-by: Marek Behún <kabel@kernel.org> --- drivers/leds/leds-turris-omnia.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)