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:
signature.asc
Description: This is a digitally signed message part