devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jacek Anaszewski <j.anaszewski@samsung.com>
To: Florian Vaussard <florian.vaussard@heig-vd.ch>
Cc: Florian Vaussard <florian.vaussard@gmail.com>,
	devicetree@vger.kernel.org, Richard Purdie <rpurdie@rpsys.net>,
	Rob Herring <robh+dt@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>, Pavel Machek <pavel@ucw.cz>,
	linux-leds@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] leds: ncp5623: Add device tree binding documentation
Date: Mon, 27 Jun 2016 10:33:47 +0200	[thread overview]
Message-ID: <5770E4EB.4040609@samsung.com> (raw)
In-Reply-To: <4125a334-2e15-285d-2721-c007b30ed65d@heig-vd.ch>

On 06/27/2016 10:30 AM, Florian Vaussard wrote:
> Hi Jacek,
>
> Le 27. 06. 16 à 10:11, Jacek Anaszewski a écrit :
>> Hi Florian,
>>
>> On 06/27/2016 09:03 AM, Florian Vaussard wrote:
>>> Add device tree binding documentation for On Semiconductor NCP5623 I2C
>>> LED driver. The driver can independently control the PWM of the 3
>>> channels with 32 levels of intensity.
>>>
>>> The current delivered by the current source can also be controlled. To
>>> do so, the led-max-microamp property is used by each LED sub-node. The
>>> maximum value is then found and used as a limit to compute the final
>>> intensity of the current source. If a LED happens to have a lower limit,
>>> the PWM is then used to limit the current to the requested value.
>>>
>>> In order to control the current source, it is also necessary to know
>>> the current on the Iref pin, hence the onnn,led-iref-microamp property.
>>> It is usually set using an external bias resistor, following
>>> Iref = Vref/Rbias with Vref=0.6V.
>>>
>>> Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
>>> ---
>>>    .../devicetree/bindings/leds/leds-ncp5623.txt      | 60 ++++++++++++++++++++++
>>>    1 file changed, 60 insertions(+)
>>>    create mode 100644 Documentation/devicetree/bindings/leds/leds-ncp5623.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/leds/leds-ncp5623.txt
>>> b/Documentation/devicetree/bindings/leds/leds-ncp5623.txt
>>> new file mode 100644
>>> index 0000000..77dd7ad
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/leds/leds-ncp5623.txt
>>> @@ -0,0 +1,60 @@
>>> +* ON Semiconductor - NCP5623 3-Channel LED Driver
>>> +
>>> +The NCP5623 is a 3-channel I2C LED driver. The brightness of each
>>> +channel can be independently set using 32 levels. Each LED is represented
>>> +as a sub-node of the device.
>>> +
>>> +Required properties:
>>> +  - compatible: Should be "onnn,ncp5623"
>>> +  - reg: I2C slave address (fixed to 0x38)
>>> +  - #address-cells: must be 1
>>> +  - #size-cells: must be 0
>>> +  - onnn,led-iref-microamp: Current on the Iref pin in microampere. It depends
>>> +    on the value of the external bias resistor Rbias, following
>>> +    Iref = Vref / Rbias with Vref = 0.6V. This is used to set the intensity of
>>> +    the current that can be provided by the internal current source, based on
>>> +    the maximum current permitted by LED sub-nodes (see below), but no more than
>>> +    Imax = 2400 * Iref.
>>> +
>>> +LED sub-nodes
>>> +=============
>>> +
>>> +Required properties:
>>> +  - reg : LED channel number (0..2)
>>> +  - led-max-microamp: Maximum allowable current inside the LED in microampere.
>>> +    This property is used to limit the PWM ratio, based on the intensity of the
>>> +    internal current source (see above).
>>> +
>>> +Optional properties:
>>> +  - label: Used for naming LEDs
>>
>> Instead of the above description use same reference to common led
>> bindings as below.
>>
>
> Ok.
>
> BTW I saw the thread about the "default-state" property on the DT list and
> realized that it was not implemented in my driver. I wonder if standard LED
> properties (with label and default-trigger) should not be parsed by LED core
> (i.e. using a helper function) to avoid such mistake. This could also remove
> some boilerplate code in other LED drivers.

Yes, generic DT parser is a nice-to-have feature for the LED subsystem.
Would you like to implement it?

>
>>> +  - default-trigger: see Documentation/devicetree/bindings/leds/common.txt
>>> +
>>> +Example
>>> +=======
>>> +
>>> +led1: ncp5623@38 {
>>> +    #address-cells = <1>;
>>> +    #size-cells = <0>;
>>> +    compatible = "onnn,ncp5623";
>>> +    reg = <0x38>;
>>> +    onnn,led-iref-microamp = <10>;
>>> +
>>> +    led1r@0 {
>>> +        label = "ncp:power:red";
>>> +        linux,default-trigger = "default-on";
>>> +        reg = <0>;
>>> +        led-max-microamp = <20000>;
>>> +    };
>>> +
>>> +    led1b@1 {
>>> +        label = "ncp:power:blue";
>>> +        reg = <1>;
>>> +        led-max-microamp = <20000>;
>>> +    };
>>> +
>>> +    led1g@2 {
>>> +        label = "ncp:power:green";
>>> +        reg = <2>;
>>> +        led-max-microamp = <20000>;
>>> +    };
>>> +};
>>>
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-leds" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>


-- 
Best regards,
Jacek Anaszewski

  reply	other threads:[~2016-06-27  8:33 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-27  7:03 [PATCH v2 0/2] leds: Add driver for NCP5623 3-channel I2C LED driver Florian Vaussard
2016-06-27  7:03 ` [PATCH v2 1/2] leds: ncp5623: Add device tree binding documentation Florian Vaussard
2016-06-27  8:11   ` Jacek Anaszewski
2016-06-27  8:30     ` Florian Vaussard
2016-06-27  8:33       ` Jacek Anaszewski [this message]
     [not found]         ` <5770E4EB.4040609-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2016-06-27  8:59           ` Florian Vaussard
2016-06-28 20:56     ` Rob Herring
2016-06-27  7:03 ` [PATCH v2 2/2] leds: Add driver for NCP5623 3-channel I2C LED driver Florian Vaussard
2016-06-27  8:14   ` Jacek Anaszewski
2016-06-27  8:54     ` Florian Vaussard
     [not found]       ` <a16b7031-87db-dcd3-57d2-412e6f707970-EWQkb/GNqlFyDzI6CaY1VQ@public.gmane.org>
2016-06-27  9:12         ` Jacek Anaszewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5770E4EB.4040609@samsung.com \
    --to=j.anaszewski@samsung.com \
    --cc=devicetree@vger.kernel.org \
    --cc=florian.vaussard@gmail.com \
    --cc=florian.vaussard@heig-vd.ch \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pavel@ucw.cz \
    --cc=robh+dt@kernel.org \
    --cc=rpurdie@rpsys.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).