Hi Maxime, >> 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 think notifiers are great for customers, but not really adequate for > the clock drivers tree. Indeed, you can only react to a (sub)tree > configuration using notifiers, but you can't affect it to try something > new that would be a better fit. > > Like, if we have a PLL A, with two child clocks that are dividers. B is > initially (exclusively) set to freq X, and then you want to set C to 2X. > > The best thing to do is to set A to 2X, and double B's divider. It's > simple enough, but we have no way to try to negociate that at the > moment. Indeed. Do you have something in mind to address this situation (eg. a new clk provider or core API)? Thanks, Miquèl
