mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Dan Murphy <dmurphy@ti.com>
To: Jacek Anaszewski <jacek.anaszewski@gmail.com>,
	<robh+dt@kernel.org>, <pavel@ucw.cz>
Cc: <linux-kernel@vger.kernel.org>, <linux-leds@vger.kernel.org>
Subject: Re: [PATCH 3/5] dt-bindings: ti-lmu: Modify dt bindings for the LM3697
Date: Thu, 4 Apr 2019 14:27:08 -0500	[thread overview]
Message-ID: <28007702-cee0-079b-ccda-864f98a7b520@ti.com> (raw)
In-Reply-To: <4983e0b6-ae2b-9d15-0408-fdb23869711a@gmail.com>

On 4/4/19 1:39 PM, Jacek Anaszewski wrote:
> Dan,
> 
> On 4/3/19 10:23 PM, Dan Murphy wrote:
>> Jacek
>>
>> On 4/3/19 3:10 PM, Jacek Anaszewski wrote:
>>> Hi Dan,
>>>
>>> Thank you for the patch.
>>>
>>> You need Lee Jones on CC for this series.
>>>
>>
>> Yes I saw I missed Lee.
>>
>>> One more comment below.
>>>
>>> On 3/25/19 3:24 PM, Dan Murphy wrote:
>>>> The LM3697 is a single function LED driver. The single function LED
>>>> driver needs to reside in the LED directory as a dedicated LED driver
>>>> and not as a MFD device.  The device does have common brightness and ramp
>>>> features and those can be accomodated by a TI LMU framework.
>>>>
>>>> The LM3697 dt binding needs to be moved from the ti-lmu.txt and a dedicated
>>>> LED dt binding needs to be added.  The new LM3697 LED dt binding will then
>>>> reside in the Documentation/devicetree/bindings/leds directory and follow the
>>>> current LED and general bindings guidelines.
>>>>
>>>> Signed-off-by: Dan Murphy <dmurphy@ti.com>
>>>> ---
>>>>    .../devicetree/bindings/leds/leds-lm3697.txt  | 77 +++++++++++++++++++
>>>>    .../devicetree/bindings/mfd/ti-lmu.txt        | 26 +------
>>>>    2 files changed, 78 insertions(+), 25 deletions(-)
>>>>    create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3697.txt
>>>>
>>>> diff --git a/Documentation/devicetree/bindings/leds/leds-lm3697.txt b/Documentation/devicetree/bindings/leds/leds-lm3697.txt
>>>> new file mode 100644
>>>> index 000000000000..a780f11acd38
>>>> --- /dev/null
>>>> +++ b/Documentation/devicetree/bindings/leds/leds-lm3697.txt
>>>> @@ -0,0 +1,77 @@
>>>> +* Texas Instruments - LM3697 Highly Efficient White LED Driver
>>>> +
>>>> +The LM3697 11-bit LED driver provides high-
>>>> +performance backlight dimming for 1, 2, or 3 series
>>>> +LED strings while delivering up to 90% efficiency.
>>>> +
>>>> +This device is suitable for display and keypad Lighting
>>>> +
>>>> +Required properties:
>>>> +    - compatible:
>>>> +        "ti,lm3697"
>>>> +    - reg :  I2C slave address
>>>> +    - #address-cells : 1
>>>> +    - #size-cells : 0
>>>> +
>>>> +Optional properties:
>>>> +    - enable-gpios : GPIO pin to enable/disable the device
>>>> +    - vled-supply : LED supply
>>>> +
>>>> +Required child properties:
>>>> +    - reg : 0 - LED is Controlled by bank A
>>>> +        1 - LED is Controlled by bank B
>>>> +    - led-sources : Indicates which HVLED string is associated to which
>>>> +            control bank.  This is a zero based property so
>>>> +            HVLED1 = 0, HVLED2 = 1, HVLED3 = 2.
>>>> +            Additional information is contained
>>>> +            in Documentation/devicetree/bindings/leds/common.txt
>>>> +
>>>> +Optional child properties:
>>>> +    - max_brightness - This determines whether to use 8 bit brightness mode
>>>> +               or 11 bit brightness mode.  If this value is not
>>>> +               set the device is defaulted to the preferred 8bit
>>>> +               brightness mode per 7.3.4.1 of the data sheet.
>>>> +               The values are 255 (8bit) or 2047 (11bit).
>>>
>>> We should use led-max-microamp for that, if possible.
>>>
>>
>> Actually I was thinking this property could move to common.txt
>> LM3697 would use it and it is also defined in leds-pwm.txt leds-netxbig.txt
> 
> It was considered back in 2014 when I was working on LED flash
> class framework. It was then assessed inappropriate for describing
> physical property of a device. It needs to be kept in mind that
> it was in the context of flash LEDs, where currents are much
> higher than for common LEDs. Since then we have been always using
> led-max-microamp.
> 
> With max-brightness in Device Tree there is also another problem -
> we don't know what it really means - greater allowed current or
> greater resolution.
> 
> Why not allow for maximum available brightness resolution for ti-lmu
> always when the amperage is not an issue?
> 

Maybe I should rename this to ti,brightness-resolution with the same values.
or ti,brightness-res for short hand.

Or I could try to figure out the max-microamp but it really does not describe the hardware or
the configuration.

Dan


> 
>> But I could rename it to led-max-microamp and figure out an algo to convert to max brightness
>>
>> Dan
>>
> 


-- 
------------------
Dan Murphy

  reply	other threads:[~2019-04-04 19:27 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-25 14:23 [PATCH 0/5] TI LMU rework Dan Murphy
2019-03-25 14:23 ` [PATCH 1/5] dt-bindings: mfd: Update the ramp up/down property Dan Murphy
2019-04-04  8:19   ` Lee Jones
2019-04-04 12:07     ` Dan Murphy
2019-03-25 14:24 ` [PATCH 2/5] leds: TI LMU: Add common code for TI LMU devices Dan Murphy
2019-04-04 13:22   ` Pavel Machek
2019-03-25 14:24 ` [PATCH 3/5] dt-bindings: ti-lmu: Modify dt bindings for the LM3697 Dan Murphy
2019-04-03 20:10   ` Jacek Anaszewski
2019-04-03 20:23     ` Dan Murphy
2019-04-04 18:39       ` Jacek Anaszewski
2019-04-04 19:27         ` Dan Murphy [this message]
2019-04-04 19:31           ` Jacek Anaszewski
2019-04-04 19:34           ` Dan Murphy
2019-03-25 14:24 ` [PATCH 4/5] mfd: ti-lmu: Remove support for LM3697 Dan Murphy
2019-04-04  8:17   ` Lee Jones
2019-04-04  8:18     ` Lee Jones
2019-04-04 12:09     ` Dan Murphy
2019-03-25 14:24 ` [PATCH 5/5] leds: lm3697: Introduce the lm3697 driver Dan Murphy
2019-04-13 20:06   ` Pavel Machek
2019-04-15 12:49     ` Dan Murphy
2019-04-15 14:03       ` Pavel Machek
2019-04-15 19:53         ` Dan Murphy
2019-04-03 12:02 ` [PATCH 0/5] TI LMU rework Dan Murphy
2019-04-03 20:14   ` 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=28007702-cee0-079b-ccda-864f98a7b520@ti.com \
    --to=dmurphy@ti.com \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-leds@vger.kernel.org \
    --cc=pavel@ucw.cz \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®