Thanks, Vaibhav Hiremath Senior Software Engg. Platform Support Products Texas Instruments Inc Ph: +91-80-25099927 > -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap-owner@xxxxxxxxxxxxxxx] On Behalf Of > Högander Jouni > Sent: Tuesday, September 23, 2008 1:36 PM > To: ext arun c > Cc: linux-omap@xxxxxxxxxxxxxxx > Subject: Re: PM related problem with dispc controller > > "ext arun c" <arun.edarath@xxxxxxxxx> writes: > > > On Tue, Sep 23, 2008 at 2:49 AM, Högander Jouni > > <jouni.hogander@xxxxxxxxx> wrote: > >> 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. > > > > Try disabling the smart standby feature of DISPC > > Yes, this actually helps. I see this also as a workaround. Is the case > here that L3 domain is entering some sleep state and waking it up > takes too long for dispc? > I have seen that without ENWAKEUP flag set (1 << 2), DISPC runs into sync lost issue. > -- > 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 -- 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
