Re: [PATCH] x86/tsc: Use hard-coded crystal clock for Skylake mobile

[Paul Menzel]

Dear Thomas,


Thank you for the quick reply.

Am 11.05.20 um 09:17 schrieb Thomas Gleixner:

> Paul Menzel <pmenzel@xxxxxxxxxxxxx> writes:
>
> please send patches to LKML and not offlist.

Sorry about that. From `MAINTAINERS` I thought x86@xxxxxxxxxx is wanted. 
Other subsystems list LKML explicitly there.

> > From: Radoslaw Biernacki <biernacki@xxxxxxxxxx>
> >
> > @@ -636,10 +636,24 @@ unsigned long native_calibrate_tsc(void)
> >   	 * Denverton SoCs don't report crystal clock, and also don't support
> >   	 * CPUID.0x16 for the calculation below, so hardcode the 25MHz crystal
> >   	 * clock.
> > +	 * Also estimation code is not reliable and gives 1.5%  difference for
> > +	 * tsc/clock ratio on Skylake mobile. Therefore below is a hardcoded
> > +	 * crystal frequency for Skylake which was removed by upstream commit
> > +	 * "x86/tsc: Use CPUID.0x16 to calculate missing crystal frequency"
> > +	 * This is temporary workaround for bugs:
> > +	 * b/148108096, b/154283905, b/146787525, b/153400677, b/148178929
> > +	 * chromium/1031054
> >   	 */
> > -	if (crystal_khz == 0 &&
> > -			boot_cpu_data.x86_model == INTEL_FAM6_ATOM_GOLDMONT_D)
> > -		crystal_khz = 25000;
> > +	if (crystal_khz == 0) {
> > +		switch (boot_cpu_data.x86_model) {
> > +		case INTEL_FAM6_SKYLAKE_MOBILE:
> > +			crystal_khz = 24000;	/* 24.0 MHz */
> > +			break;
> > +		case INTEL_FAM6_ATOM_GOLDMONT_X:
> > +			crystal_khz = 25000;	/* 25.0 MHz */
> > +			break;
> > +		}
>
> Aside of being a workaround for Google issues which are probably caused > by broken BIOSes

Even if it was caused by broken firmware, wouldnât Linuxâ no regression 
policy still consider this a regression as user should be able to the 
Linux kernel âno matter whatâ?

> that patch is broken.
>
>     INTEL_FAM6_ATOM_GOLDMONT_D != INTEL_FAM6_ATOM_GOLDMONT_X

Good catch. The commit didnât apply cleanly to the master branch, and I 
missed this.

Iâll wait for Radoslaw to comment before proceeding further with this.


Kind regards,

Paul