Re: [PATCH v4 4/8] ACPI: CPPC: add APIs and sysfs interface for min/max_perf

[Sumit Gupta]

On 13/11/25 16:26, Ionela Voinescu wrote:
> External email: Use caution opening links or attachments
>
>
> Hi,
>
> On Wednesday 05 Nov 2025 at 17:08:40 (+0530), Sumit Gupta wrote:
> > CPPC allows platforms to specify minimum and maximum performance
> > limits that constrain the operating range for CPU performance scaling
> > when Autonomous Selection is enabled. These limits can be dynamically
> > adjusted to implement power management policies or workload-specific
> > optimizations.
> >
> > Add cppc_get_min_perf() and cppc_set_min_perf() functions to read and
> > write the MIN_PERF register, allowing dynamic adjustment of the minimum
> > performance floor.
> >
> > Add cppc_get_max_perf() and cppc_set_max_perf() functions to read and
> > write the MAX_PERF register, enabling dynamic ceiling control for
> > maximum performance.
> >
> > Expose these capabilities through cpufreq sysfs attributes that accept
> > frequency values in kHz (which are converted to/from performance values
> > internally):
> > - /sys/.../cpufreq/policy*/min_perf: Read/write min perf as freq (kHz)
> > - /sys/.../cpufreq/policy*/max_perf: Read/write max perf as freq (kHz)
> There's a theoretical problem here for CPUFREQ_SHARED_TYPE_ANY, when
> multiple CPUs share a policy, but that existed before your
> patches :). Almost all of the files exposed by cppc_cpufreq should be
> per-CPU and not per policy: auto_select, energy_performance_preference,
> etc., and now min_perf, max_perf and perf_limited.
>
> In practice it's likely not a problem as all CPUs that have P-State
> dependencies would likely share all of these controls. But that's not
> mandated by the ACPI specification.

Will send a separate patch as improvement for the existing code.

> > The frequency-based interface provides a user-friendly abstraction which
> > is similar to other cpufreq sysfs interfaces, while the driver handles
> > conversion to hardware performance values.
> >
> > Also update EPP constants for better clarity:
> > - Rename CPPC_ENERGY_PERF_MAX to CPPC_EPP_ENERGY_EFFICIENCY_PREF
> > - Add CPPC_EPP_PERFORMANCE_PREF for the performance-oriented setting
> >
> > Signed-off-by: Sumit Gupta <sumitg@xxxxxxxxxx>
......
> > +/**
> > + * store_max_perf - Set maximum performance from frequency (kHz)
> > + *
> > + * Converts the user-provided frequency (kHz) to a performance value
> > + * and writes it to the MAX_PERF register.
> > + */
> > +static ssize_t store_max_perf(struct cpufreq_policy *policy, const char *buf, size_t count)
> > +{
> > +     struct cppc_cpudata *cpu_data = policy->driver_data;
> > +     unsigned int freq_khz;
> > +     u64 perf;
> > +     int ret;
> > +
> > +     ret = kstrtouint(buf, 0, &freq_khz);
> > +     if (ret)
> > +             return ret;
> > +
> > +     /* Convert frequency (kHz) to performance value */
> > +     perf = cppc_khz_to_perf(&cpu_data->perf_caps, freq_khz);
> > +
> > +     ret = cppc_cpufreq_set_max_perf(policy, perf, true, cpu_data->perf_caps.auto_sel);
> Can you give me some details around updating the policy limits when
> auto-select is true? I suppose if P-state selection is autonomous, the
> policy limits should not matter, right?
>
> Thanks,
> Ionela.


Yes, the cpufreq sw policy limits don't matter to hw in autonomous mode.
This is done to notify the cpufreq framework and keep sw policy limits in
sync with the new limits in HW. This was raised by Pierre also in [1] about
cpufreq not being notified after user modifies the HW limits.

[1] 
https://lore.kernel.org/lkml/b2bd3258-51bd-462a-ae29-71f1d6f823f3@xxxxxxxxxx/

Thank you,
Sumit Gupta