clk: rockchip: rk3399: add pll up and down when change pll freq

Commit Message

zhengxing Aug. 2, 2016, 1:13 p.m. UTC

From: Elaine Zhang <[e-mail]>

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

Signed-off-by: Elaine Zhang <[e-mail]>
Signed-off-by: Xing Zheng <[e-mail]>
---

 drivers/clk/rockchip/clk-pll.c |   10 ++++++++++
 1 file changed, 10 insertions(+)

Comments

Doug Anderson Aug. 3, 2016, 12:49 a.m. UTC | #1

Xing,

On Tue, Aug 2, 2016 at 6:13 AM, Xing Zheng <[e-mail]> wrote:
> From: Elaine Zhang <[e-mail]>
>
> 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.

zhengxing Aug. 3, 2016, 1:25 a.m. UTC | #2

Hi Doug,

On 2016年08月03日 08:49, Doug Anderson wrote:
> Xing,
>
> On Tue, Aug 2, 2016 at 6:13 AM, Xing Zheng <[e-mail]> wrote:
>> From: Elaine Zhang <[e-mail]>
>>
>> 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.

Patch

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) {