RE: Suspend to RAM broken on BeagleBoard ?

RE: Suspend to RAM broken on BeagleBoard ?

[msinger]

-------- Original Message --------
Subject: Suspend to RAM broken on BeagleBoard ?
From: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Date: Fri, September 10, 2010 11:48 am
To: "linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>

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



Same on an Overo.  And ondemand cpufreq doesnt work either anymore.

Re: Suspend to RAM broken on BeagleBoard ?

[Kevin Hilman]

Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

> Hello,
>
> On Mon, 13 Sep 2010 07:56:54 -0700
> Kevin Hilman <khilman@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

Re: Suspend to RAM broken on BeagleBoard ?

[Grazvydas Ignotas]

> 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.

Re: Suspend to RAM broken on BeagleBoard ?

[Thomas Petazzoni]

Hello,

On Mon, 13 Sep 2010 07:56:54 -0700
Kevin Hilman <khilman@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 ? 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 ?

Regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

Re: Suspend to RAM broken on BeagleBoard ?

[Kevin Hilman]

Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

> On Fri, 10 Sep 2010 14:54:23 -0700
> Kevin Hilman <khilman@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

Re: Suspend to RAM broken on BeagleBoard ?

[Felipe Balbi]

Hi,

On Fri, Sep 10, 2010 at 01:47:13PM -0500, Thomas Petazzoni 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.

Would you have any debugging dumps to share ? What shows up on dmesg
after you attach the device ? (please clear the message ring buffer
before attaching the device with dmesg -c).

-- 
balbi

Re: Suspend to RAM broken on BeagleBoard ?

[Thomas Petazzoni]

On Fri, 10 Sep 2010 14:54:23 -0700
Kevin Hilman <khilman@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

Re: Suspend to RAM broken on BeagleBoard ?

[Kevin Hilman]

Thomas Petazzoni <thomas.petazzoni@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

Re: Suspend to RAM broken on BeagleBoard ?

[Thomas Petazzoni]

On Fri, 10 Sep 2010 20:00:53 +0300
Felipe Balbi <balbi@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

Re: Suspend to RAM broken on BeagleBoard ?

[Felipe Balbi]

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

Suspend to RAM broken on BeagleBoard ?

[Thomas Petazzoni]

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