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

[Janusz Krzysztofik]

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