[PATCH v3 0/2] rockchip: fix serial output on rk3036

[PATCH v3 0/2] rockchip: fix serial output on rk3036

[Heiko Stuebner]

Recent changes to the 8250-dw variant revealed issues concerning
how the clock rates are handled on the rk3036 uart.

For one, there was an error in the clock declaration, but also the
shared uart-pll-select-mux also as default got supplied from the apll
that also supplies the cpu and thus gets frequency scaled.

The patches in this series remedy this and make the debug uart
function again on 4.10 + current merge window.


As for the merge-path, I've now tested all Rockchip socs I have access
to (3036, 3288, 3368, 3399) and didn't find any more clock-related issues
with the merge-window as of today. So if no other subtle issue turns up
this week, these should be all fixes for the 4.11 cycle.
So these 2 patches could be picked up by clock-maintainers directly if
so desired, or I can send a pull request after the merge-window closes
and we're save to say that nothing else broke.

changes in v3:
- use a direct register write, instead of using clock apis

changes in v2:
- Fixes tag for the missing ","
- do reparenting in the driver itself
- drop clock-id addition, as they're not needed for the fix anymore

Heiko Stuebner (2):
  clk: rockchip: add "," to mux_pll_src_apll_dpll_gpll_usb480m_p on
    rk3036
  clk: rockchip: Make uartpll a child of the gpll on rk3036

 drivers/clk/rockchip/clk-rk3036.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

-- 
2.11.0

[PATCH v3 0/2] rockchip: fix serial output on rk3036

[Heiko Stuebner]

Recent changes to the 8250-dw variant revealed issues concerning
how the clock rates are handled on the rk3036 uart.

For one, there was an error in the clock declaration, but also the
shared uart-pll-select-mux also as default got supplied from the apll
that also supplies the cpu and thus gets frequency scaled.

The patches in this series remedy this and make the debug uart
function again on 4.10 + current merge window.


As for the merge-path, I've now tested all Rockchip socs I have access
to (3036, 3288, 3368, 3399) and didn't find any more clock-related issues
with the merge-window as of today. So if no other subtle issue turns up
this week, these should be all fixes for the 4.11 cycle.
So these 2 patches could be picked up by clock-maintainers directly if
so desired, or I can send a pull request after the merge-window closes
and we're save to say that nothing else broke.

changes in v3:
- use a direct register write, instead of using clock apis

changes in v2:
- Fixes tag for the missing ","
- do reparenting in the driver itself
- drop clock-id addition, as they're not needed for the fix anymore

Heiko Stuebner (2):
  clk: rockchip: add "," to mux_pll_src_apll_dpll_gpll_usb480m_p on
    rk3036
  clk: rockchip: Make uartpll a child of the gpll on rk3036

 drivers/clk/rockchip/clk-rk3036.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

-- 
2.11.0

[PATCH v3 1/2] clk: rockchip: add "," to mux_pll_src_apll_dpll_gpll_usb480m_p on rk3036

[Heiko Stuebner]

The mux_pll_src_apll_dpll_gpll_usb480m_p parent list was missing a ","
between the 3rd and 4th parent names, making them fall together and thus
lookups fail. Fix that.

Fixes: 5190c08b2989 ("clk: rockchip: add clock controller for rk3036")
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
 drivers/clk/rockchip/clk-rk3036.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-rk3036.c b/drivers/clk/rockchip/clk-rk3036.c
index 924f560dcf80..dcde70f4c105 100644
--- a/drivers/clk/rockchip/clk-rk3036.c
+++ b/drivers/clk/rockchip/clk-rk3036.c
@@ -127,7 +127,7 @@ PNAME(mux_ddrphy_p)		= { "dpll_ddr", "gpll_ddr" };
 PNAME(mux_pll_src_3plls_p)	= { "apll", "dpll", "gpll" };
 PNAME(mux_timer_p)		= { "xin24m", "pclk_peri_src" };
 
-PNAME(mux_pll_src_apll_dpll_gpll_usb480m_p)	= { "apll", "dpll", "gpll" "usb480m" };
+PNAME(mux_pll_src_apll_dpll_gpll_usb480m_p)	= { "apll", "dpll", "gpll", "usb480m" };
 
 PNAME(mux_mmc_src_p)	= { "apll", "dpll", "gpll", "xin24m" };
 PNAME(mux_i2s_pre_p)	= { "i2s_src", "i2s_frac", "ext_i2s", "xin12m" };
-- 
2.11.0

[PATCH v3 1/2] clk: rockchip: add ", " to mux_pll_src_apll_dpll_gpll_usb480m_p on rk3036

[Heiko Stuebner]

The mux_pll_src_apll_dpll_gpll_usb480m_p parent list was missing a ","
between the 3rd and 4th parent names, making them fall together and thus
lookups fail. Fix that.

Fixes: 5190c08b2989 ("clk: rockchip: add clock controller for rk3036")
Signed-off-by: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
---
 drivers/clk/rockchip/clk-rk3036.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/rockchip/clk-rk3036.c b/drivers/clk/rockchip/clk-rk3036.c
index 924f560dcf80..dcde70f4c105 100644
--- a/drivers/clk/rockchip/clk-rk3036.c
+++ b/drivers/clk/rockchip/clk-rk3036.c
@@ -127,7 +127,7 @@ PNAME(mux_ddrphy_p)		= { "dpll_ddr", "gpll_ddr" };
 PNAME(mux_pll_src_3plls_p)	= { "apll", "dpll", "gpll" };
 PNAME(mux_timer_p)		= { "xin24m", "pclk_peri_src" };
 
-PNAME(mux_pll_src_apll_dpll_gpll_usb480m_p)	= { "apll", "dpll", "gpll" "usb480m" };
+PNAME(mux_pll_src_apll_dpll_gpll_usb480m_p)	= { "apll", "dpll", "gpll", "usb480m" };
 
 PNAME(mux_mmc_src_p)	= { "apll", "dpll", "gpll", "xin24m" };
 PNAME(mux_i2s_pre_p)	= { "i2s_src", "i2s_frac", "ext_i2s", "xin12m" };
-- 
2.11.0

[PATCH v3 2/2] clk: rockchip: Make uartpll a child of the gpll on rk3036

[Heiko Stuebner]

The shared uart-pll is on boot a child of the apll that can get changed
by cpu frequency scaling. So move it away to the more stable gpll to
make sure the uart doesn't break on cpu frequency changes.

This turned up during the 4.11 merge-window when commit
6a171b299379 ("serial: 8250_dw: Allow hardware flow control to be used")
added general termios enablement making the uart on rk3036 change
frequency and thus making it susceptible for the frequency scaling issue.

Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
 drivers/clk/rockchip/clk-rk3036.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/clk/rockchip/clk-rk3036.c b/drivers/clk/rockchip/clk-rk3036.c
index dcde70f4c105..00d4150e33c3 100644
--- a/drivers/clk/rockchip/clk-rk3036.c
+++ b/drivers/clk/rockchip/clk-rk3036.c
@@ -450,6 +450,13 @@ static void __init rk3036_clk_init(struct device_node *np)
 		return;
 	}
 
+	/*
+	 * Make uart_pll_clk a child of the gpll, as all other sources are
+	 * not that usable / stable.
+	 */
+	writel_relaxed(HIWORD_UPDATE(0x2, 0x3, 10),
+		       reg_base + RK2928_CLKSEL_CON(13));
+
 	ctx = rockchip_clk_init(np, reg_base, CLK_NR_CLKS);
 	if (IS_ERR(ctx)) {
 		pr_err("%s: rockchip clk init failed\n", __func__);
-- 
2.11.0

[PATCH v3 2/2] clk: rockchip: Make uartpll a child of the gpll on rk3036

[Heiko Stuebner]

The shared uart-pll is on boot a child of the apll that can get changed
by cpu frequency scaling. So move it away to the more stable gpll to
make sure the uart doesn't break on cpu frequency changes.

This turned up during the 4.11 merge-window when commit
6a171b299379 ("serial: 8250_dw: Allow hardware flow control to be used")
added general termios enablement making the uart on rk3036 change
frequency and thus making it susceptible for the frequency scaling issue.

Signed-off-by: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
---
 drivers/clk/rockchip/clk-rk3036.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/clk/rockchip/clk-rk3036.c b/drivers/clk/rockchip/clk-rk3036.c
index dcde70f4c105..00d4150e33c3 100644
--- a/drivers/clk/rockchip/clk-rk3036.c
+++ b/drivers/clk/rockchip/clk-rk3036.c
@@ -450,6 +450,13 @@ static void __init rk3036_clk_init(struct device_node *np)
 		return;
 	}
 
+	/*
+	 * Make uart_pll_clk a child of the gpll, as all other sources are
+	 * not that usable / stable.
+	 */
+	writel_relaxed(HIWORD_UPDATE(0x2, 0x3, 10),
+		       reg_base + RK2928_CLKSEL_CON(13));
+
 	ctx = rockchip_clk_init(np, reg_base, CLK_NR_CLKS);
 	if (IS_ERR(ctx)) {
 		pr_err("%s: rockchip clk init failed\n", __func__);
-- 
2.11.0

Re: [PATCH v3 0/2] rockchip: fix serial output on rk3036

[Stephen Boyd]

On 03/01, Heiko Stuebner wrote:
> Recent changes to the 8250-dw variant revealed issues concerning
> how the clock rates are handled on the rk3036 uart.
> 
> For one, there was an error in the clock declaration, but also the
> shared uart-pll-select-mux also as default got supplied from the apll
> that also supplies the cpu and thus gets frequency scaled.
> 
> The patches in this series remedy this and make the debug uart
> function again on 4.10 + current merge window.
> 
> 
> As for the merge-path, I've now tested all Rockchip socs I have access
> to (3036, 3288, 3368, 3399) and didn't find any more clock-related issues
> with the merge-window as of today. So if no other subtle issue turns up
> this week, these should be all fixes for the 4.11 cycle.
> So these 2 patches could be picked up by clock-maintainers directly if
> so desired, or I can send a pull request after the merge-window closes
> and we're save to say that nothing else broke.
> 
> changes in v3:
> - use a direct register write, instead of using clock apis

Great. I'm happy to merge this into clk-fixes now (and I will do
it now unless you have some need to send a pull request).

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v3 0/2] rockchip: fix serial output on rk3036

[Heiko Stübner]

Am Dienstag, 7. M=E4rz 2017, 05:54:43 CET schrieb Stephen Boyd:
> On 03/01, Heiko Stuebner wrote:
> > Recent changes to the 8250-dw variant revealed issues concerning
> > how the clock rates are handled on the rk3036 uart.
> >=20
> > For one, there was an error in the clock declaration, but also the
> > shared uart-pll-select-mux also as default got supplied from the apll
> > that also supplies the cpu and thus gets frequency scaled.
> >=20
> > The patches in this series remedy this and make the debug uart
> > function again on 4.10 + current merge window.
> >=20
> >=20
> > As for the merge-path, I've now tested all Rockchip socs I have access
> > to (3036, 3288, 3368, 3399) and didn't find any more clock-related issu=
es
> > with the merge-window as of today. So if no other subtle issue turns up
> > this week, these should be all fixes for the 4.11 cycle.
> > So these 2 patches could be picked up by clock-maintainers directly if
> > so desired, or I can send a pull request after the merge-window closes
> > and we're save to say that nothing else broke.
> >=20
> > changes in v3:
> > - use a direct register write, instead of using clock apis
>=20
> Great. I'm happy to merge this into clk-fixes now (and I will do
> it now unless you have some need to send a pull request).

Nope, go ahead ... it seems everything else survived the merge window just =
fine=20
clk-wise

Re: [PATCH v3 0/2] rockchip: fix serial output on rk3036

[Heiko Stübner]

Am Dienstag, 7. März 2017, 05:54:43 CET schrieb Stephen Boyd:
> On 03/01, Heiko Stuebner wrote:
> > Recent changes to the 8250-dw variant revealed issues concerning
> > how the clock rates are handled on the rk3036 uart.
> > 
> > For one, there was an error in the clock declaration, but also the
> > shared uart-pll-select-mux also as default got supplied from the apll
> > that also supplies the cpu and thus gets frequency scaled.
> > 
> > The patches in this series remedy this and make the debug uart
> > function again on 4.10 + current merge window.
> > 
> > 
> > As for the merge-path, I've now tested all Rockchip socs I have access
> > to (3036, 3288, 3368, 3399) and didn't find any more clock-related issues
> > with the merge-window as of today. So if no other subtle issue turns up
> > this week, these should be all fixes for the 4.11 cycle.
> > So these 2 patches could be picked up by clock-maintainers directly if
> > so desired, or I can send a pull request after the merge-window closes
> > and we're save to say that nothing else broke.
> > 
> > changes in v3:
> > - use a direct register write, instead of using clock apis
> 
> Great. I'm happy to merge this into clk-fixes now (and I will do
> it now unless you have some need to send a pull request).

Nope, go ahead ... it seems everything else survived the merge window just fine 
clk-wise