On Sat, 21 Jan 2012 17:57:07 +0200 Tomi Valkeinen <tomi.valkeinen@xxxxxx> wrote: > On Sat, 2012-01-21 at 00:47 -0700, Paul Walmsley wrote: > > On Fri, 20 Jan 2012, Tomi Valkeinen wrote: > > > > > 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. > > > > If this particular problem persists after you apply the patch set that I > > sent earlier, it suggests that something in the DSS is sensitive to the > > amount of time it takes the MPU to wake up and service an interrupt when > > the MPU powerdomain is in a low-power state. Total guess, but perhaps > > omap_dispc_irq_handler() is getting called after each frame and needs to > > run within a certain bounded time when that happens? > > No. After the DSS has been configured and started (by the MPU), it runs > by itself, reading the pixels from the memory displaying them on the > screen. Only when the user wants to change the configs or the frame, the > MPU does something. And interrupts are only needed to handle the > changing of configs or frame data using VSYNCs as the interval. The user > probably doesn't like it if the VSYNC irq is handled a few seconds > later, but the DSS HW doesn't care, and functions normally. > > In this case something is affecting the DSS (clocks? powers?), or the > memory, or the process of reading the pixels. I really don't see the MPU > or IRQs affecting this problem, except indirectly. Which clocks, exactly, are important? I collected some clock.c tracing while dss was repeatedly complaining about losing SYNC, and notice that omap_96m_fck was being enabled and disabled in hardware. omap_96m_fck is upstream for dss_96m_fck which provides the tv_dac_clk. Could it be this clock turning on and off which causes the problem? Thanks, NeilBrown
Attachment:
signature.asc
Description: PGP signature
