From: davidb@codeaurora.org (David Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv2 2/2] ARM: debug: Move DEBUG_ICEDCC into the DEBUG_LL choice
Date: Thu, 29 Sep 2011 11:04:28 -0700 [thread overview]
Message-ID: <20110929180428.GA8125@huya.qualcomm.com> (raw)
In-Reply-To: <4E84A962.9030806@codeaurora.org>
On Thu, Sep 29, 2011 at 10:22:42AM -0700, Stephen Boyd wrote:
> >> One of the problems you'll encounter is that there's places where we
> >> don't have any timer infrastructure (eg, decompressor) and software
> >> timing loops won't work (they'll be too slow for the lower-end CPUs
> >> and too fast for the upper-end CPUs.)
> > Agreed, software timing loops are the only option and it's impossible to get
> > them right everywhere. I think the Kconfig help text should be updated so
> > that the timeout paragraph is removed.
>
> Yes if you wait a long time the timeout for each character will expire
> and the execution will continue.
Wouldn't it be better to detect the first timeout and then stop trying
to write to the DCC?
But, do we really want fancy auto-detection stuff in DEBUG_LL? A
timeout might make sense for a DCC console, but not here.
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
WARNING: multiple messages have this Message-ID (diff)
From: David Brown <davidb@codeaurora.org>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: Will Deacon <will.deacon@arm.com>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
David Brown <davidb@codeaurora.org>
Subject: Re: [PATCHv2 2/2] ARM: debug: Move DEBUG_ICEDCC into the DEBUG_LL choice
Date: Thu, 29 Sep 2011 11:04:28 -0700 [thread overview]
Message-ID: <20110929180428.GA8125@huya.qualcomm.com> (raw)
In-Reply-To: <4E84A962.9030806@codeaurora.org>
On Thu, Sep 29, 2011 at 10:22:42AM -0700, Stephen Boyd wrote:
> >> One of the problems you'll encounter is that there's places where we
> >> don't have any timer infrastructure (eg, decompressor) and software
> >> timing loops won't work (they'll be too slow for the lower-end CPUs
> >> and too fast for the upper-end CPUs.)
> > Agreed, software timing loops are the only option and it's impossible to get
> > them right everywhere. I think the Kconfig help text should be updated so
> > that the timeout paragraph is removed.
>
> Yes if you wait a long time the timeout for each character will expire
> and the execution will continue.
Wouldn't it be better to detect the first timeout and then stop trying
to write to the DCC?
But, do we really want fancy auto-detection stuff in DEBUG_LL? A
timeout might make sense for a DCC console, but not here.
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
next prev parent reply other threads:[~2011-09-29 18:04 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-21 1:23 [PATCHv2 1/2] ARM: debug: Add UART1 config choices Stephen Boyd
2011-09-21 1:23 ` Stephen Boyd
2011-09-21 1:23 ` [PATCHv2 2/2] ARM: debug: Move DEBUG_ICEDCC into the DEBUG_LL choice Stephen Boyd
2011-09-21 1:23 ` Stephen Boyd
2011-09-21 7:56 ` Stephen Boyd
2011-09-21 7:56 ` Stephen Boyd
2011-09-29 2:05 ` Stephen Boyd
2011-09-29 2:05 ` Stephen Boyd
2011-09-29 9:21 ` Will Deacon
2011-09-29 9:21 ` Will Deacon
2011-09-29 9:42 ` Will Deacon
2011-09-29 9:42 ` Will Deacon
2011-09-29 9:46 ` Russell King - ARM Linux
2011-09-29 9:46 ` Russell King - ARM Linux
2011-09-29 10:39 ` Will Deacon
2011-09-29 10:39 ` Will Deacon
2011-09-29 10:49 ` Russell King - ARM Linux
2011-09-29 10:49 ` Russell King - ARM Linux
2011-09-29 17:22 ` Stephen Boyd
2011-09-29 17:22 ` Stephen Boyd
2011-09-29 17:30 ` Will Deacon
2011-09-29 17:30 ` Will Deacon
2011-09-29 18:04 ` David Brown [this message]
2011-09-29 18:04 ` David Brown
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=20110929180428.GA8125@huya.qualcomm.com \
--to=davidb@codeaurora.org \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.