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
