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: <1269004294.4292.18.camel@rex>
Date:	Fri, 19 Mar 2010 13:11:34 +0000
From:	Richard Purdie <rpurdie@...ys.net>
To:	InKi Dae <daeinki@...il.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Pavel Machek <pavel@....cz>,
	Kyungmin Park <kmpark@...radead.org>,
	linux-fbdev-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] fixed sparkling issue on lcd panel when fb_blank mode
 is  changed.

Hi,

On Fri, 2010-03-19 at 13:36 +0900, InKi Dae wrote:
> This issue is a problem that lcd panel is spakled when fb_blank mode is changed
> From FB_BLANK_UNBLANK to FB_BLANK_POWER or FB_BLANK_POWER to FB_BLANK_UNBLANK.
> 
> In case of FB_BLANK_UNBLANK, screen = on, vsync = on, hsync = on and
> For FB_BLANK_POWERDOWN screen = blanked, vsync = off, hsync = off
> So like this when fb_blank mode becomes FB_BLANK_POWERDOWN,
> Display controller and lcd panel should become off to reduce power consumption.
> 
> Let's see fb_blank function of fbmem.c file.
> 
> fb_blank()
> {
>     if (info->fbops->fb_blank)
>             ret = info->fbops->fb_blank(blank, info(
>     if (!ret)
>             fb_notifier_call_chain(FB_EVENT_BLANK, &event);
> }
> 
> This problem is because this code calls fb_blank (fb_blank of device
> specific framebuffer driver)
> Earlier then fb_notifier_call_chain.
> 
> For example,
> Device specific fb_blank function is registered to generic framebuffer
> driver through register_framebuffer function
> And fb_notifier_call_chain calls any callback function registered to
> lcd class(lcd.c) through fb_notifier_callback function.
> So if fb_blank mode is changed to FB_BLANK_POWERDOWN then display
> controller would become off(clock disable)
> On the other hand, lcd panel would still be on. at this time, some
> situation on lcd panel occers like sparkling
> Because video clock to be delivered to ldi module of lcd panel is disabled also.
> 
> This patch get fb_notifier_call_chain to be called earlier then fb_blank.
> Please, review this patch.

So to summarise the problem more succinctly the LCD and the display
controllers power off in the wrong order causing visual defects
(sparkling) on the display.

I was a bit worried about event order and loops with this change so I
checked and there are three consumers of these events in the kernel:
consoles, LCD and backlight. None of them have a problem with this
change of order for power down so from that point of view I'm ok with
the change.

However this function also covers powerup from a screen blank to an
active screen. When powering up it makes sense to power up the video
device first, then the LCD, backlight and console as per the current
code, otherwise I can imagine "sparkling" upon powerup.

So it looks like we need to change order only on powerdown, not upon
resume, otherwise we'll get further regression reports on poweron?

Cheers,

Richard




--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ