On 12/12/22 18:37, Stephen Boyd wrote:

Quoting Sean Anderson (2022-12-08 07:36:45)

quoted

On 12/6/22 21:17, Stephen Boyd wrote:

quoted

Quoting Sean Anderson (2022-11-01 16:27:21)

quoted

On 11/1/22 16:10, Stephen Boyd wrote:

quoted

quoted

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?

Huh, I didn't realize that best_parent_hw was an input as well as an
output. The way it's documented, it makes it seem like this is set by
determine_rate.

I'm still not very happy with having to use an aux bus, as there are
plenty of other drivers which just register clocks with the top-level
device.

I will try and revisit this at some point, but the project has ended so
I'm not sure when I will find the time.

--Sean