From: tony@atomide.com (Tony Lindgren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv3] ARM: omap2+: Revert omap-smp.c changes resetting CPU1 during boot
Date: Tue, 28 Mar 2017 11:51:05 -0700 [thread overview]
Message-ID: <20170328185105.GA10760@atomide.com> (raw)
In-Reply-To: <b1773b1c-8cd4-d085-c695-4d01a2223b02@ti.com>
* Andrew F. Davis <afd@ti.com> [170328 10:55]:
> On 03/28/2017 12:09 PM, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@armlinux.org.uk> [170328 04:39]:
> >> On Mon, Mar 27, 2017 at 09:43:09AM -0700, Tony Lindgren wrote:
> >>> Yes problems still remains. I think the immediate fix there is to
> >>> disable kexec during runtime based on some criteria for your use
> >>> case rather than BUG() though. Somehow kexec needs to know if CPU1
> >>> reset is acceptable, then reset CPU1 before kexec.
> >>
> >> The only acceptable way to do that is to make the decision when loading
> >> the image(s), and refuse to load the image(s) if kexec is not possible.
> >> (As is already done when dealing with whether we can CPU hot-unplug the
> >> secondary CPUs.)
> >
> > OK so how about the following to disable kexec for Andrew's
> > test case?
> >
> > That is assuming that omap_type() test works for HS dra7
> > like it does for the other omap2 variants.
> >
> > Regards,
> >
> > Tony
> >
> > 8< ---------------------
> > diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> > --- a/arch/arm/mach-omap2/common.h
> > +++ b/arch/arm/mach-omap2/common.h
> > @@ -260,6 +260,7 @@ extern u32 omap_modify_auxcoreboot0(u32 set_mask, u32 clear_mask);
> > extern void omap_auxcoreboot_addr(u32 cpu_addr);
> > extern u32 omap_read_auxcoreboot0(void);
> >
> > +extern bool omap4_cpu_can_disable(unsigned int cpu);
> > extern void omap4_cpu_die(unsigned int cpu);
> > extern int omap4_cpu_kill(unsigned int cpu);
> >
> > diff --git a/arch/arm/mach-omap2/omap-hotplug.c b/arch/arm/mach-omap2/omap-hotplug.c
> > --- a/arch/arm/mach-omap2/omap-hotplug.c
> > +++ b/arch/arm/mach-omap2/omap-hotplug.c
> > @@ -22,6 +22,15 @@
> > #include "omap-wakeupgen.h"
> > #include "common.h"
> > #include "powerdomain.h"
> > +#include "soc.h"
> > +
> > +bool omap4_cpu_can_disable(unsigned int cpu)
> > +{
> > + if (soc_is_dra7xx() && (omap_type() != OMAP2_DEVICE_TYPE_GP))
> > + return false;
> > +
>
> NAK!
>
> HS variants can have aux cores disabled, we are already doing it right
> now, this is another hack to avoid having to fix kexec.
Oh sorry the intention was to not break things for your. So probably
just having a separate dra7_hs_smp_ops with no cpu_kill initialized
should do the trick for kexec.
> You are failing to park cores correctly, so instead of fixing that you
> hack around it on non-HS devices by hard-resetting those cores, now
> because you can't do that hack on HS devices you suggest we disable
> hotplug on HS devices altogether!?
Me failing to park cores? The current code has always assumed that
CPU1 enters a low power state for hot-unplug. And AFAIK, there's no
way to have CPU1 continue at a different address at that point
without a reset. The need for preserving CPU1 state through kexec
boot without a reset is something new that you need.
> Kexec *does* work on HS devices. It only fails if we fail to park a core
> correctly, something that should never happen, the check here must be
> for that, unconditionally disabling Kexec for all HS devices is not a
> valid option.
Well sounds like you have to come up with checks for when we
need to disable kexec and use dra7_hs_smp_ops with no cpu_kill.
Regards,
Tony
next prev parent reply other threads:[~2017-03-28 18:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-14 18:05 [PATCHv3] ARM: omap2+: Revert omap-smp.c changes resetting CPU1 during boot Tony Lindgren
2017-03-15 9:41 ` Keerthy
2017-03-27 16:33 ` Andrew F. Davis
2017-03-27 16:43 ` Tony Lindgren
2017-03-28 11:36 ` Russell King - ARM Linux
2017-03-28 17:09 ` Tony Lindgren
2017-03-28 17:52 ` Andrew F. Davis
2017-03-28 18:51 ` Tony Lindgren [this message]
2017-03-28 19:15 ` Russell King - ARM Linux
2017-03-28 20:12 ` Tony Lindgren
2017-03-28 11:33 ` Russell King - ARM Linux
2017-03-28 17:53 ` Andrew F. Davis
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=20170328185105.GA10760@atomide.com \
--to=tony@atomide.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).