Re: Abstraction for dual LED driver override feature

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Phillip,

On 7/25/19 9:43 PM, Philip Molloy wrote:
> Hello,
> 
> I'm writing a driver for the TI LM3644 dual current flash LED driver[1] and could use some advice on how to abstract a feature of the device that allows the user to fix the brightness of the 2nd LED to the brightness of the 1st.
> 
> Bit 7 of the LED1 torch brightness register signifies whether the LED2 torch current should be set to the LED1 torch current. By default this override is enabled.
> 
> Is it worth exposing this feature to userspace? And what might a good way to do that be?

It depends if you want to control this LEDs separately all as one
logical flash LED? If the two LEDs are located next to each other on
the board then they can be treated as a single source of light and
logically coupled into one with use of led-sources DT property.

In this case the way how you will control the LED brightness in the
driver is an implementation detail and does not need to be exposed to
the userspace. The feature will allow for nice optimization then.

Please compare drivers/leds/leds-max77693.c flash LED class driver
which allows for coupling iouts.

See also the related DT bindings:

Documentation/devicetree/bindings/mfd/max77693.txt

On the other hand if you wish to expose two separate LED class devices,
then the feature would allow for configurable LED synchronization,
but I'm not sure if this would be much beneficial for only two LEDs.

We've had discussions about LED synchronization mechanism that would
allow for setting cross-LED patterns, but it needs more analysis.

> Or alternatively, hide the feature by setting bit 7 of the LED1 torch brightness register to 0 every time I write to the LED2 torch brightness register?
> 
> Unfortunately, I couldn't find an example of similar functionality in any of the mainline LED kernel modules.


-- 
Best regards,
Jacek Anaszewski



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux