All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacek Anaszewski <j.anaszewski@samsung.com>
To: "Kim, Milo" <milo.kim@ti.com>
Cc: robh+dt@kernel.org, lee.jones@linaro.org, broonie@kernel.org,
	devicetree@vger.kernel.org, linux-leds@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 3/9] Documentation: dt-bindings: leds: add LM3633 LED binding information
Date: Mon, 30 Nov 2015 13:26:51 +0100	[thread overview]
Message-ID: <565C408B.9070703@samsung.com> (raw)
In-Reply-To: <565C0677.4030606@ti.com>

Hi Milo,

On 11/30/2015 09:19 AM, Kim, Milo wrote:
> Hi Jacek,
>
> On 11/27/2015 8:19 PM, Jacek Anaszewski wrote:
>> Hi Milo,
>>
>> On 11/26/2015 07:56 AM, Milo Kim wrote:
>>> LM3633 LED device is one of TI LMU device list.
>>>
>>> Cc: Rob Herring <robh+dt@kernel.org>
>>> Cc: devicetree@vger.kernel.org
>>> Cc: Lee Jones <lee.jones@linaro.org>
>>> Cc: Jacek Anaszewski <j.anaszewski@samsung.com>
>>> Cc: Mark Brown <broonie@kernel.org>
>>> Cc: linux-leds@vger.kernel.org
>>> Cc: linux-kernel@vger.kernel.org
>>> Signed-off-by: Milo Kim <milo.kim@ti.com>
>>> ---
>>>    .../devicetree/bindings/leds/leds-lm3633.txt       | 24
>>> ++++++++++++++++++++++
>>>    1 file changed, 24 insertions(+)
>>>    create mode 100644
>>> Documentation/devicetree/bindings/leds/leds-lm3633.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/leds/leds-lm3633.txt
>>> b/Documentation/devicetree/bindings/leds/leds-lm3633.txt
>>> new file mode 100644
>>> index 0000000..a553894
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/leds/leds-lm3633.txt
>>> @@ -0,0 +1,24 @@
>>> +TI LMU LM3633 LED device tree bindings
>>> +
>>> +Required properties:
>>> +  - compatible: "ti,lm3633-leds"
>>> +
>>> +Child nodes:
>>> +  Each node matches with LED control bank.
>>> +  Please refer to the datasheet [1].
>>
>> leds/common.txt documentation says that child nodes represent discrete
>> LED elements.
>>
>>> +  Required properties of a child node:
>>> +  - led-sources: List of enabled channels from 0 to 5.
>>> +                 Please refer to LED binding [2].
>>
>> led-sources property should contain always one element -

Here I should have added that this would have been the correct approach
for this device. For led flash controllers where we have one LED
connected to two outputs there are two element in the led-sources array.

>> a control bank identifier that the iout is to be associated with.
>> For example, if there are three LEDs and they should be controlled
>> with control bank A, then the bindings should look as follows
>> (assuming that control bank identifiers start from 0 [A:0, B:1,
>> C:2, etc. - it has to be also explicitly stated in the documentation]:
>
> My understanding is 'led-sources' means output channel rather than
> control bank. Output channel is visible and intuitive - just output LED.
> On the other hand, control banks works inside the silicon, LM3633.
> I'm not sure other LED devices have control bank or not, but output
> channel is common concept.

There is no "channel" notion present in the leds/common.txt
documentation.

led-sources property is documented as "list of device current outputs
the LED is connected to." In case of your device the LVLEDn pins can be
configured so that they are routed to the common current output.

led-sources property has been initially designed for representing
one-LED-to many-iouts relation, but it can be equally well exploited for
representing many-LEDs-to-one-iout relation, if used in conjunction
with DT child nodes.

>>
>> lvled1 {
>>     led-sources = <2>;
>>     led-max-microamp = <1000>;
>> }
>>
>> lvled2 {
>>     led-sources = <2>;
>>     led-max-microamp = <29000>;
>> }
>>
>> lvled3 {
>>     led-sources = <2>;
>>     led-max-microamp = <7000>;
>> }
>
> For this reason, I don't understand this LED configuration - one output
> channel with multiple LED devices. LED child node should be matched with
> led class device.

I can't find any claim saying that child node should represent
LED class device. Instead, there is a statement saying that
discrete LED components "are represented by child nodes of the parent
LED device binding". What is more e.g. leds-bcm6328.txt bindings don't
expose LED class device for the LEDs marked as hardware controlled.

Device tree describes hardware, and above bindings properly reflect
hardware arrangement - there are three LEDs and each of them
is connected to the same current output. Please note that
common/leds.txt documentation doesn't make any reservation saying
that current output necessarily reflects a hardware pin.

In case of LM3633 the real current outputs are banks and multiplexing
that occurs between banks and LVLEDn pins can be conveniently expressed
with the bindings I proposed above.

> If three output channels are controlled by one control bank, then it
> should be represented as below.
>
> lvled-group-A {
>      led-sources = <0>, <1>, <2>;
>      led-max-microamp = <some value>;
> }
>
> Please let me know if I misunderstand.

You silently assumed some definition of a "channel". led-sources means
in fact current sources, and when device is configured so that three
output pins are routed to the same current source, then in fact
they share common current source.

-- 
Best Regards,
Jacek Anaszewski

  reply	other threads:[~2015-11-30 12:26 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-26  6:56 [PATCH v2 0/9] Support TI LMU devices Milo Kim
2015-11-26  6:56 ` Milo Kim
2015-11-26  6:56 ` [PATCH v2 1/9] Documentation: dt-bindings: mfd: add TI LMU device binding information Milo Kim
2015-11-26  6:56   ` Milo Kim
2015-11-27 20:55   ` Rob Herring
2016-01-11  9:46   ` Lee Jones
2015-11-26  6:56 ` [PATCH v2 2/9] Documentation: dt-bindings: leds: backlight: add TI LMU backlight " Milo Kim
2015-11-26  6:56   ` Milo Kim
2016-01-11  9:53   ` Lee Jones
2015-11-26  6:56 ` [PATCH v2 3/9] Documentation: dt-bindings: leds: add LM3633 LED " Milo Kim
2015-11-26  6:56   ` Milo Kim
2015-11-27 11:19   ` Jacek Anaszewski
2015-11-30  8:19     ` Kim, Milo
2015-11-30  8:19       ` Kim, Milo
2015-11-30 12:26       ` Jacek Anaszewski [this message]
     [not found]         ` <565C408B.9070703-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2015-12-07  8:46           ` Kim, Milo
2015-12-07  8:46             ` Kim, Milo
2015-12-07 10:50             ` Jacek Anaszewski
2015-11-26  6:57 ` [PATCH v2 4/9] Documentation: dt-bindings: regulator: add LM363x regulator " Milo Kim
2015-11-26  6:57   ` Milo Kim
2015-11-27 12:37   ` Mark Brown
2015-11-27 20:44     ` Rob Herring
2015-11-27 22:07       ` Mark Brown
2015-11-27 12:55   ` Applied "regulator: lm363x: add LM363x regulator binding information" to the regulator tree Mark Brown
2015-11-27 20:57   ` [PATCH v2 4/9] Documentation: dt-bindings: regulator: add LM363x regulator binding information Rob Herring
2015-11-26  6:57 ` [PATCH v2 5/9] mfd: add TI LMU driver Milo Kim
2015-11-26  6:57   ` Milo Kim
2016-01-11 10:17   ` Lee Jones
2015-11-26  6:57 ` [PATCH v2 6/9] mfd: add TI LMU hardware fault monitoring driver Milo Kim
2015-11-26  6:57   ` Milo Kim
2016-01-11 10:21   ` Lee Jones
2016-01-12  3:36     ` Milo Kim
2016-01-12  3:36       ` Milo Kim
2016-01-12  7:37       ` Lee Jones
2015-11-26  6:57 ` [PATCH v2 7/9] backlight: add TI LMU backlight driver Milo Kim
2015-11-26  6:57   ` Milo Kim
2016-01-11  9:57   ` Lee Jones
2016-01-11 23:32     ` Milo Kim
2016-01-11 23:32       ` Milo Kim
2015-11-26  6:57 ` [PATCH v2 8/9] leds: add LM3633 driver Milo Kim
2015-11-26  6:57   ` Milo Kim
2015-11-27 11:19   ` Jacek Anaszewski
     [not found]     ` <56583C37.1050307-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2015-11-28  8:28       ` Jacek Anaszewski
2015-11-28  8:28         ` Jacek Anaszewski
2015-11-30  8:48     ` Kim, Milo
2015-11-30  8:48       ` Kim, Milo
2015-11-30 12:26       ` Jacek Anaszewski
2015-11-26  6:57 ` [PATCH v2 9/9] regulator: add LM363X driver Milo Kim
2015-11-26  6:57   ` Milo Kim
2015-11-27 12:55   ` Applied "regulator: add LM363X driver" to the regulator tree Mark Brown
2016-01-14  7:56   ` [PATCH v2 9/9] regulator: add LM363X driver Milo Kim
2016-01-14  7:56     ` Milo Kim
     [not found]     ` <56975493.7050900-l0cyMroinI0@public.gmane.org>
2016-01-14 10:27       ` Mark Brown
2016-01-14 10:27         ` Mark Brown
2016-01-14 23:41         ` Kim, Milo
2016-01-14 23:41           ` Kim, Milo
2016-01-06  7:20 ` [PATCH v2 0/9] Support TI LMU devices Milo Kim
2016-01-06  7:20   ` Milo Kim

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=565C408B.9070703@samsung.com \
    --to=j.anaszewski@samsung.com \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=lee.jones@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=milo.kim@ti.com \
    --cc=robh+dt@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.