Message-ID: <f323ce2c-01f9-f474-4071-96c3c4ef2b24@ti.com>
Date:   Tue, 8 Jan 2019 15:25:10 -0600
From:   Dan Murphy <dmurphy@...com>
To:     Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Pavel Machek <pavel@....cz>
CC:     Vesa Jääskeläinen <dachaac@...il.com>,
        <robh+dt@...nel.org>, <devicetree@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-leds@...r.kernel.org>
Subject: Re: Generic RGB LED support was Re: [PATCH 2/2] leds: lp5024: Add the
 LP5024/18 RGB LED driver

Jacek

On 1/8/19 3:18 PM, Jacek Anaszewski wrote:
> Hi Dan,
> 
> On 1/7/19 10:14 PM, Dan Murphy wrote:
>> Jacek
>>
>> On 1/7/19 2:59 PM, Jacek Anaszewski wrote:
>>> Dan,
>>>
>>> On 1/7/19 8:36 PM, Dan Murphy wrote:
>>>> Jacek
>>>>
>>>> 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:
>>>>>>> Hi!
>>>>>>>
>>>>>>>>> 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 [0] 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
>>>>>>>> that.
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>>> <quote>
>>>>>> 8.3.1.2 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.
>>>>>>
>>>>>> 8.3.1.2.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.
>>>>>> </quote>
>>>>>>
>>>>>>> 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" [0]
>>>>>> 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 [1].
>>>>>>
>>>>>> Document [0] mentions also specific "Design considerations" in the
>>>>>> chapter 2.2:
>>>>>>
>>>>>> <quote>
>>>>>> 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.
>>>>>> </quote>
>>>>>>
>>>>>> 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
>>>>>>>        monitors.
>>>>>>>
>>>>>>> Nice to have features:
>>>>>>>
>>>>>>> 3) Full range of available colors/intensities should be available to
>>>>>>> userspace
>>>>>>>
>>>>>>> 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
>>>>>>> variations).
>>>>>>>
>>>>>>> 6) Complexity of math in kernel should be low, and preferably it
>>>>>>> should be integer or fixed point
>>>>>>>
>>>>>>> Problems:
>>>>>>>
>>>>>>> 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
>>>>>>> spectrums.
>>>>>>>
>>>>>>> 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?
>>>>>>
>>>>>> [0] http://www.ti.com/lit/ug/tiduee6/tiduee6.pdf
>>>>>> [1] 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.
>>>
>>> As you can see from the discussion in this thread it may take some
>>> time to work out the interface satisfying everyone. I made some design
>>> proposal, but Pavel had no warm word for it. It would be easier if
>>> we had more opinions.
>>
>> I got it from the threads and just the time invested in the FW and HSV.
>>
>>>
>>> How do you feel about using brightness file for setting LEDn_BRIGHTNESS?
>>
>> I am using that now.  The brightness file will adjust the overall brightness of the LED group
>> or bank pending on how the LEDs are grouped in the DT file.
>>
>>>
>>> Does increasing LEDn_BRIGHTNESS value (i.e. color intensity) feel like
>>> increasing color lightness (i.e. the pattern presented in the video [0]
>>> starting from 1:22)?
>>
>> No unfortunately this is why I introduced the new files to control the individual RGB intensities
>> so that the designers can set, tune, create color variations or patterns like the video.
>>
>> The RGB group brightness would be independent based on lighting conditions, enclosures and diffusers.
>> So you could technically be changing color and overall brightness virtually simultaneously
> 
> Oh, so this is surprising. Now it gets even more obscure to me.
> 
> It would be really helpful if we could see a video showing
> the LED effects with regard to the applied settings.

Well I am doing a test off the command line to ensure the user space can interface with the RGB LED.

I can ping someone in product development to see the application of this device if that would help.
We did give them a test driver to work on their features but told them the driver is not final until it
is in the mainline kernel

Dan

> 
>>>> But keep in mind I still need to invest my time in the other TI-lmu patches on my list to complete.
>>>
>>> Do what you deem most suitable for you. We are here only to help
>>> merging the patches, but keeping in mind that kernel interface once
>>> introduced must be preserved forever. Therefore we need to do our
>>> best to make the best possible design decisions.
>>>
>>> [0] https://www.youtube.com/watch?v=qdt-alh8i6E
>>>
>>
>> I understand.  Maybe I can make the files generic to use for either control or individual control.
>>
>> We can probably define new ABI's until either HSV or DT frameworks get going.  And them make the file presentation
>> configurable and default to the new files.
> 
> I am leaning towards it. Just commented on your patches.
> 


-- 
------------------
Dan Murphy

Powered by blists - more mailing lists