This is an attempt to upstream a set of Proton patches that correct the value of HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\*\~MHz to not be the maximum frequency of the processor, but the calibrated TSC.
Some games like Horizon Zero Dawn and most likely some more obscure benchmark/profiling tools use this as indicated in this forum post: https://community.osr.com/discussion/288014/how-to-find-out-tsc-frequency
The last comment also suggests querying the above registry key for the TSC.
To my understanding the calibration code has been successfully in use for some time now without any known issues.
I tried to be as faithful to the original history as possible with separating out my changes into their own commits.
If everything should be squashed to be prettier, just let me know!
FYI @rbernon
``` In HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor
Squashed with patches from:
* Arkadiusz Hiler ahiler@codeweavers.com
Check if the kernel trusts TSC before using it for Qpc.
Even if the bits are claiming that TSC meets our requirements the hardware implementation may still be broken.
The Linux kernel does a lot of quality testing before deciding to use as the clock source. If it (or the user, through an override) does not trust the TSC we should not trust it either.
* Joshua Ashton joshua@froggi.es
Some games such as Horizon Zero Dawn use this registry value to correlate values from rtdsc to real time.
Testing across a few devices, is seems like Windows always returns the TSC frequency in this entry, not the current/maximum frequency of the processor.
Returning the nominal/maximum cpu frequency here causes the game to run in slow motion as it may not match the tsc frequency of the processor.
Ideally we'd not have to measure this and the kernel would return tsc_khz to userspace, but this is a good enough stop-gap until https://lkml.org/lkml/2020/12/31/72 or something similar is merged.
CW-Bug-Id: #18918 CW-Bug-Id: #18958 ```
-- v2: wineboot: Add comment about TSC trust check.