Re: [PATCH] ARM: OMAP2: UART: fix console UART mismatched runtime PM status
On Mon, Oct 15, 2012 at 04:49:58PM -0700, Kevin Hilman wrote: From: Kevin Hilman khil...@ti.com The runtime PM framework assumes that the hardware state of devices when initialized is disabled. For all omap_devices, we idle/disable device by default. However, the console uart uses a no idle option during omap_device init in order to allow earlyprintk usage to work seamlessly during boot. Because the hardware is left partially enabled after init (whatever the bootloader settings were), the omap_device should later be fully initialized (including mux) and the runtime PM framework should be told that the device is active, and not disabled so that the hardware state is in sync with runtime PM state. To fix, after the device has been created/registered, call omap_device_enable() to finialize init and use pm_runtime_set_active() to tell the runtime PM core the device is enabled. I still believe you're better off with the approach I gave. Why? Because every driver you have contains virtually the same sequence of runtime PM initialization which is to runtime PM enable the device and then do a get on it. Why not do that in bus code if all your drivers are doing the same thing, and kill off a bunch of code in the drivers? It's fairly easy to do with the BUS_NOTIFY_BIND_DRIVER / BUS_NOTIFY_UNBIND_DRIVER bus level notifies, and you've already hooked the notifier list for these callbacks in omap_device.c -- 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: [PATCH] ARM: OMAP2: UART: fix console UART mismatched runtime PM status
Hi,
On Mon, Oct 15, 2012 at 04:49:58PM -0700, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
The runtime PM framework assumes that the hardware state of devices
when initialized is disabled. For all omap_devices, we idle/disable
device by default. However, the console uart uses a no idle option
during omap_device init in order to allow earlyprintk usage to work
seamlessly during boot.
Because the hardware is left partially enabled after init (whatever
the bootloader settings were), the omap_device should later be fully
initialized (including mux) and the runtime PM framework should be
told that the device is active, and not disabled so that the hardware
state is in sync with runtime PM state.
To fix, after the device has been created/registered, call
omap_device_enable() to finialize init and use pm_runtime_set_active()
to tell the runtime PM core the device is enabled.
Tested on 2420/n810, 3530/Overo, 3530/Beagle, 3730/OveroSTORM,
3730/Beagle-xM, 4460/PandaES.
Reported-by: Paul Walmsley p...@pwsan.com
Suggested-by: Russell King rmk+ker...@arm.linux.org.uk
Cc: Felipe Balbi ba...@ti.com
Cc: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
Applies against v3.7-rc1.
Fix targetted for v3.7.
I'm still not entirely sure why this has worked up to now on OMAP3/4
but not on OMAP2. Even so, this fix is needed for all platforms to
ensure matching hardware state and runtime PM state.
arch/arm/mach-omap2/serial.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0405c81..37b5dbe 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -327,6 +327,11 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
if ((console_uart_id == bdata-id) no_console_suspend)
omap_device_disable_idle_on_suspend(pdev);
+ if (console_uart_id == bdata-id) {
+ omap_device_enable(pdev);
+ pm_runtime_set_active(pdev-dev);
+ }
+
oh-mux = omap_hwmod_mux_init(bdata-pads, bdata-pads_cnt);
oh-dev_attr = uart;
looks good to me. Even took care of doing that only for the console
UART.
Reviewed-by: Felipe Balbi ba...@ti.com
sorry for the issues caused.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH] ARM: OMAP2: UART: fix console UART mismatched runtime PM status
* Felipe Balbi ba...@ti.com [121016 03:32]:
Hi,
On Mon, Oct 15, 2012 at 04:49:58PM -0700, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
The runtime PM framework assumes that the hardware state of devices
when initialized is disabled. For all omap_devices, we idle/disable
device by default. However, the console uart uses a no idle option
during omap_device init in order to allow earlyprintk usage to work
seamlessly during boot.
Because the hardware is left partially enabled after init (whatever
the bootloader settings were), the omap_device should later be fully
initialized (including mux) and the runtime PM framework should be
told that the device is active, and not disabled so that the hardware
state is in sync with runtime PM state.
To fix, after the device has been created/registered, call
omap_device_enable() to finialize init and use pm_runtime_set_active()
to tell the runtime PM core the device is enabled.
Tested on 2420/n810, 3530/Overo, 3530/Beagle, 3730/OveroSTORM,
3730/Beagle-xM, 4460/PandaES.
Reported-by: Paul Walmsley p...@pwsan.com
Suggested-by: Russell King rmk+ker...@arm.linux.org.uk
Cc: Felipe Balbi ba...@ti.com
Cc: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
Applies against v3.7-rc1.
Fix targetted for v3.7.
I'm still not entirely sure why this has worked up to now on OMAP3/4
but not on OMAP2. Even so, this fix is needed for all platforms to
ensure matching hardware state and runtime PM state.
arch/arm/mach-omap2/serial.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0405c81..37b5dbe 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -327,6 +327,11 @@ void __init omap_serial_init_port(struct
omap_board_data *bdata,
if ((console_uart_id == bdata-id) no_console_suspend)
omap_device_disable_idle_on_suspend(pdev);
+ if (console_uart_id == bdata-id) {
+ omap_device_enable(pdev);
+ pm_runtime_set_active(pdev-dev);
+ }
+
oh-mux = omap_hwmod_mux_init(bdata-pads, bdata-pads_cnt);
oh-dev_attr = uart;
looks good to me. Even took care of doing that only for the console
UART.
Applying into omap-for-v3.7-rc1/fixes-take3.
Regards,
Tony
--
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: [PATCH] ARM: OMAP2: UART: fix console UART mismatched runtime PM status
Tony Lindgren t...@atomide.com writes:
* Felipe Balbi ba...@ti.com [121016 03:32]:
Hi,
On Mon, Oct 15, 2012 at 04:49:58PM -0700, Kevin Hilman wrote:
From: Kevin Hilman khil...@ti.com
The runtime PM framework assumes that the hardware state of devices
when initialized is disabled. For all omap_devices, we idle/disable
device by default. However, the console uart uses a no idle option
during omap_device init in order to allow earlyprintk usage to work
seamlessly during boot.
Because the hardware is left partially enabled after init (whatever
the bootloader settings were), the omap_device should later be fully
initialized (including mux) and the runtime PM framework should be
told that the device is active, and not disabled so that the hardware
state is in sync with runtime PM state.
To fix, after the device has been created/registered, call
omap_device_enable() to finialize init and use pm_runtime_set_active()
to tell the runtime PM core the device is enabled.
Tested on 2420/n810, 3530/Overo, 3530/Beagle, 3730/OveroSTORM,
3730/Beagle-xM, 4460/PandaES.
Reported-by: Paul Walmsley p...@pwsan.com
Suggested-by: Russell King rmk+ker...@arm.linux.org.uk
Cc: Felipe Balbi ba...@ti.com
Cc: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
Applies against v3.7-rc1.
Fix targetted for v3.7.
I'm still not entirely sure why this has worked up to now on OMAP3/4
but not on OMAP2. Even so, this fix is needed for all platforms to
ensure matching hardware state and runtime PM state.
arch/arm/mach-omap2/serial.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0405c81..37b5dbe 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -327,6 +327,11 @@ void __init omap_serial_init_port(struct
omap_board_data *bdata,
if ((console_uart_id == bdata-id) no_console_suspend)
omap_device_disable_idle_on_suspend(pdev);
+ if (console_uart_id == bdata-id) {
+ omap_device_enable(pdev);
+ pm_runtime_set_active(pdev-dev);
+ }
+
oh-mux = omap_hwmod_mux_init(bdata-pads, bdata-pads_cnt);
oh-dev_attr = uart;
looks good to me. Even took care of doing that only for the console
UART.
Applying into omap-for-v3.7-rc1/fixes-take3.
Doh, this isn't quite right yet. Some more PM testing shows that UART
wakeups are broken, so this isn't ready for v3.7 yet.
To be continued...
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: [PATCH] ARM: OMAP2: UART: fix console UART mismatched runtime PM status
* Kevin Hilman khil...@deeprootsystems.com [121016 18:04]: Doh, this isn't quite right yet. Some more PM testing shows that UART wakeups are broken, so this isn't ready for v3.7 yet. OK I'll drop it then. Tony -- 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
[PATCH] ARM: OMAP2: UART: fix console UART mismatched runtime PM status
From: Kevin Hilman khil...@ti.com
The runtime PM framework assumes that the hardware state of devices
when initialized is disabled. For all omap_devices, we idle/disable
device by default. However, the console uart uses a no idle option
during omap_device init in order to allow earlyprintk usage to work
seamlessly during boot.
Because the hardware is left partially enabled after init (whatever
the bootloader settings were), the omap_device should later be fully
initialized (including mux) and the runtime PM framework should be
told that the device is active, and not disabled so that the hardware
state is in sync with runtime PM state.
To fix, after the device has been created/registered, call
omap_device_enable() to finialize init and use pm_runtime_set_active()
to tell the runtime PM core the device is enabled.
Tested on 2420/n810, 3530/Overo, 3530/Beagle, 3730/OveroSTORM,
3730/Beagle-xM, 4460/PandaES.
Reported-by: Paul Walmsley p...@pwsan.com
Suggested-by: Russell King rmk+ker...@arm.linux.org.uk
Cc: Felipe Balbi ba...@ti.com
Cc: Sourav Poddar sourav.pod...@ti.com
Signed-off-by: Kevin Hilman khil...@ti.com
---
Applies against v3.7-rc1.
Fix targetted for v3.7.
I'm still not entirely sure why this has worked up to now on OMAP3/4
but not on OMAP2. Even so, this fix is needed for all platforms to
ensure matching hardware state and runtime PM state.
arch/arm/mach-omap2/serial.c |5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 0405c81..37b5dbe 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -327,6 +327,11 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
if ((console_uart_id == bdata-id) no_console_suspend)
omap_device_disable_idle_on_suspend(pdev);
+ if (console_uart_id == bdata-id) {
+ omap_device_enable(pdev);
+ pm_runtime_set_active(pdev-dev);
+ }
+
oh-mux = omap_hwmod_mux_init(bdata-pads, bdata-pads_cnt);
oh-dev_attr = uart;
--
1.7.9.2
--
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: [PATCH] ARM: OMAP2: UART: fix console UART mismatched runtime PM status
* Kevin Hilman khil...@deeprootsystems.com [121015 16:51]: From: Kevin Hilman khil...@ti.com The runtime PM framework assumes that the hardware state of devices when initialized is disabled. For all omap_devices, we idle/disable device by default. However, the console uart uses a no idle option during omap_device init in order to allow earlyprintk usage to work seamlessly during boot. Because the hardware is left partially enabled after init (whatever the bootloader settings were), the omap_device should later be fully initialized (including mux) and the runtime PM framework should be told that the device is active, and not disabled so that the hardware state is in sync with runtime PM state. To fix, after the device has been created/registered, call omap_device_enable() to finialize init and use pm_runtime_set_active() to tell the runtime PM core the device is enabled. Tested on 2420/n810, 3530/Overo, 3530/Beagle, 3730/OveroSTORM, 3730/Beagle-xM, 4460/PandaES. Reported-by: Paul Walmsley p...@pwsan.com Suggested-by: Russell King rmk+ker...@arm.linux.org.uk Cc: Felipe Balbi ba...@ti.com Cc: Sourav Poddar sourav.pod...@ti.com Signed-off-by: Kevin Hilman khil...@ti.com Seems to work for my n800: Tested-by: Tony Lindgren t...@atomide.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
