linux-kernel - RE: [PATCH v2] pwm_backlight: Add device tree support for Low Threshold Brightness

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, 27 Sep 2012 09:24:47 +0000
From:	"Philip, Avinash" <avinashphilip@...com>
To:	Thierry Reding <thierry.reding@...onic-design.de>,
	Stephen Warren <swarren@...dotorg.org>
CC:	"grant.likely@...retlab.ca" <grant.likely@...retlab.ca>,
	"rob.herring@...xeda.com" <rob.herring@...xeda.com>,
	"rob@...dley.net" <rob@...dley.net>,
	"rpurdie@...ys.net" <rpurdie@...ys.net>,
	"broonie@...nsource.wolfsonmicro.com" 
	<broonie@...nsource.wolfsonmicro.com>,
	"shawn.guo@...aro.org" <shawn.guo@...aro.org>,
	"devicetree-discuss@...ts.ozlabs.org" 
	<devicetree-discuss@...ts.ozlabs.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Nori, Sekhar" <nsekhar@...com>,
	"Hebbar, Gururaja" <gururaja.hebbar@...com>
Subject: RE: [PATCH v2] pwm_backlight: Add device tree support for Low
 Threshold Brightness

On Wed, Sep 26, 2012 at 22:19:49, Thierry Reding wrote:
> On Wed, Sep 26, 2012 at 09:27:51AM -0600, Stephen Warren wrote:
> > On 09/25/2012 10:35 PM, Philip, Avinash wrote:
> > > On Tue, Sep 25, 2012 at 11:49:14, Stephen Warren wrote:
> > >> On 09/24/2012 10:29 PM, Philip, Avinash wrote:
> > >>> On Fri, Sep 21, 2012 at 23:13:39, Stephen Warren wrote:
> > >>>> 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.
> > >>>
> > >>> This is correct.
> > >>>
> > >>>> But then, in the email you linked to, what does "But brightness-levels won't
> > >>>> be uniformly divided" mean?
> > >>>
> > >>> For some panels, backlight would absent on low end of brightness due to low
> > >>> percentage in duty_cycle. Consider following example where backlight absent
> > >>> for brightness levels from 0 - 51.
> > >>>
> > >>> pwms = <&pwm 0 50000>;
> > >>> brightness-levels = <0 51 53 56 62 75 101 152 255>; 
> > >>> default-brightness-level = <6>;
> > >>>
> > >>> So in the example, brightness-levels are set to have values for backlight present.
> > >>> Here levels are not uniformly divided.
> > >>
> > >> So why not just change the values so they /are/ what you want? After
> > >> all, it's just data and you can put whatever values you want there. What
> > >> is preventing you from doing this?
> > > 
> > > brightness_threshold_level was added to explore lth_brightness support already
> > > present in non-DT case.
> > 
> > I understand that. Given my discussion above, I would advocate removing
> > lth_brightness from the non-DT case rather than adding it to the DT
> > case, since it seems entirely pointless.
> 
> It is still required for the case where brightness levels are not used.
> So we can't drop it right away. I agree however that we should plan to
> get rid of the max_brightness and lth_brightness eventually. Since the
> DT bindings don't use it yet we should keep only the brightness levels.
> Once all users have been converted we can rename max_brightness to
> something like num_levels and remove lth_brightness. dft_brightness can
> probably be renamed to default_level.

In non-DT case lth_brightness is required. 
But for DT we have options with/without lth_brightness support. 
In case if patch is dropped, user has to put proper brightness-levels 
(brightness-levels DT parameters should be specified considering the 
low-threshold values)

Meanwhile I had submitted another version yesterday (with more documentation)

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

https://lkml.org/lkml/2012/9/26/271

Thierry,

Can you please confirm the acceptance/rejection of the patch? This will help me
to submit the backlight DT blob for AM335x platform.

Thanks
Avinash

> 
> Thierry
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/