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
next prev parent 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®