On Thu, 2 Mar 2023 at 00:58, Jeremy Kerr <jk@xxxxxxxxxxxxxxxxxxxx> wrote: > > Add a little description about how reset lines can be implicit with > clock enable/disable. This is mostly based on the commit message > from the original submission in 15ed8ce5f8. Excellent, thank you. Reviewed-by: Joel Stanley <joel@xxxxxxxxx> > > Signed-off-by: Jeremy Kerr <jk@xxxxxxxxxxxxxxxxxxxx> > --- > drivers/clk/clk-ast2600.c | 21 +++++++++++++++++++++ > 1 file changed, 21 insertions(+) > > diff --git a/drivers/clk/clk-ast2600.c b/drivers/clk/clk-ast2600.c > index 09f26ab5f9af..a094a2601a37 100644 > --- a/drivers/clk/clk-ast2600.c > +++ b/drivers/clk/clk-ast2600.c > @@ -73,6 +73,27 @@ static void __iomem *scu_g6_base; > static u8 soc_rev; > > /* > + * The majority of the clocks in the system are gates paired with a reset > + * controller that holds the IP in reset; this is represented by the @reset_idx > + * member of entries here. > + * > + * This borrows from clk_hw_register_gate, but registers two 'gates', one > + * to control the clock enable register and the other to control the reset > + * IP. This allows us to enforce the ordering: > + * > + * 1. Place IP in reset > + * 2. Enable clock > + * 3. Delay > + * 4. Release reset > + * > + * Consequently, if reset_idx is set, reset control is implicit: the clock > + * consumer does not need its own reset handling, as enabling the clock will > + * also deassert reset. > + * > + * There are some gates that do not have an associated reset; these are > + * handled by using -1 as the index for the reset, and the consumer must > + * explictly assert/deassert reset lines as required. > + * > * Clocks marked with CLK_IS_CRITICAL: > * > * ref0 and ref1 are essential for the SoC to operate > -- > 2.39.1 >
