Quoting Rajendra Nayak (2020-07-27 21:17:28)

On 7/28/2020 6:22 AM, Stephen Boyd wrote:

quoted

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

quoted

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 would, but only if I also update the OPP table to have 533000097
instead of 533000000 (which I guess is needed anyway)
If this is the actual frequency that's achievable, then perhaps even the clock
freq table should have this? 533000097 and not 533000000?
That way clk_round_rate() would return the actual rate that's achieved and
we don't need any extra math. Isn't that the reason these freq tables exist
anyway.

Yes the freq tables are there in the clk driver so we don't have to do a
bunch of math. Fixing them to be accurate has been deemed "hard" from
what I recall because the tables are generated from some math function
that truncates the lower Hertz values.