v3.5-rc4 doesn't wake from dynamic idle on 3530ES3 Beagle

v3.5-rc4 doesn't wake from dynamic idle on 3530ES3 Beagle

[Paul Walmsley]

Looks like something broke between v3.5-rc3 and v3.5-rc4 with dynamic 
idle on 3530ES3 Beagle.  37xx EVM doesn't seem to be affected.

Taking a closer look now.


- Paul

echo mem > /sys/power/state
#
echo mem > /sys/power/state
#
cat /debug/pm_debug/count
#
echo 1000 > /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms
echo 1000 > /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms
echo 1000 > /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms
echo 1000 > /sys/devices/platform/omap_uart.3/power/autosuspend_delay_ms

(hang)

Re: v3.5-rc4 doesn't wake from dynamic idle on 3530ES3 Beagle

[Kevin Hilman]

Paul Walmsley <paul@pwsan.com> writes:

> Looks like something broke between v3.5-rc3 and v3.5-rc4 with dynamic 
> idle on 3530ES3 Beagle.  37xx EVM doesn't seem to be affected.
>
> Taking a closer look now.

I don't currently have access to a 3530 Beagle so I couldn't test there,
but just confirmed that vanilla v3.5-rc4 wakes up from dynamic idle (via
serial console) on 3430/n900, 3730/OveroSTORM and 3730/Beagle-xM.

Sounds like it may be something specific to Beagle board changes?

Kevin

Re: v3.5-rc4 doesn't wake from dynamic idle on 3530ES3 Beagle

[Paul Walmsley]

On Wed, 27 Jun 2012, Paul Walmsley wrote:

> Looks like something broke between v3.5-rc3 and v3.5-rc4 with dynamic 
> idle on 3530ES3 Beagle.  37xx EVM doesn't seem to be affected.
> 
> Taking a closer look now.

Reverting commit 91930652a23de0873a157aa1d9962cb878d64451 ("OMAP2+: UART: 
Add mechanism to probe uart pins and configure rx wakeup") makes wakeup 
from dynamic retention idle work again.


- Paul

Re: v3.5-rc4 doesn't wake from dynamic idle on 3530ES3 Beagle

[Shilimkar, Santosh]

+ Shubro, Felipe,

On Thu, Jun 28, 2012 at 12:57 AM, Paul Walmsley <paul@pwsan.com> wrote:
> On Wed, 27 Jun 2012, Paul Walmsley wrote:
>
>> Looks like something broke between v3.5-rc3 and v3.5-rc4 with dynamic
>> idle on 3530ES3 Beagle.  37xx EVM doesn't seem to be affected.
>>
>> Taking a closer look now.
>
> Reverting commit 91930652a23de0873a157aa1d9962cb878d64451 ("OMAP2+: UART:
> Add mechanism to probe uart pins and configure rx wakeup") makes wakeup
> from dynamic retention idle work again.
>
I suspected this.
This could be because, all the board are now expected to setup the pin
configurations.

Regards
Santosh
--
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: v3.5-rc4 doesn't wake from dynamic idle on 3530ES3 Beagle

[Shubhrajyoti]

On Thursday 28 June 2012 11:45 AM, Shilimkar, Santosh wrote:
> + Shubro, Felipe,
>
> On Thu, Jun 28, 2012 at 12:57 AM, Paul Walmsley <paul@pwsan.com> wrote:
>> On Wed, 27 Jun 2012, Paul Walmsley wrote:
>>
>>> Looks like something broke between v3.5-rc3 and v3.5-rc4 with dynamic
>>> idle on 3530ES3 Beagle.  37xx EVM doesn't seem to be affected.
>>>
>>> Taking a closer look now.
>> Reverting commit 91930652a23de0873a157aa1d9962cb878d64451 ("OMAP2+: UART:
>> Add mechanism to probe uart pins and configure rx wakeup") makes wakeup
>> from dynamic retention idle work again.
>>
> I suspected this.
> This could be because, all the board are now expected to setup the pin
> configurations.
I do not have access to a 3530 Beagle

Just tried on 3630 beagle that seems to be fine.
let me see if I can reproduce in other onap3 boards that I have.

Hi Paul,

On my beaglexm 3630

This is with the following steps:
1. merge your 32k timer fix branch
2. disable USB host: set CONFIG_MFD_OMAP_USB_HOST=n

Let me know if I missed anything.

# echo 3000 > /sys/devices/platform/omap_uart.0/power/autosuspend_delay_ms
# echo 3000 > /sys/devices/platform/omap_uart.1/power/autosuspend_delay_ms
# echo 3000 > /sys/devices/platform/omap_uart.2/power/autosuspend_delay_ms
#
# mount -t debugfs debugfs /debug/
# cat /debug/pm_debug/count | grep per_pwrdm
per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
per_clkdm->per_pwrdm (17)
# echo 1 > /debug/pm_debug/enable_off_mode
# echo enabled > /sys/devices/platform/omap_uart.2/tty/ttyO2/power/wakeup
# echo mem > /sys/power/state
[   12.404083] PM: Syncing filesystems ... done.
[   12.426055] Freezing user space processes ... (elapsed 0.01 seconds)
done.
[   12.452728] Freezing remaining freezable tasks ... (elapsed 0.02
seconds) done.
[   12.483795] Suspending console(s) (use no_console_suspend to debug)
[   12.609039] PM: suspend of devices complete after 115.564 msecs
[   12.611511] PM: late suspend of devices complete after 2.471 msecs
[   12.615966] PM: noirq suspend of devices complete after 4.424 msecs
[   12.616027] Disabling non-boot CPUs ...
[   13.203704] Successfully put all powerdomains to target state
[   13.206115] PM: noirq resume of devices complete after 2.135 msecs
[   13.209228] PM: early resume of devices complete after 1.708 msecs
[   13.585815] PM: resume of devices complete after 376.464 msecs
[   13.637603] Restarting tasks ... done.
#
# cat /debug/pm_debug/count | grep per_pwrdm
per_pwrdm (ON),OFF:1,RET:0,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0
per_clkdm->per_pwrdm (17)
#





>
> Regards
> Santosh

Re: v3.5-rc4 doesn't wake from dynamic idle on 3530ES3 Beagle

[Datta, Shubhrajyoti]

On Mon, Jul 2, 2012 at 3:52 PM, Shubhrajyoti <shubhrajyoti@ti.com> wrote:
>
> On Thursday 28 June 2012 11:45 AM, Shilimkar, Santosh wrote:
> > + Shubro, Felipe,
> >
> > On Thu, Jun 28, 2012 at 12:57 AM, Paul Walmsley <paul@pwsan.com> wrote:
> >> On Wed, 27 Jun 2012, Paul Walmsley wrote:
> >>
> >>> Looks like something broke between v3.5-rc3 and v3.5-rc4 with dynamic
> >>> idle on 3530ES3 Beagle.  37xx EVM doesn't seem to be affected.
> >>>
> >>> Taking a closer look now.
> >> Reverting commit 91930652a23de0873a157aa1d9962cb878d64451 ("OMAP2+: UART:
> >> Add mechanism to probe uart pins and configure rx wakeup") makes wakeup
> >> from dynamic retention idle work again.
> >>

Looks like the mux settings are not set in the board file.
So the boot-loader settings could play a role here.
Could you try the below patch. I gave a run on my 3630 beagle-xm



---
 arch/arm/mach-omap2/board-omap3beagle.c |   46 ++++++++++++++++++++++++++++++-
 1 files changed, 45 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 580fd17..163b23e 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -492,6 +492,50 @@ static void __init beagle_opp_init(void)
 	return;
 }

+#ifdef CONFIG_OMAP_MUX
+
+static struct omap_device_pad serial2_pads[] __initdata = {
+	{
+		.name	= "uart3_rx_irrx.uart3_rx_irrx",
+		.flags	= OMAP_DEVICE_PAD_REMUX,
+		.enable	= OMAP_INPUT_EN | OMAP_MUX_MODE0,
+		.idle	= OMAP_INPUT_EN | OMAP_WAKEUP_EN | OMAP_MUX_MODE0,
+	},
+	{
+		.name	= "uart3_cts_rctx.uart3_cts_rctx",
+		.enable	= OMAP_PIN_INPUT_PULLDOWN | OMAP_MUX_MODE0,
+	},
+	{
+		.name	= "uart3_rts_sd.uart3_rts_sd",
+		.enable	= OMAP_OFF_EN | OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+	},
+	{
+		.name	= "uart3_tx_irtx.uart3_tx_irtx",
+		.enable	= OMAP_PIN_OUTPUT | OMAP_MUX_MODE0,
+	},
+};
+
+static inline void __init board_serial_init(void)
+{
+	struct omap_board_data bdata;
+
+	bdata.flags = 0;
+	bdata.id = 2;
+	bdata.pads = serial2_pads;
+	bdata.pads_cnt = ARRAY_SIZE(serial2_pads);
+	omap_serial_init_port(&bdata, NULL);
+
+}
+
+#else
+
+static inline void __init board_serial_init(void)
+{
+	omap_serial_init();
+}
+
+#endif
+
 static void __init omap3_beagle_init(void)
 {
 	omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
@@ -511,7 +555,7 @@ static void __init omap3_beagle_init(void)
 	if (gpio_is_valid(beagle_config.dvi_pd_gpio))
 		omap_mux_init_gpio(beagle_config.dvi_pd_gpio, OMAP_PIN_OUTPUT);
 	omap_display_init(&beagle_dss_data);
-	omap_serial_init();
+	board_serial_init();
 	omap_sdrc_init(mt46h32m32lf6_sdrc_params,
 				  mt46h32m32lf6_sdrc_params);

-- 
1.7.5.4

Re: v3.5-rc4 doesn't wake from dynamic idle on 3530ES3 Beagle

[Paul Walmsley]

On Mon, 2 Jul 2012, Shubhrajyoti wrote:

> I do not have access to a 3530 Beagle

I'm afraid that's what you'll need.

I suggest you try reproducing the problem on a configuration similar to 
mine: a 3530ES3 Beagle running v3.5-rc4.


- Paul