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. I don't see the problem with v3.3, but as there has been a lot of DSS changes also, it could as well be a DSS change that has triggered the problem. It also looks that the sync lost happens when the system idles a bit. I compared count and time files in debugfs/pm_debug/ for both working (i.e. usb compiled in) and non-working cases, but they seem similar for the relevant parts. core_pwrdm is always ON, mpu_pwrdm has both RET and ON states, dss_pwrdm both RET and ON states (identical counts). Do you have anything in mind related to PM that has changed for v3.4 which could affect DSS? Any idea what effect USB gadget has? My understanding is that it keeps usbhost_pwrdm forcibly alive, maybe also something else, but I'm not sure why it would affect DSS. I also tested with my DSS OPP100 patches, which try to force OPP100 when DSS is enabled by adding a PM constraint for bus tput of 1000000000, but it doesn't seem to have any effect. And, I guess, the constraint affects only core_pwrdm, and as seen it's anyway always on in both cases. Any debugging ideas are welcome. Tomi
Attachment:
signature.asc
Description: This is a digitally signed message part
