All of lore.kernel.org
 help / color / mirror / Atom feed
From: robherring2@gmail.com (Rob Herring)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v4 2/2] arm: prefer PSCI for SMP bringup
Date: Fri, 29 Mar 2013 14:31:52 -0500	[thread overview]
Message-ID: <5155EC28.8050608@gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.03.1303291349150.1372@syhkavp.arg>

On 03/29/2013 12:53 PM, Nicolas Pitre wrote:
> On Fri, 29 Mar 2013, Stefano Stabellini wrote:
> 
>> On Fri, 29 Mar 2013, Nicolas Pitre wrote:
>>> On Fri, 29 Mar 2013, Stefano Stabellini wrote:
>>>
>>>> If PSCI initializes correctly and PSCI SMP operations are available, use them.
>>>> This is required for SMP support in Dom0 on Xen.
>>>>
>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>> CC: will.deacon at arm.com
>>>> CC: arnd at arndb.de
>>>> CC: marc.zyngier at arm.com
>>>> CC: linux at arm.linux.org.uk
>>>> CC: nico at linaro.org
>>>
>>> I'd suggest you also include in your series the patch I posted earlier 
>>> providing a runtime mdesc->smp_init method as well.
>>
>> OK.
>>
>>
>>> This way the 
>>> priority order would be:
>>>
>>> - If mdesc->smp_init is non null then use that.
>>>
>>> - Otherwise, if PSCI is available then use that.
>>>
>>> - Otherwise use mdesc->smp.
>>>
>>> This way, if the PSCI default has to be overriden (like in the MCPM case 
>>> because it needs to wrap PSCI itself, or to cover Rob's concern) then 
>>> this can be achieved at run time on a per mdesc basis.
>>
>> Actually that's not a bad idea, it could make everybody happy.
>> What about the following, in this precise order:
>>
>> - if a xen hypervisor node is present on device tree, use PSCI;
>> - otherwise if mdesc->smp_init is non null then use it;
>> - otherwise if PSCI is available then use it;
>> - otherwise use mdesc->smp.
>>
>> It's the most practical solution to satisfy everybody's needs.
> 
> Maybe I'm missing something obvious, but why can't xen declare a mdesc 
> of its own?  Given it is going to tweak the DT passed to the kernel 
> anyway that shouldn't be a problem.

Xen does have it's own mdesc. It is (or will be) mach-virt, but that is
only for DomU guests. For Dom0, you still need all the platform specific
code except smp_ops. However, I'm doubtful this would work without other
changes on more complicated platforms like OMAP.

I would say wait to add this until you have platforms that actually need
the first case.

Rob

> 
> That would be more eleguant than adding xen exception hooks in generic 
> code.
> 
> 
> Nicolas
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

WARNING: multiple messages have this Message-ID (diff)
From: Rob Herring <robherring2@gmail.com>
To: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Stefano Stabellini <stefano.stabellini@eu.citrix.com>,
	"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Arnd Bergmann <arnd@arndb.de>,
	"marc.zyngier@arm.com" <marc.zyngier@arm.com>,
	Will Deacon <will.deacon@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v4 2/2] arm: prefer PSCI for SMP bringup
Date: Fri, 29 Mar 2013 14:31:52 -0500	[thread overview]
Message-ID: <5155EC28.8050608@gmail.com> (raw)
In-Reply-To: <alpine.LFD.2.03.1303291349150.1372@syhkavp.arg>

On 03/29/2013 12:53 PM, Nicolas Pitre wrote:
> On Fri, 29 Mar 2013, Stefano Stabellini wrote:
> 
>> On Fri, 29 Mar 2013, Nicolas Pitre wrote:
>>> On Fri, 29 Mar 2013, Stefano Stabellini wrote:
>>>
>>>> If PSCI initializes correctly and PSCI SMP operations are available, use them.
>>>> This is required for SMP support in Dom0 on Xen.
>>>>
>>>> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>>>> CC: will.deacon@arm.com
>>>> CC: arnd@arndb.de
>>>> CC: marc.zyngier@arm.com
>>>> CC: linux@arm.linux.org.uk
>>>> CC: nico@linaro.org
>>>
>>> I'd suggest you also include in your series the patch I posted earlier 
>>> providing a runtime mdesc->smp_init method as well.
>>
>> OK.
>>
>>
>>> This way the 
>>> priority order would be:
>>>
>>> - If mdesc->smp_init is non null then use that.
>>>
>>> - Otherwise, if PSCI is available then use that.
>>>
>>> - Otherwise use mdesc->smp.
>>>
>>> This way, if the PSCI default has to be overriden (like in the MCPM case 
>>> because it needs to wrap PSCI itself, or to cover Rob's concern) then 
>>> this can be achieved at run time on a per mdesc basis.
>>
>> Actually that's not a bad idea, it could make everybody happy.
>> What about the following, in this precise order:
>>
>> - if a xen hypervisor node is present on device tree, use PSCI;
>> - otherwise if mdesc->smp_init is non null then use it;
>> - otherwise if PSCI is available then use it;
>> - otherwise use mdesc->smp.
>>
>> It's the most practical solution to satisfy everybody's needs.
> 
> Maybe I'm missing something obvious, but why can't xen declare a mdesc 
> of its own?  Given it is going to tweak the DT passed to the kernel 
> anyway that shouldn't be a problem.

Xen does have it's own mdesc. It is (or will be) mach-virt, but that is
only for DomU guests. For Dom0, you still need all the platform specific
code except smp_ops. However, I'm doubtful this would work without other
changes on more complicated platforms like OMAP.

I would say wait to add this until you have platforms that actually need
the first case.

Rob

> 
> That would be more eleguant than adding xen exception hooks in generic 
> code.
> 
> 
> Nicolas
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 


  parent reply	other threads:[~2013-03-29 19:31 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-29 16:42 [PATCH v4 2/2] arm: prefer PSCI for SMP bringup Stefano Stabellini
2013-03-29 16:42 ` Stefano Stabellini
2013-03-29 16:42 ` Stefano Stabellini
2013-03-29 17:31 ` Nicolas Pitre
2013-03-29 17:31   ` Nicolas Pitre
2013-03-29 17:38   ` Stefano Stabellini
2013-03-29 17:38     ` Stefano Stabellini
2013-03-29 17:53     ` Nicolas Pitre
2013-03-29 17:53       ` Nicolas Pitre
2013-03-29 18:07       ` Stefano Stabellini
2013-03-29 18:07         ` Stefano Stabellini
2013-03-29 19:31       ` Rob Herring [this message]
2013-03-29 19:31         ` Rob Herring
2013-04-01 14:42         ` Stefano Stabellini
2013-04-01 14:42           ` Stefano Stabellini
2013-04-01 18:20           ` Nicolas Pitre
2013-04-01 18:20             ` Nicolas Pitre
2013-04-02 14:28             ` Stefano Stabellini
2013-04-02 14:28               ` Stefano Stabellini
2013-04-02 16:11               ` Nicolas Pitre
2013-04-02 16:11                 ` Nicolas Pitre
2013-04-09 12:21                 ` Dave Martin
2013-04-09 12:21                   ` Dave Martin
2013-04-09 18:34                   ` Nicolas Pitre
2013-04-09 18:34                     ` Nicolas Pitre
2013-04-09 18:34                     ` Nicolas Pitre
2013-03-29 18:04     ` Nicolas Pitre
2013-03-29 18:04       ` Nicolas Pitre
2013-03-29 18:10       ` Stefano Stabellini
2013-03-29 18:10         ` Stefano Stabellini

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=5155EC28.8050608@gmail.com \
    --to=robherring2@gmail.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 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.