From mboxrd@z Thu Jan 1 00:00:00 1970 From: khilman@ti.com (Kevin Hilman) Date: Wed, 22 Feb 2012 14:37:47 -0800 Subject: [PATCHv2 8/8] arm: omap3: prevent per_clkdm from attempting manual domain transitions In-Reply-To: <1329470938.4102.408.camel@sokoban> (Tero Kristo's message of "Fri, 17 Feb 2012 11:28:58 +0200") References: <1329320274-481-1-git-send-email-t-kristo@ti.com> <1329320274-481-9-git-send-email-t-kristo@ti.com> <87pqdf99c2.fsf@ti.com> <1329382652.4102.386.camel@sokoban> <1329398159.4102.391.camel@sokoban> <1329405804.4102.400.camel@sokoban> <1329410895.4102.404.camel@sokoban> <877gzmit2c.fsf@ti.com> <1329470938.4102.408.camel@sokoban> Message-ID: <87pqd6xzno.fsf@ti.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Tero Kristo writes: > On Thu, 2012-02-16 at 09:31 -0800, Kevin Hilman wrote: >> Tero Kristo writes: >> >> > On Thu, 2012-02-16 at 21:15 +0530, Shilimkar, Santosh wrote: >> >> On Thu, Feb 16, 2012 at 8:53 PM, Tero Kristo wrote: >> >> > On Thu, 2012-02-16 at 15:15 +0200, Tero Kristo wrote: >> >> >> On Thu, 2012-02-16 at 15:27 +0530, Shilimkar, Santosh wrote: >> >> >> > On Thu, Feb 16, 2012 at 2:27 PM, Tero Kristo wrote: >> >> >> > > On Wed, 2012-02-15 at 11:37 -0800, Kevin Hilman wrote: >> >> >> > >> Tero Kristo writes: >> >> >> > >> >> >> >> > >> > Attempting this will cause problems especially with off-mode enabled. >> >> >> > >> >> >> >> > >> Please be more verbose about the problems seen, and the root cause(s). >> >> >> > >> >> >> >> > > >> >> >> > > I was actually looking forward for some help with this commit message, >> >> >> > > as I am still not quite sure what is going on in here. :) Here is the >> >> >> > > log for suspend (btw, cam_pwrdm does not go to off in mainline yet, but >> >> >> > > I think that is probably fixed by the patch from Paul, >> >> >> > > omap_set_pwrdm_state() does not work properly.) The warning comes out >> >> >> > > after wakeup from off-mode, and it is triggered by the disabling of >> >> >> > > autodeps before off-mode entry. >> >> >> > > >> >> >> > This mostly indicates that one of the per clock-domain module >> >> >> > clock turning ON seems to be not working well with auto deps >> >> >> > disabled. This leads to interconnect violation. >> >> >> > >> >> >> > if not tried already, can you put the per_clockdomain in SW_WKUP >> >> >> > in the low power code early resume path and see if this >> >> >> > error goes away. >> >> >> >> >> >> This seems to get rid of the dump also. It looks like some driver resume >> >> >> is not behaving nicely, I am trying to pinpoint the culprit currently >> >> >> and see whether it can provide more info. >> >> > >> >> > Okay, I have some more info about this now. >> >> > >> >> > What happens is that when entering off-mode, PER domain remains OFF even >> >> > during the execution of the exit phase from omap_sram_idle. Adding a >> >> > manual SW_WKUP it comes up and there are no issues. If autodeps are >> >> > enabled on the domain, it comes back from off mode as active. >> >> > >> >> > Looking further in the code, we have this at the end of omap_sram_idle: >> >> > >> >> > if (per_next_state < PWRDM_POWER_ON) { >> >> > per_prev_state = pwrdm_read_prev_pwrst(per_pwrdm); >> >> > omap2_gpio_resume_after_idle(); >> >> > wake_per(); >> >> > if (per_prev_state == PWRDM_POWER_OFF) >> >> > omap3_per_restore_context(); >> >> > } >> >> > >> >> > ... which seems to assume that per domain is on. Gpio code does not >> >> > control any clocks currently, as it only requires the interface clock to >> >> > be on, and as this is autoidled.... >> >> > >> >> > Any comments how we should handle this? Shall we just keep these two >> >> > patches for handling this or add some different hackery for the gpio >> >> > issue? >> >> > >> >> Good. I thought too that issue will disappear. >> >> The issue is pretty clear. Technically every driver pm_runtime() code should >> >> be able to manage a clock->clockdomain->power domain power up/down >> >> sequence. That should work without auto deps. >> >> >> >> Do you narrowed down which driver resume is creating the dump ? >> >> UART , GPIO ? >> > >> > It is the gpio base stuff called from omap_sram_idle(), basically the >> > restore context part. If I force enable per domain before the code >> > snippet before, there is no dump, but if it is done after, I get the >> > dump. >> > >> > The thing is that gpio driver doesn't currently have this kind of >> > mechanism for the restore context part, at least not on omap3 due to >> > above clocking issue (only autoidled interface clock is used.) >> >> I'm not sure if it fully addresses this, but Tarun's series converts >> GPIO to runtime PM. >> >> Can you try with Tarun's series. See the for_3.4/gpio_cleanup_fixes_v9 >> branch here: >> git://gitorious.org/~tarunkanti/omap-sw-develoment/tarunkantis-linux-omap-dev.git > > It does something for the issue, but I still get this during suspend to > off: > > [ 11.284973] PM: Syncing filesystems ... done. > [ 11.379241] Freezing user space processes ... (elapsed 0.02 seconds) > done. > [ 11.408233] Freezing remaining freezable tasks ... (elapsed 0.02 > seconds) don > e. > [ 11.439239] Suspending console(s) (use no_console_suspend to debug) > [ 11.564178] PM: suspend of devices complete after 115.506 msecs > [ 11.567382] PM: late suspend of devices complete after 3.204 msecs > [ 11.567443] Disabling non-boot CPUs ... > [ 12.004089] Powerdomain (cam_pwrdm) didn't enter target state 0 > [ 12.004119] Could not enter target state in pm_suspend > [ 12.009368] PM: early resume of devices complete after 4.944 msecs > [ 12.436645] PM: resume of devices complete after 426.086 msecs > [ 12.480285] Restarting tasks ... done. > /sys/kernel/debu[ 12.488433] ------------[ cut here ]------------ > [ 12.494415] WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1604 _idle > +0x164/0x1 > 7c() > [ 12.502258] omap_hwmod: gpio6: idle state can only be entered from > enabled st > ate > [ 12.509979] Modules linked in: > [ 12.513214] [] (unwind_backtrace+0x0/0xf4) from > [] (warn_ > slowpath_common+0x4c/0x64) > [ 12.523071] [] (warn_slowpath_common+0x4c/0x64) from > [] ( > warn_slowpath_fmt+0x30/0x40) > [ 12.533081] [] (warn_slowpath_fmt+0x30/0x40) from > [] (_id > le+0x164/0x17c) > [ 12.541931] [] (_idle+0x164/0x17c) from [] > (omap_hwmod_id > le+0x28/0x3c) > [ 12.550567] [] (omap_hwmod_idle+0x28/0x3c) from > [] (omap_ > device_idle_hwmods+0x24/0x3c) > [ 12.560699] [] (omap_device_idle_hwmods+0x24/0x3c) from > [ > ] (_omap_device_deactivate+0xa4/0x138) > [ 12.571594] [] (_omap_device_deactivate+0xa4/0x138) from > [>] (omap_device_idle+0x28/0x54) > [ 12.581909] [] (omap_device_idle+0x28/0x54) from > [] (_od_ > runtime_suspend+0x1c/0x24) > [ 12.591735] [] (_od_runtime_suspend+0x1c/0x24) from > [] (_ > _rpm_callback+0x2c/0x78) > [ 12.601379] [] (__rpm_callback+0x2c/0x78) from [] > (rpm_su > spend+0x264/0x6c4) > [ 12.610504] [] (rpm_suspend+0x264/0x6c4) from [] > (__pm_ru > ntime_suspend+0x5c/0x74) > [ 12.620178] [] (__pm_runtime_suspend+0x5c/0x74) from > [] ( > omap2_gpio_prepare_for_idle+0x50/0x64) > [ 12.631103] [] (omap2_gpio_prepare_for_idle+0x50/0x64) from > [ d30>] (omap_sram_idle+0xa0/0x3b0) > [ 12.641571] [] (omap_sram_idle+0xa0/0x3b0) from > [] (omap3 > _pm_idle+0x60/0x178) > [ 12.650848] [] (omap3_pm_idle+0x60/0x178) from [] > (cpu_id > le+0xc4/0x108) > [ 12.659606] [] (cpu_idle+0xc4/0x108) from [] > (start_kerne > l+0x2b0/0x304) > [ 12.668365] ---[ end trace 441b8fea2b56dcb1 ]--- > > > Also, this goes away if I manually force wakeup for the per domain, so > this might be caused by some additional latency. > What platform are you testing on? When I test Tarun's series with off-mode on 3430/n900 suspend/resume works fine. But when I add your v2 series, it never comes out of suspend, and I don't get a kernel dump either. Can you debug this a little further so we can explain what's going on here? Thanks, Kevin