From: Tony Lindgren <tony@atomide.com> To: "Andrew F. Davis" <afd@ti.com> Cc: Tero Kristo <t-kristo@ti.com>, Keerthy <j-keerthy@ti.com>, linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: Re: [PATCH] ARM: omap2+: Revert omap-smp.c changes resetting cpu1 during boot Date: Fri, 17 Feb 2017 13:09:40 -0800 [thread overview] Message-ID: <20170217210939.GG21809@atomide.com> (raw) In-Reply-To: <45e4f34e-833d-77df-bc3d-f5852f614d5d@ti.com> * Andrew F. Davis <afd@ti.com> [170217 12:28]: > On 02/17/2017 09:55 AM, Tony Lindgren wrote: > > * Tony Lindgren <tony@atomide.com> [170216 11:08]: > >> * Tony Lindgren <tony@atomide.com> [170216 08:55]: > >>> For your use case, probably all we need is runtime checks for HS in > >>> addition to parking cpu1 for kexec. If that's not enough, then maybe > >>> a device specific DT property for never-reset-no-matter-what. > >> > >> Below is a first take on the last resort cpu1 reset done based on > >> configured CPU1_WAKEUP_NS_PA_ADDR_OFFSET for omap4 and 5. Note that > >> we can't merge it yet as it will break kexec boot for dra7. To fix that, > >> we need to first do what you're suggesting and properly park cpu1 for > >> kexec. > > > > Something like the patch below might be doable for the first fix > > before we have something to park cpu1 for kexec. I've added more checks > > to attemp to detect cpu1 being in WFI. At least things keep on working > > for kexec on omap4/5 and GP dra7. > > > > Andrew, care to give it a try and see if can add some HS dra7 checks > > there too to have kexec work on it? Basically we want to attempt to > > detect if there's a chance cpu1 is in WFI, and if I think the only > > optino is to reset it before bringing it up as otherwise outcome will > > be unpredictable. > > > > This patch seems stop the reset issue on my boards, so as long as it is > just a temporary workaround until we can fix the real issue (a core that > should be off going into omap_do_wfi() instead of parking), then this > patch works for me. OK > > + > > + /* REVISIT: Anything to check for HS dra7? */ > > + if (soc_is_dra74x() && omap_secure_apis_support()) > > + return; > > omap_secure_apis_support() only returns true when cpu_is_omap44xx() is > true, so this will never be true. Someday we may add the secure APIs to > secure DRA7xx devices, but I don't know of a good way to detect this > from kernel right now. OK so that can be removed. Can you check what happens with suspend/resume cycle? Based on what I've seen omap5 and dra7 currently always hit the "smp_ops.cpu_die() returned, trying to resuscitate" on resume meaning it will get sent to secondary_start_kernel on resume. Regards, Tony
WARNING: multiple messages have this Message-ID (diff)
From: tony@atomide.com (Tony Lindgren) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH] ARM: omap2+: Revert omap-smp.c changes resetting cpu1 during boot Date: Fri, 17 Feb 2017 13:09:40 -0800 [thread overview] Message-ID: <20170217210939.GG21809@atomide.com> (raw) In-Reply-To: <45e4f34e-833d-77df-bc3d-f5852f614d5d@ti.com> * Andrew F. Davis <afd@ti.com> [170217 12:28]: > On 02/17/2017 09:55 AM, Tony Lindgren wrote: > > * Tony Lindgren <tony@atomide.com> [170216 11:08]: > >> * Tony Lindgren <tony@atomide.com> [170216 08:55]: > >>> For your use case, probably all we need is runtime checks for HS in > >>> addition to parking cpu1 for kexec. If that's not enough, then maybe > >>> a device specific DT property for never-reset-no-matter-what. > >> > >> Below is a first take on the last resort cpu1 reset done based on > >> configured CPU1_WAKEUP_NS_PA_ADDR_OFFSET for omap4 and 5. Note that > >> we can't merge it yet as it will break kexec boot for dra7. To fix that, > >> we need to first do what you're suggesting and properly park cpu1 for > >> kexec. > > > > Something like the patch below might be doable for the first fix > > before we have something to park cpu1 for kexec. I've added more checks > > to attemp to detect cpu1 being in WFI. At least things keep on working > > for kexec on omap4/5 and GP dra7. > > > > Andrew, care to give it a try and see if can add some HS dra7 checks > > there too to have kexec work on it? Basically we want to attempt to > > detect if there's a chance cpu1 is in WFI, and if I think the only > > optino is to reset it before bringing it up as otherwise outcome will > > be unpredictable. > > > > This patch seems stop the reset issue on my boards, so as long as it is > just a temporary workaround until we can fix the real issue (a core that > should be off going into omap_do_wfi() instead of parking), then this > patch works for me. OK > > + > > + /* REVISIT: Anything to check for HS dra7? */ > > + if (soc_is_dra74x() && omap_secure_apis_support()) > > + return; > > omap_secure_apis_support() only returns true when cpu_is_omap44xx() is > true, so this will never be true. Someday we may add the secure APIs to > secure DRA7xx devices, but I don't know of a good way to detect this > from kernel right now. OK so that can be removed. Can you check what happens with suspend/resume cycle? Based on what I've seen omap5 and dra7 currently always hit the "smp_ops.cpu_die() returned, trying to resuscitate" on resume meaning it will get sent to secondary_start_kernel on resume. Regards, Tony
next prev parent reply other threads:[~2017-02-17 21:09 UTC|newest] Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-02-13 21:50 [PATCH] ARM: omap2+: Revert omap-smp.c changes resetting cpu1 during boot Tony Lindgren 2017-02-13 21:50 ` Tony Lindgren 2017-02-14 19:36 ` Tony Lindgren 2017-02-14 19:36 ` Tony Lindgren 2017-02-15 18:39 ` Tony Lindgren 2017-02-15 18:39 ` Tony Lindgren 2017-02-15 19:12 ` Tony Lindgren 2017-02-15 19:12 ` Tony Lindgren 2017-02-15 22:13 ` Andrew F. Davis 2017-02-15 22:13 ` Andrew F. Davis 2017-02-15 22:27 ` Tony Lindgren 2017-02-15 22:27 ` Tony Lindgren 2017-02-16 16:10 ` Tony Lindgren 2017-02-16 16:10 ` Tony Lindgren 2017-02-16 16:21 ` Tony Lindgren 2017-02-16 16:21 ` Tony Lindgren 2017-02-16 16:29 ` Andrew F. Davis 2017-02-16 16:29 ` Andrew F. Davis 2017-02-16 16:54 ` Tony Lindgren 2017-02-16 16:54 ` Tony Lindgren 2017-02-16 19:07 ` Tony Lindgren 2017-02-16 19:07 ` Tony Lindgren 2017-02-17 15:55 ` Tony Lindgren 2017-02-17 15:55 ` Tony Lindgren 2017-02-17 20:27 ` Andrew F. Davis 2017-02-17 20:27 ` Andrew F. Davis 2017-02-17 21:09 ` Tony Lindgren [this message] 2017-02-17 21:09 ` Tony Lindgren 2017-03-13 20:52 [PATCH] ARM: omap2+: Revert omap-smp.c changes resetting CPU1 " Tony Lindgren 2017-03-13 20:52 ` Tony Lindgren 2017-03-13 21:28 ` Andrew F. Davis 2017-03-13 21:28 ` Andrew F. Davis 2017-03-13 21:47 ` Tony Lindgren 2017-03-13 21:47 ` Tony Lindgren 2017-03-14 7:30 ` Tero Kristo 2017-03-14 7:30 ` Tero Kristo 2017-03-14 15:17 ` Tony Lindgren 2017-03-14 15:17 ` Tony Lindgren 2017-03-14 16:02 ` Andrew F. Davis 2017-03-14 16:02 ` Andrew F. Davis 2017-03-14 16:41 ` Tony Lindgren 2017-03-14 16:41 ` Tony Lindgren 2017-03-14 17:57 ` Andrew F. Davis 2017-03-14 17:57 ` Andrew F. Davis 2017-03-14 18:14 ` Tony Lindgren 2017-03-14 18:14 ` Tony Lindgren 2017-03-15 17:22 ` Tony Lindgren 2017-03-15 17:22 ` Tony Lindgren 2017-03-16 15:29 ` Tony Lindgren 2017-03-16 15:29 ` Tony Lindgren 2017-03-17 9:24 ` Russell King - ARM Linux 2017-03-17 9:24 ` Russell King - ARM Linux 2017-03-17 13:57 ` Tony Lindgren 2017-03-17 13:57 ` Tony Lindgren 2017-03-17 16:25 ` Andrew F. Davis 2017-03-17 16:25 ` Andrew F. Davis 2017-03-22 17:57 ` Tony Lindgren 2017-03-22 17:57 ` Tony Lindgren
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=20170217210939.GG21809@atomide.com \ --to=tony@atomide.com \ --cc=afd@ti.com \ --cc=j-keerthy@ti.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-omap@vger.kernel.org \ --cc=t-kristo@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: linkBe 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.