On 04-07-22, 21:04, Dmitry Osipenko wrote: > On 7/4/22 18:52, Viresh Kumar wrote: > > On 04-07-22, 16:17, Dmitry Osipenko wrote: > >> Actually the freq was 0 and it was 1 on the next loop like you suggested. > >> > >> Previously, the _read_opp_key() was always reading the opp-hz. Now it > >> skips reading the rates in _read_rate() because opp_table->clk_count=0 > >> for the tegra30-devfreq driver the uses devm_pm_opp_of_add_table_noclk(). > > > > This is exactly what I wrote in an earlier email :) > > > > Anyway, I have pushed two patches on top of my opp/linux-next branch > > and they should fix it in a good way now I suppose. Can you please > > give that a try. > > > > This is how the diff looks like: > > > > PM / devfreq: tegra30: Register config_clks helper > > > > There is a corner case with Tegra30, where we want to skip clk > > configuration via dev_pm_opp_set_opp(), but still want the OPP core to > > read the "opp-hz" property so we can find the right OPP via freq finding > > helpers. > > > > The OPP core provides support for the platforms to provide config_clks > > helpers now, lets use them instead of devm_pm_opp_of_add_table_noclk() > > to achieve the same result, as the OPP core won't parse the DT's > > "opp-hz" property if the clock isn't provided. > > Works, thanks you! > > Tested-by: Dmitry Osipenko <dmitry.osipenko@xxxxxxxxxxxxx> Finally, thanks a lot Dmitry :) -- viresh
