Re: [PATCH] cpufreq/amd-pstate: Supply nominal/lowest freq for TRX40-based motherboards

[Mario Limonciello <mario.limonciello@amd.com>]

On 10/7/26 14:38, Giovanni Gherdovich wrote:
> Hello Mario,
> 
> [moving Kyle to BCC, I hope it's OK]
> 
> in my last message I forgot to reply to the rest of your questions;
> see below. In any event, next step for me is testing the latest bios,
> as there seems to be an update.
> 
> On Wed Oct 7, 2026 16:56, Mario Limonciello wrote:
>>
>> Can you please add more information about the vendor/model of the MB, 
>> etc?
> 
> right.
> 
> Motherboard is MSI, model is TRX40 PRO WIFI, CPU is AMD Ryzen 
> Threadripper 3960X.
> https://www.msi.com/Motherboard/TRX40-PRO-WIFI
> Practically the same system as Kyle.
> 
>>> amd-pstate requires explicit knowledge of nominal frequency, so it
>>> can't load on this hardware. The driver already has a mechanism (the
>>> so-called "quirks") to accommodate for missing nominal freq in ACPI
>>> tables, so here we use it to match against CPU family, model, core
>>> count, and BIOS version.
>>
>> Yeah; it's intended for this specific case of really old hardware that 
>> the BIOS isn't going to fix it.
>>
>> I don't understand why core count matters though.
> 
> My thinking was:
> 
> 1. I want to make the "quirk" to match as many chips as possible, to
>     make it more useful and worthwhile.
> 2. The doc I have, "Power and Thermal Data Sheet" (publication #56736
>     in the AMD doc library), is for family 0x17, models 0x30-0x3F
>     processors.
> 3. Problem: these have different nominal frequencies, depending on the
>     core count. Specifically:
>     24 cores: 3800 MHz (like the Ryzen 3090x I need)
>     32 cores: 3700 Mhz
>     64 cores: 2900 MHz
> 4. Thus I decided to match for family 0x17, model 0x30-0x3f, 24 cores.
>     Without the core count constraint, I couldn't tell which of the
>     three nominal frequencies above should apply.

If there does need to be a quirk I guess I would actually say there 
should be 3 quirks then. One for each core count version.>
>>> @@ -174,6 +179,22 @@ static int __init 
>>> dmi_matched_7k62_bios_bug(const struct dmi_system_id *dmi)
>>>       return 0;
>>>   }
>>> +static int __init dmi_matched_trx40_bios_bug(const struct 
>>> dmi_system_id *dmi)
>>> +{
>>> +    /**
>>> +     * Match the Ryzen Threadripper 3000 series, 24-core SKU, sTRX4 
>>> socket / TRX40 chipset.
>>> +     */
>>> +    if (boot_cpu_data.x86 == 0x17 &&
>>> +        boot_cpu_data.x86_model >= 0x30 && boot_cpu_data.x86_model 
>>> <= 0x3F &&
>>> +        topology_num_cores_per_package() == 24) {
>>
>> Does the number of cores actually matter?  Do you mean to say if you 
>> swap the CPU to another part CPPC works?
> 
> No no. It was either wide matching (models 0x30-0x3f) but constraint
> on #cores, or narrow matching for the exact CPU in my motherboard, 
> (model 0x31).
> Since I'm hard-coding data into the kernel, I figured wide matching
> would make the quirk more applicable to potentially other affected
> systems, hence more useful.
> 
>>> +        quirks = dmi->driver_data;
>>> +        pr_info("Overriding nominal and lowest frequencies for 
>>> %s\n", dmi->ident);
>>
>> The BIOS bug specifically is lack of values, not invalid values, 
>> right? Just want to make sure I'm following this right.
> 
> Correct, BIOS is lacking the values. That info message "Overriding"
> is taken verbatim from the other "quirk" in the source, but strictly
> speaking inaccurate. Values weren't there to begin with.
> 
> All that said, I've asked the openSUSE user to test the newer BIOS,
> we'll see what that gives.
> 
> 
> Thanks,
> Giovanni

Thanks!  Based on the findings from the BIOS update everything in this 
thread should be enough to either make a v2 incorporating feedback 
(mostly making it clearer) or to drop the patch.