Monday 24 May 2010 09:26:03 Tomi Valkeinen napisał(a):

Hi,

On Sun, 2010-05-23 at 14:09 +0200, ext Janusz Krzysztofik wrote:

quoted

Monday 17 May 2010 03:20:13 Janusz Krzysztofik wrote:

quoted

I was observing the following error messages on my OMAP1 based Amstrad
Delta board when first changing from text to graphics mode or vice
versa after the LCD display had been blanked:
	omapfb omapfb: timeout waiting for FRAME DONE
with a followup error message while unblanking it back:
	omapfb omapfb: resetting (status 0xffffffb2,reset count 1)
As a visible result, image pixels happened to be shifted by a few bits,
giving wrong colors.

Examining the code, I found that this problem occures when an OMAP1
internal LCD controller is disabled from omap_lcdc_suspend() and then a
subsequent omap_lcdc_setup_plane() calls disable_controller() again.
This potentially error provoking behaviour is triggered by the
lcdc.update_mode flag being kept at OMAP_AUTO_UPDATE, regardless of the
controller and panel being suspended.

This patch tries to correct the problem by replacing both
omap_lcdc_suspend() and omap_lcdc_resume() function bodies with single
calls to
omap_lcdc_set_update_mode() with a respective OMAP_UPDATE_DISABLE or
OMAP_AUTO_UPDATE argument. As a result, exactly the same lower level
operations are performed, with addition of changing the
lcdc.update_mode flag to a value better suited for the controller
state. This prevents any further calls to disable_controller() from
omap_lcdc_setup_plane() while the display is suspended.

Hi,

One more week of successfull, trouble-free testing on my side. Although
there were no other test reports, no objections nor change requests were
raised as well on this relatively simple and straightforward patch. Could
we then agree on it being accepted for inclusion? Tomi?

Yep, looks ok to me. Applied to DSS tree.

Tomi,
Thanks, you were so fast that I missed asking you if it could still be pushed 
as a fix in the upcoming 2.6.35-rc cycle.

Thanks,
Janusz