Date:	Mon, 22 Mar 2010 13:48:10 +0900
From:	InKi Dae <daeinki@...il.com>
To:	Richard Purdie <rpurdie@...ys.net>
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.

I has modified my patch.

this patch would change order only in case of FB_BLANK_POWERDOWN
with Richard's opinion.

if requested blank mode is less then FB_BLANK_POWERDOWN then
it would call device specific fb_blank and then fb_notifer_call_chan
otherwise fb_notifier_call_chain first, this case means power up
and display controller should become on earlier then other devices
like lcd panel.

Please review this path again.

signed-off-by : InKi Dae <inki.dae@...sung.com>

Best Regards,
InKi Dae.

2010/3/22 InKi Dae <daeinki@...il.com>:
> yes, you are right.
>
> when fb_blank mode is changed to FB_BLANK_NORMAL or
> FB_BLANK_UNBLANK(power down -> power up)
> it has a possibility that we would encounter same issue.
>
> I'd try to modify my patch to be considered with your opinion and will
> send it again.
> Thank you for your answer.
>
> Best Regards,
> InKi Dae.
>
> 2010/3/19 Richard Purdie <rpurdie@...ys.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
>>
>>
>>
>>
>>
>

Download attachment "fbmem.patch" of type "application/octet-stream" (1378 bytes)

Powered by blists - more mailing lists