Re: BeagleBoard not resuming from uart with latest pm-core ?
Thomas Petazzoni thomas.petazz...@free-electrons.com writes: Hello Govindraj, On Mon, 15 Nov 2010 19:24:05 +0530 Govindraj govindraj...@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 -- 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: BeagleBoard not resuming from uart with latest pm-core ?
Hello, On Tue, 16 Nov 2010 14:59:30 -0800 Kevin Hilman khil...@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 -- 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: BeagleBoard not resuming from uart with latest pm-core ?
Hello, On Wed, 10 Nov 2010 09:32:53 -0800 Kevin Hilman khil...@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 -- 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: BeagleBoard not resuming from uart with latest pm-core ?
On Mon, 15 Nov 2010 11:50:05 +0100 Thomas Petazzoni thomas.petazz...@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 -- 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: BeagleBoard not resuming from uart with latest pm-core ?
On Mon, Nov 15, 2010 at 6:43 PM, Thomas Petazzoni thomas.petazz...@free-electrons.com wrote: On Mon, 15 Nov 2010 11:50:05 +0100 Thomas Petazzoni thomas.petazz...@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 majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BeagleBoard not resuming from uart with latest pm-core ?
Hello Govindraj, On Mon, 15 Nov 2010 19:24:05 +0530 Govindraj govindraj...@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 -- 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: BeagleBoard not resuming from uart with latest pm-core ?
Thomas Petazzoni thomas.petazz...@free-electrons.com writes: On Mon, 15 Nov 2010 11:50:05 +0100 Thomas Petazzoni thomas.petazz...@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 -- 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: BeagleBoard not resuming from uart with latest pm-core ?
On Wed, Nov 10, 2010 at 06:32:53PM +0100, ext Kevin Hilman wrote: Jean Pihet jean.pi...@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. -- 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: BeagleBoard not resuming from uart with latest pm-core ?
Peter 'p2' De Schrijver peter.de-schrij...@nokia.com writes: On Wed, Nov 10, 2010 at 06:32:53PM +0100, ext Kevin Hilman wrote: Jean Pihet jean.pi...@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 -- 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: BeagleBoard not resuming from uart with latest pm-core ?
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.petazz...@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 majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BeagleBoard not resuming from uart with latest pm-core ?
Jean Pihet jean.pi...@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.petazz...@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 majord...@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 majord...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
