On Mon, Sep 15, 2025 at 11:02:07AM +0100, Qais Yousef wrote:
On 09/15/25 15:29, Shawn Guo wrote:
On Sun, Sep 14, 2025 at 06:43:26PM +0100, Qais Yousef wrote:
Why do you want to address the issue in the cpufreq core instead of doing that in the cpufreq-dt driver?
My intuition was to fix the regression at where the regression was introduced by recovering the code behavior.
Isn't the right fix here is at the driver level still? We can only give drivers what they ask for. If they ask for something wrong and result in something wrong, it is still their fault, no?
I'm not sure. The cpufreq-dt driver is following suggestion to use CPUFREQ_ETERNAL, which has the implication that core will figure out a reasonable default value for platforms where the latency is unknown. And that was exactly the situation before the regression. How does it become the fault of cpufreq-dt driver?
Rafael and Viresh would know better, but amd-pstate chooses to fallback to specific values if cppc returned CPUFREQ_ETERNAL.
Have you tried to look why dev_pm_opp_get_max_transition_latency() returns 0 for your platform? I think this is the problem that was being masked before.
My platform doesn't scale voltage along with frequency, and the platform DT doesn't specify 'clock-latency-ns' which is an optional property after all.
Shawn