-----Original Message----- From: Archit <a0393...@ti.com> To: Joe Woodward <j...@terrafix.co.uk> Cc: Paul Walmsley <p...@pwsan.com>, NeilBrown <ne...@suse.de>, <khil...@ti.com>, <linux-omap@vger.kernel.org>, Tomi Valkeinen <tomi.valkei...@ti.com> Date: Wed, 11 Jan 2012 21:22:00 +0530 Subject: Re: DSS2/PM on 3.2 broken?
> Hi, > > On Wednesday 11 January 2012 08:45 PM, Joe Woodward wrote: > > ...snip... > > > >> > >> Could you enable omapdss debug by adding 'omapdss.debug=1 debug' in > >> your bootargs and share logs? > > > > As requested: > > > > # echo mem> /sys/power/state > > [ 37.371734] PM: Syncing filesystems ... done. > > [ 37.397460] PM: Preparing system for mem sleep > > [ 37.402923] Freezing user space processes ... (elapsed 0.02 > seconds) done. > > [ 37.432312] Freezing remaining freezable tasks ... (elapsed 0.02 > seconds) done. > > [ 37.463256] PM: Entering mem sleep > > [ 37.467132] Suspending console(s) (use no_console_suspend to > debug) > > > > #### SYSTEM SUSPENDS HERE > > > > [ 37.587646] omapdss CORE: suspend 2 > > [ 37.776000] omapdss DISPC: dispc_runtime_put > > [ 37.776336] omapdss DSS: dss_runtime_put > > [ 37.779693] PM: suspend of devices complete after 305.389 msecs > > [ 37.786010] omapdss DISPC: dispc_save_context > > [ 37.786437] omapdss DISPC: context saved, ctx_loss_count 0 > > [ 37.786560] omapdss DSS: dss_runtime_put > > [ 37.786773] omapdss DSS: dss_save_context > > [ 37.786895] omapdss DSS: context saved > > [ 37.787384] PM: late suspend of devices complete after 7.446 msecs > > [ 40.932312] Successfully put all powerdomains to target state > > [ 40.934509] omapdss DSS: dss_restore_context > > [ 40.934661] omapdss DSS: context restored > > [ 40.934814] omapdss DSS: dss_runtime_get > > [ 40.934967] @@@ dss_runtime_get::pm_runtime_get_sync() return val > = -13 > > This resume/restore looks to be happening a bit early according to me. > All the resuming should happen after the print 'omapdss CORE: resume'. > > One experiment worth trying would be to reboot/halt the kernel which > will lead to only shutdown of DSS, and no resume. This will help us > figure out if the issue is in the suspend or resume path. > > Archit I'm not 100% sure what you mean for me to do here? Do you mean to halt the kernel after suspending, but before resuming? If so, how would I go about doing this? If I just reboot or poweroff I get the following... # poweroff The system is going down NOW! Sent SIGTERM to all processes Sent SIGKILL to all processes Requesting system poweroff [ 43.310607] omapdss CORE: shutdown [ 43.499053] omapdss DISPC: dispc_runtime_put [ 43.504272] omapdss DISPC: dispc_save_context [ 43.509399] omapdss DISPC: context saved, ctx_loss_count 0 [ 43.515747] omapdss DSS: dss_runtime_put [ 43.521453] omapdss DSS: dss_runtime_put [ 43.527221] System halted. # reboot The system is going down NOW! Sent SIGTERM to all processes Sent SIGKILL to all processes Requesting system reboot [ 25.652008] omapdss CORE: shutdown [ 25.836120] omapdss DISPC: dispc_runtime_put [ 25.841125] omapdss DISPC: dispc_save_context [ 25.846221] omapdss DSS: dss_runtime_put [ 25.851776] omapdss DISPC: context saved, ctx_loss_count 0 [ 25.857788] omapdss DSS: dss_runtime_put [ 25.864074] Restarting system. Cheers, Joe -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
