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
