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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
