Message ID | 1470143599-8851-1-git-send-email-zhengxing@rock-chips.com (mailing list archive) |
---|---|
State | Not Applicable, archived |
Headers | show |
Xing, On Tue, Aug 2, 2016 at 6:13 AM, Xing Zheng <zhengxing@rock-chips.com> wrote: > From: Elaine Zhang <zhangqing@rock-chips.com> > > The suggestion that is from IC designer, the correct pll sequence setting > should be like these: > ---- > set pll to slow mode or other plls > set pll down > set pll params > set pll up > wait pll lock status > set pll to normal mode > ---- > > Hence, there are potential risks that we need to fix: > rockchip_rk3399_wait_pll_lock - timeout waiting for pll to lock > rockchip_rk3399_pll_set_params - pll update unsucessful, trying to restore old params I still don't understand how that groks with the statement in the TRM: > In most cases the PLL programming can be changed on-the-fly and the PLL will simply slew to the new frequency That makes it sound like these PLLs are super great at dynamic updates. -- To unsubscribe from this list: send the line "unsubscribe linux-clk" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Doug, On 2016年08月03日 08:49, Doug Anderson wrote: > Xing, > > On Tue, Aug 2, 2016 at 6:13 AM, Xing Zheng <zhengxing@rock-chips.com> wrote: >> From: Elaine Zhang <zhangqing@rock-chips.com> >> >> The suggestion that is from IC designer, the correct pll sequence setting >> should be like these: >> ---- >> set pll to slow mode or other plls >> set pll down >> set pll params >> set pll up >> wait pll lock status >> set pll to normal mode >> ---- >> >> Hence, there are potential risks that we need to fix: >> rockchip_rk3399_wait_pll_lock - timeout waiting for pll to lock >> rockchip_rk3399_pll_set_params - pll update unsucessful, trying to restore old params > I still don't understand how that groks with the statement in the TRM: > >> In most cases the PLL programming can be changed on-the-fly and the PLL will simply slew to the new frequency > That makes it sound like these PLLs are super great at dynamic updates. > > Well, I will report it to IC & Doc folkers to update the TRM and make it clear. Thanks.
diff --git a/drivers/clk/rockchip/clk-pll.c b/drivers/clk/rockchip/clk-pll.c index db81e45..35994e8 100644 --- a/drivers/clk/rockchip/clk-pll.c +++ b/drivers/clk/rockchip/clk-pll.c @@ -681,6 +681,11 @@ static int rockchip_rk3399_pll_set_params(struct rockchip_clk_pll *pll, rate_change_remuxed = 1; } + /* set pll power down */ + writel(HIWORD_UPDATE(RK3399_PLLCON3_PWRDOWN, + RK3399_PLLCON3_PWRDOWN, 0), + pll->reg_base + RK3399_PLLCON(3)); + /* update pll values */ writel_relaxed(HIWORD_UPDATE(rate->fbdiv, RK3399_PLLCON0_FBDIV_MASK, RK3399_PLLCON0_FBDIV_SHIFT), @@ -704,6 +709,11 @@ static int rockchip_rk3399_pll_set_params(struct rockchip_clk_pll *pll, RK3399_PLLCON3_DSMPD_SHIFT), pll->reg_base + RK3399_PLLCON(3)); + /* set pll power up */ + writel(HIWORD_UPDATE(0, + RK3399_PLLCON3_PWRDOWN, 0), + pll->reg_base + RK3399_PLLCON(3)); + /* wait for the pll to lock */ ret = rockchip_rk3399_pll_wait_lock(pll); if (ret) {