Dave Hansen dave.hansen@intel.com writes:
On 1/29/20 12:57 PM, Thomas Gleixner wrote:
Just to make it entirely clear. We are wasting days already due to the fact that Intel, who designs, specifies and most importantly sells these CPUs is either unable or unwilling to provide accurate information about the trivial and essential information to support these CPUs:
1) The crystal frequency 2) The nominator/denominator pair to calculate the TSC frequency from #1
Circling back... The problem here, as I understand it is that we have some of these tables:
static const struct freq_desc freq_desc_byt = { 1, { 83300, 100000, 133300, 116700, 80000, 0, 0, 0 } };
Where "83300" means "83.3 MHz". the 83.3 came literally from the SDM. Talking to some of the folks who work on the silicon, they confirmed that when the SDM says "083.3 MHz", it represents an approximation of 2000/24. Intel can go through and explain the values more precisely in the documentation. The big-core tables already have more significant digits, for instance. To me, it also seems like the SDM should probably just explicitly state the actual ratios rather than a decimal approximation.
Yes please.
But, in the end, the CPU is just enumerating frequencies that are derived from crystals outside the CPU. The hardware in question here tended to be put on boards which were not using the highest-end components and probably don't have the most accurate crystals.
So, while we can add precision to the numbers in the documentation, we're not super confident that it will result in a meaningfully more accurate frequency across a big fleet of systems.
Even if you have a cheapo 24MHz crystal it's way less off than the rounding error in these tables.
Thanks,
tglx