[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <7C9DF12E-32C6-4D7C-BAAD-5CE9F8BA305A@goldelico.com>
Date: Sat, 10 Sep 2016 11:10:17 +0200
From: "H. Nikolaus Schaller" <hns@...delico.com>
To: Matthijs van Duin <matthijsvanduin@...il.com>
Cc: David Rivshin <drivshin@...worx.com>,
BenoƮt Cousson <bcousson@...libre.com>,
Tony Lindgren <tony@...mide.com>,
Rob Herring <robh+dt@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Russell King <linux@...linux.org.uk>,
Marek Belisko <marek@...delico.com>,
"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
devicetree <devicetree@...r.kernel.org>,
lkml <linux-kernel@...r.kernel.org>,
Discussions about the Letux Kernel
<letux-kernel@...nphoenux.org>,
Neil Armstrong <narmstrong@...libre.com>
Subject: Re: [PATCH] ARM: dts: omap3-gta04: reduce panel backlight PWM frequency to 83Hz
Hi,
> Am 10.09.2016 um 10:20 schrieb Matthijs van Duin <matthijsvanduin@...il.com>:
>
> On 10 September 2016 at 09:08, H. Nikolaus Schaller <hns@...delico.com> wrote:
>> Reducing the PWM frequency is good by itself since it should not be unnecessarily
>> fast and helps to make the PWM to "average current" translation more linear.
>>
>> The non-linear effect is that the PWM controlled DC/DC converter reacts almost
>> immediately to a 1->0 control transition but needs some time (ca. 0.5ms) to recover
>> on a 0->1 transition.
>
> DT already allows for compensation of many non-linearities by
> specifying the duty cycle of each brightness increment. Though, as
> you observed, there's one limitation it cannot fix here:
>
>> If we just fix the PWM generator to output a steady 1 signal at 100%, we have a
>> very significant change if we switch to 99%, depending on PWM frequency.
>
> Specifically the next-to-brightest step (assuming 0.5ms off-time) would be:
> 75% @ 500 Hz
> 90% @ 200 Hz
> 95% @ 100 Hz
> 96% @ 83 Hz
Yes.
>
> Note that perceptually the distance to 100% might be smaller due to
> non-linear response of the eye. That's my experience with pwm
> controlled leds anyway, which may or may not apply to backlights
basically it does. Eye is basically logarithmic - but has several auto-exposure
and auto-iris mechanisms... So perceived brightness is a very complex topic.
It might even depend on the color and contrast of the image presented. This
is something we can ever fix by DT...
> (though with my laptop's backlight I never really have use for the
> distinct steps at the brightest end while those at the darkest end
> seem disproportionally large).
>
>> This effect becomes smaller if the PWM frequency is reduced and 83Hz seems more
>> reasonable (although still a little arbitrary) than the current value.
>
> While 500Hz is perhaps a bit high, 83Hz actually seems very low to me.
Why? The eye can't even see flicker @ 50 Hz.
And, there is a capacitor that averages the voltage applied, hence it is
low pass filtered. But the capacitor can't compensate for the startup delay
of the DC/DC converter.
And, I have tested that on the device targeted by this DTS... No visible
issue (except that maximum brightness decreases if too high).
> Searching a bit around yielded 175 Hz as common frequency for CCFL
> backlights and higher for LED backlights (source:
> http://www.tftcentral.co.uk/articles/pulse_width_modulation.htm).
>
> (I may be reacting a bit twitchy here due to having encountered dimmed
> LED lighting that was flickering obnoxiously for me while noone else
> noticed this.)
>
> Matthijs
But with the patch submitted, I just want to give the dts of a single
device I have even designed a more reasonable value than in current
linux/master and don't really want to make it a fundamental discussion...
BR,
Nikolaus
Powered by blists - more mailing lists