From: Bjorn Andersson <bjorn.andersson@linaro.org>
To: Dan Murphy <dmurphy@ti.com>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>,
Pavel Machek <pavel@ucw.cz>,
Linux LED Subsystem <linux-leds@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v11 04/16] leds: multicolor: Introduce a multicolor class definition
Date: Wed, 9 Oct 2019 16:25:39 -0700 [thread overview]
Message-ID: <20191009232539.GB571@minitux> (raw)
In-Reply-To: <d6b68a79-235a-0a9b-bbf3-519571646eff@ti.com>
On Wed 09 Oct 13:44 PDT 2019, Dan Murphy wrote:
> Bjorn
>
> On 10/9/19 3:11 PM, Bjorn Andersson wrote:
> > On Tue, Oct 8, 2019 at 1:49 PM Dan Murphy <dmurphy@ti.com> wrote:
> > > Introduce a multicolor class that groups colored LEDs
> > > within a LED node.
> > >
> > > The multi color class groups monochrome LEDs and allows controlling two
> > > aspects of the final combined color: hue and lightness. The former is
> > > controlled via <color>_intensity files and the latter is controlled
> > > via brightness file.
> > >
> > Thanks for making progress on this, it's been the one outstanding
> > question mark for the long overdue respin of the Qualcomm LPG driver.
>
> > But while it works for the LPG, in that it has outputs named "RGB" I
> > have boards with "generic" LED drivers that are connected to RGB LEDs.
> > So per your proposed solution we would need to add the additional
>
> You don't have to add the MC class to those drivers. This is an optional
> framework but if you wanted to use the framework for specific devices then
> yes you would need to add that support. This is why I did the LP55xx patches
> to demonstrate the feasibility since the LP50xx has the MC class
> intelligence already.
>
Correct me if I've misunderstood something, but if I have a product
using e.g. lm3533 connected to an RGB LED then the correct way to
represent this towards userspace is to introduce the MC class in the
lm3533 LED driver, no?
> The LP55xx driver can register to the LED class and/or the MC LED class
> pending on the DT organization.
>
Understood.
> I don't plan on going through all of TI's RGB drivers and retrofitting them
> to the MC class. I do have to update the GPIO LED driver to use the class
> but that work is still pending.
>
> I may also update the Motorola PCAP driver as well since I have a Droid4 to
> test.
>
My concern with this is that being connected to a RGB LED is not a
property of the controller, but the system design and the proposed
implementation makes it a property of each controller.
I'm not saying that the proposed path is wrong, I'm saying that we have
83 files named leds-*.c in drivers/leds and this adaption needs to
happen on each one.
And I'm not saying I expect you to do this.
> > mc_class handling to every single LED driver that might be used to
> > sink current into an RGB LED.
> >
> > I also don't see anything preventing hardware designers from feeding
> > single RGB LEDs from multiple different LED controllers, something the
> > current proposal would prohibit.
>
> What do you mean by a single RGB LED? Are you referring to a RGB module?
>
> http://wiki.sunfounder.cc/index.php?title=RGB_LED_Module
>
Yes
> There is no prevention for HW designers to put a driver on each LED output
> but I am not sure why they would incur
>
> the additional BOM cost seems quite silly unless you have an unlimited
> budget ;)
>
So if you have a system with e.g. 8 PWM channels on one PMIC and a
single PWM available on a different PMIC then you're saying that the
hardware guys would be silly to believe that they can drive 3 RGB LEDS
off this?
> If they did design the system that way then the SW would need to revert back
> to the standard LED class as it is done today.
>
If that is the agreed upon design then I'll continue to adapt my LED
drivers to the MC class.
Regards,
Bjorn
next prev parent reply other threads:[~2019-10-09 23:25 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-08 20:47 [PATCH v11 00/16] Multicolor Framework v11 Dan Murphy
2019-10-08 20:47 ` [PATCH v11 01/16] dt: bindings: Add multicolor class dt bindings documention Dan Murphy
2019-10-09 22:07 ` Jacek Anaszewski
2019-10-10 0:49 ` Dan Murphy
2019-10-10 18:42 ` Jacek Anaszewski
2019-10-08 20:47 ` [PATCH v11 02/16] dt-bindings: leds: Add multicolor ID to the color ID list Dan Murphy
2019-10-08 20:47 ` [PATCH v11 03/16] " Dan Murphy
2019-10-08 20:47 ` [PATCH v11 04/16] leds: multicolor: Introduce a multicolor class definition Dan Murphy
2019-10-09 20:11 ` Bjorn Andersson
2019-10-09 20:44 ` Dan Murphy
2019-10-09 23:25 ` Bjorn Andersson [this message]
2019-10-10 0:43 ` Dan Murphy
2019-10-09 21:47 ` Jacek Anaszewski
2019-10-10 0:27 ` Dan Murphy
2019-10-10 18:36 ` Jacek Anaszewski
2019-10-10 18:37 ` Jacek Anaszewski
2019-10-08 20:47 ` [PATCH v11 05/16] dt: bindings: lp50xx: Introduce the lp50xx family of RGB drivers Dan Murphy
2019-10-08 20:47 ` [PATCH v11 06/16] leds: lp50xx: Add the LP50XX family of the RGB LED driver Dan Murphy
2019-10-08 20:47 ` [PATCH v11 07/16] dt: bindings: lp55xx: Be consistent in the document with LED acronym Dan Murphy
2019-10-08 20:47 ` [PATCH v11 08/16] dt: bindings: lp55xx: Update binding for Multicolor Framework Dan Murphy
2019-10-16 11:25 ` Linus Walleij
2019-10-08 20:47 ` [PATCH v11 09/16] ARM: dts: n900: Add reg property to the LP5523 channel node Dan Murphy
2019-10-08 20:47 ` [PATCH v11 10/16] ARM: dts: imx6dl-yapp4: Add reg property to the lp5562 " Dan Murphy
2019-10-08 20:47 ` [PATCH v11 11/16] ARM: dts: ste-href: Add reg property to the LP5521 channel nodes Dan Murphy
2019-10-16 11:24 ` Linus Walleij
2019-10-08 20:47 ` [PATCH v11 12/16] leds: lp55xx: Add multicolor framework support to lp55xx Dan Murphy
2019-10-09 22:04 ` Jacek Anaszewski
2019-10-10 0:47 ` Dan Murphy
2019-10-08 20:47 ` [PATCH v11 13/16] leds: lp5523: Update the lp5523 code to add intensity function Dan Murphy
2019-10-08 20:47 ` [PATCH v11 14/16] leds: lp5521: Add multicolor framework intensity support Dan Murphy
2019-10-08 20:47 ` [PATCH v11 15/16] leds: lp55xx: Fix checkpatch file permissions issues Dan Murphy
2019-10-08 20:48 ` [PATCH v11 16/16] leds: lp5523: Fix checkpatch issues in the code 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=20191009232539.GB571@minitux \
--to=bjorn.andersson@linaro.org \
--cc=dmurphy@ti.com \
--cc=jacek.anaszewski@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=pavel@ucw.cz \
/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).