Re: [PATCH] OMAP1: PM: Fix omapfb/lcd on Amstrad Delta broken when PM set
STALE6157d
From: Tony Lindgren <tony@atomide.com>
Date: 2009-10-30 17:33:18
Also in:
linux-arm-kernel, linux-omap
* Janusz Krzysztofik [off-list ref] [091030 07:43]:
Thursday 29 October 2009 23:39:44 Janusz Krzysztofik napisał(a):quoted
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.
Hmm to me it looks like the OMAP_DMA_CCR_EN should be set in one of the channels if enabled. Maybe you need add a similar check somewhere in the *_lcd_dma_* functions too in dma.c? Regards, Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html