Linux-LEDs Archive on
 help / color / Atom feed
From: Jacek Anaszewski <>
To: Philip Molloy <>,
	"" <>
Subject: Re: Abstraction for dual LED driver override feature
Date: Thu, 25 Jul 2019 22:12:09 +0200
Message-ID: <> (raw)
In-Reply-To: <>

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:


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

  reply index

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-25 19:43 Philip Molloy
2019-07-25 20:12 ` Jacek Anaszewski [this message]
2019-07-25 20:26 ` Dan Murphy

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-LEDs Archive on

Archives are clonable:
	git clone --mirror 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/ \
	public-inbox-index linux-leds

Example config snippet for mirrors

Newsgroup available over NNTP:

AGPL code for this site: git clone