Re: [PATCH v3 1/3] ACPI: CPPC: Refactor boost ratio handling

[Mario Limonciello <superm1@kernel.org>]

On 9/30/26 14:43, Rafael J. Wysocki (Intel) wrote:
> On Wed, Sep 30, 2026 at 9:41 PM Mario Limonciello <superm1@kernel.org> wrote:
>>
>> On 9/30/26 14:37, Rafael J. Wysocki (Intel) wrote:
>>> On Fri, Sep 25, 2026 at 4:54 PM Mario Limonciello <superm1@kernel.org> wrote:
>>>>
>>>> On 9/25/26 04:40, Christian Loehle wrote:
>>>>> On 9/24/26 17:00, Mario Limonciello (AMD) wrote:
>>>>>> From: Mario Limonciello <mario.limonciello@amd.com>
>>>>>>
>>>>>> Rename amd_get_boost_ratio_numerator() to amd_get_effective_highest_perf()
>>>>>> to better reflect that it returns the effective highest performance value
>>>>>> for a CPU, accounting for preferred cores and heterogeneous topologies.
>>>>>>
>>>>>> Add a new helper amd_get_boost_ratio() for doing both for boost
>>>>>> ratio calculations and update callers to use it.
>>>>>>
>>>>>> This refactoring is needed because on some AMD systems (Zen6+),
>>>>>> the boost ratio should be calculated from frequency values rather than
>>>>>> performance values.
>>>>>
>>>>> I think I see why you chose to implement it this way (the x86 APERF / MPERF)
>>>>> issue, but I'd still prefer it to be spelled out here why this is necessary.
>>>>>
>>>>
>>>> Do you mean in the commit message, like spin the patch?  Or just in this
>>>> thread?
>>>>
>>>> Not all cores will operate at the same frequency and fixed scaling
>>>> values from CPPC perf don't apply anymore.
>>>
>>> Well, CPPC is per-CPU at least in principle, so the above doesn't
>>> explain much TBH.
>>>
>>> It kind of follows from the cover letter that there's something
>>> missing in CPPC, so this is a stop-gap thing, but it would be good to
>>> put the information from the cover letter to the changelog of this
>>> patch.
>>
>> OK; I'll respin the series with the detail in this commit message.
> 
> Thanks!
> 
> With that, please feel free to add my ACKs to the first two patches in
> this series and route it as a whole through the amd-pstate tree.

Will do; thanks.

> 
>> And yeah; this is totally stop gap to allow other development that needs
>> this.
>>
>> Once next ACPI spec is out I'll tear out the stop gap and put in the
>> right support.
> 
> OK