Re: [PATCH v8 3/3] cpufreq: CPPC: Reflect the OSPM nominal in boost and limits

[Christian Loehle <christian.loehle@arm.com>]

On 11/4/26 15:08, Sumit Gupta wrote:
> Hi Christian,
> 
> 
> On 03/11/26 22:42, Christian Loehle wrote:
>> External email: Use caution opening links or attachments
>>
>>
>> On 10/30/26 17:27, Sumit Gupta wrote:
>>> Boost is the performance range above nominal, so lowering the OSPM
>>> Nominal Performance enlarges the boost range and drops the non-boost
>>> ceiling. Keep the policy limits consistent with the register.
>>>
>>> Add cppc_cpufreq_effective_nominal(), which returns the OSPM Nominal
>>> Performance when set and the platform nominal otherwise. Use it for the
>>> non-boost ceiling in set_boost(), and to update the policy limits when
>>> ospm_nominal_freq is written.
>>>
>>> The cpufreq core caps scaling_max_freq with a per-policy QoS request,
>>> boost_freq_req, that it sets to cpuinfo.max_freq and refreshes only when
>>> boost is toggled. A write to ospm_nominal_freq changes cpuinfo.max_freq
>>> without toggling boost, so cppc_cpufreq_update_nominal_limits() updates
>>> the request itself, rather than leaving scaling_max_freq at the old
>>> nominal.
>>>
>>> When boost is enabled the ceiling is highest_perf, not the nominal, so
>>> the update is skipped. set_boost() applies the new nominal when boost is
>>> turned off.
>>>
>>> A platform with highest_perf == nominal_perf has no boost range at boot.
>>> Lowering the OSPM nominal from sysfs can create one. The core, however,
>>> adds its boost FREQ_QOS_MAX request only at policy setup, and only if
>>> boost_supported is already set. Set boost_supported in init() when the
>>> OSPM register is supported and highest_perf > lowest_perf. Boost can
>>> then be enabled after the nominal is lowered.
>>>
>>> Suggested-by: Pierre Gondois <pierre.gondois@arm.com>
>>> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
>>
>> Thinking out loud here:
>> I'm curious if there's actually a use-case for this, presumably once we
>> let userspace effectively dictate boost allocation, we practically expect
>> userspace to sort out scheduling, too (e.g. by pinning?) and therefore this
>> becomes largely irrelevant?
>>
> 
> I think it is still needed. Lowering the OSPM nominal puts the levels
> between it and the platform nominal into the boost range.
> Without this patch, boost=0 still allows those levels. Userspace would
> then need an extra frequency cap to stay out of boost. This patch makes
> boost=0 cap the policy at the OSPM nominal.

Duh of course, I was somehow too focused on the cpufreq capacity pressure
to not see the obvious one, nevermind and sorry for the noise.

Reviewed-by: Christian Loehle <christian.loehle@arm.com>