linux-kernel - Re: [PATCH v4] pwm-backlight: Avoid backlight flicker when probed from DT

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]

Message-ID: <20151110173257.GA21727@ulmo>
Date:	Tue, 10 Nov 2015 18:32:57 +0100
From:	Thierry Reding <thierry.reding@...il.com>
To:	Heiko Stuebner <heiko@...ech.de>
Cc:	linux-arm-kernel@...ts.infradead.org,
	Philipp Zabel <p.zabel@...gutronix.de>,
	linux-pwm@...r.kernel.org, YH Huang <yh.huang@...iatek.com>,
	Jingoo Han <jingoohan1@...il.com>, linux-fbdev@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Christian Gmeiner <christian.gmeiner@...il.com>,
	kernel@...gutronix.de, Lee Jones <lee.jones@...aro.org>,
	Ajay Kumar <ajaykumar.rs@...sung.com>
Subject: Re: [PATCH v4] pwm-backlight: Avoid backlight flicker when probed
 from DT

On Tue, Nov 10, 2015 at 03:18:10PM +0100, Heiko Stuebner wrote:
> Hi Philipp,
> 
> Am Montag, 2. November 2015, 17:55:56 schrieb Philipp Zabel:
> > If the driver is probed from the device tree, and there is a phandle
> > property set on it, and the enable GPIO is already configured as output,
> > and the backlight is currently disabled, keep it disabled.
> > If all these conditions are met, assume there will be some other driver
> > that can enable the backlight at the appropriate time.
> > 
> > Signed-off-by: Philipp Zabel <p.zabel@...gutronix.de>
> > Reviewed-by: Christian Gmeiner <christian.gmeiner@...il.com>
> 
> this patch improves the white screen when booting a veyron chromebook
> a lot. I still see a small white flash, but that can probably come from
> the WIP edp driver.

Some panels require a couple of frames before they actually enable. You
may want to look at the datasheet of your panel to see if it has some
specific requirement and update the panel driver with that.

From a high-level view the way that this is supposed to work is that
your encoder driver (e.g. eDP) "prepares" the panel, then starts sending
frames and finally "enables" the panel. With something like the simple
panel driver you can influence this by setting the delay.enable field in
the panel descriptor.

See struct panel_desc in drivers/gpu/drm/panel/panel-simple.c

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)