On 5/1/19 12:12 PM, Jacek Anaszewski wrote:
[...]
Hi,
I am aware of this issue. I plan to change the driver to multicolor led
class as soon as it is available. But from the discussions I have read
it does not seem it will be available in the next kernel release. I
would like at least full brigthness for the next release and maybe hw
triggering, for which the first version I plan to send this week...
If you used led-sources property in your DT bindings it would be all
fine. It will justify having three channels controlled by single LED
class device.
I've just dropped the driver from linux-leds.git. Please resend
with added led-sources property.
You should provide identifiers in the bindings for each iout and list
them in each child node like below:
LED sub-node properties:
- reg : Must be from 0x0 to 0xb, since there are 12 RGB
LEDs on this
controller.
- label : (optional)
see Documentation/devicetree/bindings/leds/common.txt
- linux,default-trigger : (optional)
see Documentation/devicetree/bindings/leds/common.txt
- led-sources : Each child node should describe RGB LED it controls,
by listing corresponding iout identifiers:
0 - RGB LED 0: red
1 - RGB LED 0: green
2 - RGB LED 0: blue
3 - RGB LED 1: red
4 - RGB LED 1: green
5 - RGB LED 1: blue
6 - RGB LED 2: red
7 - RGB LED 2: green
8 - RGB LED 2: blue
9 - RGB LED 3: red
10 - RGB LED 3: green
11 - RGB LED 3: blue
... and list all the iouts, maybe other names will be more
appropriate for this device, feel free to propose something
Example:
led-controller@2b {
compatible = "cznic,turris-omnia-leds";
reg = <0x2b>;
#address-cells = <1>;
#size-cells = <0>;
led@0 {
reg = <0x0>;
label = "userB";
linux,default-trigger = "heartbeat";
led-sources = <0 1 2>;
};
led@1 {
reg = <0x1>;
label = "userA";
led-sources = <3 4 5>;
};
led@2 {
reg = <0x2>;
label = "pci3";
led-sources = <6 7 8>;
};
led@3 {
reg = <0x3>;
label = "pci2";
led-sources = <9 10 11>;
};
...
Then, there is an issue of what configurations we should allow for.
In the simplest form you could restrict that it is possible to do
only single RGB LED -> LED class device mapping.
But maybe it would be useful to allow for grouping more RGB LEDs
under single LED class deivce. It's up to you. It will complicate
the in-driver logic for sure, so for now we can abide by the simplest
mapping - it will need to be stated in the bindings.
--
Best regards,
Jacek Anaszewski
