On 6/27/22 10:19, Viresh Kumar wrote: > On 27-06-22, 10:09, Dmitry Osipenko wrote: >> Yes, I missed that multi-clock OPP patch, thanks. >> >> Seems _opp_compare_key() won't work properly for the multi-clocks since >> Tegra doesn't have bandwidth nor level for the 3d OPPs. Why does it need >> to check opp_table->clk_count == 1? Shouldn't it be opp_table->clk_count >>> 0? > > The problem is that when we have multiple clocks, we can't assume any > of them as primary. Its the combination of the clock frequencies that > make them unique. Otherwise, what will happen if we have same > frequency of the first clock in two OPPs, but different frequency of > the second clock. > > Because of this, we won't also support multiple clocks in all freq > finder APIs, like dev_pm_opp_find_freq_exact(). We can't do that from > just one frequency. > > Ideally, the drivers should now be calling dev_pm_opp_set_opp() to set > the OPP now. > > For your case, I think you can just add levels (like index) in the OPP > table. So we can uniquely identify each OPP. > What about to bump the "by-level" sorting priority, making it above the "by-rate" sorting and then always use the first clock for the "by-rate" sorting? Then the multi-clock will work for Tegra without breaking dtbs and those for whom this sorting option won't be appropriate will have to add levels to the DT. -- Best regards, Dmitry
