Re: [PATCH 04/24] dt-bindings: leds: Add function and color properties

[Jacek Anaszewski]

Hi Vesa,

On 11/09/2018 09:32 AM, Vesa JÃÃskelÃinen wrote:
> On 07/11/2018 0.07, Jacek Anaszewski wrote:
>> Introduce dedicated properties for conveying information about
>> LED function and color. Mark old "label" property as deprecated.
>>
>> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@xxxxxxxxx>
>> Cc: Baolin Wang <baolin.wang@xxxxxxxxxx>
>> Cc: Daniel Mack <daniel@xxxxxxxxxx>
>> Cc: Dan Murphy <dmurphy@xxxxxx>
>> Cc: Linus Walleij <linus.walleij@xxxxxxxxxx>
>> Cc: Oleh Kravchenko <oleg@xxxxxxxxxx>
>> Cc: Sakari Ailus <sakari.ailus@xxxxxxxxxxxxxxx>
>> Cc: Simon Shields <simon@xxxxxxxxxxxxx>
>> Cc: Xiaotong Lu <xiaotong.lu@xxxxxxxxxxxxxx>
>> ---
>> Â Documentation/devicetree/bindings/leds/common.txt | 52
>> +++++++++++++++++++----
>> Â 1 file changed, 44 insertions(+), 8 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/leds/common.txt
>> b/Documentation/devicetree/bindings/leds/common.txt
>> index aa13998..3efc826 100644
>> --- a/Documentation/devicetree/bindings/leds/common.txt
>> +++ b/Documentation/devicetree/bindings/leds/common.txt
>> @@ -10,14 +10,20 @@ can influence the way of the LED device
>> initialization, the LED components
>> Â have to be tightly coupled with the LED device binding. They are
>> represented
>> Â by child nodes of the parent LED device binding.
>> Â +
>> Â Optional properties for child nodes:
>> Â - led-sources : List of device current outputs the LED is connected
>> to. The
>> ÂÂÂÂÂÂÂÂÂ outputs are identified by the numbers that must be defined
>> ÂÂÂÂÂÂÂÂÂ in the LED device binding documentation.
>> +- function: LED functon. Use one of the LED_FUNCTION_* prefixed
>> definitions
>> +ÂÂÂÂÂÂÂ from the header include/dt-bindings/leds/functions.h.
>> +ÂÂÂÂÂÂÂ If there is no matching LED_FUNCTION available, add a new one.
>> +- color : Color of the LED.
> 
> We have had for years out-of-tree patch for multi color gpio led driver
> which extends this concept with multiple colors. Then in sysfs there has
> been possibility to control the color and otherwise use blinking or
> other features.
> 
> Our need is multi color status led of the device which includes
> different kind of blinkings and colors on different situations.
> 
> Current in-tree gpio led driver just wasn't atomic enough and a bit
> clumsy interface for handling this.
> 
> Now that this is being looked at could we come up with solution that we
> could define multiple colors for one led in device tree and then we
> could work on getting the driver upstreamed?
> 
> What we did was generally:
> 
> leds-multi {
> ÂÂÂÂcompatible = "gpio-multi-leds";
> 
> ÂÂÂÂstatus {
> ÂÂÂÂÂÂÂ gpios = <...>;
> ÂÂÂÂÂÂÂ linux,default-trigger = "none";
> ÂÂÂÂÂÂÂ deafult-state = "keep";
> 
> ÂÂÂÂÂÂÂ color-red {
> ÂÂÂÂÂÂÂÂÂÂÂ pin-mask = <0x01>;
> ÂÂÂÂÂÂÂ };
> 
> ÂÂÂÂÂÂÂ color-green {
> ÂÂÂÂÂÂÂÂÂÂÂ pin-mask = <0x02>;
> ÂÂÂÂÂÂÂ };
> 
> ÂÂÂÂÂÂÂ color-orange {
> ÂÂÂÂÂÂÂÂÂÂÂ pin-mask = <0x03>;
> ÂÂÂÂÂÂÂ };
> ÂÂÂÂ};
> };
> 

Device Tree node implementation doesn't actually say too much
about the sysfs interface you came up with, which is most vital
in this case.

Support for RGB LEDs, or other variations of LED synchronization
have been approached several times, but without satisfying result
so far.

Generally the problem boils down to the issue of how triggers
should handle multiple synchronized LED class devices in a backwards
compatible way with monochrome LEDs.

At some point the HSV [0] approach was proposed, but there was a problem
with getting uniform colors across devices. Especially white.
Certainly a calibration mechanism would be required.

[0] https://lkml.org/lkml/2017/8/30/423

-- 
Best regards,
Jacek Anaszewski