All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andrew F. Davis" <afd@ti.com>
To: Tony Lindgren <tony@atomide.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: Thu, 16 Feb 2017 10:29:16 -0600	[thread overview]
Message-ID: <fc1e75e8-87ef-59f1-3c8a-cb45f1749e50@ti.com> (raw)
In-Reply-To: <20170216161010.GU21809@atomide.com>

On 02/16/2017 10:10 AM, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [170215 14:28]:
>> * Andrew F. Davis <afd@ti.com> [170215 14:14]:
>>> On 02/15/2017 01:12 PM, Tony Lindgren wrote:
>>>> And also the same issue happens doing kexec on beagle-x15 naturally if
>>>> the cpu1 reset is removed.
>>>>
>>>
>>> When a core actually powers up it idles in ROM code waiting for
>>> OMAP_AUX_CORE_BOOT_0 to be set. When we shutdown a core it is not really
>>> powered off, we just let it spin in omap4_cpu_die() or
>>> omap4_secondary_startup() waiting on OMAP_AUX_CORE_BOOT_0, just like if
>>> it were still trapped in ROM after a reset.
> 
> OK so I debugged this a bit more. We have CPU1 in omap_do_wfi()
> as we don't currently have omap5_secondary_startup() or any deeper
> idle mode support beyond retention for omap5 or dra7 in the mainline
> kernel.
> 
>>> The issue with this fake startup idle loop is that, unlike the ROM based
>>> startup idle loop, these do *not* jump to the address we stored in
>>> OMAP_AUX_CORE_BOOT_1, they just make the assumption that they can safely
>>> jump to the kernel startup function.
> 
> This does not seem to be the case here.
> 

Well this is what I am seeing every time, this code only works when it
is the same kernel we kexec, any changed addresses here will not work.

>>> So when we tell this core to boot, and it is not in the real ROM startup
>>> loop, it breaks stuff as it jumps to the old kernel's
>>> secondary_startup() even though we gave it the correct address in
>>> OMAP_AUX_CORE_BOOT_1.
> 
> And this is not happening. I think this is what I was seeing earlier,
> but it's not the omap5/dra7 issue.
> 
> What we have is cpu1 returning from previous kernel's omap_do_wfi()
> in the kexec booted kernel's code and that's when things go wrong.
> 

We are the ones sending it to omap_do_wfi(), in omap4_cpu_die() it gets
idled in a loop, it shouldn't be idled after it is shut off, it should
get parked, we should do this like we do in omap5_secondary_startup().

> So if cpu1 was configured for idle for any reason, it will never gets
> to omap5_secondary_startup without the reset currently.
> 
> The reason kexec and suspend/resume mostly works for omap4 without
> cpu1 reset is that we usually enter off mode for cpu1 and the context
> is lost and then we properly go through omap4_secondary_startup. Or
> that's my theory so far for the occasional flakeyness I've been seeing :)
> 
> Any ideas what we should try to check to see if cpu1 is in idle
> mode so we can do the reset if needed?
> 

You can never reset the core, resetting the core is not allowed on HS
devices and so it really doesn't matter what the core is doing. In no
case is reseting the core a valid work-around for not correctly parking
it. We need to fix the omap4_cpu_die() to not let the core go idle if
the return from idle path is the problem.

Andrew

> Regards,
> 
> Tony
> 

WARNING: multiple messages have this Message-ID (diff)
From: afd@ti.com (Andrew F. Davis)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: omap2+: Revert omap-smp.c changes resetting cpu1 during boot
Date: Thu, 16 Feb 2017 10:29:16 -0600	[thread overview]
Message-ID: <fc1e75e8-87ef-59f1-3c8a-cb45f1749e50@ti.com> (raw)
In-Reply-To: <20170216161010.GU21809@atomide.com>

On 02/16/2017 10:10 AM, Tony Lindgren wrote:
> * Tony Lindgren <tony@atomide.com> [170215 14:28]:
>> * Andrew F. Davis <afd@ti.com> [170215 14:14]:
>>> On 02/15/2017 01:12 PM, Tony Lindgren wrote:
>>>> And also the same issue happens doing kexec on beagle-x15 naturally if
>>>> the cpu1 reset is removed.
>>>>
>>>
>>> When a core actually powers up it idles in ROM code waiting for
>>> OMAP_AUX_CORE_BOOT_0 to be set. When we shutdown a core it is not really
>>> powered off, we just let it spin in omap4_cpu_die() or
>>> omap4_secondary_startup() waiting on OMAP_AUX_CORE_BOOT_0, just like if
>>> it were still trapped in ROM after a reset.
> 
> OK so I debugged this a bit more. We have CPU1 in omap_do_wfi()
> as we don't currently have omap5_secondary_startup() or any deeper
> idle mode support beyond retention for omap5 or dra7 in the mainline
> kernel.
> 
>>> The issue with this fake startup idle loop is that, unlike the ROM based
>>> startup idle loop, these do *not* jump to the address we stored in
>>> OMAP_AUX_CORE_BOOT_1, they just make the assumption that they can safely
>>> jump to the kernel startup function.
> 
> This does not seem to be the case here.
> 

Well this is what I am seeing every time, this code only works when it
is the same kernel we kexec, any changed addresses here will not work.

>>> So when we tell this core to boot, and it is not in the real ROM startup
>>> loop, it breaks stuff as it jumps to the old kernel's
>>> secondary_startup() even though we gave it the correct address in
>>> OMAP_AUX_CORE_BOOT_1.
> 
> And this is not happening. I think this is what I was seeing earlier,
> but it's not the omap5/dra7 issue.
> 
> What we have is cpu1 returning from previous kernel's omap_do_wfi()
> in the kexec booted kernel's code and that's when things go wrong.
> 

We are the ones sending it to omap_do_wfi(), in omap4_cpu_die() it gets
idled in a loop, it shouldn't be idled after it is shut off, it should
get parked, we should do this like we do in omap5_secondary_startup().

> So if cpu1 was configured for idle for any reason, it will never gets
> to omap5_secondary_startup without the reset currently.
> 
> The reason kexec and suspend/resume mostly works for omap4 without
> cpu1 reset is that we usually enter off mode for cpu1 and the context
> is lost and then we properly go through omap4_secondary_startup. Or
> that's my theory so far for the occasional flakeyness I've been seeing :)
> 
> Any ideas what we should try to check to see if cpu1 is in idle
> mode so we can do the reset if needed?
> 

You can never reset the core, resetting the core is not allowed on HS
devices and so it really doesn't matter what the core is doing. In no
case is reseting the core a valid work-around for not correctly parking
it. We need to fix the omap4_cpu_die() to not let the core go idle if
the return from idle path is the problem.

Andrew

> Regards,
> 
> Tony
> 

  parent reply	other threads:[~2017-02-16 16:29 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 [this message]
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
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=fc1e75e8-87ef-59f1-3c8a-cb45f1749e50@ti.com \
    --to=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 \
    --cc=tony@atomide.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: 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.