[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <b3fbe9aa24bce4f99e864b81ae8ec440.sboyd@kernel.org>
Date: Tue, 17 Dec 2024 11:46:13 -0800
From: Stephen Boyd <sboyd@...nel.org>
To: Manivannan Sadhasivam via B4 Relay <devnull+manivannan.sadhasivam.linaro.org@...nel.org>, Rafael J. Wysocki <rafael@...nel.org>, Viresh Kumar <viresh.kumar@...aro.org>, Xiu Jianfeng <xiujianfeng@...wei.com>, manivannan.sadhasivam@...aro.org
Cc: linux-arm-msm@...r.kernel.org, linux-pm@...r.kernel.org, linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org, Johan Hovold <johan+linaro@...nel.org>, Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
Subject: Re: [PATCH 2/2] cpufreq: qcom: Implement clk_ops::determine_rate() for qcom_cpufreq* clocks
Quoting Manivannan Sadhasivam via B4 Relay (2024-12-05 08:50:29)
> From: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
>
> determine_rate() callback is used by the clk_set_rate() API to get the
> closest rate of the target rate supported by the clock. If this callback
> is not implemented (nor round_rate() callback), then the API will assume
> that the clock cannot set the requested rate. And since there is no parent,
> it will return -EINVAL.
>
> This is not an issue right now as clk_set_rate() mistakenly compares the
> target rate with cached rate and bails out early. But once that is fixed
> to compare the target rate with the actual rate of the clock (returned by
> recalc_rate()), then clk_set_rate() for this clock will start to fail as
> below:
>
> cpu cpu0: _opp_config_clk_single: failed to set clock rate: -22
>
> So implement the determine_rate() callback that just returns the actual
> rate at which the clock is passed to the CPUs in a domain.
>
> Fixes: 4370232c727b ("cpufreq: qcom-hw: Add CPU clock provider support")
> Reported-by: Johan Hovold <johan+linaro@...nel.org>
> Closes: https://lore.kernel.org/all/20241202100621.29209-1-johan+linaro@kernel.org
> Suggested-by: Stephen Boyd <sboyd@...nel.org>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
> ---
Reviewed-by: Stephen Boyd <sboyd@...nel.org>
Powered by blists - more mailing lists