From: Govindraj <govindraj.ti@gmail.com>
To: "Mohammed, Afzal" <afzal@ti.com>
Cc: "R, Govindraj" <govindraj.raja@ti.com>,
"linux-omap@vger.kernel.org" <linux-omap@vger.kernel.org>,
"Hilman, Kevin" <khilman@ti.com>,
Tony Lindgren <tony@atomide.com>,
"Nayak, Rajendra" <rnayak@ti.com>,
"Basak, Partha" <p-basak2@ti.com>,
"Shilimkar, Santosh" <santosh.shilimkar@ti.com>,
"linux-serial@vger.kernel.org" <linux-serial@vger.kernel.org>,
"Sripathy, Vishwanath" <vishwanath.bs@ti.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v7 21/21] OMAP2+: UART: Do not gate uart clocks if used for debug_prints
Date: Thu, 20 Oct 2011 14:09:22 +0530 [thread overview]
Message-ID: <CAAL8m4ztvsGiJz_2uPd8rtEYSsVv24oSPi4eK==U30k==75muA@mail.gmail.com> (raw)
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB5930328693855@dbde02.ent.ti.com>
On Wed, Oct 19, 2011 at 7:50 PM, Mohammed, Afzal <afzal@ti.com> wrote:
> Hi Govindraj,
>
> On Wed, Oct 19, 2011 at 18:22:58, Govindraj wrote:
>> On Wed, Oct 19, 2011 at 11:05 AM, Mohammed, Afzal <afzal@ti.com> wrote:
>> > Hi Govindraj,
>> >
>> > On Tue, Oct 18, 2011 at 21:05:41, R, Govindraj wrote:
>> >> If OMAP UART is used as console uart and debug is enabled,
>> >> avoid gating of uart clocks to print all debug prints.
>> > :
>> > :
>> >> console_uart_id = uart->num;
>> >>
>> >> + if (cmdline_find_option("debug")) {
>> >> + uart_debug = true;
>> >
>> > Shouldn't "loglevel" also be checked?
>> >
>>
>> Might not be necessary,
>>
>> loglevel only sets the option in console driver how a printk should be handled
>> from vprintk so any printk should be to sent to console or to syslogd action
>> where it will be buffered to a file(var/log/messages).
>>
>> Any print's with any log level should be handled and printed to console.
>>
>> consider below path below path
>>
>> uart->ops
>> -> runtime_get_sync
>> -> omap_device_enable
>> -> clock_enable
>>
>> All the prints in given path are dev_dbgs for which we need debug to be set from
>> command line argument.
>>
>> As stated in change log any dev_dbg prints from these path can be
>> redirect to uart->ops
>> so even before our clock was enabled we got redirected back to uart code.
>>
>> So for dev_dbg prints from above path we need debug to be set from command-line
>> and we can prevent uart clock gating to this scenario.
>
> Isn't passing bootargs "loglevel=10" same as "debug"? (init/main.c)
Yes correct, I missed that part here is the updated patch [1]
Updated change-log for debug/loglevel and checked console_loglevel
in addition to debug in bootargs.
Same is updated in the branch hosted for v7_runtime:
https://gitorious.org/runtime_3-0/runtime_3-0/commit/3775d72f1205d218eb423a83ed87afe4c643ef38
git://gitorious.org/runtime_3-0/runtime_3-0.git v7_rc9_uart_runtime
--
Thanks,
Govindraj.R
[1]:
From 3775d72f1205d218eb423a83ed87afe4c643ef38 Mon Sep 17 00:00:00 2001
From: Govindraj.R <govindraj.raja@ti.com>
Date: Wed, 21 Sep 2011 16:54:12 +0530
Subject: [PATCH] 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.raja@ti.com>
---
arch/arm/mach-omap2/serial.c | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/serial.c b/arch/arm/mach-omap2/serial.c
index 5e3bbce..b3d0086 100644
--- a/arch/arm/mach-omap2/serial.c
+++ b/arch/arm/mach-omap2/serial.c
@@ -65,6 +65,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 */
@@ -310,6 +311,14 @@ static int __init omap_serial_early_init(void)
if (cmdline_find_option(uart_name)) {
console_uart_id = uart->num;
+ if (cmdline_find_option("debug") ||
+ 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;
@@ -414,7 +423,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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2011-10-20 8:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-18 15:35 [PATCH v7 20/21] OMAP2+: UART: Avoid uart idling on suspend for no_console_suspend usecase Govindraj.R
2011-10-18 15:35 ` [PATCH v7 21/21] OMAP2+: UART: Do not gate uart clocks if used for debug_prints Govindraj.R
2011-10-19 5:35 ` Mohammed, Afzal
2011-10-19 12:52 ` Govindraj
2011-10-19 14:20 ` Mohammed, Afzal
2011-10-20 8:39 ` Govindraj [this message]
2011-10-20 9:28 ` Mohammed, Afzal
2011-10-20 9:47 ` Govindraj
2011-10-19 6:51 ` Mohammed, Afzal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAAL8m4ztvsGiJz_2uPd8rtEYSsVv24oSPi4eK==U30k==75muA@mail.gmail.com' \
--to=govindraj.ti@gmail.com \
--cc=afzal@ti.com \
--cc=govindraj.raja@ti.com \
--cc=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-serial@vger.kernel.org \
--cc=p-basak2@ti.com \
--cc=rnayak@ti.com \
--cc=santosh.shilimkar@ti.com \
--cc=tony@atomide.com \
--cc=vishwanath.bs@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).