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
chenhui.z...@freescale.com 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
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 only
...@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:
The bootloader have done a timebase sync. If we do not need KEXEC or
HOTPLUG_CPU
On Tue, Jun 26, 2012 at 5:25 AM, Zhao Chenhui
chenhui.z...@freescale.com 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.
On 06/29/2012 10:39 AM, Tabi Timur-B04825 wrote:
On Tue, Jun 26, 2012 at 5:25 AM, Zhao Chenhui
chenhui.z...@freescale.com wrote:
+static void mpc85xx_give_timebase(void)
+{
+ unsigned long flags;
+
+ local_irq_save(flags);
+
+ while (!tb_req)
+ barrier();
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 CPU would
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
node doesn't help
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 ever
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 the timebase
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 apply to
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.
Only
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 unconditional ?
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 HOTPLUG_CPU is enabled
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: Zhao Chenhui chenhui.z...@freescale.com
Signed-off-by: Li Yang
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: Zhao
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, such as
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 --
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: Zhao
20 matches
Mail list logo
