1. 06 Aug, 2020 2 commits
  2. 24 Mar, 2020 1 commit
  3. 11 Mar, 2020 3 commits
    • Hans de Goede's avatar
      x86/tsc_msr: Make MSR derived TSC frequency more accurate · fac01d11
      Hans de Goede authored
      The "Intel 64 and IA-32 Architectures Software Developer’s Manual Volume 4:
      Model-Specific Registers" has the following table for the values from
         000B: 083.3 MHz
         001B: 100.0 MHz
         010B: 133.3 MHz
         011B: 116.7 MHz
         100B: 080.0 MHz
      Notice how for e.g the 83.3 MHz value there are 3 significant digits, which
      translates to an accuracy of a 1000 ppm, where as a typical crystal
      oscillator is 20 - 100 ppm, so the accuracy of the frequency format used in
      the Software Developer’s Manual is not really helpful.
      As far as we know Bay Trail SoCs use a 25 MHz crystal and Cherry Trail
      uses a 19.2 MHz crystal, the crystal is the source clock for a root PLL
      which outputs 1600 and 100 MHz. It is unclear if the root PLL outputs are
      used directly by the CPU clock PLL or if there is another PLL in between.
      This does not matter though, we can model the chain of PLLs as a single PLL
      with a quotient equal to the quotients of all PLLs in the chain multiplied.
      So we can create a simplified model of the CPU clock setup using a
      reference clock of 100 MHz plus a quotient which gets us as close to the
      frequency from the SDM as possible.
      For the 83.3 MHz example from above this would give 100 MHz * 5 / 6 = 83
      and 1/3 MHz, which matches exactly what has been measured on actual
      Use a simplified PLL model with a reference clock of 100 MHz for all Bay
      and Cherry Trail models.
      This has been tested on the following models:
                    CPU freq before:        CPU freq after:
      Intel N2840   2165.800 MHz            2166.667 MHz
      Intel Z3736   1332.800 MHz            1333.333 MHz
      Intel Z3775   1466.300 MHz            1466.667 MHz
      Intel Z8350   1440.000 MHz            1440.000 MHz
      Intel Z8750   1600.000 MHz            1600.000 MHz
      This fixes the time drifting by about 1 second per hour (20 - 30 seconds
      per day) on (some) devices which rely on the tsc_msr.c code to determine
      the TSC frequency.
      Reported-by: default avatarVipul Kumar <vipulk0511@gmail.com>
      Suggested-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20200223140610.59612-3-hdegoede@redhat.com
    • Hans de Goede's avatar
      x86/tsc_msr: Fix MSR_FSB_FREQ mask for Cherry Trail devices · c8810e2f
      Hans de Goede authored
      According to the "Intel 64 and IA-32 Architectures Software Developer's
      Manual Volume 4: Model-Specific Registers" on Cherry Trail (Airmont)
      devices the 4 lowest bits of the MSR_FSB_FREQ mask indicate the bus freq
      unlike on e.g. Bay Trail where only the lowest 3 bits are used.
      This is also the reason why MAX_NUM_FREQS is defined as 9, since Cherry
      Trail SoCs have 9 possible frequencies, so the lo value from the MSR needs
      to be masked with 0x0f, not with 0x07 otherwise the 9th frequency will get
      interpreted as the 1st.
      Bump MAX_NUM_FREQS to 16 to avoid any possibility of addressing the array
      out of bounds and makes the mask part of the cpufreq struct so it can be
      set it per model.
      While at it also log an error when the index points to an uninitialized
      part of the freqs lookup-table.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20200223140610.59612-2-hdegoede@redhat.com
    • Hans de Goede's avatar
      x86/tsc_msr: Use named struct initializers · 812c2d75
      Hans de Goede authored
      Use named struct initializers for the freq_desc struct-s initialization
      and change the "u8 msr_plat" to a "bool use_msr_plat" to make its meaning
      more clear instead of relying on a comment to explain it.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/20200223140610.59612-1-hdegoede@redhat.com
  4. 06 Sep, 2019 1 commit
  5. 09 May, 2019 1 commit
  6. 02 Oct, 2018 1 commit
    • Peter Zijlstra's avatar
      x86/cpu: Sanitize FAM6_ATOM naming · f2c4db1b
      Peter Zijlstra authored
      Going primarily by:
      with additional information gleaned from other related pages; notably:
       - Bonnell shrink was called Saltwell
       - Moorefield is the Merriefield refresh which makes it Airmont
      The general naming scheme is: FAM6_ATOM_UARCH_SOCTYPE
        for i in `git grep -l FAM6_ATOM` ; do
      	sed -i  -e 's/ATOM_PINEVIEW/ATOM_BONNELL/g'		\
      Signed-off-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: dave.hansen@linux.intel.com
      Cc: len.brown@intel.com
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
  7. 03 Jul, 2018 4 commits
  8. 18 Nov, 2016 1 commit
  9. 11 Jul, 2016 1 commit
  10. 10 Jul, 2016 6 commits
  11. 12 May, 2016 1 commit
  12. 06 May, 2016 1 commit
  13. 19 Feb, 2014 2 commits
    • Mika Westerberg's avatar
      x86: tsc: Add missing Baytrail frequency to the table · 3e11e818
      Mika Westerberg authored
      Intel Baytrail is based on Silvermont core so MSR_FSB_FREQ[2:0] == 0 means
      that the CPU reference clock runs at 83.3MHz. Add this missing frequency to
      the table.
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Cc: Bin Gao <bin.gao@linux.intel.com>
      Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Link: http://lkml.kernel.org/r/1392810750-18660-2-git-send-email-mika.westerberg@linux.intel.com
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    • Thomas Gleixner's avatar
      x86, tsc: Fallback to normal calibration if fast MSR calibration fails · 5f0e0309
      Thomas Gleixner authored
      If we cannot calibrate TSC via MSR based calibration
      try_msr_calibrate_tsc() stores zero to fast_calibrate and returns that
      to the caller. This value gets then propagated further to clockevents
      code resulting division by zero oops like the one below:
       divide error: 0000 [#1] PREEMPT SMP
       Modules linked in:
       CPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W    3.13.0+ #47
       task: ffff880075508000 ti: ffff880075506000 task.ti: ffff880075506000
       RIP: 0010:[<ffffffff810aec14>]  [<ffffffff810aec14>] clockevents_config.part.3+0x24/0xa0
       RSP: 0000:ffff880075507e58  EFLAGS: 00010246
       RAX: ffffffffffffffff RBX: ffff880079c0cd80 RCX: 0000000000000000
       RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffffffffffff
       RBP: ffff880075507e70 R08: 0000000000000001 R09: 00000000000000be
       R10: 00000000000000bd R11: 0000000000000003 R12: 000000000000b008
       R13: 0000000000000008 R14: 000000000000b010 R15: 0000000000000000
       FS:  0000000000000000(0000) GS:ffff880079c00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
       CR2: ffff880079fff000 CR3: 0000000001c0b000 CR4: 00000000001006f0
        ffff880079c0cd80 000000000000b008 0000000000000008 ffff880075507e88
        ffffffff810aecb0 ffff880079c0cd80 ffff880075507e98 ffffffff81030168
        ffff880075507ed8 ffffffff81d1104f 00000000000000c3 0000000000000000
       Call Trace:
        [<ffffffff810aecb0>] clockevents_config_and_register+0x20/0x30
        [<ffffffff81030168>] setup_APIC_timer+0xc8/0xd0
        [<ffffffff81d1104f>] setup_boot_APIC_clock+0x4cc/0x4d8
        [<ffffffff81d0f5de>] native_smp_prepare_cpus+0x3dd/0x3f0
        [<ffffffff81d02ee9>] kernel_init_freeable+0xc3/0x205
        [<ffffffff8177c910>] ? rest_init+0x90/0x90
        [<ffffffff8177c91e>] kernel_init+0xe/0x120
        [<ffffffff8178deec>] ret_from_fork+0x7c/0xb0
        [<ffffffff8177c910>] ? rest_init+0x90/0x90
      Prevent this from happening by:
       1) Modifying try_msr_calibrate_tsc() to return calibration value or zero
          if it fails.
       2) Check this return value in native_calibrate_tsc() and in case of zero
          fallback to use normal non-MSR based calibration.
      [mw: Added subject and changelog]
      Reported-and-tested-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Bin Gao <bin.gao@linux.intel.com>
      Cc: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Link: http://lkml.kernel.org/r/1392810750-18660-1-git-send-email-mika.westerberg@linux.intel.com
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
  14. 16 Jan, 2014 2 commits