Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 18 Apr 2019 15:12:12 +0200 (CEST)
From:   Thomas Gleixner <tglx@linutronix.de>
To:     Daniel Drake <drake@endlessm.com>
cc:     lenb@kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org,
        linux@endlessm.com, rjw@rjwysocki.net
Subject: Re: Detecting x86 LAPIC timer frequency from CPUID data
In-Reply-To: <20190417052810.3052-1-drake@endlessm.com>
Message-ID: <alpine.DEB.2.21.1904181511150.3174@nanos.tec.linutronix.de>
References: <20190417052810.3052-1-drake@endlessm.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, 17 Apr 2019, Daniel Drake wrote:

> The CPUID.0x16 leaf provides "Bus (Reference) Frequency (in MHz)".
> 
> In the thread "No 8254 PIT & no HPET on new Intel N3350 platforms
> causes kernel panic during early boot" we are exploring ways to have
> the kernel avoid using the PIT/HPET IRQ0 timer in more cases, and
> Thomas Gleixner suggested that we could use this CPUID data to set
> lapic_timer_frequency, avoiding the need for calibrate_APIC_clock()
> to measure the APIC clock against the IRQ0 timer.
> 
> I'm thinking of the the following code change, however I get
> unexpected results on Intel i7-8565U (Whiskey Lake). When
> booting without this change, and with apic=notscdeadline (so that
> APIC clock gets calibrated and used), the bus speed is detected as
> 23MHz:
> 
>  ... lapic delta = 149994
>  ... PM-Timer delta = 357939
>  ... PM-Timer result ok
>  ..... delta 149994
>  ..... mult: 6442193
>  ..... calibration result: 23999
>  ..... CPU clock speed is 1991.0916 MHz.
>  ..... host bus clock speed is 23.0999 MHz.
> 
> However the CPUID.0x16 ECX reports a 100MHz bus speed on this device,
> so this code change would produce a significantly different calibration.
> 
> Am I doing anything obviously wrong?

It's probably just my fault sending you down the wrong path. What's the
content of CPUUD.0x15 on that box?

Thanks,

	tglx