linux-leds.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jacek Anaszewski <jacek.anaszewski@gmail.com>
To: Philip Molloy <philip@philipmolloy.com>,
	"linux-leds@vger.kernel.org" <linux-leds@vger.kernel.org>
Subject: Re: Abstraction for dual LED driver override feature
Date: Thu, 25 Jul 2019 22:12:09 +0200	[thread overview]
Message-ID: <af1df777-4a34-7c47-5b59-3b1c34a622bc@gmail.com> (raw)
In-Reply-To: <-SZHSFMkCZILLVhmVPIa2HVHWpZN2OId3iixPCrsBNWCmtyC2bt5ATy3iOTlNuD_12k6xRBcXwUf7_WT3Ij7ccp0357LdxUUSjojm2_LFUc=@philipmolloy.com>

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

  reply	other threads:[~2019-07-25 20:12 UTC|newest]

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

Reply instructions:

You may reply publicly 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=af1df777-4a34-7c47-5b59-3b1c34a622bc@gmail.com \
    --to=jacek.anaszewski@gmail.com \
    --cc=linux-leds@vger.kernel.org \
    --cc=philip@philipmolloy.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).