cvs commit: src/sys/sparc64/include clock.h cpufunc.h pcpu.h smp.h tick.h ver.h src/sys/sparc64/sparc64 clock.c genassym.c locore.S machdep.c mp_locore.S mp_machdep.c tick.c

[Marius Strobl]

marius      2008-09-03 17:39:19 UTC

  FreeBSD src repository

  Modified files:
    sys/sparc64/include  clock.h cpufunc.h pcpu.h smp.h tick.h 
                         ver.h 
    sys/sparc64/sparc64  clock.c genassym.c locore.S machdep.c 
                         mp_locore.S mp_machdep.c tick.c 
  Log:
  SVN rev 182730 on 2008-09-03 17:39:19Z by marius
  
  - USIII-based machines can consist of CPUs running at different
    frequencies (and having different cache sizes) so use the STICK
    (System TICK) timer, which was introduced due to this and is
    driven by the same frequency across all CPUs, instead of the
    TICK timer, whose frequency varies with the CPU clock, to drive
    hardclock. We try to use the STICK counter with all CPUs that are
    USIII or beyond, even when not necessary due to identical CPUs,
    as we can can also avoid the workaround for the BlackBird erratum
    #1 there. Unfortunately, using the STICK counter currently causes
    a hang with USIIIi MP machines for reasons unknown, so we still
    use the TICK timer there (which is okay as they can only consist
    of identical CPUs).
  - Given that we only (try to) synchronize the (S)TICK timers of APs
    with the BSP during startup, we could end up spinning forever in
    DELAY(9) if that function is migrated to another CPU while we're
    spinning due to clock drift afterwards, so pin to the CPU in order
    to avoid migration. Unfortunately, pinning doesn't work at the
    point DELAY(9) is required by the low-level console drivers, yet,
    so switch to a function pointer, which is updated accordingly, for
    implementing DELAY(9). For USIII and beyond, this would also allow
    to easily use the STICK counter instead of the TICK one here,
    there's no benefit in doing so however.
    While at it, use cpu_spinwait(9) for spinning in the delay-
    functions. This currently is a NOP though.
  - Don't set the TICK timer of the BSP to 0 during at startup as
    there's no need to do so.
  - Implement cpu_est_clockrate().
  - Unfortunately, USIIIi-based machines don't provide a timecounter
    device besides the STICK and TICK counters (well, in theory the
    Tomatillo bridges have a performance counter that can be (ab)used
    as timecounter by configuring it to count bus cycles, though unlike
    the performance counter of Schizo bridges, the Tomatillo one is
    broken and counts Sun knows what in this mode). This means that
    we've to use a (S)TICK counter for timecounting, which has the old
    problem of not being in sync across CPUs, so provide an additional
    timecounter function which binds itself to the BSP but has an
    adequate low priority.
  
  Revision  Changes    Path
  1.9       +5 -3      src/sys/sparc64/include/clock.h
  1.24      +9 -0      src/sys/sparc64/include/cpufunc.h
  1.26      +1 -0      src/sys/sparc64/include/pcpu.h
  1.24      +5 -3      src/sys/sparc64/include/smp.h
  1.5       +1 -1      src/sys/sparc64/include/tick.h
  1.7       +4 -0      src/sys/sparc64/include/ver.h
  1.13      +42 -9     src/sys/sparc64/sparc64/clock.c
  1.72      +3 -2      src/sys/sparc64/sparc64/genassym.c
  1.25      +0 -1      src/sys/sparc64/sparc64/locore.S
  1.144     +39 -44    src/sys/sparc64/sparc64/machdep.c
  1.10      +25 -9     src/sys/sparc64/sparc64/mp_locore.S
  1.44      +11 -3     src/sys/sparc64/sparc64/mp_machdep.c
  1.24      +184 -52   src/sys/sparc64/sparc64/tick.c