From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] ARM: tegra: moving the clock gating procedure to tegra_cpu_kill
Date: Sun, 23 Dec 2012 11:25:40 +0000 [thread overview]
Message-ID: <20121223112540.GF16237@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <50D4D345.6030804@wwwdotorg.org>
On Fri, Dec 21, 2012 at 09:23:17PM +0000, Stephen Warren wrote:
> On 12/21/2012 02:58 AM, Joseph Lo wrote:
> > About the kexec issue, it's complicate. Your solution should be the
> > right solution. And we should implement the hardware shutdown code in
> > cpu_die not cpu_kill. I suspect this issue can be reproduced on all ARM
> > platform. Because the smp_send_stop can't really shutdown the secondary
> > CPU core if just call machine_shutdown without disable_nonboot_cpu. And
> > in platform_shutdown and platform_reboot case, the secondary CPU already
> > been offlined and killed before this function be called. Does any other
> > ARM SMP platform can run kexec without any issue?
> >
> > (I will check if we can do some HW shutdown in tegra_cpu_kill. For ex,
> > just clock gate the CPU without wait_for_reset.)
>
> Will, Joseph's thoughts above pretty much match mine re: kexec. In the
> kexec thread I started earlier, I talked about replacing:
>
> void machine_shutdown(void)
> {
> #ifdef CONFIG_SMP
> smp_send_stop();
> #endif
> }
>
> with something like:
>
> void machine_shutdown(void)
> {
> #ifdef CONFIG_HOTPLUG_CPU
> disable_nonboot_cpus();
> #elifdef CONFIG_SMP
> smp_send_stop();
> #endif
> }
>
> and you'd responded "I think you're better off using what we currently
> have and hanging your code off platform_cpu_kill.".
Sorry for being vague: I just meant that the code as it stands in mainline
is better than calling disable_nonboot_cpus(), because the latter seems to
require all the secondary cores to hit the idle loop, notice that they are
not online, and then call cpu_die. We really need this sequence to be
synchronous wrt the CPU initiating the kexec.
> What exactly did you mean by "what we currently have"; did you mean that
> cpu_kill() should work without cpu_die() having executed on the target
> CPU itself first, so Tegra should simply implement cpu_kill()? As Joseph
> says above, I'm not sure that will work. Any more detailed thoughts you
> have here would be greatly appreciated. Thanks.
I guess this comes down to the different between cpu_die/cpu_kill and
whether you actually need cpu_die if you're not planning on returning to
the same kernel that you left. If you really need to call cpu_die, then we
need to figure out a way to do that whilst ensuring that only one CPU is
left standing at the time we start copying the new kernel into place.
Will
next prev parent reply other threads:[~2012-12-23 11:25 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-20 2:28 [PATCH 1/2] ARM: tegra: update the cache maintenance order for CPU shutdown Joseph Lo
2012-12-20 2:28 ` [PATCH 2/2] ARM: tegra: moving the clock gating procedure to tegra_cpu_kill Joseph Lo
2012-12-20 17:01 ` Stephen Warren
2012-12-21 9:58 ` Joseph Lo
2012-12-21 21:23 ` Stephen Warren
2012-12-23 11:25 ` Will Deacon [this message]
2012-12-23 12:12 ` Will Deacon
2013-01-02 21:08 ` Stephen Warren
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=20121223112540.GF16237@mudshark.cambridge.arm.com \
--to=will.deacon@arm.com \
--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 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).