Re: [PATCH v2] pwm_backlight: Add device tree support for Low Threshold Brightness

[Stephen Warren <swarren@wwwdotorg.org>]

On 09/21/2012 12:03 AM, Philip, Avinash wrote:
> Hi Stephen,
> 
> On Fri, Sep 21, 2012 at 10:46:45, Stephen Warren wrote:
>> On 09/20/2012 10:51 PM, Philip, Avinash wrote:
>>> Some backlights perform poorly when driven by a PWM with a short
>>> duty-cycle. For such devices, the low threshold can be used to specify a
>>> lower bound for the duty-cycle and should be chosen to exclude the
>>> problematic range.
>>>
>>> This patch adds support for an optional low-threshold-brightness
>>> property.
>>
>>> diff --git a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
>>
>>>  Optional properties:
>>>    - pwm-names: a list of names for the PWM devices specified in the
>>>                 "pwms" property (see PWM binding[0])
>>> +  - low-threshold-brightness: brightness threshold low level. Low threshold
>>> +    brightness set to value so that backlight present on low end of
>>> +    brightness.
>>
>> For my education, why not just specify values above this value in the
>> brightness-levels array; how do those two interact?
> 
> Please find details from 
> https://lkml.org/lkml/2012/7/18/284

Hmm. That still doesn't really explain what this property does.

I'm going to guess that if this property is present, and values in the
brightness-levels property get scaled between the
low-threshold-brightness and 255 instead of being used directly. But
then, in the email you linked to, what does "But brightness-levels won't
be uniformly divided" mean? Why would doing the calculation at run-time
be any better than simply putting the correct values into
brightness-levels in the first place?

Either way, the DT binding should explain exactly what this value is
used for, and how it affects the interpretation of values in
brightness-levels.