Hi, I'm debugging pm-0 branch with SDP board and seeing lots of dispc related error printouts: / # <4>__ratelimit: 453 callbacks suppressed __ratelimit: 453 callbacks suppressed <3>omapfb omapfb: irq error status 00e2 omapfb omapfb: irq error status 00e2 <3>omapfb omapfb: irq error status 00e2 omapfb omapfb: irq error status 00e2 <3>omapfb omapfb: irq error status 00c0 omapfb omapfb: irq error status 00c0 <3>omapfb omapfb: irq error status 0062 omapfb omapfb: irq error status 0062 <3>omapfb omapfb: irq error status 00c2 omapfb omapfb: irq error status 00c2 The error bit in all these statuses is "GFXFIFOUNDERFLOW". Is this something that could happen e.g. in a case that mpu wake-up from wfi takes too long? I mean is there some interrupt that should be served faster? Or is this taken care by sdma/hw triggering and now sdma is not capable to fill the fifo for reason or another? I have cpuidle enabled and it is "forced" to select only C1 or C0. This means tha MPU, NEON, CORE and PER are always ON/INACTIVE. Display is also on and there is penguin logo on it. When I see these error messages there is also flickering on the display. This far I had found that on mpu wfi something is switched off sometimes. I can see that from consumption of SDP board. Sometimes consumption is much lower on wfi even if the states of domains are same. When this happens, also these omapfb irq errors begin to happen. I can workaround this problem by disabling DSS_ICK AUTOIDLE. Another workaround is to disable hw supervised mode for core_l3_clkdm or core_l4_clkdm. All comments and ideas are welcome. -- Jouni Högander -- 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
