Quoting Tero Kristo (2019-08-29 23:06:41) > On 29/08/2019 23:05, Stephen Boyd wrote: > > Quoting Tero Kristo (2019-08-27 23:59:27) > >> diff --git a/drivers/clk/ti/clkctrl.c b/drivers/clk/ti/clkctrl.c > >> index e3e0a66a6ce2..47a0d1398c6f 100644 > >> --- a/drivers/clk/ti/clkctrl.c > >> +++ b/drivers/clk/ti/clkctrl.c > >> @@ -680,3 +689,38 @@ u32 ti_clk_is_in_standby(struct clk *clk) > >> return false; > >> } > >> EXPORT_SYMBOL_GPL(ti_clk_is_in_standby); > >> + > >> +/** > >> + * ti_clk_notify_resets - Notify the clock driver associated reset status > > > > This is completely unused in this patch series. What's going on? > > This is needed by the OMAP reset driver. See: > > https://lwn.net/Articles/797597/ > Ok. I decided to punt this topic forward to next release at the least. To clarify, TI is not special with regards to coordinating resets and clk enable/disable state. Every other silicon vendor has the same requirements and nobody is doing a good job at it. Please devise a way that avoids making a tight coupling between the clk driver and the reset driver in this way. Are the two in the same register space? Perhaps we need to combine the two drivers then. Or can this be implemented as a genpd that coordinates the resets and clk controls for various devices?
