Quoting Thierry Reding (2020-03-05 09:51:38) > From: Thierry Reding <treding@xxxxxxxxxx> > > As part of the clock frequency change sequence, a driver may need to > reparent a clock. In that case, the rate will already have been updated > and the cached parent rate will no longer be valid, so just skip the > recalculation. Can you describe more about what's going on and why this needs to change? For example, we have 'set_rate_and_parent' for cases where a driver reparents a clk during a rate change. Is that not sufficient here? > > Signed-off-by: Thierry Reding <treding@xxxxxxxxxx> > --- > drivers/clk/clk.c | 9 ++++++++- > 1 file changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c > index ebfc1e2103cb..49d92f4785a2 100644 > --- a/drivers/clk/clk.c > +++ b/drivers/clk/clk.c > @@ -2079,7 +2079,14 @@ static void clk_change_rate(struct clk_core *core) > > trace_clk_set_rate_complete(core, core->new_rate); > > - core->rate = clk_recalc(core, best_parent_rate); > + /* > + * Some drivers need to change the parent of a clock as part of the > + * rate change sequence. In that case, best_parent_rate is no longer > + * valid. However, reparenting already recalculates the rate for the > + * entire clock subtree, so we can safely skip this here. > + */ > + if (core->parent == parent) > + core->rate = clk_recalc(core, best_parent_rate); > I wonder if we can undo the recursion and figure out a way to make this only happen once, when we want it to happen.
