Re: [PATCH 2/2] clk: imx: disable i.mx7ulp composite clock during initialization

[Stephen Boyd]

Quoting Anson Huang (2019-04-24 22:19:12)
> i.MX7ULP peripheral clock ONLY allow parent/rate to be changed
> with clock gated, however, during clock tree initialization, the
> peripheral clock could be enabled by bootloader, but the prepare
> count in clock tree is still zero, so clock core driver will allow
> parent/rate changed even with CLK_SET_RATE_GATE/CLK_SET_PARENT_GATE

That's a bug. Can you send a patch to fix the core framework code to
fail an assigned rate or parent change if those flags are set? Or is
that because the core doesn't respect these flags when they're buried in
the middle of the clk tree and some rate or parent change comes in and
affects the middle of the tree that has the flag set on it?

> set, but the change will fail due to HW NOT allow parent/rate change
> with clock enabled. It will cause clock HW status mismatch with
> clock tree info and lead to function issue. Below is an example:
> 
> usdhc0's pcc clock value is 0xC5000000 during kernel boot up, it
> means usdhc0 clock is enabled, its parent is APLL_PFD1. In DT file,
> the usdhc0 clock settings are as below:
> 
> assigned-clocks = <&pcc2 IMX7ULP_CLK_USDHC0>;
> assigned-clock-parents = <&scg1 IMX7ULP_CLK_NIC1_DIV>;
> 
> when kernel boot up, the clock tree info is as below, but the usdhc0
> PCC register is still 0xC5000000, which means its parent is still
> from APLL_PFD1, which is incorrect and cause usdhc0 NOT work.
> 
> nic1_clk       2        2        0   176000000          0     0  50000
>     usdhc0       0        0        0   176000000          0     0  50000
> 
> After making sure the peripheral clock is disabled during clock tree
> initialization, the usdhc0 is working, and this change is necessary
> for all i.MX7ULP peripheral clocks.
> 
> Signed-off-by: Anson Huang <Anson.Huang@xxxxxxx>
> ---
>  drivers/clk/imx/clk-composite-7ulp.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/drivers/clk/imx/clk-composite-7ulp.c b/drivers/clk/imx/clk-composite-7ulp.c
> index 060f860..1a05411 100644
> --- a/drivers/clk/imx/clk-composite-7ulp.c
> +++ b/drivers/clk/imx/clk-composite-7ulp.c
> @@ -32,6 +32,7 @@ struct clk_hw *imx7ulp_clk_composite(const char *name,
>         struct clk_gate *gate = NULL;
>         struct clk_mux *mux = NULL;
>         struct clk_hw *hw;
> +       u32 val;
>  
>         if (mux_present) {
>                 mux = kzalloc(sizeof(*mux), GFP_KERNEL);
> @@ -70,6 +71,18 @@ struct clk_hw *imx7ulp_clk_composite(const char *name,
>                 gate_hw = &gate->hw;
>                 gate->reg = reg;
>                 gate->bit_idx = PCG_CGC_SHIFT;
> +               /*
> +                * make sure clock is gated during clock tree initialization,
> +                * the HW ONLY allow clock parent/rate changed with clock gated,
> +                * during clock tree initialization, clocks could be enabled
> +                * by bootloader, so the HW status will mismatch with clock tree
> +                * prepare count, then clock core driver will allow parent/rate
> +                * change since the prepare count is zero, but HW actually
> +                * prevent the parent/rate change due to the clock is enabled.
> +                */

Is it OK to forcibly gate the clk like this at init time? If so, why
can't we force the clk off when we change the rate and then restore the
on state after changing the rate? That would be more "robust" than doing
it once here. Plus then we could remove the CLK_SET_RATE_GATE flag.

> +               val = readl_relaxed(reg);
> +               val &= ~(1 << PCG_CGC_SHIFT);
> +               writel_relaxed(val, reg);
>         }
>