Re: Generic RGB LED support was Re: [PATCH 2/2] leds: lp5024: Add the LP5024/18 RGB LED driver
From: Dan Murphy
Date: Mon Jan 07 2019 - 14:36:37 EST
On 1/7/19 1:13 PM, Jacek Anaszewski wrote:
> On 1/6/19 4:52 PM, Jacek Anaszewski wrote:
>> Hi Pavel,
>> On 1/5/19 11:12 PM, Pavel Machek wrote:
>>>>> Grab yourself an RGB LED and play with it; you'll see what the
>>>>> problems are. It is hard to explain colors over email...
>>>> Video  gives some overview of lp5024 capabilities.
>>>> I don't see any problems in exposing separate red,green,blue
>>>> files and brightness for the devices with hardware support for
>>> Well, that's what we do today, as three separate LEDs, right?
>> No. It doesn't allow for setting color intensity by having
>> the color fixed beforehand. Below is relevant excerpt from
>> the lp5024 documentation. This is not something that can be
>> mapped to RGB color space, but rather to HSV/HSL, with the
>> reservation that the hardware implementation uses PWM
>> for setting color intensity.
>> 188.8.131.52 Independent Intensity Control Per RGB LED Module
>> When color is fixed, the independent intensity-control is used to
>> achieve accurate and flexible dimming control for every RGB LED module.
>> 184.108.40.206.1 Intensity-Control Register Configuration
>> Every three consecutive output channels are assigned to their respective
>> intensity-control register (LEDx_BRIGHTNESS). For example, OUT0, OUT1,
>> and OUT2 are assigned to LED0_BRIGHTNESS, so it is recommended to
>> connect the RGB LEDs in the sequence as shown in Table 1. The LP50xx
>> device allows 256-step intensity control for each RGB LED module, which
>> helps achieve a smooth dimming effect.
>>> I don't have problem with that, either; other drivers already do
>>> that. He's free to use existing same interface.
>>> But that is insufficient, as it does not allow simple stuff, such as
>>> turning led "white".
>>> So... perhaps we should agree on requirements, first, and then we can
>>> discuss solutions?
>>> Requirements for RGB LED interface:
>>> 1) Userspace should be able to set the white color
>>> 2) Userspace should be able to arbitrary color from well known list
>>> and it should approximately match what would CRT, LCD or OLED monitor display
>> The difference is that monitor display driver is pre-calibrated
>> for given display by the manufacturer. With the LED controllers the
>> manufacturer has no control over what LEDs will be connected to the
>> iouts. Therefore it should be not surprising that colors produced
>> by custom LEDs are not as user would expect when comparing to
>> the RGB color displayed on the monitor display.
>> TI provides "Various LED Ring Lighting Patterns Reference Design" 
>> that show how to produce various patterns with use of the reference
>> board with LED ring built using sixteen 19-337/R6GHBHC-A01/2T LEDs .
>> Document  mentions also specific "Design considerations" in the
>> chapter 2.2:
>> Several considerations are taken into account for this particular design:
>> • LED map (ring) for meeting the requirement of popular human-machine interaction style.
>> • LED size, numbers and the diffuse design for meeting lighting pattern uniformity.
>> • Analog dimming in the difference ambient light lux without losing dimming resolution in lighting pattern.
>> These considerations apply to most human-machine interaction end equipment with day and night vision
>> designs in some way, but the designer must decide the particular considerations to take into account for a
>> specific design.
>> This renders your requirement 2) infeasible with use of custom LEDs
>> any fixed algorithm, since the final effect will always heavily depend
> Typo here: s/any fixed/and fixed/
>> on the LED circuit design.
>>> 2a) LEDs probably slightly change color as they age. That's out of
>>> scope, unless the variation is much greater than on monitors.
>>> 2b) Manufacturing differences cause small color variation. Again,
>>> that's out of scope, unless the variation is much greater than on
>>> Nice to have features:
>>> 3) Full range of available colors/intensities should be available to
>>> 4) Interface should work well with existing triggers
>>> 5) It would be nice if userland knew how many lumens are produced at
>>> each wavelength for each setting (again, minus aging and manufacturing
>>> 6) Complexity of math in kernel should be low, and preferably it
>>> should be integer or fixed point
>>> a) RGB LEDs are usually not balanced. Setting 100% PWM on
>>> red/green/blue channels will result in nothing close to white
>>> light. In fact, to get white light on N900, blue and green channel's
>>> PWM needs to be set pretty low, as in 5%.
>>> b) LED class does not define any relation between "brightness" in
>>> sysfs and ammount of light in lumens. Some drivers use close to linear
>>> relation, some use exponential relation. Human eyes percieve logarithm
>>> of lumens. RGB color model uses even more complex function.
>>> c) Except for white LEDs, LEDs are basically sources of single
>>> wavelength of light, while CRTs and LCDs produce broader
>>> d) RG, RGBW and probably other LED combinations exist.
>>> e) Not all "red" LEDs will produce same wavelength. Similar
>>> differences will exist for other colors.
>>> f) We have existing RGB LEDs represented as three separate
>>> monochromatic LEDs in sysfs.
>> One general question: do you have any solutions in store?
>>  http://www.ti.com/lit/ug/tiduee6/tiduee6.pdf
>>  http://www.everlight.com/file/ProductFile/19-337-R6GHBHC-A01-2T.pdf
I just wanted to point out that there are 4 total devices right now that use the same mapping
LP5018, LP5024, LP5030 and the LP5036.
I can implement what ever we would like to I just need to know what to design against.
But keep in mind I still need to invest my time in the other TI-lmu patches on my list to complete.