RE: [PATCH v8 19/20] OMAP2+: UART: Do not gate uart clocks if used for debug_prints
Hi Govindraj, On Mon, Jan 02, 2012 at 16:00:37, Govindraj wrote: currently runtime pm is available from omap-serial device and not from tty_dev. Setting tty_dev wakeup is to use irq_wakeup from suspend available from serail_core layer which I think we are not using for omap-uart and we use pad wakeup from suspend path. Also omap-uart.x/power/wakeup is used to gate uart clocks using runtime PM api's in omap-serial driver. Thanks for clarifying. On AM335x, one of the UARTs is in a wakeup domain and swakeup from this is used to come out of suspend. I have basic suspend-resume working on it. Strangely this works irrespective of the value of tty_dev wakeup entry. Do you know if this is expected on OMAP? The other issue concerning runtime PM is that as soon as I set a non-zero to the autosuspend_delay_ms I get some garbage characters and eventually the console stops responding. [root@arago /]# cat .../omap_uart.0/power/autosuspend_delay_ms -1 [root@arago /]# echo 3000 ÖKWëé«+×é«+wU.Éѹ,z,½Ý.ɽosuspend_delayÕ£½ÍÕÍ... [root@arago /]# - No response after some time The comment in the code mentions delay is receiving characters if runtime PM is enabled. Any idea what's going wrong at my end? Regards, Vaibhav B. -- 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 v8 19/20] OMAP2+: UART: Do not gate uart clocks if used for debug_prints
On Tue, Jan 3, 2012 at 3:54 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote: Hi Govindraj, On Mon, Jan 02, 2012 at 16:00:37, Govindraj wrote: currently runtime pm is available from omap-serial device and not from tty_dev. Setting tty_dev wakeup is to use irq_wakeup from suspend available from serail_core layer which I think we are not using for omap-uart and we use pad wakeup from suspend path. Also omap-uart.x/power/wakeup is used to gate uart clocks using runtime PM api's in omap-serial driver. Thanks for clarifying. On AM335x, one of the UARTs is in a wakeup domain and swakeup from this is used to come out of suspend. I have basic suspend-resume working on it. Strangely this works irrespective of the value of tty_dev wakeup entry. Do you know if this is expected on OMAP? AFAIK yes. The other issue concerning runtime PM is that as soon as I set a non-zero to the autosuspend_delay_ms I get some garbage characters and eventually the console stops responding. [root@arago /]# cat .../omap_uart.0/power/autosuspend_delay_ms -1 [root@arago /]# echo 3000 ÖKWëé«+×é«+wU.Éѹ,z,½Ý.ɽosuspend_delayÕ£½ÍÕÍ... [root@arago /]# - No response after some time try enabling CONFIG_CPU_IDLE for pm qos_usage from uart driver. -- Thanks, Govindraj.R -- 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 v8 19/20] OMAP2+: UART: Do not gate uart clocks if used for debug_prints
On Tue, Jan 03, 2012 at 16:01:52, Govindraj wrote: I have basic suspend-resume working on it. Strangely this works irrespective of the value of tty_dev wakeup entry. Do you know if this is expected on OMAP? AFAIK yes. Ok. The other issue concerning runtime PM is that as soon as I set a non-zero to the autosuspend_delay_ms I get some garbage characters and eventually the console stops responding. [root@arago /]# cat .../omap_uart.0/power/autosuspend_delay_ms -1 [root@arago /]# echo 3000 ÖKWëé«+×é«+wU.Éѹ,z,½Ý.ɽosuspend_delayÕ£½ÍÕÍ... [root@arago /]# - No response after some time try enabling CONFIG_CPU_IDLE for pm qos_usage from uart driver. Its enabled. Regards, Vaibhav -- 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 v8 19/20] OMAP2+: UART: Do not gate uart clocks if used for debug_prints
On Tue, Jan 3, 2012 at 5:22 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote: On Tue, Jan 03, 2012 at 16:01:52, Govindraj wrote: I have basic suspend-resume working on it. Strangely this works irrespective of the value of tty_dev wakeup entry. Do you know if this is expected on OMAP? AFAIK yes. Ok. The other issue concerning runtime PM is that as soon as I set a non-zero to the autosuspend_delay_ms I get some garbage characters and eventually the console stops responding. [root@arago /]# cat .../omap_uart.0/power/autosuspend_delay_ms -1 [root@arago /]# echo 3000 ÖKWëé«+×é«+wU.Éѹ,z,½Ý.ɽosuspend_delayÕ£½ÍÕÍ... [root@arago /]# - No response after some time try enabling CONFIG_CPU_IDLE for pm qos_usage from uart driver. Its enabled. I checked on Beagle-xm with latest LO master I don't see that issue. Lo master commit used commit: 6489f6de3a219dfd23a91261eea1b09fba7ae128 Logs: http://pastebin.pandaboard.org/index.php/view/55509914 -- Thanks, Govindraj.R -- 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 v8 19/20] OMAP2+: UART: Do not gate uart clocks if used for debug_prints
Hello, On Fri, Nov 11, 2011 at 15:31:52, R, Govindraj wrote: [...] - if ((cpu_is_omap34xx() || cpu_is_omap44xx()) bdata-pads) + if (((cpu_is_omap34xx() || cpu_is_omap44xx()) bdata-pads) + !uart_debug) device_init_wakeup(pdev-dev, true); } I was testing this on AM335x and realized that this leads to creation of two 'wakeup' entries for UART. One is created by the tty layer in serial-core.c and the other is created here. Here's what I see on a branch based on Tony's 3.2-rc6: ./sys/devices/platform/omap/omap_uart.0/power/wakeup ./sys/devices/platform/omap/omap_uart.0/tty/ttyO0/power/wakeup Shouldn't the OMAP serial just enable the 'wakeup' entry created by serial-core.c? Regards, Vaibhav -- 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 v8 19/20] OMAP2+: UART: Do not gate uart clocks if used for debug_prints
Hi Vaibhav, On Mon, Jan 2, 2012 at 2:55 PM, Bedia, Vaibhav vaibhav.be...@ti.com wrote: Hello, On Fri, Nov 11, 2011 at 15:31:52, R, Govindraj wrote: [...] - if ((cpu_is_omap34xx() || cpu_is_omap44xx()) bdata-pads) + if (((cpu_is_omap34xx() || cpu_is_omap44xx()) bdata-pads) + !uart_debug) device_init_wakeup(pdev-dev, true); } I was testing this on AM335x and realized that this leads to creation of two 'wakeup' entries for UART. One is created by the tty layer in serial-core.c and the other is created here. Here's what I see on a branch based on Tony's 3.2-rc6: ./sys/devices/platform/omap/omap_uart.0/power/wakeup ./sys/devices/platform/omap/omap_uart.0/tty/ttyO0/power/wakeup Shouldn't the OMAP serial just enable the 'wakeup' entry created by serial-core.c? currently runtime pm is available from omap-serial device and not from tty_dev. Setting tty_dev wakeup is to use irq_wakeup from suspend available from serail_core layer which I think we are not using for omap-uart and we use pad wakeup from suspend path. Also omap-uart.x/power/wakeup is used to gate uart clocks using runtime PM api's in omap-serial driver. -- Thanks, Govindraj.R -- 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 v8 19/20] OMAP2+: UART: Do not gate uart clocks if used for debug_prints
If OMAP UART is used as console uart and debug is enabled,
avoid gating of uart clocks to print all debug prints.
If uart clocks are gated then the debug prints from omap_device
framework or hwmod framework can cause uart to enter recursive
pm_runtime calls, which can cause a deadlock over power lock usage.
For example: Say, uart clocks are cut and we get a print from
omap_device_disable stating disabling uart clocks. This print
calls omap_uart driver console_write which will call runtime API
get_sync which means we enter from runtime API put context to
runtime API get context.
-- runtime put (take power lock)
-- print disabling uart clocks
-- call uart console write
-- call get_sync (try to take power lock)
Also any clock enable API call from uart driver should not call any uart
operation until clocks are enabled back. Like get_sync having debug print
calling uart console write even before clocks are enabled.
So to avoid these scenarios, identify from bootargs if OMAP_UART(ttyO) is used
in debug mode. If so, do not set device_may_wakeup. This will prevent
pm_runtime_enable in uart driver and will avoid uart clock gating.
Debug is enabled either by adding debug word in bootarg or by setting
loglevel=10
Signed-off-by: Govindraj.R govindraj.r...@ti.com
---
arch/arm/mach-omap2/serial.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 5d910ef..a5d9c9c 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -66,6 +66,7 @@ static LIST_HEAD(uart_list);
static u8 num_uarts;
static u8 console_uart_id = -1;
static u8 no_console_suspend;
+static u8 uart_debug;
#define DEFAULT_RXDMA_POLLRATE 1 /* RX DMA polling rate (us) */
#define DEFAULT_RXDMA_BUFSIZE 4096/* RX DMA buffer size */
@@ -329,6 +330,13 @@ static int __init omap_serial_early_init(void)
if (cmdline_find_option(uart_name)) {
console_uart_id = uart-num;
+ if (console_loglevel = 10) {
+ uart_debug = true;
+ pr_info(%s used as console in debug mode
+uart%d clocks will not be
+gated, uart_name, uart-num);
+ }
+
if (cmdline_find_option(no_console_suspend))
no_console_suspend = true;
@@ -432,7 +440,8 @@ void __init omap_serial_init_port(struct omap_board_data
*bdata,
oh-dev_attr = uart;
- if ((cpu_is_omap34xx() || cpu_is_omap44xx()) bdata-pads)
+ if (((cpu_is_omap34xx() || cpu_is_omap44xx()) bdata-pads)
+!uart_debug)
device_init_wakeup(pdev-dev, true);
}
--
1.7.4.1
--
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
