Re: v3.4-rc4 DSS PM problem (Was: Re: Problems with 3.4-rc5)

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

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

On Fri, 2012-05-04 at 17:58 +0300, Tomi Valkeinen wrote:
> On Fri, 2012-05-04 at 17:54 +0300, Tomi Valkeinen wrote:
> > Hi Kevin, Paul,
> > 
> > On Fri, 2012-05-04 at 15:09 +0100, Joe Woodward wrote:
> > 
> > > > > Ok, I can replicate it now. It seems to be somehow PM related. I
> > > > > normally have USB gadget stuff compiled into kernel so that I can
> > > > boot
> > > > > via nfsroot with usb. After disabling USB support from the kernel, I
> > > > can
> > > > > see synclosts.
> > > > > 
> > > > > I have no idea yet what could be causing this. I've also tried adding
> > > > > the couple of DSS patches which are in queue for next merge window,
> > > > that
> > > > > force OPP100 when DSS is enabled. They don't seem to help.
> > > > 
> > > > Also, at least on my setup, the sync lost doesn't happen very quickly
> > > > after starting the video output, but (I think) only when the system
> > > > starts to idle. My init scripts generate keys for sshd and some other
> > > > stuff, and no sync lost there, only just before the shell prompt do I
> > > > get a sync lost.
> > > > 
> > > >  Tomi
> > > > 
> > > 
> > > That sounds like the same as I'm seeing. It seems that the sync lost jumps 
> > > around a bit, from almost immediately (when the graphics are enabled), to 
> > > up to 3 or 4 seconds later (still just before the shell prompt).
> > > 
> > > I'm assuming that setting the FIFO low and high points fixes your sync losts 
> > > as well (as in the first patch you sent)?
> > > 
> > > I've also noted that doing things in different orders can sometimes fix the 
> > > sync lost (such as disabling or enabling DVI output), but this all seems a bit 
> > > random.
> > > 
> > > I'm just glad someone else has been able to replicate the problem :p
> > 
> > Kevin, Paul, there seems to be a problem with DSS on v3.4-rc4 running on
> > omap3, causing DSS losing sync. I didn't notice this earlier as I have
> > USB gadget compiled into my kernel. Removing USB support from the kernel
> > causes the problem to appear, which more or less hints at a PM related
> > issue.
> 
> Sorry, not sync lost, but FIFO underflow. So DSS is unable to fetch
> enough pixels to update the panel. And in this case the pixel clock is
> very low (small panel), so it's nowhere near any limit.

And two more interesting points about the problem:

Setting DISPC's SIDLEMODE to no-idle seems to remove the issue.

With some DISPC's fifo high/low threshold values things seem to work,
while with others we get underflows. And as the required bandwidth here
is quite small, and the threshold values I tested are close to each
other, I don't think it's really a proper bandwidth issue.

I'm guessing that certain threshold values cause somehow un-optimal
accesses to the memory, and with smart-idle this somehow causes
problems.

Archit, you looked into the thresholds some time ago. I recall that some
threshold values were "bad" in some way? Were those only for OMAP4?

 Tomi


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]