Linux-LEDs Archive on lore.kernel.org
 help / color / Atom feed
* Abstraction for dual LED driver override feature
@ 2019-07-25 19:43 Philip Molloy
  2019-07-25 20:12 ` Jacek Anaszewski
  2019-07-25 20:26 ` Dan Murphy
  0 siblings, 2 replies; 3+ messages in thread
From: Philip Molloy @ 2019-07-25 19:43 UTC (permalink / raw)
  To: linux-leds

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?

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,
Philip

[1]: http://www.ti.com/lit/ds/symlink/lm3644.pdf

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Abstraction for dual LED driver override feature
  2019-07-25 19:43 Abstraction for dual LED driver override feature Philip Molloy
@ 2019-07-25 20:12 ` Jacek Anaszewski
  2019-07-25 20:26 ` Dan Murphy
  1 sibling, 0 replies; 3+ messages in thread
From: Jacek Anaszewski @ 2019-07-25 20:12 UTC (permalink / raw)
  To: Philip Molloy, linux-leds

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Abstraction for dual LED driver override feature
  2019-07-25 19:43 Abstraction for dual LED driver override feature Philip Molloy
  2019-07-25 20:12 ` Jacek Anaszewski
@ 2019-07-25 20:26 ` Dan Murphy
  1 sibling, 0 replies; 3+ messages in thread
From: Dan Murphy @ 2019-07-25 20:26 UTC (permalink / raw)
  To: Philip Molloy, linux-leds

Phill

On 7/25/19 2: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?
>
> 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.

You could define this in the DT using the pre-defined led-sources property.

Unless this needs to be run time configurable which it does not appear

that it needs to be.  The default is combined LED brightness registers.

led-sources = < 0 1 >;

If led-sources does not exist in the DT then assume they are separate.

Example DT with combined LED outputs

led-controller@63 {
     compatible = "ti,lm3644";
     #address-cells = <1>;
     #size-cells = <0>;
     reg = <0x63>;

     led@0 {
         reg = <0>;

         led-sources = < 0 1 >;

         function = LED_FUNCTION_TORCH;
         color = <LED_COLOR_ID_WHITE>;
         led-max-microamp = <376000>;
         flash-max-microamp = <1500000>;
         flash-max-timeout-us = <1600000>;
     };
}

Example DT with separated LED outputs where output is the flash and 
output 2 is a torch

This would be two separate class registrations

led-controller@63 {
     compatible = "ti,lm3644";
     #address-cells = <1>;
     #size-cells = <0>;
     reg = <0x63>;

     led@0 {
         reg = <0>;

         function = LED_FUNCTION_FLASH;

         color = <LED_COLOR_ID_WHITE>;
         led-max-microamp = <376000>;
         flash-max-microamp = <1500000>;
         flash-max-timeout-us = <1600000>;
     };

     led@1 {
         reg = <1>;

         function = LED_FUNCTION_TORCH;

         color = <LED_COLOR_ID_WHITE>;
     };

}



Dan


>
> Best,
> Philip
>
> [1]: http://www.ti.com/lit/ds/symlink/lm3644.pdf

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, back to index

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-07-25 19:43 Abstraction for dual LED driver override feature Philip Molloy
2019-07-25 20:12 ` Jacek Anaszewski
2019-07-25 20:26 ` Dan Murphy

Linux-LEDs Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-leds/0 linux-leds/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-leds linux-leds/ https://lore.kernel.org/linux-leds \
		linux-leds@vger.kernel.org linux-leds@archiver.kernel.org
	public-inbox-index linux-leds


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-leds


AGPL code for this site: git clone https://public-inbox.org/ public-inbox