Re: [RFC PATCH 2/5] dt: bindings: Add multicolor class dt bindings documention

[Jacek Anaszewski <jacek.anaszewski@gmail.com>]

On 4/1/19 11:29 PM, Pavel Machek wrote:
> Hi!
> 
> 
>>   .../bindings/leds/leds-class-multicolor.txt   | 140 ++++++++++++++++++
>>   1 file changed, 140 insertions(+)
>>   create mode 100644 Documentation/devicetree/bindings/leds/leds-class-multicolor.txt
>>
>> diff --git a/Documentation/devicetree/bindings/leds/leds-class-multicolor.txt b/Documentation/devicetree/bindings/leds/leds-class-multicolor.txt
>> new file mode 100644
>> index 000000000000..4b1a26104c79
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/leds/leds-class-multicolor.txt
>> @@ -0,0 +1,140 @@
>> +* Multicolor LED properties
>> +
>> +Multicolor LEDs can consist of a RGB, RGBW or a RGBA LED clusters.  These devices
>> +can be grouped together and also provide a modeling mechanism so that the
>> +cluster LEDs can vary in hue and intensity to produce a wide range of colors.
>> +
>> +The nodes and properties defined in this document are unique to the multicolor
>> +LED class.  Common LED nodes and properties are inherited from the common.txt
>> +within this documentation directory.
>> +
>> +Required LED Child properties:
>> +	- color : This is the color ID of the LED.  Definitions can be found
>> +		  in include/linux/leds/common.txt
>> +
>> +Optional LED Child properties:
>> +	- available-brightness-models : This is the phandle to the brightness-model
>> +					node(s) that this LED cluster can support.
>> +
>> +Required Brightness model properties
>> +	- led-brightness-model : This flag alerts the device driver and class
>> +				 code that this node is a brightness model node
>> +				 and to process the properties differently.
>> +
>> +Required Brightness model child properties
>> +	- model_name : This is the name of the model presented to the user.  This
>> +		       should be a color that the LED cluster can produce for
>> +		       the device it is attached to.
>> +	- layout : This is the LED layout for the levels.  This layout will
>> +		   determine the color order of the levels.  The layout and
>> +		   level-x properties array should be the same size.
>> +	- level-x : These are the values for the LEDs to produce the color that
>> +		    is defined.  These values are placed in the array according
>> +		    to the layout property.
> 
>> +led-controller@30 {
>> +	#address-cells = <1>;
>> +	#size-cells = <0>;
>> +	compatible = "ti,lp5024";
>> +	reg = <0x29>;
>> +
>> +	lp5024_model_yellow: brightness-models {
>> +		led-brightness-model;
>> +		model@0 {
>> +			model_name = "yellow";
>> +			layout = <LED_COLOR_ID_RED
>> +				  LED_COLOR_ID_GREEN
>> +				  LED_COLOR_ID_BLUE>;
>> +			level-1 = <255 227 40>;
>> +			level-2 = <255 240 136>;
>> +			level-3 = <255 247 196>;
>> +		};
>> +	};
> 
> I don't think this works. RGB LED can show millions of colors. Do you
> propose to have millions of entries in dts?

Pavel, you know very well what is going on here and what is the
background of this design. I suppose you've just entered your trolling
mode - you lately admitted that it sometimes happens :-) [0]

This aims at solving the problem with multi color LED support in
a backward compatible way, which is especially important in relation
to existing triggers.

This is our attempt of addressing that problem in a color space
agnostic way. It was inspired by out-of-tree approach presented
by Vesa few months ago.

[0] https://www.spinics.net/lists/linux-leds/msg11388.html

-- 
Best regards,
Jacek Anaszewski