On Fri, 2012-04-20 at 17:50 +0530, T Krishnamoorthy, Balaji wrote: > On Fri, Apr 20, 2012 at 3:03 PM, Tero Kristo <t-kristo@xxxxxx> wrote: > > Hi, > > > > First version for this work. Applies on top of mainline + iochain set + > > OMAP4 core retention set. Working tree available here: > > tree: git://gitorious.org/~kristo/omap-pm/omap-pm-work.git > > branch: mainline-3.4-omap4-dev-off > > > > Tested on omap4430 EMU blaze + omap4460 GP panda boards. > > > > Some drivers have issues with device off, most notably MMC, as it breaks > > device off on blaze device after 1 entry to device off mode: > > > > [ 208.906921] omap_i2c omap_i2c.1: XRDY IRQ while no data to send > > [ 209.905639] omap_i2c omap_i2c.1: controller timed out > > [ 209.905792] twl: i2c_read failed to transfer all messages > > [ 209.905792] omap_hsmmc omap_hsmmc.1: could not set regulator OCR (-110) > > [ 212.296203] mmc0: error -110 during resume (card was removed?) > Hi Tero, > > I tried your branch on gp/emu devices but could not reproduce this issue. > My observation is that while resuming, omap_hsmmc.1 eMMC is > trying to turn on phoenix vaux1 regulator via i2c which fails due > to controller timeout. > Note: eMMC is present only on sdp/blaze Did you try this with off-mode enabled and did you check the device actually goes to off? (see pm_debug/count and verify core off count is increasing.) And as said, I was only able to see this problem on a blaze device, panda works fine. But yes, you are probably right and it is not an MMC driver issue but I2C. > > > [ 212.562164] PM: resume of devices complete after 3656.007 msecs > > [ 212.660125] Restarting tasks ... done. > > # > > # echo mem > /sys/power/state > > [ 220.376892] PM: Syncing filesystems ... done. > > [ 220.382476] Freezing user space processes ... (elapsed 0.01 seconds) done. > > [ 220.408386] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) don > > e. > > [ 220.439605] Suspending console(s) (use no_console_suspend to debug) > > [ 220.454650] dpm_run_callback(): platform_pm_suspend+0x0/0x54 returns -110 > > [ 220.454711] PM: Device omap_hsmmc.1 failed to suspend: error -110 > > [ 220.454711] PM: Some devices failed to suspend > > [ 220.718261] PM: resume of devices complete after 263.539 msecs > > [ 220.743988] Restarting tasks ... done. > > > > Attempting to disable MMC from config prevented boot completely for me, > > so this issue is likely to stay until someone fixes the MMC driver. > > Panda device works fine though, although the wakeup from device off is > > slow due to problems with some other drivers (most likely I2C.) > > > > can you try this patch if you want to disable MMC > http://permalink.gmane.org/gmane.linux.ports.arm.omap/74540 Tried this patch and disabled MMC completely. Device off now works with blaze board also multiple times. -Tero > or > http://www.spinics.net/lists/linux-omap/msg67879.html > and build omap_hsmmc as module. > > > Off mode is disabled by default, it can be enabled by either calling > > omap4_pm_enable_off_mode(1) from board files or alternatively writing > > to a debugfs node from userspace: > > > > echo 1 > /debug/pm_debug/enable_off_mode > > > > Device off entry can be tracked through the debugfs also, it increases > > the core_pwrdm OFF state counter / timer, as this is an invalid state > > for the chip normally (core enters OSWR in device off.) Not sure if this > > a good way to do this but comments are welcome. > > > > -Tero > > > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > > the body of a message to majordomo@xxxxxxxxxxxxxxx > > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html