Re: [PATCH v11 04/16] leds: multicolor: Introduce a multicolor class definition

[Bjorn Andersson]

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@xxxxxx> 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