On Jun 26, 2012, at 5:25 AM, Zhao Chenhui wrote:
> Do hardware timebase sync. Firstly, stop all timebases, and transfer
> the timebase value of the boot core to the other core. Finally,
> start all timebases.
>
> Only apply to dual-core chips, such as MPC8572, P2020, etc.
>
> Signed-off-by: Zha
On 06/26/2012 09:03 AM, Kumar Gala wrote:
>
> On Jun 26, 2012, at 5:25 AM, Zhao Chenhui wrote:
>
>> Do hardware timebase sync. Firstly, stop all timebases, and transfer
>> the timebase value of the boot core to the other core. Finally,
>> start all timebases.
>>
>> Only apply to dual-core chips,
On Tue, 2012-06-26 at 16:45 -0500, Scott Wood wrote:
> Some parts are due to corenet versus non-corenet, such as the actual
> register you write to to disable/enable the timebase.
>
> There's also a two-core assumption in the synchronization code which
> I've complained about multiple times -- al
On Tue, 2012-06-26 at 18:25 +0800, Zhao Chenhui wrote:
> Do hardware timebase sync. Firstly, stop all timebases, and transfer
> the timebase value of the boot core to the other core. Finally,
> start all timebases.
>
> Only apply to dual-core chips, such as MPC8572, P2020, etc.
>
> Signed-off-by:
On Tue, Jun 26, 2012 at 09:03:42AM -0500, Kumar Gala wrote:
>
> On Jun 26, 2012, at 5:25 AM, Zhao Chenhui wrote:
>
> > Do hardware timebase sync. Firstly, stop all timebases, and transfer
> > the timebase value of the boot core to the other core. Finally,
> > start all timebases.
> >
> > Only ap
On Wed, Jun 27, 2012 at 08:10:34AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2012-06-26 at 18:25 +0800, Zhao Chenhui wrote:
> > Do hardware timebase sync. Firstly, stop all timebases, and transfer
> > the timebase value of the boot core to the other core. Finally,
> > start all timebases.
> >
On Wed, 2012-06-27 at 18:21 +0800, Zhao Chenhui wrote:
> > What's that CONFIG option for ?
> >
> > Cheers,
> > Ben.
>
> This option is to guard the timebase sync routines. It is selected
> when KEXEC or HOTPLUG_CPU is enabled on Freescale Book-E platforms.
Any reason not to just make it uncondit
On Wed, Jun 27, 2012 at 09:48:52PM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2012-06-27 at 18:21 +0800, Zhao Chenhui wrote:
> > > What's that CONFIG option for ?
> > >
> > > Cheers,
> > > Ben.
> >
> > This option is to guard the timebase sync routines. It is selected
> > when KEXEC or HOTPLU
On Thu, 2012-06-28 at 11:38 +0800, Zhao Chenhui wrote:
>
>
> The bootloader have done a timebase sync. If we do not need KEXEC or
> HOTPLUG_CPU feature, it is unnecessary to do it again at boot time of
> kernel. I only compile the timebase sync routines
> when users enable KEXEC or HOTPLUG_CPU.
On Jun 28, 2012, at 5:50 AM, Benjamin Herrenschmidt wrote:
> On Thu, 2012-06-28 at 11:38 +0800, Zhao Chenhui wrote:
>>
>>
>> The bootloader have done a timebase sync. If we do not need KEXEC or
>> HOTPLUG_CPU feature, it is unnecessary to do it again at boot time of
>> kernel. I only compile th
s.org list;
> linux-ker...@vger.kernel.org list
> Subject: Re: [PATCH v6 1/5] powerpc/85xx: implement hardware timebase sync
>
>
> On Jun 28, 2012, at 5:50 AM, Benjamin Herrenschmidt wrote:
>
> > On Thu, 2012-06-28 at 11:38 +0800, Zhao Chenhui wrote:
> >>
> >>
On Tue, Jun 26, 2012 at 5:25 AM, Zhao Chenhui
wrote:
> Do hardware timebase sync. Firstly, stop all timebases, and transfer
> the timebase value of the boot core to the other core. Finally,
> start all timebases.
>
> Only apply to dual-core chips, such as MPC8572, P2020, etc.
>
> Signed-off-by: Zh
On 06/29/2012 10:39 AM, Tabi Timur-B04825 wrote:
> On Tue, Jun 26, 2012 at 5:25 AM, Zhao Chenhui
> wrote:
>> +static void mpc85xx_give_timebase(void)
>> +{
>> + unsigned long flags;
>> +
>> + local_irq_save(flags);
>> +
>> + while (!tb_req)
>> + barrier();
>
> I th
Scott Wood wrote:
>> I wonder if it's possible to dynamically generate the compatible
>> string by using the SOC name?
>
> Where are you going to get the SoC name from?
Well, that is why I said "I wonder". I'm disappointed that the "cpus"
node doesn't help much. You'd think the name of the CP
On 06/29/2012 11:04 AM, Timur Tabi wrote:
> Scott Wood wrote:
>
>>> I wonder if it's possible to dynamically generate the compatible
>>> string by using the SOC name?
>>
>> Where are you going to get the SoC name from?
>
> Well, that is why I said "I wonder". I'm disappointed that the "cpus"
>
Scott Wood wrote:
> Why is this different from anywhere else where we have a list of
> compatibles to match, often based on various SoCs? Note that we
> explicitly want to match only certain SoCs here.
I was just hoping to find a way to avoid an ever increasing list of
compatible strings. Other
On 06/29/2012 11:12 AM, Timur Tabi wrote:
> Scott Wood wrote:
>> Why is this different from anywhere else where we have a list of
>> compatibles to match, often based on various SoCs? Note that we
>> explicitly want to match only certain SoCs here.
>
> I was just hoping to find a way to avoid an
On Fri, Jun 29, 2012 at 10:39:24AM -0500, Tabi Timur-B04825 wrote:
> On Tue, Jun 26, 2012 at 5:25 AM, Zhao Chenhui
> wrote:
> > Do hardware timebase sync. Firstly, stop all timebases, and transfer
> > the timebase value of the boot core to the other core. Finally,
> > start all timebases.
> >
> >
On Thu, Jun 28, 2012 at 08:50:51PM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2012-06-28 at 11:38 +0800, Zhao Chenhui wrote:
> >
> >
> > The bootloader have done a timebase sync. If we do not need KEXEC or
> > HOTPLUG_CPU feature, it is unnecessary to do it again at boot time of
> > kernel. I
19 matches
Mail list logo
