[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=XHT_iEU918NVYHf26Xe=4UE0WO0oxBNy_VUfi2FdYGVA@mail.gmail.com>
Date: Mon, 27 Nov 2017 15:55:19 -0800
From: Doug Anderson <dianders@...gle.com>
To: Enric Balletbo Serra <eballetbo@...il.com>
Cc: Rob Herring <robh@...nel.org>,
Enric Balletbo i Serra <enric.balletbo@...labora.com>,
Daniel Thompson <daniel.thompson@...aro.org>,
Jingoo Han <jingoohan1@...il.com>,
Richard Purdie <rpurdie@...ys.net>,
Jacek Anaszewski <jacek.anaszewski@...il.com>,
Pavel Machek <pavel@....cz>,
Brian Norris <briannorris@...gle.com>,
Guenter Roeck <groeck@...gle.com>,
Lee Jones <lee.jones@...aro.org>,
Alexandru Stan <amstan@...gle.com>, linux-leds@...r.kernel.org,
"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [RFC v2 1/2] backlight: pwm_bl: linear interpolation between
values of brightness-levels
Hi,
On Mon, Nov 27, 2017 at 3:21 AM, Enric Balletbo Serra
<eballetbo@...il.com> wrote:
> Hi Rob,
>
> 2017-11-20 19:58 GMT+01:00 Rob Herring <robh@...nel.org>:
>> On Thu, Nov 16, 2017 at 03:11:50PM +0100, Enric Balletbo i Serra wrote:
>>> Setting use-linear-interpolation in the dts will allow you to have linear
>>> interpolation between values of brightness-levels.
>>>
>>> There are now 256 between each of the values of brightness-levels. If
>>> something is requested halfway between 2 values, we'll use linear
>>> interpolation.
>>>
>>> This way a high resolution pwm duty cycle can be used without having to
>>> list out every possible value in the dts.
>>
>> I thought we already had a way to do that.
>>
>>> This system also allows for
>>> gamma corrected values (eg: "brightness-levels = <0 2 4 8 16 32>;").
>>>
>>> Patch based on the Alexandru M Stan work done for ChromeOS kernels.
>>>
>>> Signed-off-by: Enric Balletbo i Serra <enric.balletbo@...labora.com>
>>> ---
>>> .../bindings/leds/backlight/pwm-backlight.txt | 2 +
>>> drivers/video/backlight/pwm_bl.c | 55 +++++++++++++++++-----
>>> include/linux/pwm_backlight.h | 2 +
>>> 3 files changed, 47 insertions(+), 12 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
>>> index 764db86..7c48f20 100644
>>> --- a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
>>> +++ b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
>>> @@ -17,6 +17,8 @@ Optional properties:
>>> "pwms" property (see PWM binding[0])
>>> - enable-gpios: contains a single GPIO specifier for the GPIO which enables
>>> and disables the backlight (see GPIO binding[1])
>>> + - use-linear-interpolation: set this propriety to enable linear interpolation
>>> + between each of the values of brightness-levels.
>>
>> Isn't this really just whether you allow values not listed because what
>> other kind of interpolation would you do?
>
> Yes, the idea behind this is just allow values not listed.
>
>> Seems like you should just be
>> able to query the resolution of the PWM and decide if it can take more
>> values than listed.
>>
>
> Without using a new DT propriety and let decide the driver when use
> intepolation and when not? Shouldn't this break current behavior then?
> You can have a high resolution PWM but I'm not sure if you want allow
> always more values than listed.
Right. The assumption is that it's _possible_ that only the exact
values listed are valid duty cycles. We don't want to break old
hardware by suddenly allowing other duty cycles to be used. However,
it's expected that on most hardware you can simply use any duty cycle
between any of the specified ones and it should be fine. Anyone
specifying this property would say that's OK for their hardware.
-Doug
Powered by blists - more mailing lists