Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 21 3月, 2009 1 次提交
  3. 20 3月, 2009 1 次提交
  5. 18 3月, 2009 8 次提交
  7. 17 3月, 2009 4 次提交
    • K
      powerpc/mm: Respect _PAGE_COHERENT on classic ppc32 SW · a4bd6a93
      由 Kumar Gala 提交于 
      Since we now set _PAGE_COHERENT in the Linux PTE we shouldn't be clearing
it out before we setup the SW TLB.  Today all the SW TLB machines
(603/e300) that we support are non-SMP, however there are some errata on
some devices that cause us to set _PAGE_COHERENT via CPU_FTR_NEED_COHERENT.
Signed-off-by: NKumar Gala <galak@kernel.crashing.org>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      a4bd6a93
    • P
      powerpc/5200: Enable CPU_FTR_NEED_COHERENT for MPC52xx · c9310920
      由 Piotr Ziecik 提交于 
      BestComm, a DMA engine in MPC52xx SoC, requires snooping when
CPU caches are enabled to work properly.

Adding CPU_FTR_NEED_COHERENT fixes NFS problems on MPC52xx machines
introduced by 'powerpc/mm: Fix handling of _PAGE_COHERENT in BAT setup
code' (sha1: 4c456a67).
Signed-off-by: NPiotr Ziecik <kosmo@semihalf.com>
Signed-off-by: NGrant Likely <grant.likely@secretlab.ca>
      c9310920
    • L
      Fast TSC calibration: calculate proper frequency error bounds · 9e8912e0
      由 Linus Torvalds 提交于 
      In order for ntpd to correctly synchronize the clocks, the frequency of
the system clock must not be off by more than 500 ppm (or, put another
way, 1:2000), or ntpd will end up giving up on trying to synchronize
properly, and ends up reseting the clock in jumps instead.

The fast TSC PIT calibration sometimes failed this test - it was
assuming that the PIT reads always took about one microsecond each (2us
for the two reads to get a 16-bit timer), and that calibrating TSC to
the PIT over 15ms should thus be sufficient to get much closer than
500ppm (max 2us error on both sides giving 4us over 15ms: a 270 ppm
error value).

However, that assumption does not always hold: apparently some hardware
is either very much slower at reading the PIT registers, or there was
other noise causing at least one machine to get 700+ ppm errors.

So instead of using a fixed 15ms timing loop, this changes the fast PIT
calibration to read the TSC delta over the individual PIT timer reads,
and use the result to calculate the error bars on the PIT read timing
properly.  We then successfully calibrate the TSC only if the maximum
error bars fall below 500ppm.

In the process, we also relax the timing to allow up to 25ms for the
calibration, although it can happen much faster depending on hardware.
Reported-and-tested-by: NJesper Krogh <jesper@krogh.cc>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Acked-by: NIngo Molnar <mingo@elte.hu>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      9e8912e0
    • L
      Fix potential fast PIT TSC calibration startup glitch · a6a80e1d
      由 Linus Torvalds 提交于 
      During bootup, when we reprogram the PIT (programmable interval timer)
to start counting down from 0xffff in order to use it for the fast TSC
calibration, we should also make sure to delay a bit afterwards to allow
the PIT hardware to actually start counting with the new value.

That will happens at the next CLK pulse (1.193182 MHz), so the easiest
way to do that is to just wait at least one microsecond after
programming the new PIT counter value.  We do that by just reading the
counter value back once - which will take about 2us on PC hardware.
Reported-and-tested-by: Njohn stultz <johnstul@us.ibm.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      a6a80e1d
  9. 14 3月, 2009 2 次提交
  11. 13 3月, 2009 18 次提交
  13. 12 3月, 2009 5 次提交
  15. 11 3月, 2009 1 次提交