[PATCH v2 1/7] powerpc/85xx: re-enable timebase sync disabled by KEXEC patch

Scott Wood scottwood at freescale.com
Sat Nov 19 05:01:14 EST 2011


On Fri, Nov 18, 2011 at 08:35:02AM -0600, Kumar Gala wrote:
> 
> On Nov 16, 2011, at 12:42 PM, Scott Wood wrote:
> 
> > On 11/16/2011 03:55 AM, Zhao Chenhui wrote:
> >> From: Li Yang <leoli at freescale.com>
> >> 
> >> The timebase sync is not only necessary when using KEXEC. It should also
> >> be used by normal boot up and cpu hotplug. Remove the ifdef added by
> >> the KEXEC patch.
> > 
> > Again, no it should not be used by normal boot up (whether KEXEC support
> > is enabled or not).  We should only do timebase sync when we actually
> > need to (when we've actually just reset a core), and we should do it the
> > way U-Boot does rather than with smp-tbsync.c.
> 
> 
> How can we do u-boot bases timebase sync after the system us up and
> running?  For example would we losing some ticks of time in the case
> that one core is up and we bring a second core online?

Yes, we'll lose a small handful of ticks relative to wall clock time --
but it'll be the same loss on all cores.  It's better than possibly
having the timebase be imperfectly synchronized, and should complete more
quickly.

This is only during intrusive events such as kexec or deep sleep (we only
need to reset the core for jog on mpc8536 which has only one core). 
During deep sleep all cores' timebases will be stopped.  Kexec is
resetting the kernel; it's not going to care what the old timebase was,
and should resync from RTC.

Even if we end up using this for some future power management mode where
we take down some CPUs to the point their timebase stops, but never take
down others, the time loss should be negligible (for comparison, what's
the error tolerance on the crystal frequency?) and acceptable for what is
still a fairly intrusive and rare event.

-Scott



More information about the Linuxppc-dev mailing list