Re: [PATCH v1 2/5] clk: Introduce clk_round_rate_unboundly()

[Stephen Boyd]

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.