Re: [PATCH leds/for-next v2 2/2] leds: turris-omnia: Add support for 256 brightness values

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed 2019-05-01 12:44:47, Jacek Anaszewski wrote:
> 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



>         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>;
>                 };

> 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.

I'd propose to keep it simple... we are unlikely to see different
configurations in future. I'm not even sure if we should have it in
the dts, as this hardware is fixed -- this is not some kind of
reusable component.

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Attachment: signature.asc
Description: Digital signature


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux