Quoting Dmitry Osipenko (2020-05-27 10:57:01) > 27.05.2020 08:55, Stephen Boyd \u043f\u0438\u0448\u0435\u0442: > > Quoting Dmitry Osipenko (2020-03-30 16:16:14) > >> In same cases it may be desired to round clock's rate without taking into > >> account current min/max requests made by the clock's users. One example is > >> building up OPP table based on a possible clock rates. > > > > Shouldn't the OPP table come from firmware/DT? I don't quite understand > > why we're generating OPP tables on top of the rate rounding API. > > clk_round_rate() is supposed to tell us what rate we'll get if we call > > clk_set_rate() with the same arguments. An unboundly version of that > > doesn't make sense. > > The OPP should come from the DT, but unfortunately DT and Tegra's > devfreq driver wasn't designed like that from the start, so it will take > some extra effort to re-do it properly now. I wanted to postpone that > effort a tad and get at least the basics upstreamed for the starter. > > > I wonder if perhaps the clk provider should be populating OPP tables in > > this case? Or basically anything besides adding another clk consumer API > > to solve this problem. Who is the caller? Something later in this > > series? > > I'll try to add a proper OPP table with freqs and voltages, will see how > it goes. We will need to do it sooner or later anyways. So perhaps it's > fine to drop the current approach with the clk_round_rate_unboundly() > and re-focus on a proper OPP implementation. > > Thank you for getting back and replying to this topic :) Alright, it sounds better to me if we can avoid a one off addition to the clk API in favor of implementing a proper OPP table from the start.
