It is possible that a PFD is enabled in HW but not in SW. That means the enable count & prepare count of the PFD clock is '0', so the 'CLK_SET_RATE' flag can do nothing when the rate is changed while the PFD is hw enabled. In order to safely change the pfd rate, we can disable the PFD directly if it is hw enabled but not used by SW end user. Signed-off-by: Jacky Bai <ping.bai@xxxxxxx> --- drivers/clk/imx/clk-pfdv2.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) diff --git a/drivers/clk/imx/clk-pfdv2.c b/drivers/clk/imx/clk-pfdv2.c index 6b744c84278e..9cba83521988 100644 --- a/drivers/clk/imx/clk-pfdv2.c +++ b/drivers/clk/imx/clk-pfdv2.c @@ -161,8 +161,17 @@ static int clk_pfdv2_set_rate(struct clk_hw *hw, unsigned long rate, if (!rate) return -EINVAL; - /* PFD can NOT change rate without gating */ - WARN_ON(clk_pfdv2_is_enabled(hw)); + /* + * PFD can NOT change rate without gating. + * as the PFDs may enabled in HW by default but no + * consumer used it, the enable count is '0', so the + * 'SET_RATE_GATE' can NOT help on blocking the set_rate + * ops especially for 'assigned-clock-xxx'. In order + * to simplify the case, just disable the PFD if it is + * enabled in HW but not in SW. + */ + if (clk_pfdv2_is_enabled(hw)) + clk_pfdv2_disable(hw); tmp = tmp * 18 + rate / 2; do_div(tmp, rate); -- 2.26.2
