Re: PM(?) problems on v3.3-rc1 on OMAP3

[NeilBrown <neilb@suse.de>]

[-- Attachment #1: Type: text/plain, Size: 2160 bytes --]

On Sat, 21 Jan 2012 17:57:07 +0200 Tomi Valkeinen <tomi.valkeinen@ti.com>
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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]