On Fri, Jan 20, 2012 at 4:03 PM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > Hi, > > I'm testing v3.3-rc1 on OMAP3 overo, and I'm having problems probably > related to PM. > > First, when I boot up, the console (via USB serial) is very laggy, it > often takes many seconds until the key pressed appears so it's more or > less unusable. > > Second, I compile DSS as modules, and don't load them. Looking at > debugfs/pm_debug/time, I can see that both RET and ON for dss_pwrdm are > increasing. What is making DSS powerdomain switch back and forth? > > Third, when I load the DSS modules, I see only ON state increasing for > dss_pwrdm, as it should be. However, I'm getting constant stream of sync > losts from DSS, and the display doesn't basically work at all. > > I can see MPU pwrdm going into RET a lot, and if I do "while true; do > echo foo; done", which I presume basically prevents RET for MPU, the > display becomes stable. > > This sounds a bit like the problem reported by Joe (DSS2/PM on 3.2 > broken?), although this is happening all the time. In this case, as in > Joe's, the DSS fck is well below 96MHz, which is the limit on OMAP3 for > DSS fclk on OPP2. And I'm not aware of any other constraints for DSS > (well, memory throughput, but that should cause fifo underflows). > > Is there a way to lock the OPP to the full power OPP? > btw, I think enabling cpu_idle and performance governor to should ensure that. However enabling performance governor boot fails. failure logs as in here [1]. I was using latest mainline and beagle -XM -- Thanks, Govindraj.R [1]: http://pastebin.com/9ZfB2V6B -- 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
