On Fri, 29 Mar 2013, Rob Herring wrote:
> On 03/29/2013 08:22 AM, Stefano Stabellini wrote:
> > On Thu, 28 Mar 2013, Rob Herring wrote:
> >> On 03/28/2013 10:39 AM, Nicolas Pitre wrote:
> >>> On Thu, 28 Mar 2013, Rob Herring wrote:
> >>>
> On 03/28/2013 09:51 AM, Nicolas Pitre wrote:
> > O
On 03/29/2013 08:22 AM, Stefano Stabellini wrote:
> On Thu, 28 Mar 2013, Rob Herring wrote:
>> On 03/28/2013 10:39 AM, Nicolas Pitre wrote:
>>> On Thu, 28 Mar 2013, Rob Herring wrote:
>>>
On 03/28/2013 09:51 AM, Nicolas Pitre wrote:
> On Thu, 28 Mar 2013, Stefano Stabellini wrote:
>
>>
On Thu, 28 Mar 2013, Rob Herring wrote:
> On 03/28/2013 10:39 AM, Nicolas Pitre wrote:
> > On Thu, 28 Mar 2013, Rob Herring wrote:
> >
> >> On 03/28/2013 09:51 AM, Nicolas Pitre wrote:
> >>> On Thu, 28 Mar 2013, Stefano Stabellini wrote:
> >>>
> - the interface to bring up secondary cpus is d
On 03/28/2013 10:39 AM, Nicolas Pitre wrote:
> On Thu, 28 Mar 2013, Rob Herring wrote:
>
>> On 03/28/2013 09:51 AM, Nicolas Pitre wrote:
>>> On Thu, 28 Mar 2013, Stefano Stabellini wrote:
>>>
- the interface to bring up secondary cpus is different and based on
PSCI, in fact Xen is going
On Thu, 28 Mar 2013, Will Deacon wrote:
> On Thu, Mar 28, 2013 at 03:39:42PM +, Nicolas Pitre wrote:
> > On Thu, 28 Mar 2013, Rob Herring wrote:
> >
> > > On 03/28/2013 09:51 AM, Nicolas Pitre wrote:
> > > > On Thu, 28 Mar 2013, Stefano Stabellini wrote:
> > > >
> > > >> - the interface to br
On Thu, 28 Mar 2013, Will Deacon wrote:
> On Thu, Mar 28, 2013 at 03:39:42PM +, Nicolas Pitre wrote:
> > On Thu, 28 Mar 2013, Rob Herring wrote:
> >
> > > On 03/28/2013 09:51 AM, Nicolas Pitre wrote:
> > > > On Thu, 28 Mar 2013, Stefano Stabellini wrote:
> > > >
> > > >> - the interface to b
On Thu, Mar 28, 2013 at 03:39:42PM +, Nicolas Pitre wrote:
> On Thu, 28 Mar 2013, Rob Herring wrote:
>
> > On 03/28/2013 09:51 AM, Nicolas Pitre wrote:
> > > On Thu, 28 Mar 2013, Stefano Stabellini wrote:
> > >
> > >> - the interface to bring up secondary cpus is different and based on
> > >>
On Thu, 28 Mar 2013, Rob Herring wrote:
> On 03/28/2013 09:51 AM, Nicolas Pitre wrote:
> > On Thu, 28 Mar 2013, Stefano Stabellini wrote:
> >
> >> - the interface to bring up secondary cpus is different and based on
> >> PSCI, in fact Xen is going to add a PSCI node to the device tree so that
> >
On Thu, 28 Mar 2013, Rob Herring wrote:
> On 03/28/2013 09:51 AM, Nicolas Pitre wrote:
> > On Thu, 28 Mar 2013, Stefano Stabellini wrote:
> >
> >> - the interface to bring up secondary cpus is different and based on
> >> PSCI, in fact Xen is going to add a PSCI node to the device tree so that
> >>
On 03/28/2013 09:51 AM, Nicolas Pitre wrote:
> On Thu, 28 Mar 2013, Stefano Stabellini wrote:
>
>> - the interface to bring up secondary cpus is different and based on
>> PSCI, in fact Xen is going to add a PSCI node to the device tree so that
>> Dom0 can use it.
>>
>> Oh wait, Dom0 is not going t
On Thu, 28 Mar 2013, Stefano Stabellini wrote:
> - the interface to bring up secondary cpus is different and based on
> PSCI, in fact Xen is going to add a PSCI node to the device tree so that
> Dom0 can use it.
>
> Oh wait, Dom0 is not going to use the PSCI interface even if the node is
> presen
On Wed, 27 Mar 2013, Will Deacon wrote:
> On Wed, Mar 27, 2013 at 04:23:15PM +, Stefano Stabellini wrote:
> > OK, let's see if I can make this acceptable to you.
> >
> >
> > Would you agree on a patch that moves virt_smp_ops out of mach-virt and
> > renames them to psci_smp_ops (maybe to arch
On Wednesday 27 March 2013, Will Deacon wrote:
> The interface is standard. The functions have well-defined headers and can
> be called in the same way between implementations. The difference is in the
> semantics of the parameters. For example:
>
> int cpu_off(u32 power_state);
I think that is
On 03/27/2013 01:12 PM, Will Deacon wrote:
> On Wed, Mar 27, 2013 at 05:50:51PM +, Arnd Bergmann wrote:
>> On Wednesday 27 March 2013, Will Deacon wrote:
>>> The channel is common, sure, but I wouldn't expect the semantics of each
>>> call to be identical between firmware implementations (going
On Wed, 27 Mar 2013, Nicolas Pitre wrote:
> On Wed, 27 Mar 2013, Stefano Stabellini wrote:
>
> > On Wed, 27 Mar 2013, Rob Herring wrote:
> > > On 03/27/2013 11:23 AM, Stefano Stabellini wrote:
> > > > Would you agree on a patch that moves virt_smp_ops out of mach-virt and
> > > > renames them to p
On Wed, 27 Mar 2013, Arnd Bergmann wrote:
> On Wednesday 27 March 2013, Rob Herring wrote:
> > No, I was thinking in the case of Xen and mach-virt, you would not set
> > mdesc->smp. So you would have something like this:
> >
> > if (mdesc->smp)
> > smp_set_ops(mdesc->smp);
> > else
> >
On Wed, Mar 27, 2013 at 05:50:51PM +, Arnd Bergmann wrote:
> On Wednesday 27 March 2013, Will Deacon wrote:
> > The channel is common, sure, but I wouldn't expect the semantics of each
> > call to be identical between firmware implementations (going back to my
> > previous examples of CPU IDs a
On Wednesday 27 March 2013, Rob Herring wrote:
> No, I was thinking in the case of Xen and mach-virt, you would not set
> mdesc->smp. So you would have something like this:
>
> if (mdesc->smp)
> smp_set_ops(mdesc->smp);
> else
> smp_set_ops(&psci_smp_ops);
The case that Stefano is
On Wednesday 27 March 2013, Will Deacon wrote:
> The channel is common, sure, but I wouldn't expect the semantics of each
> call to be identical between firmware implementations (going back to my
> previous examples of CPU IDs and implementation-defined state parameters).
>
> If a platform happens
On 03/27/2013 12:10 PM, Stefano Stabellini wrote:
> On Wed, 27 Mar 2013, Rob Herring wrote:
>> On 03/27/2013 11:23 AM, Stefano Stabellini wrote:
>>> Would you agree on a patch that moves virt_smp_ops out of mach-virt and
>>> renames them to psci_smp_ops (maybe to arch/arm/kernel/psci_smp_ops.c)?
>>
On Wed, 27 Mar 2013, Stefano Stabellini wrote:
> On Wed, 27 Mar 2013, Rob Herring wrote:
> > On 03/27/2013 11:23 AM, Stefano Stabellini wrote:
> > > Would you agree on a patch that moves virt_smp_ops out of mach-virt and
> > > renames them to psci_smp_ops (maybe to arch/arm/kernel/psci_smp_ops.c)?
On Wed, Mar 27, 2013 at 04:23:15PM +, Stefano Stabellini wrote:
> OK, let's see if I can make this acceptable to you.
>
>
> Would you agree on a patch that moves virt_smp_ops out of mach-virt and
> renames them to psci_smp_ops (maybe to arch/arm/kernel/psci_smp_ops.c)?
Moving the code out of
On Wed, 27 Mar 2013, Rob Herring wrote:
> On 03/27/2013 11:23 AM, Stefano Stabellini wrote:
> > Would you agree on a patch that moves virt_smp_ops out of mach-virt and
> > renames them to psci_smp_ops (maybe to arch/arm/kernel/psci_smp_ops.c)?
> >
> > Would you agree on initializing psci from setu
On Wed, Mar 27, 2013 at 04:33:58PM +, Rob Herring wrote:
> On 03/27/2013 08:38 AM, Will Deacon wrote:
> > On Wed, Mar 27, 2013 at 12:50:39PM +, Stefano Stabellini wrote:
> >> +struct smp_operations __initdata psci_smp_ops = {
> >> + .smp_init_cpus = psci_smp_init_cpus,
> >> + .sm
On 03/27/2013 11:23 AM, Stefano Stabellini wrote:
> On Wed, 27 Mar 2013, Will Deacon wrote:
>> Hi Stefano,
>>
>> On Wed, Mar 27, 2013 at 12:50:39PM +, Stefano Stabellini wrote:
>>> Check for the presence of PSCI before setting smp_ops, use PSCI if it is
>>> available.
>>>
>>> This is useful bec
On 03/27/2013 08:38 AM, Will Deacon wrote:
> Hi Stefano,
>
> On Wed, Mar 27, 2013 at 12:50:39PM +, Stefano Stabellini wrote:
>> Check for the presence of PSCI before setting smp_ops, use PSCI if it is
>> available.
>>
>> This is useful because at least when running on Xen it's possible to have
On Wed, 27 Mar 2013, Will Deacon wrote:
> Hi Stefano,
>
> On Wed, Mar 27, 2013 at 12:50:39PM +, Stefano Stabellini wrote:
> > Check for the presence of PSCI before setting smp_ops, use PSCI if it is
> > available.
> >
> > This is useful because at least when running on Xen it's possible to ha
On 03/27/2013 08:35 AM, Marc Zyngier wrote:
> On 27/03/13 12:50, Stefano Stabellini wrote:
>> Check for the presence of PSCI before setting smp_ops, use PSCI if it is
>> available.
>>
>> This is useful because at least when running on Xen it's possible to have a
>> PSCI node for example on a Versat
On 03/27/2013 07:50 AM, Stefano Stabellini wrote:
> Check for the presence of PSCI before setting smp_ops, use PSCI if it is
> available.
>
> This is useful because at least when running on Xen it's possible to have a
> PSCI node for example on a Versatile Express or an Exynos5 machine. In these
>
Hi Stefano,
On Wed, Mar 27, 2013 at 12:50:39PM +, Stefano Stabellini wrote:
> Check for the presence of PSCI before setting smp_ops, use PSCI if it is
> available.
>
> This is useful because at least when running on Xen it's possible to have a
> PSCI node for example on a Versatile Express or
On 27/03/13 12:50, Stefano Stabellini wrote:
> Check for the presence of PSCI before setting smp_ops, use PSCI if it is
> available.
>
> This is useful because at least when running on Xen it's possible to have a
> PSCI node for example on a Versatile Express or an Exynos5 machine. In these
> case
31 matches
Mail list logo
