summaryrefslogtreecommitdiff
path: root/arch/m68k/include/asm/motorola_pgtable.h
diff options
context:
space:
mode:
authorLinus Torvalds <torvalds@linux-foundation.org>2020-03-31 05:55:39 +0300
committerLinus Torvalds <torvalds@linux-foundation.org>2020-03-31 05:55:39 +0300
commit458ef2a25e0cbdc216012aa2b9cf549d64133b08 (patch)
tree462665e7ac3dbe2ea249a6d9692db17858a24f7b /arch/m68k/include/asm/motorola_pgtable.h
parent2853d5fafb1e21707e89aa2e227c90bb2c1ea4a9 (diff)
parentfac01d11722c92a186b27ee26cd429a8066adfb5 (diff)
downloadlinux-458ef2a25e0cbdc216012aa2b9cf549d64133b08.tar.xz
Merge tag 'x86-timers-2020-03-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip
Pull x86 timer updates from Thomas Gleixner: "A series of commits to make the MSR derived CPU and TSC frequency more accurate. It turned out that the frequency tables which have been taken from the SDM are inaccurate because the SDM provides truncated and rounded values, e.g. 83.3Mhz (83.3333...) or 116.7Mhz (116.6666...). This causes time drift in the range of ~1 second per hour (20-30 seconds per day). On some of these SoCs it's not possible to recalibrate the TSC because there is no reference (PIT, HPET) available. With some reverse engineering it was established that the possible frequencies are derived from the base clock with fixed multiplier / divider pairs. For the CPU models which have a known crystal frequency the kernel now uses multiplier / divider pairs which bring the frequencies closer to reality and fix the observed time drift issues" * tag 'x86-timers-2020-03-30' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/tsc_msr: Make MSR derived TSC frequency more accurate x86/tsc_msr: Fix MSR_FSB_FREQ mask for Cherry Trail devices x86/tsc_msr: Use named struct initializers
Diffstat (limited to 'arch/m68k/include/asm/motorola_pgtable.h')
0 files changed, 0 insertions, 0 deletions