BeagleBoard not resuming from uart with latest pm-core ?

BeagleBoard not resuming from uart with latest pm-core ?

[Thomas Petazzoni]

Hello,

I've updated my tree to the last pm-core branch today (I'm at commit
42289e226ec996a13ab8a2aaef5ad9dda61ee57e), and I've built the
omap2plus_defconfig with no change (except adding an initramfs). On my
BeagleBoard, I enable the wakeup from UART
in /sys/devices/platform/omap/omap-hsuart.2/tty/ttyO2/power/wakeup,
then trigger suspend to RAM. It enters suspend to RAM, but then
it doesn't wakeup when I send data through the UART.

Is it a known problem, or is again a mistake on my side ?

Thanks,

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

Re: BeagleBoard not resuming from uart with latest pm-core ?

[Jean Pihet]

Hi Thomas,

l-o is currently broken wrt to suspend and idle.
Solutions are being worked on for the moment.

Kevin, are there solutions available yet?

Regards,
Jean

On Wed, Nov 10, 2010 at 4:44 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> Hello,
>
> I've updated my tree to the last pm-core branch today (I'm at commit
> 42289e226ec996a13ab8a2aaef5ad9dda61ee57e), and I've built the
> omap2plus_defconfig with no change (except adding an initramfs). On my
> BeagleBoard, I enable the wakeup from UART
> in /sys/devices/platform/omap/omap-hsuart.2/tty/ttyO2/power/wakeup,
> then trigger suspend to RAM. It enters suspend to RAM, but then
> it doesn't wakeup when I send data through the UART.
>
> Is it a known problem, or is again a mistake on my side ?
>
> 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 majordomo@vger.kernel.org
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: BeagleBoard not resuming from uart with latest pm-core ?

[Kevin Hilman]

Jean Pihet <jean.pihet@newoldbits.com> writes:

> l-o is currently broken wrt to suspend and idle.
> Solutions are being worked on for the moment.
>
> Kevin, are there solutions available yet?

The solution to your previous problem (ensuring runtime PM transitions
work during system PM) is included in my pm-core branch, but is not yet
the final solution.  I've been disussing this issue with the runtime PM
maintainers for a final solution.  Until then, I will carry this in
pm-core.

The other problem that I'm aware of so far I've only seen on boards with
UART2 console (beagle, Overo, n900.)  The printk messages that warn of
'new worst case [de]activate latency" seem to be racing with UART
disable code.  This makes sense, since this printk is printed to the
UART immediately after the UART is disabled, which is going to cause
problems with the current approach to UART pm we have in
mach-omap2/serial.c.   I have not yet fully debugged this and found a
workaround. 

Of course, any help debugging these problems is appreciated.  I will not
get to debugging this until I catch up on the mailing list backlog.

Kevin


> On Wed, Nov 10, 2010 at 4:44 PM, Thomas Petazzoni
> <thomas.petazzoni@free-electrons.com> wrote:
>> Hello,
>>
>> I've updated my tree to the last pm-core branch today (I'm at commit
>> 42289e226ec996a13ab8a2aaef5ad9dda61ee57e), and I've built the
>> omap2plus_defconfig with no change (except adding an initramfs). On my
>> BeagleBoard, I enable the wakeup from UART
>> in /sys/devices/platform/omap/omap-hsuart.2/tty/ttyO2/power/wakeup,
>> then trigger suspend to RAM. It enters suspend to RAM, but then
>> it doesn't wakeup when I send data through the UART.
>>
>> Is it a known problem, or is again a mistake on my side ?
>>
>> 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 majordomo@vger.kernel.org
>> 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@vger.kernel.org
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: BeagleBoard not resuming from uart with latest pm-core ?

[Peter 'p2' De Schrijver]

On Wed, Nov 10, 2010 at 06:32:53PM +0100, ext Kevin Hilman wrote:
> Jean Pihet <jean.pihet@newoldbits.com> writes:
> 
> > l-o is currently broken wrt to suspend and idle.
> > Solutions are being worked on for the moment.
> >
> > Kevin, are there solutions available yet?
> 
> The solution to your previous problem (ensuring runtime PM transitions
> work during system PM) is included in my pm-core branch, but is not yet
> the final solution.  I've been disussing this issue with the runtime PM
> maintainers for a final solution.  Until then, I will carry this in
> pm-core.
> 
> The other problem that I'm aware of so far I've only seen on boards with
> UART2 console (beagle, Overo, n900.)  The printk messages that warn of

N900 uses UART3 as its console... UART2 is bluetooth iirc.

CHeers,

Peter.

Re: BeagleBoard not resuming from uart with latest pm-core ?

[Kevin Hilman]

"Peter 'p2' De Schrijver" <peter.de-schrijver@nokia.com> writes:

> On Wed, Nov 10, 2010 at 06:32:53PM +0100, ext Kevin Hilman wrote:
>> Jean Pihet <jean.pihet@newoldbits.com> writes:
>> 
>> > l-o is currently broken wrt to suspend and idle.
>> > Solutions are being worked on for the moment.
>> >
>> > Kevin, are there solutions available yet?
>> 
>> The solution to your previous problem (ensuring runtime PM transitions
>> work during system PM) is included in my pm-core branch, but is not yet
>> the final solution.  I've been disussing this issue with the runtime PM
>> maintainers for a final solution.  Until then, I will carry this in
>> pm-core.
>> 
>> The other problem that I'm aware of so far I've only seen on boards with
>> UART2 console (beagle, Overo, n900.)  The printk messages that warn of
>
> N900 uses UART3 as its console... UART2 is bluetooth iirc.

You're right, beagle and Overo are also UART3, so s/UART2/UART3/ in my
above comment.

Kevin

Re: BeagleBoard not resuming from uart with latest pm-core ?

[Thomas Petazzoni]

Hello,

On Wed, 10 Nov 2010 09:32:53 -0800
Kevin Hilman <khilman@deeprootsystems.com> wrote:

> The other problem that I'm aware of so far I've only seen on boards
> with UART2 console (beagle, Overo, n900.)  The printk messages that
> warn of 'new worst case [de]activate latency" seem to be racing with
> UART disable code.  This makes sense, since this printk is printed to
> the UART immediately after the UART is disabled, which is going to
> cause problems with the current approach to UART pm we have in
> mach-omap2/serial.c.   I have not yet fully debugged this and found a
> workaround. 

Even if I comment the "new worst case deactivate latency" message, my
BeagleBoard still doesn't wake-up from suspend. Here's what I do:

# echo enabled > /sys/class/tty/ttyO2/power/wakeup
# echo mem > /sys/power/state 
[  227.685028] PM: Syncing filesystems ... done.
[  227.699432] Freezing user space processes ... (elapsed 0.01 seconds) done.
[  227.725524] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
[  227.880706] PM: suspend of devices complete after 117.767 msecs
[  227.889160] PM: late suspend of devices complete after 2.136 msecs
[  227.895782] Disabling non-boot CPUs ...

Any idea ?

Thanks!

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

Re: BeagleBoard not resuming from uart with latest pm-core ?

[Thomas Petazzoni]

On Mon, 15 Nov 2010 11:50:05 +0100
Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:

> # echo enabled > /sys/class/tty/ttyO2/power/wakeup
> # echo mem > /sys/power/state 
> [  227.685028] PM: Syncing filesystems ... done.
> [  227.699432] Freezing user space processes ... (elapsed 0.01 seconds) done.
> [  227.725524] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
> [  227.880706] PM: suspend of devices complete after 117.767 msecs
> [  227.889160] PM: late suspend of devices complete after 2.136 msecs
> [  227.895782] Disabling non-boot CPUs ...
> 
> Any idea ?

Removing "no_console_suspend" from my bootargs made it work. However,
it was previously working with no_console_suspend, and that was very
useful since I need to debug things happening fairly early in the
resume procedure. Any clue on how to make "no_console_suspend" work
again ?

Regards,

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

Re: BeagleBoard not resuming from uart with latest pm-core ?

[Govindraj]

On Mon, Nov 15, 2010 at 6:43 PM, Thomas Petazzoni
<thomas.petazzoni@free-electrons.com> wrote:
> On Mon, 15 Nov 2010 11:50:05 +0100
> Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
>
>> # echo enabled > /sys/class/tty/ttyO2/power/wakeup
>> # echo mem > /sys/power/state
>> [  227.685028] PM: Syncing filesystems ... done.
>> [  227.699432] Freezing user space processes ... (elapsed 0.01 seconds) done.
>> [  227.725524] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
>> [  227.880706] PM: suspend of devices complete after 117.767 msecs
>> [  227.889160] PM: late suspend of devices complete after 2.136 msecs
>> [  227.895782] Disabling non-boot CPUs ...
>>
>> Any idea ?
>
> Removing "no_console_suspend" from my bootargs made it work. However,
> it was previously working with no_console_suspend, and that was very
> useful since I need to debug things happening fairly early in the
> resume procedure. Any clue on how to make "no_console_suspend" work
> again ?
>

Can you check if you have below two patches in the kernel you have?

http://www.spinics.net/lists/linux-serial/msg02684.html
http://www.spinics.net/lists/linux-serial/msg02683.html

If not there can you check applying these two patch

--
Regards,
Govindraj.R




> Regards,
>
> 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 majordomo@vger.kernel.org
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: BeagleBoard not resuming from uart with latest pm-core ?

[Thomas Petazzoni]

Hello Govindraj,

On Mon, 15 Nov 2010 19:24:05 +0530
Govindraj <govindraj.ti@gmail.com> wrote:

> Can you check if you have below two patches in the kernel you have?
> 
> http://www.spinics.net/lists/linux-serial/msg02684.html
> http://www.spinics.net/lists/linux-serial/msg02683.html
> 
> If not there can you check applying these two patch

I have both of these patches in my kernel (I'm running the latest
pm-core from Kevin's repository). See
http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git;a=history;f=drivers/serial/serial_core.c;h=c4ea14670d4486fc142df31d806c528d2752c238;hb=pm-core.

Thanks for the hint, anyway.

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

Re: BeagleBoard not resuming from uart with latest pm-core ?

[Kevin Hilman]

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

> Hello Govindraj,
>
> On Mon, 15 Nov 2010 19:24:05 +0530
> Govindraj <govindraj.ti@gmail.com> wrote:
>
>> Can you check if you have below two patches in the kernel you have?
>> 
>> http://www.spinics.net/lists/linux-serial/msg02684.html
>> http://www.spinics.net/lists/linux-serial/msg02683.html
>> 
>> If not there can you check applying these two patch
>
> I have both of these patches in my kernel (I'm running the latest
> pm-core from Kevin's repository).

Hmm, using pm-core, I can hit full-chip retention in suspend on my
Beagle C4.

However, upgrading to a recent x-loader and u-boot, I can reproduce the
problem.

The problem is an old one that seems to have resurfaced.  Namely, u-boot
leaves the MUSB block in a state that prevents it from idling, and thus
prevents CORE from hitting RET.

I have a series of hacks for this in the PM branch (see my pm-otg-reset
branch) that fixes the problem, but is not clean.  This will work until
the omap_hwmod conversion for MUSB is done.   One of the perks we get
from omap_hwmod is that a reset is done for each hwmod ensuring that any
(mis)configuration of the bootloader is cleared and the HW is in a known
default state.

Kevin

Re: BeagleBoard not resuming from uart with latest pm-core ?

[Thomas Petazzoni]

Hello,

On Tue, 16 Nov 2010 14:59:30 -0800
Kevin Hilman <khilman@deeprootsystems.com> wrote:

> Hmm, using pm-core, I can hit full-chip retention in suspend on my
> Beagle C4.
> 
> However, upgrading to a recent x-loader and u-boot, I can reproduce
> the problem.

Ok, as you told me on IRC yesterday.

> The problem is an old one that seems to have resurfaced.  Namely,
> u-boot leaves the MUSB block in a state that prevents it from idling,
> and thus prevents CORE from hitting RET.
> 
> I have a series of hacks for this in the PM branch (see my
> pm-otg-reset branch) that fixes the problem, but is not clean.  This
> will work until the omap_hwmod conversion for MUSB is done.   One of
> the perks we get from omap_hwmod is that a reset is done for each
> hwmod ensuring that any (mis)configuration of the bootloader is
> cleared and the HW is in a known default state.

Ah, that's nice indeed. Are the hwmod conversion patches of musb
already available somewhere (even preliminary versions) ?

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

Re: BeagleBoard not resuming from uart with latest pm-core ?

[Kevin Hilman]

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

> On Mon, 15 Nov 2010 11:50:05 +0100
> Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
>
>> # echo enabled > /sys/class/tty/ttyO2/power/wakeup
>> # echo mem > /sys/power/state 
>> [  227.685028] PM: Syncing filesystems ... done.
>> [  227.699432] Freezing user space processes ... (elapsed 0.01 seconds) done.
>> [  227.725524] Freezing remaining freezable tasks ... (elapsed 0.02 seconds) done.
>> [  227.880706] PM: suspend of devices complete after 117.767 msecs
>> [  227.889160] PM: late suspend of devices complete after 2.136 msecs
>> [  227.895782] Disabling non-boot CPUs ...
>> 
>> Any idea ?
>
> Removing "no_console_suspend" from my bootargs made it work. However,
> it was previously working with no_console_suspend, and that was very
> useful since I need to debug things happening fairly early in the
> resume procedure. Any clue on how to make "no_console_suspend" work
> again ?

Until we convert the omap-serial driver to use runtime PM (currently
under development), no_console_suspend is going to be unpredictable at
best.  Until then, there will be races with the current UART PM code.

Kevin