[PATCH 0/4] OMAP2+: Fix boot hang with earlycon enabled

[PATCH 0/4] OMAP2+: Fix boot hang with earlycon enabled

[Rajendra Nayak]

Boot on all OMAP2+ devices is broken with earlycon enabled
as discussed here [1]

There were 2 issues which were rootcaused
1. Issue caused due to hwmod doing a reset of console uart while
earlycon was using it (seen only on am335x devices)

2. omap serial causing a NULL context restore with context loss
count missing.

This patch set attempts to fix both the issues and is one of the
different approaches discussed [1] on how to fix these issues.

Boot tested on omap4 panda es with and without earlycon (DT boot)
Boot tested on am335x bone black with and without earlycon (DT boot)
Boot tested on OMAP3 beagle XM with and without earlycon (non-DT boot)

[1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg91662.html

Grygorii Strashko (1):
  serial: omap: enable PM runtime only when its fully configured

Rajendra Nayak (3):
  ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with DEBUG_LL
  ARM: OMAP2+: Avoid idling memory controllers with no drivers
  ARM: OMAP2+: Sync hwmod state with the pm_runtime and omap_device
    state

 arch/arm/mach-omap2/omap_device.c                  |   18 ++++++++
 arch/arm/mach-omap2/omap_hwmod.h                   |   48 ++++++++++++++++++++
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |    6 +--
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    2 +-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    9 ++--
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    5 +-
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |    3 +-
 arch/arm/mach-omap2/serial.c                       |   11 -----
 drivers/tty/serial/omap-serial.c                   |    3 +-
 9 files changed, 81 insertions(+), 24 deletions(-)

-- 
1.7.9.5

[PATCH 1/4] ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with DEBUG_LL

[Rajendra Nayak]

With commit '82702ea11ddfe0e43382e1fa5b66d807d8114916' "ARM: OMAP2+:
Fix serial init for device tree based booting" stubbing out omap_serial_early_init()
for Device tree based booting, there was a crash observed on AM335x based devices
when hwmod does a _setup_reset() early at boot.

This was rootcaused to hwmod trying to reset console uart while earlycon was using it.
The way to tell hwmod not to do this is to specify the HWMOD_INIT_NO_RESET flag,
which were infact set by the omap_serial_early_init() function by parsing the
cmdline to identify the console device.

Parsing the cmdline to identify the uart used by earlycon itself seems broken
as there is nothing preventing earlycon to use a different one.

This patch, instead, attempts to populate the requiste flags for hwmod based on
the CONFIG_DEBUG_OMAPxUARTy FLAGS. This gets rid of the need for cmdline parsing
in the DT as well as non-DT cases to identify the uart used by earlycon.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
Reported-by: Mark Jackson <mpfj-list@newflow.co.uk>
Reported-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
---
 arch/arm/mach-omap2/omap_hwmod.h                   |   48 ++++++++++++++++++++
 arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |    6 +--
 arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    2 +-
 arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    9 ++--
 arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    5 +-
 arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |    3 +-
 arch/arm/mach-omap2/serial.c                       |   11 -----
 7 files changed, 61 insertions(+), 23 deletions(-)

diff --git a/arch/arm/mach-omap2/omap_hwmod.h b/arch/arm/mach-omap2/omap_hwmod.h
index aab33fd..8440a21 100644
--- a/arch/arm/mach-omap2/omap_hwmod.h
+++ b/arch/arm/mach-omap2/omap_hwmod.h
@@ -95,6 +95,54 @@ extern struct omap_hwmod_sysc_fields omap_hwmod_sysc_type3;
 #define MODULEMODE_HWCTRL		1
 #define MODULEMODE_SWCTRL		2
 
+#define DEBUG_OMAP2UART1_FLAGS	0
+#define DEBUG_OMAP2UART2_FLAGS	0
+#define DEBUG_OMAP2UART3_FLAGS	0
+#define DEBUG_OMAP3UART3_FLAGS	0
+#define DEBUG_OMAP3UART4_FLAGS	0
+#define DEBUG_OMAP4UART3_FLAGS	0
+#define DEBUG_OMAP4UART4_FLAGS	0
+#define DEBUG_TI81XXUART1_FLAGS	0
+#define DEBUG_TI81XXUART2_FLAGS	0
+#define DEBUG_TI81XXUART3_FLAGS	0
+#define DEBUG_AM33XXUART1_FLAGS	0
+
+#define DEBUG_OMAPUART_FLAGS	(HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET)
+
+#if defined(CONFIG_DEBUG_OMAP2UART1)
+#undef DEBUG_OMAP2UART1_FLAGS
+#define DEBUG_OMAP2UART1_FLAGS DEBUG_OMAPUART_FLAGS
+#elif defined(CONFIG_DEBUG_OMAP2UART2)
+#undef DEBUG_OMAP2UART2_FLAGS
+#define DEBUG_OMAP2UART2_FLAGS DEBUG_OMAPUART_FLAGS
+#elif defined(CONFIG_DEBUG_OMAP2UART3)
+#undef DEBUG_OMAP2UART3_FLAGS
+#define DEBUG_OMAP2UART3_FLAGS DEBUG_OMAPUART_FLAGS
+#elif defined(CONFIG_DEBUG_OMAP3UART3)
+#undef DEBUG_OMAP3UART3_FLAGS
+#define DEBUG_OMAP3UART3_FLAGS DEBUG_OMAPUART_FLAGS
+#elif defined(CONFIG_DEBUG_OMAP3UART4)
+#undef DEBUG_OMAP3UART4_FLAGS
+#define DEBUG_OMAP3UART4_FLAGS DEBUG_OMAPUART_FLAGS
+#elif defined(CONFIG_DEBUG_OMAP4UART3)
+#undef DEBUG_OMAP4UART3_FLAGS
+#define DEBUG_OMAP4UART3_FLAGS DEBUG_OMAPUART_FLAGS
+#elif defined(CONFIG_DEBUG_OMAP4UART4)
+#undef DEBUG_OMAP4UART4_FLAGS
+#define DEBUG_OMAP4UART4_FLAGS DEBUG_OMAPUART_FLAGS
+#elif defined(CONFIG_DEBUG_TI81XXUART1)
+#undef DEBUG_TI81XXUART1_FLAGS
+#define DEBUG_TI81XXUART1_FLAGS DEBUG_OMAPUART_FLAGS
+#elif defined(CONFIG_DEBUG_TI81XXUART2)
+#undef DEBUG_TI81XXUART2_FLAGS
+#define DEBUG_TI81XXUART2_FLAGS DEBUG_OMAPUART_FLAGS
+#elif defined(CONFIG_DEBUG_TI81XXUART3)
+#undef DEBUG_TI81XXUART3_FLAGS
+#define DEBUG_TI81XXUART3_FLAGS DEBUG_OMAPUART_FLAGS
+#elif defined(CONFIG_DEBUG_AM33XXUART1)
+#undef DEBUG_AM33XXUART1_FLAGS
+#define DEBUG_AM33XXUART1_FLAGS DEBUG_OMAPUART_FLAGS
+#endif
 
 /**
  * struct omap_hwmod_mux_info - hwmod specific mux configuration
diff --git a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
index d05fc7b..56cebb0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c
@@ -512,7 +512,7 @@ struct omap_hwmod omap2xxx_uart1_hwmod = {
 	.mpu_irqs	= omap2_uart1_mpu_irqs,
 	.sdma_reqs	= omap2_uart1_sdma_reqs,
 	.main_clk	= "uart1_fck",
-	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_OMAP2UART1_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = CORE_MOD,
@@ -532,7 +532,7 @@ struct omap_hwmod omap2xxx_uart2_hwmod = {
 	.mpu_irqs	= omap2_uart2_mpu_irqs,
 	.sdma_reqs	= omap2_uart2_sdma_reqs,
 	.main_clk	= "uart2_fck",
-	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_OMAP2UART2_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = CORE_MOD,
@@ -552,7 +552,7 @@ struct omap_hwmod omap2xxx_uart3_hwmod = {
 	.mpu_irqs	= omap2_uart3_mpu_irqs,
 	.sdma_reqs	= omap2_uart3_sdma_reqs,
 	.main_clk	= "uart3_fck",
-	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_OMAP2UART3_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = CORE_MOD,
diff --git a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
index 28bbd56..d4114a9 100644
--- a/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_33xx_data.c
@@ -1512,7 +1512,7 @@ static struct omap_hwmod am33xx_uart1_hwmod = {
 	.name		= "uart1",
 	.class		= &uart_class,
 	.clkdm_name	= "l4_wkup_clkdm",
-	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_AM33XXUART1_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
 	.main_clk	= "dpll_per_m2_div4_wkupdm_ck",
 	.prcm		= {
 		.omap4	= {
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index f7a3df2..0c3a427 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -490,7 +490,7 @@ static struct omap_hwmod omap3xxx_uart1_hwmod = {
 	.mpu_irqs	= omap2_uart1_mpu_irqs,
 	.sdma_reqs	= omap2_uart1_sdma_reqs,
 	.main_clk	= "uart1_fck",
-	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_TI81XXUART1_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = CORE_MOD,
@@ -509,7 +509,7 @@ static struct omap_hwmod omap3xxx_uart2_hwmod = {
 	.mpu_irqs	= omap2_uart2_mpu_irqs,
 	.sdma_reqs	= omap2_uart2_sdma_reqs,
 	.main_clk	= "uart2_fck",
-	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_TI81XXUART2_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = CORE_MOD,
@@ -528,7 +528,8 @@ static struct omap_hwmod omap3xxx_uart3_hwmod = {
 	.mpu_irqs	= omap2_uart3_mpu_irqs,
 	.sdma_reqs	= omap2_uart3_sdma_reqs,
 	.main_clk	= "uart3_fck",
-	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_OMAP3UART3_FLAGS | DEBUG_TI81XXUART3_FLAGS |
+				HWMOD_SWSUP_SIDLE_ACT,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = OMAP3430_PER_MOD,
@@ -558,7 +559,7 @@ static struct omap_hwmod omap36xx_uart4_hwmod = {
 	.mpu_irqs	= uart4_mpu_irqs,
 	.sdma_reqs	= uart4_sdma_reqs,
 	.main_clk	= "uart4_fck",
-	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_OMAP3UART4_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
 	.prcm		= {
 		.omap2 = {
 			.module_offs = OMAP3430_PER_MOD,
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index d04b5e6..9c3b504 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -2858,8 +2858,7 @@ static struct omap_hwmod omap44xx_uart3_hwmod = {
 	.name		= "uart3",
 	.class		= &omap44xx_uart_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
-	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET |
-				HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_OMAP4UART3_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
 	.main_clk	= "func_48m_fclk",
 	.prcm = {
 		.omap4 = {
@@ -2875,7 +2874,7 @@ static struct omap_hwmod omap44xx_uart4_hwmod = {
 	.name		= "uart4",
 	.class		= &omap44xx_uart_hwmod_class,
 	.clkdm_name	= "l4_per_clkdm",
-	.flags		= HWMOD_SWSUP_SIDLE_ACT,
+	.flags		= DEBUG_OMAP4UART4_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
 	.main_clk	= "func_48m_fclk",
 	.prcm = {
 		.omap4 = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
index f37ae96..3c70f5c 100644
--- a/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_54xx_data.c
@@ -1375,7 +1375,7 @@ static struct omap_hwmod omap54xx_uart3_hwmod = {
 	.name		= "uart3",
 	.class		= &omap54xx_uart_hwmod_class,
 	.clkdm_name	= "l4per_clkdm",
-	.flags		= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET,
+	.flags		= DEBUG_OMAP4UART3_FLAGS,
 	.main_clk	= "func_48m_fclk",
 	.prcm = {
 		.omap4 = {
@@ -1391,6 +1391,7 @@ static struct omap_hwmod omap54xx_uart4_hwmod = {
 	.name		= "uart4",
 	.class		= &omap54xx_uart_hwmod_class,
 	.clkdm_name	= "l4per_clkdm",
+	.flags		= DEBUG_OMAP4UART4_FLAGS,
 	.main_clk	= "func_48m_fclk",
 	.prcm = {
 		.omap4 = {
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 3a674de..a388f8c 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -208,17 +208,6 @@ static int __init omap_serial_early_init(void)
 				pr_info("%s used as console in debug mode: uart%d clocks will not be gated",
 					uart_name, uart->num);
 			}
-
-			/*
-			 * omap-uart can be used for earlyprintk logs
-			 * So if omap-uart is used as console then prevent
-			 * uart reset and idle to get logs from omap-uart
-			 * until uart console driver is available to take
-			 * care for console messages.
-			 * Idling or resetting omap-uart while printing logs
-			 * early boot logs can stall the boot-up.
-			 */
-			oh->flags |= HWMOD_INIT_NO_IDLE | HWMOD_INIT_NO_RESET;
 		}
 	} while (1);
 
-- 
1.7.9.5

[PATCH 2/4] serial: omap: enable PM runtime only when its fully configured

[Rajendra Nayak]

From: Grygorii Strashko <grygorii.strashko@ti.com>

If earlyprintk is enabled and current UART is console port the platform
code can mark it as RPM_ACTIVE to sync real IP state with PM Runtime and
avoid resuming of already active device, but now, driver initialization
will be performed in the wrong way:

	pm_runtime_enable(&pdev->dev);
    <-- PM runtime alowed (device state RPM_ACTIVE)
	if (omap_up_info->autosuspend_timeout == 0)
		omap_up_info->autosuspend_timeout = -1;
	device_init_wakeup(up->dev, true);
	pm_runtime_use_autosuspend(&pdev->dev);
	<-- update_autosuspend() will be called and it will disable device
        (device state RPM_SUSPENDED)
	pm_runtime_set_autosuspend_delay(&pdev->dev,
			omap_up_info->autosuspend_timeout);
	<-- update_autosuspend() will be called which will re-enable device
        (device state RPM_ACTIVE), because autosuspend_timeout < 0

	pm_runtime_irq_safe(&pdev->dev);
	pm_runtime_get_sync(&pdev->dev);
	<-- will do nothing

Such behavior isn't expected by OMAP serial drivers and causes
unpredictable calls of serial_omap_runtime_suspend() and
serial_omap_runtime_resume().

Hence, fix it by allowing PM runtime only after all its parameters are
configured.

CC: Tony Lindgren <tony@atomide.com>
CC: Rajendra Nayak <rnayak@ti.com>
CC: Felipe Balbi <balbi@ti.com>
CC: Kevin Hilman <khilman@linaro.org>

Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
 drivers/tty/serial/omap-serial.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index b6d1728..f39bf0c 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1501,7 +1501,6 @@ static int serial_omap_probe(struct platform_device *pdev)
 	INIT_WORK(&up->qos_work, serial_omap_uart_qos_work);
 
 	platform_set_drvdata(pdev, up);
-	pm_runtime_enable(&pdev->dev);
 	if (omap_up_info->autosuspend_timeout == 0)
 		omap_up_info->autosuspend_timeout = -1;
 	device_init_wakeup(up->dev, true);
@@ -1510,6 +1509,8 @@ static int serial_omap_probe(struct platform_device *pdev)
 			omap_up_info->autosuspend_timeout);
 
 	pm_runtime_irq_safe(&pdev->dev);
+	pm_runtime_enable(&pdev->dev);
+
 	pm_runtime_get_sync(&pdev->dev);
 
 	omap_serial_fill_features_erratas(up);
-- 
1.7.9.5

[PATCH 3/4] ARM: OMAP2+: Avoid idling memory controllers with no drivers

[Rajendra Nayak]

Memory controllers in OMAP (like GPMC and EMIF) have the hwmods marked with
HWMOD_INIT_NO_IDLE and are left in enabled state post initial setup.

Even if they have drivers missing, avoid idling them as part of
omap_device_late_idle()

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
 arch/arm/mach-omap2/omap_device.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 5cc9287..1c82cde 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -842,6 +842,7 @@ static int __init omap_device_late_idle(struct device *dev, void *data)
 {
 	struct platform_device *pdev = to_platform_device(dev);
 	struct omap_device *od = to_omap_device(pdev);
+	int i;
 
 	if (!od)
 		return 0;
@@ -850,6 +851,15 @@ static int __init omap_device_late_idle(struct device *dev, void *data)
 	 * If omap_device state is enabled, but has no driver bound,
 	 * idle it.
 	 */
+
+	/*
+	 * Some devices (like memory controllers) are always kept
+	 * enabled, and should not be idled even with no drivers.
+	 */
+	for (i = 0; i < od->hwmods_cnt; i++)
+		if (od->hwmods[i]->flags & HWMOD_INIT_NO_IDLE)
+			return 0;
+
 	if (od->_driver_status != BUS_NOTIFY_BOUND_DRIVER) {
 		if (od->_state == OMAP_DEVICE_STATE_ENABLED) {
 			dev_warn(dev, "%s: enabled but no driver.  Idling\n",
-- 
1.7.9.5

[PATCH 4/4] ARM: OMAP2+: Sync hwmod state with the pm_runtime and omap_device state

[Rajendra Nayak]

Some hwmods which are marked with HWMOD_INIT_NO_IDLE are left in enabled
state post setup(). When a omap_device gets created for such hwmods
make sure the omap_device and pm_runtime states are also in sync for such
hwmods by doing a omap_device_enable() and pm_runtime_set_active() for the
device.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>
---
 arch/arm/mach-omap2/omap_device.c |    8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/mach-omap2/omap_device.c b/arch/arm/mach-omap2/omap_device.c
index 1c82cde..f99f68e 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -129,6 +129,7 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
 	struct device_node *node = pdev->dev.of_node;
 	const char *oh_name;
 	int oh_cnt, i, ret = 0;
+	bool device_active = false;
 
 	oh_cnt = of_property_count_strings(node, "ti,hwmods");
 	if (oh_cnt <= 0) {
@@ -152,6 +153,8 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
 			goto odbfd_exit1;
 		}
 		hwmods[i] = oh;
+		if (oh->flags & HWMOD_INIT_NO_IDLE)
+			device_active = true;
 	}
 
 	od = omap_device_alloc(pdev, hwmods, oh_cnt);
@@ -172,6 +175,11 @@ static int omap_device_build_from_dt(struct platform_device *pdev)
 
 	pdev->dev.pm_domain = &omap_device_pm_domain;
 
+	if (device_active) {
+		omap_device_enable(pdev);
+		pm_runtime_set_active(&pdev->dev);
+	}
+
 odbfd_exit1:
 	kfree(hwmods);
 odbfd_exit:
-- 
1.7.9.5

Re: [PATCH 0/4] OMAP2+: Fix boot hang with earlycon enabled

[Mark Jackson]

On 22/07/13 11:01, Rajendra Nayak wrote:
> Boot on all OMAP2+ devices is broken with earlycon enabled
> as discussed here [1]
> 
> There were 2 issues which were rootcaused
> 1. Issue caused due to hwmod doing a reset of console uart while
> earlycon was using it (seen only on am335x devices)
> 
> 2. omap serial causing a NULL context restore with context loss
> count missing.
> 
> This patch set attempts to fix both the issues and is one of the
> different approaches discussed [1] on how to fix these issues.
> 
> Boot tested on omap4 panda es with and without earlycon (DT boot)
> Boot tested on am335x bone black with and without earlycon (DT boot)
> Boot tested on OMAP3 beagle XM with and without earlycon (non-DT boot)
> 
> [1] http://www.mail-archive.com/linux-omap@vger.kernel.org/msg91662.html
> 
> Grygorii Strashko (1):
>   serial: omap: enable PM runtime only when its fully configured
> 
> Rajendra Nayak (3):
>   ARM: OMAP2+: hwmod: Fix a crash in _setup_reset() with DEBUG_LL
>   ARM: OMAP2+: Avoid idling memory controllers with no drivers
>   ARM: OMAP2+: Sync hwmod state with the pm_runtime and omap_device
>     state
> 
>  arch/arm/mach-omap2/omap_device.c                  |   18 ++++++++
>  arch/arm/mach-omap2/omap_hwmod.h                   |   48 ++++++++++++++++++++
>  arch/arm/mach-omap2/omap_hwmod_2xxx_ipblock_data.c |    6 +--
>  arch/arm/mach-omap2/omap_hwmod_33xx_data.c         |    2 +-
>  arch/arm/mach-omap2/omap_hwmod_3xxx_data.c         |    9 ++--
>  arch/arm/mach-omap2/omap_hwmod_44xx_data.c         |    5 +-
>  arch/arm/mach-omap2/omap_hwmod_54xx_data.c         |    3 +-
>  arch/arm/mach-omap2/serial.c                       |   11 -----
>  drivers/tty/serial/omap-serial.c                   |    3 +-
>  9 files changed, 81 insertions(+), 24 deletions(-)
 
This now fixes the boot hang for me so ...

Tested-by: Mark Jackson <mpfj-list@newflow.co.uk>

Re: [PATCH 3/4] ARM: OMAP2+: Avoid idling memory controllers with no drivers

[Paul Walmsley]

Hi

On Mon, 22 Jul 2013, Rajendra Nayak wrote:

> Memory controllers in OMAP (like GPMC and EMIF) have the hwmods marked with
> HWMOD_INIT_NO_IDLE and are left in enabled state post initial setup.
> 
> Even if they have drivers missing, avoid idling them as part of
> omap_device_late_idle()

Since this patch is intended for the -rc series, it's best if you explain 
here what effects this patch will fix.  i.e., does this fix a crash, a 
warning, etc?  Also maybe update your series description message?


- Paul

Re: [PATCH 3/4] ARM: OMAP2+: Avoid idling memory controllers with no drivers

[Rajendra Nayak]

On Monday 22 July 2013 11:18 PM, Paul Walmsley wrote:
> Hi
> 
> On Mon, 22 Jul 2013, Rajendra Nayak wrote:
> 
>> Memory controllers in OMAP (like GPMC and EMIF) have the hwmods marked with
>> HWMOD_INIT_NO_IDLE and are left in enabled state post initial setup.
>>
>> Even if they have drivers missing, avoid idling them as part of
>> omap_device_late_idle()
> 
> Since this patch is intended for the -rc series, it's best if you explain 
> here what effects this patch will fix.  i.e., does this fix a crash, a 
> warning, etc?  Also maybe update your series description message?

This patch infact is needed because of 'PATCH 4/4' in the series which makes
sure the omap_device and pm_runtime state are in sync with the hwmod state.

Without that we always had gpmc and emif having the hwmod state as enabled but
omap_device state as disabled and we never hit the issue of omap_device_late_idle()
trying to disable gpmc and emif.

So in short, this does not fix anything in the existing code, but something that
was uncovered by syncing the states across hwmod and omap_device.

regards,
Rajendra

> 
> 
> - Paul
> 

Re: [PATCH 2/4] serial: omap: enable PM runtime only when its fully configured

[Paul Walmsley]

Rajendra,

On Mon, 22 Jul 2013, Rajendra Nayak wrote:

> From: Grygorii Strashko <grygorii.strashko@ti.com>
> 
> If earlyprintk is enabled and current UART is console port the platform
> code can mark it as RPM_ACTIVE to sync real IP state with PM Runtime and
> avoid resuming of already active device, but now, driver initialization
> will be performed in the wrong way:

...

> CC: Tony Lindgren <tony@atomide.com>
> CC: Rajendra Nayak <rnayak@ti.com>
> CC: Felipe Balbi <balbi@ti.com>
> CC: Kevin Hilman <khilman@linaro.org>
> 
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>

Did you intend to add your Signed-off-by: to this patch?  Since you're 
formally submitting it, it needs to have your Signed-off-by: for me to 
take it.  Let me know and I'll add it if needed -

- Paul

Re: [PATCH 2/4] serial: omap: enable PM runtime only when its fully configured

[Rajendra Nayak]

On Monday 29 July 2013 02:14 PM, Paul Walmsley wrote:
> Rajendra,
> 
> On Mon, 22 Jul 2013, Rajendra Nayak wrote:
> 
>> From: Grygorii Strashko <grygorii.strashko@ti.com>
>>
>> If earlyprintk is enabled and current UART is console port the platform
>> code can mark it as RPM_ACTIVE to sync real IP state with PM Runtime and
>> avoid resuming of already active device, but now, driver initialization
>> will be performed in the wrong way:
> 
> ...
> 
>> CC: Tony Lindgren <tony@atomide.com>
>> CC: Rajendra Nayak <rnayak@ti.com>
>> CC: Felipe Balbi <balbi@ti.com>
>> CC: Kevin Hilman <khilman@linaro.org>
>>
>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> 
> Did you intend to add your Signed-off-by: to this patch?  Since you're 
> formally submitting it, it needs to have your Signed-off-by: for me to 
> take it.  Let me know and I'll add it if needed -

Sorry about that Paul. I indeed missed adding my SoB for this one.

Signed-off-by: Rajendra Nayak <rnayak@ti.com>

> 
> - Paul
> 

Re: [PATCH 2/4] serial: omap: enable PM runtime only when its fully configured

[Rajendra Nayak]

On Monday 29 July 2013 02:20 PM, Rajendra Nayak wrote:
> On Monday 29 July 2013 02:14 PM, Paul Walmsley wrote:
>> Rajendra,
>>
>> On Mon, 22 Jul 2013, Rajendra Nayak wrote:
>>
>>> From: Grygorii Strashko <grygorii.strashko@ti.com>
>>>
>>> If earlyprintk is enabled and current UART is console port the platform
>>> code can mark it as RPM_ACTIVE to sync real IP state with PM Runtime and
>>> avoid resuming of already active device, but now, driver initialization
>>> will be performed in the wrong way:
>>
>> ...
>>
>>> CC: Tony Lindgren <tony@atomide.com>
>>> CC: Rajendra Nayak <rnayak@ti.com>
>>> CC: Felipe Balbi <balbi@ti.com>
>>> CC: Kevin Hilman <khilman@linaro.org>
>>>
>>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>>
>> Did you intend to add your Signed-off-by: to this patch?  Since you're 
>> formally submitting it, it needs to have your Signed-off-by: for me to 
>> take it.  Let me know and I'll add it if needed -
> 
> Sorry about that Paul. I indeed missed adding my SoB for this one.
> 
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>

Paul,

Looks like this one is already been queued by Greg.

regards,
Rajendra

> 
>>
>> - Paul
>>
> 

Re: [PATCH 2/4] serial: omap: enable PM runtime only when its fully configured

[Paul Walmsley]

On Tue, 30 Jul 2013, Rajendra Nayak wrote:

> Looks like this one is already been queued by Greg.

OK, thanks for letting me know; I've dropped it.

- Paul

Re: [PATCH 4/4] ARM: OMAP2+: Sync hwmod state with the pm_runtime and omap_device state

[Kevin Hilman]

Rajendra Nayak <rnayak@ti.com> writes:

> Some hwmods which are marked with HWMOD_INIT_NO_IDLE are left in enabled
> state post setup(). When a omap_device gets created for such hwmods
> make sure the omap_device and pm_runtime states are also in sync for such
> hwmods by doing a omap_device_enable() and pm_runtime_set_active() for the
> device.
>
> Signed-off-by: Rajendra Nayak <rnayak@ti.com>

This looks like the right fix to me.

Acked-by: Kevin Hilman <khilman@linaro.org>