Re: [PATCH v5 3/3] cpufreq: qcom-hw: Add CPU clock provider support

[Sudeep Holla <sudeep.holla@arm.com>]

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