ARM SMP startup question (regarding gic_secondary_init)

[chris]

I was looking at a some of the SMP code in the arm mach types. Inside 
the platform_secondary_init function they all seem to follow the same 
basic procedure:

  //secondary core code//
  gic_secondary_init(0);
  spin_lock(&boot_lock);
  spin_unlock(&boot_lock);

I'm porting to a board myself, so I copied that structure to get 
started. While the secondary processor is in the first bit of code, the 
boot processor is here:

  //boot core code//
  spin_lock(&boot_lock);
  while (time_before(jiffies, timeout));
  /*
   * now the secondary core is starting up let it run its
   * calibrations, then wait for it to finish
   */
  spin_unlock(&boot_lock);

which causes a deadlock because jiffies isn't being incremented, and 
the boot cpu has a lock on boot_lock that the secondary processor needs 
to sync with. Upon closer inspection gic_secondary_init uses the 
following lines of code:

  /*
   * Deal with the banked PPI and SGI interrupts - disable all
   * PPI interrupts, ensure all SGI interrupts are enabled.
   */
  writel(0xffff0000, dist_base + GIC_DIST_ENABLE_CLEAR);
  writel(0x0000ffff, dist_base + GIC_DIST_ENABLE_SET);

The timer for the scheduler seems to be attached via the GIC PPI 
interrupts. I guess it makes sense that we don't need a scheduler while 
a CPU is booting. The problem is that even ignoring platform (or should 
I say mach?) specific code that uses jiffies as timer and timeout code, 
core ARM files rely on it. For example, after disabling timer interrupts 
the secondary core gets to the calibrate_delay function, which also has 
the jiffy loops that never end. If I replace
  writel(0x0000ffff, dist_base + GIC_DIST_ENABLE_SET);
with
  writel(0xffffffff, dist_base + GIC_DIST_ENABLE_SET);
to avoid disabling the timer interrupts the system boots without any 
problems, and both cpus work happily together.

I should note that I am NOT yet using local timers.

This is actually by first post to the LKML, I hope that I've asked the 
right questions and made my points efficiently enough.

I've read a few ARM related posts here, and I'm still not clear on what 
is meant by "pointless churn". I understand that it means code is 
constantly being changed with little to no effect on the kernel, but 
what code are people refering to?

Thanks,
-Chris

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/