Quoting Viresh Kumar (2020-07-27 08:38:06)

On 27-07-20, 17:38, Rajendra Nayak wrote:

quoted

On 7/27/2020 11:23 AM, Rajendra Nayak wrote:

quoted

On 7/24/2020 7:39 PM, Stanimir Varbanov wrote:

quoted

quoted

quoted

+
+                opp-533000000 {
+                    opp-hz = /bits/ 64 <533000000>;

Is this the highest OPP in table ?

quoted

quoted

quoted

Actually it comes from videocc, where ftbl_video_cc_venus_clk_src
defines 533000000 but the real calculated freq is 533000097.

I still don't quite understand why the videocc driver returns this
frequency despite this not being in the freq table.

Ok, so I see the same issue on sc7180 also. clk_round_rate() does seem to
return whats in the freq table, but clk_set_rate() goes ahead and sets it

I'm happy to see clk_round_rate() return the actual rate that would be
achieved and not just the rate that is in the frequency tables. Would
that fix the problem? It may be that we need to make clk_round_rate() do
some more math on qcom platforms and actually figure out what the rate
is going to be instead of blindly trust the frequency that has been set
in the tables.

quoted

to 533000097. Subsequently when we try to set a different OPP, it fails to
find the 'current' OPP entry for 533000097. This sounds like an issue with the OPP
framework? Should we not fall back to the highest OPP as the current OPP?

Stephen/Viresh, any thoughts?

I think we (in all frameworks generally) try to set a frequency <=
target frequency and so there may be a problem if the frequency is
larger than highest supported. IOW, you need to fix tables a bit.

Rounding is annoying for sure.