Re: Suspend to RAM broken on BeagleBoard ?
Thomas Petazzoni thomas.petazz...@free-electrons.com writes: On Fri, 10 Sep 2010 14:54:23 -0700 Kevin Hilman khil...@deeprootsystems.com wrote: It's the CPUfreq driver that's failing to suspend. Ok. Yes, CPUfreq is not supported in l-o master or pm-core (only in the full pm branch.) If you Kconfig out CPUfreq, this failure will go away. Aah, yes, I forgot about this. I know it's temporary, but wouldn't it be good to disable CPUfreq in omap3_defconfig in this case ? Yes. BTW, I'm now seeing: [ 37.830596] Powerdomain (core_pwrdm) didn't enter target state 1 [ 37.830627] Powerdomain (dss_pwrdm) didn't enter target state 1 when the system is woken up. Looks like DSS has not been initialized, so is not hitting RET. Do you have the DSS driver enabled and built-in? Without this (and until we have DSS converted to hwmod) the DSS HW is not in a state that can hit the low power mode. If the DSS driver is allowed to initialize, even without a panel, it should set the DSS HW in a state that will then allow RET. Kevin -- 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
Re: Suspend to RAM broken on BeagleBoard ?
I have zero knowledge of DSS, but shouldn't the kernel be able to suspend properly even if the DSS driver is disabled ? But maybe it's too complicated to have the DSS init sequence required to allow the system to hit RET outside the DSS driver. Thoughts ? I'm not sure if it's supposed to work from reset state but there are chances DSS is left running by your bootloader. -- 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
Re: Suspend to RAM broken on BeagleBoard ?
Thomas Petazzoni thomas.petazz...@free-electrons.com writes: Hello, On Mon, 13 Sep 2010 07:56:54 -0700 Kevin Hilman khil...@deeprootsystems.com wrote: Looks like DSS has not been initialized, so is not hitting RET. Do you have the DSS driver enabled and built-in? Without this (and until we have DSS converted to hwmod) the DSS HW is not in a state that can hit the low power mode. If the DSS driver is allowed to initialize, even without a panel, it should set the DSS HW in a state that will then allow RET. Indeed: $ grep DSS .config # CONFIG_OMAP2_DSS is not set It's not enabled simply because it isn't enabled by omap3_defconfig. So maybe it should also be fixed for this ? I have zero knowledge of DSS, but shouldn't the kernel be able to suspend properly even if the DSS driver is disabled ? Yes, it should, and it's almost there. But maybe it's too complicated to have the DSS init sequence required to allow the system to hit RET outside the DSS driver. Thoughts ? One of the multiple motivations for moving to the omap_hwmod model of describing all the HW IP blocks in a central location is so that we have a common init and reset for every on-chip device. Once an omap_hwmod exists for a device, during init, the hwmod core will ensure that that block is properly initialized, reset and in a state that will not prevent the chip from entering low-power sleep. This will happen in the hwmod core, and is independent of the existence of a driver for that device, so will solve problems like this one. Currently, we have a hack here and a hack there for common devices that the bootloader blindy leaves in an state that prevents low-power states, but this is clearly a hack and does not scale. omap_hwmod is the solution to scaling this to every IP block. Kevin -- 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
Re: Suspend to RAM broken on BeagleBoard ?
On Fri, 10 Sep 2010 14:54:23 -0700 Kevin Hilman khil...@deeprootsystems.com wrote: It's the CPUfreq driver that's failing to suspend. Ok. Yes, CPUfreq is not supported in l-o master or pm-core (only in the full pm branch.) If you Kconfig out CPUfreq, this failure will go away. Aah, yes, I forgot about this. I know it's temporary, but wouldn't it be good to disable CPUfreq in omap3_defconfig in this case ? BTW, I'm now seeing: [ 37.830596] Powerdomain (core_pwrdm) didn't enter target state 1 [ 37.830627] Powerdomain (dss_pwrdm) didn't enter target state 1 when the system is woken up. Concerning the USB issue, no idea ? Thanks, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- 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
Suspend to RAM broken on BeagleBoard ?
Hello, I've tested the current linux-omap Git tree and Kevin's pm-core branch on a BeagleBoard using the omap3_defconfig, and when trying a suspend to RAM, I get a Class driver suspend failed for cpu0 : # echo mem /sys/power/state [ 93.395050] PM: Syncing filesystems ... done. [ 93.410827] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 93.434570] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [ 93.458557] Suspending console(s) (use no_console_suspend to debug) [ 93.590728] PM: suspend of devices complete after 119.629 msecs [ 93.593902] PM: late suspend of devices complete after 3.112 msecs [ 93.594421] Class driver suspend failed for cpu0 [ 93.595153] PM: early resume of devices complete after 0.518 msecs [ 93.887603] PM: resume of devices complete after 292.052 msecs [ 93.922851] Restarting tasks ... done. Is this a known issue ? I also have a problem with USB support, both on linux-omap and Kevin's pm-core branch. My USB Ethernet adapter, supported by the asix driver, isn't detected anymore. With a pm git tree of a couple of weeks ago, it was working. This is again with just a plain omap3_defconfig. Thanks! Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- 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
Re: Suspend to RAM broken on BeagleBoard ?
Hi, On Fri, Sep 10, 2010 at 10:48:14AM -0500, Thomas Petazzoni wrote: I also have a problem with USB support, both on linux-omap and Kevin's pm-core branch. My USB Ethernet adapter, supported by the asix driver, isn't detected anymore. With a pm git tree of a couple of weeks ago, it was working. This is again with just a plain omap3_defconfig. is it attached to EHCI/OHCI or musb port ? -- balbi -- 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
Re: Suspend to RAM broken on BeagleBoard ?
On Fri, 10 Sep 2010 20:00:53 +0300 Felipe Balbi ba...@ti.com wrote: On Fri, Sep 10, 2010 at 10:48:14AM -0500, Thomas Petazzoni wrote: I also have a problem with USB support, both on linux-omap and Kevin's pm-core branch. My USB Ethernet adapter, supported by the asix driver, isn't detected anymore. With a pm git tree of a couple of weeks ago, it was working. This is again with just a plain omap3_defconfig. is it attached to EHCI/OHCI or musb port ? It's a normal USB Ethernet adapter that is attached to the EHCI/OCHI port of the BeagleBoard. I have a revision C3. With older Git versions from the PM tree, it used to work, even if it wasn't 100% stable. But at least it was detected, and I was able to nfs mount the root filesystem. I don't know if I can easily bisect this, as I think the PM branches are constantly rebased. Thanks, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- 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
Re: Suspend to RAM broken on BeagleBoard ?
Thomas Petazzoni thomas.petazz...@free-electrons.com writes: Hello, I've tested the current linux-omap Git tree and Kevin's pm-core branch on a BeagleBoard using the omap3_defconfig, and when trying a suspend to RAM, I get a Class driver suspend failed for cpu0 : # echo mem /sys/power/state [ 93.395050] PM: Syncing filesystems ... done. [ 93.410827] Freezing user space processes ... (elapsed 0.01 seconds) done. [ 93.434570] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done. [ 93.458557] Suspending console(s) (use no_console_suspend to debug) [ 93.590728] PM: suspend of devices complete after 119.629 msecs [ 93.593902] PM: late suspend of devices complete after 3.112 msecs [ 93.594421] Class driver suspend failed for cpu0 It's the CPUfreq driver that's failing to suspend. [ 93.595153] PM: early resume of devices complete after 0.518 msecs [ 93.887603] PM: resume of devices complete after 292.052 msecs [ 93.922851] Restarting tasks ... done. Is this a known issue ? Yes, CPUfreq is not supported in l-o master or pm-core (only in the full pm branch.) If you Kconfig out CPUfreq, this failure will go away. [...] Kevin -- 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
