From: Mark Rutland <mark.rutland@arm.com>
To: tingwei@codeaurora.org
Cc: Will Deacon <will@kernel.org>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: Set DBGCLAIM when self-host debug is enabled
Date: Wed, 6 Jan 2021 12:23:56 +0000 [thread overview]
Message-ID: <20210106122356.GC26994@C02TD0UTHF1T.local> (raw)
In-Reply-To: <512a30e6cc6877687c10c0f9ccc3c4c5@codeaurora.org>
On Wed, Jan 06, 2021 at 06:29:53PM +0800, tingwei@codeaurora.org wrote:
> Hi Will and Mark,
Hi Tingwei,
> In recent implementation of save/restore ARM debug registers in
> EL2/EL3, we found it's necessary to know whether self-host debug is
> enabled so EL2/EL3 can avoid saving/restoring debug registers but no
> one is using debug.
In what situation are you considering? I assume you mean idle sequences
using CPU_SUSPEND?
Generally our expectation for CPU_SUSPEND is:
* Where StateType==0, the debug state is preserved with all other
PE state.
* Where StateType==1 and the PE returns "warm" without having entered a
powerdown state, the debug state is preserved along with all other PE
state.
* Where StateType==1, and the PE returns "cold" after having entered a
powerdown state (i.e. we return via the entry point address), the
debug state is not preserved.
... and I'm missing where you could avoid saving the state. What
situation(s) did you have in mind?
> In ARM PSCI, it has one option to set DBGCLAIM[1] to 1 to indicate
> that debug is in use by a self-host debugger. Do you think it's
> resonable to add this to Kernel?
>
> For example, can we set DBGCLAIM[1] to 1 in enable_debug_monitors()
> and clear it in disable_debug_monitors().
I was under the impression that this was solely for the benefit of an
external debugger, and should have no functional impact on the PSCI
implementation from the kernel's PoV, so as above I think we need a
better description of the case you're trying to address.
Thanks,
Mark.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next parent reply other threads:[~2021-01-06 12:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <512a30e6cc6877687c10c0f9ccc3c4c5@codeaurora.org>
2021-01-06 12:23 ` Mark Rutland [this message]
[not found] ` <20210108040055.GA11529@codeaurora.org>
2021-01-11 11:44 ` Set DBGCLAIM when self-host debug is enabled Mark Rutland
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=20210106122356.GC26994@C02TD0UTHF1T.local \
--to=mark.rutland@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tingwei@codeaurora.org \
--cc=will@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox