[PATCH] OMAP1: PM: Fix omapfb/lcd on Amstrad Delta broken when PM set

Thursday 29 October 2009 23:39:44 Janusz Krzysztofik napisa?(a):

With CONFIG_PM=y, the omapfb/lcd device on Amstrad Delta, after initially
starting correctly, breaks with the following error messages:

omapfb omapfb: resetting (status 0xffffff96,reset count 1)
...
omapfb omapfb: resetting (status 0xffffff96,reset count 100)
omapfb omapfb: too many reset attempts, giving up.

Looking closer at this I have found that it had been broken almost 2 years
ago with commit 2418996e3b100114edb2ae110d5d4acb928909d2, PM fixes for
OMAP1.

The definite reason for broken omapfb/lcd_ams_delta in PM mode appeared to
be ARM_IDLECT1:IDLIF_ARM (bit 6) put into idle. The patch below fixes it.

Since PM area is quite new to me, I am not sure if there may be a better
solution. AFAICS, the standard way to prevent an ARM_CLKCT1 bit being
switched to idle is to enable a clock that uses it (tipb_ck, dma_ck, or
tc_ck or one of its children in this case, right?).

I assume there is no bug in omapfb nor lcdc, as that would be already
detected. Maybe it would be better to fix
drivers/video/omap/lcd_ams_delta.c (or
arch/arm/mach-omap1/board-ams-delta), but I don't know what clock should I
enable, if any.

More looking at it, I found that might be omap_dma_running() from 
arch/arm/plat-omap/dma.c that needs correction. It already checks for LCD dma 
running for OMAP1610, but does nothing similiar for 1510. I have revisited 
http://focus.ti.com/lit/ug/spru674/spru674.pdf, but found no hint how to do 
that in a 1610 similiar way.

Thanks,
Janusz