Hi Stephen, >> The idea is: if the flag is set, instead of accepting the new upstream >> rate and recalculate the downstream rate based on a previously set >> divider value, we change our divider value to match the same frequency >> as before. But if we cannot, then we just keep the old way. >> > > The exclusive rate code could support this if it doesn't already do so. > If you call clk_set_rate_exclusive(child, <constant rate>) followed by > clk_set_rate(parent, <new rate>) the core code should try to keep the > child at the constant rate, or fail the clk_set_rate() call on the > parent. It should be possible to confirm this with some KUnit tests for > clk_set_rate_exclusive(). Similarly, if another child, child_B, of the > parent changes the parent rate, we should speculate the new rate of the > child_A that's protected and fail if we can't maintain the rate. We need > to start generating a list of clks that we operate a rate change on to > support this though, because right now we rely on the stack to track the > clks that we change the rate of. > > Initially we thought that we could do this with clk notifiers. That may > work here, but I suspect it will be clunky to get working because clk > notifiers operate on struct clk. I see, thanks a lot for the feedback, I'll have a look. Thanks, Miquèl
