linux-kernel - Re: [PATCH 3/5] dt-bindings: ti-lmu: Modify dt bindings for the LM3697

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 4 Apr 2019 20:39:41 +0200
From:   Jacek Anaszewski <jacek.anaszewski@...il.com>
To:     Dan Murphy <dmurphy@...com>, robh+dt@...nel.org, pavel@....cz
Cc:     linux-kernel@...r.kernel.org, linux-leds@...r.kernel.org
Subject: Re: [PATCH 3/5] dt-bindings: ti-lmu: Modify dt bindings for the
 LM3697

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


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

-- 
Best regards,
Jacek Anaszewski