lkml.org 
[lkml]   [2022]   [Nov]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5 3/3] cpufreq: qcom-hw: Add CPU clock provider support
On Wed, Nov 09, 2022 at 06:05:26PM +0530, Manivannan Sadhasivam wrote:
> I don't think using the final DCVS frequency would be applicable for cpufreq
> core.
>
> cpufreq core sets the desired frequency in the form of index using the
> target_index() callback and the qcom-cpufreq-hw driver uses that index directly
> to select the specific entry in the hardware LUT (Look Up Table).
>
> Then with get() callback, the frequency will be returned based on the LUT index
> read from the hardware. In this case, the frequency is going to be static
> (i.e, what gets set by the cpufreq core will be the same). I believe this is
> what the API also expects.
>

I guessed so and hence thought of asking. Is the cpufreq_get() API expected
to return something close to what was set or is it expected to return the
real set h/w value if and when possible. I wanted to confirm if that is the
expectation from the cpufreq core or is it just the way qcom cpufreq-hw
driver(probably many others too) work today.

> In the case of qcom_lmh_get_throttle_freq(), the frequency is going to be
> dynamic (i.e changes with every internal DCVS operation). But this is exactly
> what the OPP core expects with clk_get_rate() of CPU clock, so using
> qcom_lmh_get_throttle_freq() makes sense there.
>

OK, the reason I ask is that IIRC the ACPI CPPC driver might get the exact
delivered frequency rather than something based on the set value, so it
shouldn't be a requirement but I may be wrong.

Viresh, thoughts ?

--
Regards,
Sudeep

\
 
 \ /
  Last update: 2022-11-09 17:48    [W:0.050 / U:1.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site