diff mbox

[v4,5/8] clk: rockchip: Allow the RK3288 SPDIF clocks to change their parent

Message ID 1444311079-2892-6-git-send-email-sjoerd.simons@collabora.co.uk (mailing list archive)
State New, archived
Headers show

Commit Message

Sjoerd Simons Oct. 8, 2015, 1:31 p.m. UTC
The clock branches leading to sclk_spdif and sclk_spdif_8ch on RK3288
SoCs only feed those clocks, allow those clocks to change their parents
all the way up the hierarchy.

Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
---

Changes in v4: None
Changes in v3: None
Changes in v2: None

 drivers/clk/rockchip/clk-rk3288.c | 16 ++++++++--------
 1 file changed, 8 insertions(+), 8 deletions(-)

Comments

Heiko Stuebner Oct. 8, 2015, 3:10 p.m. UTC | #1
Am Donnerstag, 8. Oktober 2015, 15:31:16 schrieb Sjoerd Simons:
> The clock branches leading to sclk_spdif and sclk_spdif_8ch on RK3288
> SoCs only feed those clocks, allow those clocks to change their parents
> all the way up the hierarchy.
> 
> Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>

Just as comment, if I'm seeing that right, this patch needs "clk: rockchip: 
handle mux dependency of fractional dividers" and friends [0] to apply and 
also actually handle the fractional dividers correctly.

For the clock change itself:
Reviewed-by: Heiko Stuebner <heiko@sntech.de>


Heiko

[0] http://lists.infradead.org/pipermail/linux-rockchip/2015-August/003930.html


> ---
> 
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None
> 
>  drivers/clk/rockchip/clk-rk3288.c | 16 ++++++++--------
>  1 file changed, 8 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/clk/rockchip/clk-rk3288.c
> b/drivers/clk/rockchip/clk-rk3288.c index 90c1c9b..4e90252 100644
> --- a/drivers/clk/rockchip/clk-rk3288.c
> +++ b/drivers/clk/rockchip/clk-rk3288.c
> @@ -317,25 +317,25 @@ static struct rockchip_clk_branch
> rk3288_clk_branches[] __initdata = {
> 
>  	MUX(0, "spdif_src", mux_pll_src_cpll_gpll_p, 0,
>  			RK3288_CLKSEL_CON(5), 15, 1, MFLAGS),
> -	COMPOSITE_NOMUX(0, "spdif_pre", "spdif_src", 0,
> +	COMPOSITE_NOMUX(0, "spdif_pre", "spdif_src", CLK_SET_RATE_PARENT,
>  			RK3288_CLKSEL_CON(5), 0, 7, DFLAGS,
>  			RK3288_CLKGATE_CON(4), 4, GFLAGS),
> -	COMPOSITE_FRACMUX(0, "spdif_frac", "spdif_src", 0,
> +	COMPOSITE_FRACMUX(0, "spdif_frac", "spdif_src", CLK_SET_RATE_PARENT,
>  			RK3288_CLKSEL_CON(9), 0,
>  			RK3288_CLKGATE_CON(4), 5, GFLAGS,
> -		MUX(0, "spdif_mux", mux_spdif_p, 0,
> +		MUX(0, "spdif_mux", mux_spdif_p, CLK_SET_RATE_PARENT,
>  				RK3288_CLKSEL_CON(5), 8, 2, MFLAGS)),
> -	GATE(SCLK_SPDIF, "sclk_spdif", "spdif_mux", 0,
> +	GATE(SCLK_SPDIF, "sclk_spdif", "spdif_mux", CLK_SET_RATE_PARENT,
>  			RK3288_CLKGATE_CON(4), 6, GFLAGS),
> -	COMPOSITE_NOMUX(0, "spdif_8ch_pre", "spdif_src", 0,
> +	COMPOSITE_NOMUX(0, "spdif_8ch_pre", "spdif_src", CLK_SET_RATE_PARENT,
>  			RK3288_CLKSEL_CON(40), 0, 7, DFLAGS,
>  			RK3288_CLKGATE_CON(4), 7, GFLAGS),
> -	COMPOSITE_FRACMUX(0, "spdif_8ch_frac", "spdif_8ch_pre", 0,
> +	COMPOSITE_FRACMUX(0, "spdif_8ch_frac", "spdif_8ch_pre",
> CLK_SET_RATE_PARENT, RK3288_CLKSEL_CON(41), 0,
>  			RK3288_CLKGATE_CON(4), 8, GFLAGS,
> -		MUX(0, "spdif_8ch_mux", mux_spdif_8ch_p, 0,
> +		MUX(0, "spdif_8ch_mux", mux_spdif_8ch_p, CLK_SET_RATE_PARENT,
>  				RK3288_CLKSEL_CON(40), 8, 2, MFLAGS)),
> -	GATE(SCLK_SPDIF8CH, "sclk_spdif_8ch", "spdif_8ch_mux", 0,
> +	GATE(SCLK_SPDIF8CH, "sclk_spdif_8ch", "spdif_8ch_mux",
> CLK_SET_RATE_PARENT, RK3288_CLKGATE_CON(4), 9, GFLAGS),
> 
>  	GATE(0, "sclk_acc_efuse", "xin24m", 0,
Sjoerd Simons Oct. 9, 2015, 11:35 a.m. UTC | #2
Hey Heiko,

On Thu, 2015-10-08 at 17:10 +0200, Heiko Stuebner wrote:
> Am Donnerstag, 8. Oktober 2015, 15:31:16 schrieb Sjoerd Simons:
> > The clock branches leading to sclk_spdif and sclk_spdif_8ch on
> > RK3288
> > SoCs only feed those clocks, allow those clocks to change their
> > parents
> > all the way up the hierarchy.
> > 
> > Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
> 
> Just as comment, if I'm seeing that right, this patch needs "clk:
> rockchip: 
> handle mux dependency of fractional dividers" and friends [0] to
> apply and 
> also actually handle the fractional dividers correctly.
> 
> For the clock change itself:
> Reviewed-by: Heiko Stuebner <heiko@sntech.de>

Oh sorry yes, i completely forgot to at that as note on this patch
(series). These are on top of your series as those are required to make
things actually work as expected. 

Which reminds me, i was wondering how to best move that forward. Could
you pick this one up to include it in the next round of your series?
(Otherwise i'm happy to rebase it once you do a v2)

> 
> Heiko
> 
> [0] http://lists.infradead.org/pipermail/linux-rockchip/2015-August/0
> 03930.html
Heiko Stuebner Oct. 11, 2015, 10:43 a.m. UTC | #3
Hi Sjoerd,

Am Freitag, 9. Oktober 2015, 13:35:55 schrieb Sjoerd Simons:
> On Thu, 2015-10-08 at 17:10 +0200, Heiko Stuebner wrote:
> > Am Donnerstag, 8. Oktober 2015, 15:31:16 schrieb Sjoerd Simons:
> > > The clock branches leading to sclk_spdif and sclk_spdif_8ch on
> > > RK3288
> > > SoCs only feed those clocks, allow those clocks to change their
> > > parents
> > > all the way up the hierarchy.
> > > 
> > > Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
> > 
> > Just as comment, if I'm seeing that right, this patch needs "clk:
> > rockchip:
> > handle mux dependency of fractional dividers" and friends [0] to
> > apply and
> > also actually handle the fractional dividers correctly.
> > 
> > For the clock change itself:
> > Reviewed-by: Heiko Stuebner <heiko@sntech.de>
> 
> Oh sorry yes, i completely forgot to at that as note on this patch
> (series). These are on top of your series as those are required to make
> things actually work as expected.
> 
> Which reminds me, i was wondering how to best move that forward. Could
> you pick this one up to include it in the next round of your series?
> (Otherwise i'm happy to rebase it once you do a v2)

I guess that will depend on how the core series gets handled. Aka if there 
needs to be a v2 (depending on the clock maintainers) I can pick that up as 
part of it. Otherwise we'll just need to ping the clock-maintainers separately 
on this patch if necessary.


Heiko
Michael Turquette Oct. 22, 2015, 12:10 p.m. UTC | #4
Quoting Heiko Stübner (2015-10-11 03:43:27)
> Hi Sjoerd,
> 
> Am Freitag, 9. Oktober 2015, 13:35:55 schrieb Sjoerd Simons:
> > On Thu, 2015-10-08 at 17:10 +0200, Heiko Stuebner wrote:
> > > Am Donnerstag, 8. Oktober 2015, 15:31:16 schrieb Sjoerd Simons:
> > > > The clock branches leading to sclk_spdif and sclk_spdif_8ch on
> > > > RK3288
> > > > SoCs only feed those clocks, allow those clocks to change their
> > > > parents
> > > > all the way up the hierarchy.
> > > > 
> > > > Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
> > > 
> > > Just as comment, if I'm seeing that right, this patch needs "clk:
> > > rockchip:
> > > handle mux dependency of fractional dividers" and friends [0] to
> > > apply and
> > > also actually handle the fractional dividers correctly.
> > > 
> > > For the clock change itself:
> > > Reviewed-by: Heiko Stuebner <heiko@sntech.de>
> > 
> > Oh sorry yes, i completely forgot to at that as note on this patch
> > (series). These are on top of your series as those are required to make
> > things actually work as expected.
> > 
> > Which reminds me, i was wondering how to best move that forward. Could
> > you pick this one up to include it in the next round of your series?
> > (Otherwise i'm happy to rebase it once you do a v2)
> 
> I guess that will depend on how the core series gets handled. Aka if there 
> needs to be a v2 (depending on the clock maintainers) I can pick that up as 
> part of it. Otherwise we'll just need to ping the clock-maintainers separately 
> on this patch if necessary.

I've spoken with Heiko on irc about v2 about using the coordinated clock
rates patches for handling the mux/fractional dividers thing. I'd prefer
to use the ccr approach, which puts a delay on that series.

Is there anything wrong with merging this patch #5/8 as-is? Will the
struct clk_core.rate accounting not match the hardware if we set
CLK_SET_PARENT_RATE on these clocks?

Regards,
Mike

> 
> 
> Heiko
>
diff mbox

Patch

diff --git a/drivers/clk/rockchip/clk-rk3288.c b/drivers/clk/rockchip/clk-rk3288.c
index 90c1c9b..4e90252 100644
--- a/drivers/clk/rockchip/clk-rk3288.c
+++ b/drivers/clk/rockchip/clk-rk3288.c
@@ -317,25 +317,25 @@  static struct rockchip_clk_branch rk3288_clk_branches[] __initdata = {
 
 	MUX(0, "spdif_src", mux_pll_src_cpll_gpll_p, 0,
 			RK3288_CLKSEL_CON(5), 15, 1, MFLAGS),
-	COMPOSITE_NOMUX(0, "spdif_pre", "spdif_src", 0,
+	COMPOSITE_NOMUX(0, "spdif_pre", "spdif_src", CLK_SET_RATE_PARENT,
 			RK3288_CLKSEL_CON(5), 0, 7, DFLAGS,
 			RK3288_CLKGATE_CON(4), 4, GFLAGS),
-	COMPOSITE_FRACMUX(0, "spdif_frac", "spdif_src", 0,
+	COMPOSITE_FRACMUX(0, "spdif_frac", "spdif_src", CLK_SET_RATE_PARENT,
 			RK3288_CLKSEL_CON(9), 0,
 			RK3288_CLKGATE_CON(4), 5, GFLAGS,
-		MUX(0, "spdif_mux", mux_spdif_p, 0,
+		MUX(0, "spdif_mux", mux_spdif_p, CLK_SET_RATE_PARENT,
 				RK3288_CLKSEL_CON(5), 8, 2, MFLAGS)),
-	GATE(SCLK_SPDIF, "sclk_spdif", "spdif_mux", 0,
+	GATE(SCLK_SPDIF, "sclk_spdif", "spdif_mux", CLK_SET_RATE_PARENT,
 			RK3288_CLKGATE_CON(4), 6, GFLAGS),
-	COMPOSITE_NOMUX(0, "spdif_8ch_pre", "spdif_src", 0,
+	COMPOSITE_NOMUX(0, "spdif_8ch_pre", "spdif_src", CLK_SET_RATE_PARENT,
 			RK3288_CLKSEL_CON(40), 0, 7, DFLAGS,
 			RK3288_CLKGATE_CON(4), 7, GFLAGS),
-	COMPOSITE_FRACMUX(0, "spdif_8ch_frac", "spdif_8ch_pre", 0,
+	COMPOSITE_FRACMUX(0, "spdif_8ch_frac", "spdif_8ch_pre", CLK_SET_RATE_PARENT,
 			RK3288_CLKSEL_CON(41), 0,
 			RK3288_CLKGATE_CON(4), 8, GFLAGS,
-		MUX(0, "spdif_8ch_mux", mux_spdif_8ch_p, 0,
+		MUX(0, "spdif_8ch_mux", mux_spdif_8ch_p, CLK_SET_RATE_PARENT,
 				RK3288_CLKSEL_CON(40), 8, 2, MFLAGS)),
-	GATE(SCLK_SPDIF8CH, "sclk_spdif_8ch", "spdif_8ch_mux", 0,
+	GATE(SCLK_SPDIF8CH, "sclk_spdif_8ch", "spdif_8ch_mux", CLK_SET_RATE_PARENT,
 			RK3288_CLKGATE_CON(4), 9, GFLAGS),
 
 	GATE(0, "sclk_acc_efuse", "xin24m", 0,