Hi!

CC linux-leds (which I intended, but forgot to add)

cover letter at
https://lore.kernel.org/linux-devicetree/20210322144848.1065067-1-geert@linux-m68k.org/ (local)

Still does not tell me... riscv on fpga with 4 character display. What
is this? :-).

On Tue, Mar 23, 2021 at 11:08 AM Robin van der Gracht [off-list ref] wrote:

quoted

On 2021-03-22 15:48, Geert Uytterhoeven wrote:

quoted

Instantiate a single LED for a segment display.  This allows the user
to
control display brightness and blinking through the LED class API and
triggers, and exposes the display color.

Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
---
For setting display brightness, this could use the existing backlight
support for frame buffer devices instantiated for dot-matrix displays.
However, using the leds subsystem instead has the advantage that the
driver can make use of the HT16K33's hardware blinking support, and can
expose the display color.

We have multicolor support now...

quoted

quoted

-     err = ht16k33_brightness_set(priv, MAX_BRIGHTNESS);
+     of_property_read_u32(node, "color", &color);
+     seg->led.name = devm_kasprintf(dev, GFP_KERNEL,
+                     DRIVER_NAME ":%s:" LED_FUNCTION_BACKLIGHT,
+                     color < LED_COLOR_ID_MAX ? led_colors[color] : "");

And would prefer not to see driver_name as part of LED name.

quoted

quoted

+     err = ht16k33_brightness_set(priv, seg->led.brightness);
      if (err)
              return err;

The LED class can pretty much do what the backlight class can and more.

Maybe we can stop registering a backlight device in the fbdev case and
register a led device for both. This makes the code cleaner and drops
a dependency but will break backwards compatibility.

I'd prefer a single solution that covers both use cases, but I'm not
sure about the 'breaking backwards compatibility' consequence...

For new drivers, breaking compatibility should not be a problem.

Best regards,
									Pavel
-- 
http://www.livejournal.com/~pavelmachek