Quoting Sean Anderson (2022-12-08 07:36:45) > On 12/6/22 21:17, Stephen Boyd wrote: > > Quoting Sean Anderson (2022-11-01 16:27:21) > >> On 11/1/22 16:10, Stephen Boyd wrote: > >> >> > >> >> Oh, I remember why I did this. I need the reference clock for clk_hw_round_rate, > >> >> which is AFAICT the only correct way to implement round_rate. > >> >> > >> > > >> > Is the reference clk the parent of the clk implementing > >> > clk_ops::round_rate()? > >> > >> Yes. We may be able to produce a given output with multiple reference > >> rates. However, the clock API provides no mechanism to say "Don't ask > >> for the parent clock to be rate X, you just tried it and the parent > >> clock can't support it." So instead, we loop over the possible reference > >> rates and pick the first one which the parent says it can round to. > >> > > > > Sorry, I'm lost. Why can't you loop over possible reference rates in > > determine_rate/round_rate clk op here? > > This is what I do currently, but you need to have the parent clock to do > so. With your suggested method, we never actually get a struct clk(_hw) > which we can query for rate support. The clk_hw for the parent is given to the determine_rate clk_op in the clk_rate_request structure. It's stored in the best_parent_hw pointer when the determine_rate function is called. Does that work for you?
