Re: [RFC PATCH 0/2] Multicolor PWM LED support

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

Hi Sven,

On 1/26/22 8:51 AM, Sven Schwermer wrote:
> Hi Jacek,
> 
> Thank you for your feedback!
> 
> On 1/25/22 23:31, Jacek Anaszewski wrote:
> 
>>>    1. Currently, the max-brightness property is expected as a 
>>> property to
>>>       the multi-led node. That seems consistent with the existing
>>>       multicolor class code, but I'm wondering whether it would make
>>>       sense to have a max-brigthness for the individual LEDs as well?
>>
>> For the proper mixed color calculation all sub-leds should have
>> the same max_brightness as the global max_brightness.
>>
>> Look at how sub-led intensities are calculated in
>> led_mc_calc_color_components().
>>
>> See also [0] and [1].
> 
> OK, thanks. That makes sense.
> 
>>>    2. The current multi-led node definition calls for a node index which
>>>       would in turn require the reg property to be set within the node.
>>>       In this context, that doesn't seem to make sense. Should this
>>>       requirement be lifted from leds-class-multicolor.yaml?
>>
>> reg is required for all DT nodes with address unit in the name.
>> If you skipped the address unit, then reg would be also not required.
> 
> Yes, I realize this. However, leds-class-multicolor.yaml [0] requires 
> the address unit: "^multi-led@([0-9a-f])$"

This is only an example and nothing prevents you from dropping address
unit in leds-pwm-multicolor DT bindings. We don't have common DT parser
for multicolor LEDs and it will be hard to come up with something that
will fit neatly for all possible LED controllers anyway.

Dropping address unit from leds-class-multicolor.yaml would be too much
since it is useful in some cases, see e.g. [2].

[2] Documentation/devicetree/bindings/leds/leds-lp50xx.yaml

-- 
Best regards,
Jacek Anaszewski