All of lore.kernel.org
 help / color / mirror / Atom feed
From: Santosh Shilimkar <santosh.shilimkar@ti.com>
To: Russell King - ARM Linux <linux@arm.linux.org.uk>
Cc: Kevin Hilman <khilman@linaro.org>,
	tony@atomide.com, linux-omap@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus()
Date: Thu, 28 Mar 2013 17:39:51 +0530	[thread overview]
Message-ID: <5154330F.8090908@ti.com> (raw)
In-Reply-To: <20130328120450.GU30923@n2100.arm.linux.org.uk>

On Thursday 28 March 2013 05:34 PM, Russell King - ARM Linux wrote:
> On Thu, Mar 28, 2013 at 03:28:12PM +0530, Santosh Shilimkar wrote:
>> On Thursday 28 March 2013 03:16 PM, Russell King - ARM Linux wrote:
>>> On Thu, Mar 28, 2013 at 12:34:50AM +0530, Santosh Shilimkar wrote:
>>>> On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
>>>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>>>
>>>>>> Move the secondary CPU wakeup prepare code under smp_prepare_cpus(). 
>>>>>
>>>>> Why?
>>>>>
>>>> Because that code belongs to smp_prepare_cpus(). As I said
>>>> in earlier patches, it was remainder of the pen release code
>>>> which was borrowed from ARM code initially.
>>>
>>> What about hotplug after the system is suspended?  Is this setup
>>> preserved by the secure ROM?
>>>
>>> If not, it really needs to be part of the CPU bringup, not the
>>> boot-time-only preparation code.
>>>
>> Its already the case. Hotplug CPU restarts just like CPU bring-up.
>> Initial code, hotplug cpu and last cpu(suspend) were taking identical
>> path for the suspend wakeup. Later you suggested after the discussion
>> that hotplug CPU state need not be saved and can be restarted just like
>> the CPU bring-up path.
>>
>> So the current code follows above.
> 
> smp_prepare_cpus() doesn't get run apart from at initial boot.
> 
> So, I repeat my question: what restores OMAP_AUX_CORE_BOOT_1 after
> context loss?
> 
Sorry I missed your point. OMAP_AUX_CORE_BOOT_* registers
are maintained across power transitions.

Regards,
Santosh

WARNING: multiple messages have this Message-ID (diff)
From: santosh.shilimkar@ti.com (Santosh Shilimkar)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus()
Date: Thu, 28 Mar 2013 17:39:51 +0530	[thread overview]
Message-ID: <5154330F.8090908@ti.com> (raw)
In-Reply-To: <20130328120450.GU30923@n2100.arm.linux.org.uk>

On Thursday 28 March 2013 05:34 PM, Russell King - ARM Linux wrote:
> On Thu, Mar 28, 2013 at 03:28:12PM +0530, Santosh Shilimkar wrote:
>> On Thursday 28 March 2013 03:16 PM, Russell King - ARM Linux wrote:
>>> On Thu, Mar 28, 2013 at 12:34:50AM +0530, Santosh Shilimkar wrote:
>>>> On Thursday 28 March 2013 12:15 AM, Kevin Hilman wrote:
>>>>> Santosh Shilimkar <santosh.shilimkar@ti.com> writes:
>>>>>
>>>>>> Move the secondary CPU wakeup prepare code under smp_prepare_cpus(). 
>>>>>
>>>>> Why?
>>>>>
>>>> Because that code belongs to smp_prepare_cpus(). As I said
>>>> in earlier patches, it was remainder of the pen release code
>>>> which was borrowed from ARM code initially.
>>>
>>> What about hotplug after the system is suspended?  Is this setup
>>> preserved by the secure ROM?
>>>
>>> If not, it really needs to be part of the CPU bringup, not the
>>> boot-time-only preparation code.
>>>
>> Its already the case. Hotplug CPU restarts just like CPU bring-up.
>> Initial code, hotplug cpu and last cpu(suspend) were taking identical
>> path for the suspend wakeup. Later you suggested after the discussion
>> that hotplug CPU state need not be saved and can be restarted just like
>> the CPU bring-up path.
>>
>> So the current code follows above.
> 
> smp_prepare_cpus() doesn't get run apart from at initial boot.
> 
> So, I repeat my question: what restores OMAP_AUX_CORE_BOOT_1 after
> context loss?
> 
Sorry I missed your point. OMAP_AUX_CORE_BOOT_* registers
are maintained across power transitions.

Regards,
Santosh

  reply	other threads:[~2013-03-28 12:08 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-20 15:18 [PATCH 0/9] ARM: OMAP: Static deps, fiq, omap-smp cleanup Santosh Shilimkar
2013-02-20 15:18 ` Santosh Shilimkar
2013-02-20 15:18 ` [PATCH 1/9] ARM: OMAP4+: Use common scratchpad SAR RAM offsets for all architectures Santosh Shilimkar
2013-02-20 15:18   ` Santosh Shilimkar
2013-03-27 18:41   ` Kevin Hilman
2013-03-27 18:41     ` Kevin Hilman
2013-03-27 20:49     ` Santosh Shilimkar
2013-03-27 20:49       ` Santosh Shilimkar
2013-03-27 20:49       ` Tony Lindgren
2013-03-27 20:49         ` Tony Lindgren
2013-03-27 20:52         ` Santosh Shilimkar
2013-03-27 20:52           ` Santosh Shilimkar
2013-03-28  7:32           ` Santosh Shilimkar
2013-03-28  7:32             ` Santosh Shilimkar
2013-02-20 15:18 ` [PATCH 2/9] ARM: OMAP1: PM: Remove bogus fiq_[enable/disable] tuple Santosh Shilimkar
2013-02-20 15:18   ` Santosh Shilimkar
2013-02-20 16:09   ` Tony Lindgren
2013-02-20 16:09     ` Tony Lindgren
2013-02-20 16:14     ` Santosh Shilimkar
2013-02-20 16:14       ` Santosh Shilimkar
2013-02-20 15:18 ` [PATCH 3/9] ARM: OMAP2+: " Santosh Shilimkar
2013-02-20 15:18   ` Santosh Shilimkar
2013-03-27 18:36   ` Kevin Hilman
2013-03-27 18:36     ` Kevin Hilman
2013-03-27 19:02     ` Santosh Shilimkar
2013-03-27 19:02       ` Santosh Shilimkar
2013-03-28  7:37       ` Santosh Shilimkar
2013-03-28  7:37         ` Santosh Shilimkar
2013-02-20 15:18 ` [PATCH 4/9] ARM: OMAP4+: Remove the un-necessary cache flush from hotplug code Santosh Shilimkar
2013-02-20 15:18   ` Santosh Shilimkar
2013-03-27 18:43   ` Kevin Hilman
2013-03-27 18:43     ` Kevin Hilman
2013-03-27 20:47     ` Santosh Shilimkar
2013-03-27 20:47       ` Santosh Shilimkar
2013-03-28  7:29       ` Santosh Shilimkar
2013-03-28  7:29         ` Santosh Shilimkar
2013-02-20 15:18 ` [PATCH 5/9] ARM: OMAP4+: Remove un-necessary cacheflush in secondary CPU boot path Santosh Shilimkar
2013-02-20 15:18   ` Santosh Shilimkar
2013-02-20 15:18 ` [PATCH 6/9] ARM: OMAP4+: Remove out of placed smp_wmb() in secondary wakeup code Santosh Shilimkar
2013-02-20 15:18   ` Santosh Shilimkar
2013-02-21 12:55   ` Sergei Shtylyov
2013-02-21 12:55     ` Sergei Shtylyov
2013-02-21 12:59     ` Santosh Shilimkar
2013-02-21 12:59       ` Santosh Shilimkar
2013-02-20 15:18 ` [PATCH 7/9] ARM: OMAP4+: Move the CPU wakeup prepare code under smp_prepare_cpus() Santosh Shilimkar
2013-02-20 15:18   ` Santosh Shilimkar
2013-03-27 18:45   ` Kevin Hilman
2013-03-27 18:45     ` Kevin Hilman
2013-03-27 19:04     ` Santosh Shilimkar
2013-03-27 19:04       ` Santosh Shilimkar
2013-03-27 19:54       ` Kevin Hilman
2013-03-27 19:54         ` Kevin Hilman
2013-03-27 20:50         ` Santosh Shilimkar
2013-03-27 20:50           ` Santosh Shilimkar
2013-03-28  7:35           ` Santosh Shilimkar
2013-03-28  7:35             ` Santosh Shilimkar
2013-03-28  9:46       ` Russell King - ARM Linux
2013-03-28  9:46         ` Russell King - ARM Linux
2013-03-28  9:58         ` Santosh Shilimkar
2013-03-28  9:58           ` Santosh Shilimkar
2013-03-28 12:04           ` Russell King - ARM Linux
2013-03-28 12:04             ` Russell King - ARM Linux
2013-03-28 12:09             ` Santosh Shilimkar [this message]
2013-03-28 12:09               ` Santosh Shilimkar
2013-02-20 15:18 ` [PATCH 8/9] ARM: OMAP4: PM: Remove L4 wakeup depedency with MPU since errata fix exist now Santosh Shilimkar
2013-02-20 15:18   ` Santosh Shilimkar
2013-03-27 18:46   ` Kevin Hilman
2013-03-27 18:46     ` Kevin Hilman
2013-03-27 19:01     ` Peter Korsgaard
2013-03-27 19:01       ` Peter Korsgaard
2013-02-20 15:18 ` [PATCH 9/9] ARM: OMAP4: PM: Now remove L4 per clockdomain static depedency with MPU Santosh Shilimkar
2013-02-20 15:18   ` Santosh Shilimkar
2013-03-27 18:46   ` Kevin Hilman
2013-03-27 18:46     ` Kevin Hilman

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=5154330F.8090908@ti.com \
    --to=santosh.shilimkar@ti.com \
    --cc=khilman@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --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.