Re: [PATCH] fixed sparkling issue on lcd panel when fb_blank mode is changed.

[Richard Purdie <rpurdie@rpsys.net>]

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