[PATCH] Fix ppc32 smp build.

Fix PPC32 SMP build -- instead of setting the now non-existent
smp_tb_synchronized when the timebases are synchronised, we clear the
CPU_FTR_USE_TB bit when they're not. Does this look sane, and did I miss
cases where they're not synchronised?

Signed-off-by: David Woodhouse <dwmw2@infradead.org>

diff --git a/arch/powerpc/platforms/powermac/smp.c b/arch/powerpc/platforms/powermac/smp.c
--- a/arch/powerpc/platforms/powermac/smp.c
+++ b/arch/powerpc/platforms/powermac/smp.c

@@ -363,8 +363,6 @@ static void __init psurge_dual_sync_tb(i
 
 	/* now interrupt the secondary, starting both TBs */
 	psurge_set_ipi(1);
-
-	smp_tb_synchronized = 1;
 }
 
 static struct irqaction psurge_irqaction = {

@@ -396,6 +394,8 @@ static void __init smp_psurge_setup_cpu(
 
 	if (psurge_type == PSURGE_DUAL)
 		psurge_dual_sync_tb(cpu_nr);
+	else
+		cur_cpu_spec->cpu_features &= ~CPU_FTR_USE_TB;
 }
 
 void __init smp_psurge_take_timebase(void)

@@ -624,10 +624,10 @@ void smp_core99_give_timebase(void)
 	/* wait for the secondary to have taken it */
 	for (t = 100000; t > 0 && sec_tb_reset; --t)
 		udelay(10);
-	if (sec_tb_reset)
+	if (sec_tb_reset) {
 		printk(KERN_WARNING "Timeout waiting sync(2) on second CPU\n");
-	else
-		smp_tb_synchronized = 1;
+		cur_cpu_spec->cpu_features &= ~CPU_FTR_USE_TB;
+	}
 
 	/* Now, restart the timebase by leaving the GPIO to an open collector */
        	pmac_call_feature(PMAC_FTR_WRITE_GPIO, NULL, core99_tb_gpio, 0);

-- 
dwmw2

David Woodhouse writes:

Fix PPC32 SMP build -- instead of setting the now non-existent
smp_tb_synchronized when the timebases are synchronised, we clear the
CPU_FTR_USE_TB bit when they're not. Does this look sane, and did I miss
cases where they're not synchronised?

I don't like clearing the USE_TB bit, since the alternative is to use
the RTC (a la 601), and most cpus will take an illegal instruction
exception if you try to do that.

If we really can get unsynchronized timebases still, then I suppose we
need to bring back the smp_tb_synchronized variable, but I was
assuming that we could get the timebases synchronized one way or
another.  If the to-and-fro involved in synchronizing the timebases
doesn't work then there is an awful lot of other stuff that is going
to fall on its face too...  Maybe the solution is just to panic if we
can't get the other cpu to talk to us enough to synchronize the
timebases.

Paul.

On Sun, 2005-11-06 at 21:51 +1100, Paul Mackerras wrote:

If we really can get unsynchronized timebases still, then I suppose we
need to bring back the smp_tb_synchronized variable, 

We make no attempt to sync the timebases on quad powersurge, as far as I
can tell -- and we never set smp_tb_synchronized there.

-- 
dwmw2

On Mon, 2005-11-07 at 09:47 +0000, David Woodhouse wrote:

On Sun, 2005-11-06 at 21:51 +1100, Paul Mackerras wrote:

quoted

If we really can get unsynchronized timebases still, then I suppose we
need to bring back the smp_tb_synchronized variable, 

We make no attempt to sync the timebases on quad powersurge, as far as I
can tell -- and we never set smp_tb_synchronized there.

We don't even use the software sync ? Hrm... actually, I think the
software sync was designed for 2 CPUs only.

Now, go find the one user that had a quad powersurge :)

Ben.

David Woodhouse writes:

We make no attempt to sync the timebases on quad powersurge, as far as I
can tell -- and we never set smp_tb_synchronized there.

Hmmm.  Does anyone still have one of those?  I have a dual but not a
quad.

In any case we can use the generic tbsync code (smp-tbsync.c) which
should work on any machine, and doesn't require any hardware support.

Paul.

On 7-Nov-05, at 6:29 PM, Paul Mackerras wrote:

David Woodhouse writes:

quoted

We make no attempt to sync the timebases on quad powersurge, as far as I
can tell -- and we never set smp_tb_synchronized there.

Hmmm.  Does anyone still have one of those?  I have a dual but not a
quad.

I have one that is collecting dust currently.  I'd be willing to get it to someone that can work with it for the cost of shipping (not cheap, it's heavy).  Even has an RJ45 jack on the CPU card -- most I've seen don't.  Or if there's someone in the Toronto area that wants to pick it up is fine too, as long as it goes to a good home to help kernel development :)

Mark