From: Douglas Anderson <dianders@chromium.org> To: Heiko Stuebner <heiko@sntech.de> Cc: Michael Turquette <mturquette@baylibre.com>, Stephen Boyd <sboyd@kernel.org>, Caesar Wang <caesar.wang@rock-chips.com>, linux-rockchip@lists.infradead.org, mka@chromium.org, ryandcase@chromium.org, Elaine Zhang <zhangqing@rock-chips.com>, linux-clk@vger.kernel.org, Douglas Anderson <dianders@chromium.org>, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [PATCH 1/3] Revert "clk: rockchip: mark noc and some special clk as critical on rk3288" Date: Tue, 9 Apr 2019 13:47:05 -0700 [thread overview] Message-ID: <20190409204707.150347-2-dianders@chromium.org> (raw) In-Reply-To: <20190409204707.150347-1-dianders@chromium.org> This reverts commit 55bb6a633c33caf68ab470907ecf945289cb733d. The clocks that were enabled by that patch are pretty questionable. Specifically looking at what has been shipping on rk3288-veyron Chromebooks almost all of these clocks are safely turned off and cause no apparent problems. If some boards need these clocks turned on for some reason then it seems like we should figure out how to do that at a board level. NOTE: turning these clocks off doesn't seem to do a whole lot in terms of power savings (checking the power on the logic rail). It appears to save maybe 1-2mW. ...but still it seems like we should turn the clocks off if they aren't needed. Digging into the clocks here to describe why they shouldn't need to be left on: atclk: No documentation about this clock other than that it goes to the CPU. CPU functions fine without it on. jtag: Presumably this clock is only needed if you're debugging with JTAG. It doesn't seem like it makes sense to waste power for every rk3288 user. Perhaps this could be turned on with a CONFIG option? pclk_dbg, pclk_core_niu: On veyron Chromebooks we turn these two clocks on only during kernel panics in order to access some coresight registers. Since nothing in the upstream kernel does this we should be able to leave them off safely. hsicphy12m_xin12m: There is no indication of why this clock would need to be turned on for boards that don't use HSIC. pclk_ddrupctl[0-1], pclk_publ0[0-1]: On veyron Chromebooks we turn these 4 clocks on only when doing DDR transitions and they are off otherwise. I see no reason why they'd need to be on in the upstream kernel which doesn't support DDRFreq. pmu_hclk_otg0: A "chip design defect" is mentioned in the original patch but no details. This clock has always been gated in shipping veyron Chromebooks so presumably this chip defect doesn't affect all boards. Signed-off-by: Douglas Anderson <dianders@chromium.org> --- drivers/clk/rockchip/clk-rk3288.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/clk/rockchip/clk-rk3288.c b/drivers/clk/rockchip/clk-rk3288.c index 5a67b7869960..06287810474e 100644 --- a/drivers/clk/rockchip/clk-rk3288.c +++ b/drivers/clk/rockchip/clk-rk3288.c @@ -313,13 +313,13 @@ static struct rockchip_clk_branch rk3288_clk_branches[] __initdata = { COMPOSITE_NOMUX(0, "aclk_core_mp", "armclk", CLK_IGNORE_UNUSED, RK3288_CLKSEL_CON(0), 4, 4, DFLAGS | CLK_DIVIDER_READ_ONLY, RK3288_CLKGATE_CON(12), 6, GFLAGS), - COMPOSITE_NOMUX(0, "atclk", "armclk", CLK_IGNORE_UNUSED, + COMPOSITE_NOMUX(0, "atclk", "armclk", 0, RK3288_CLKSEL_CON(37), 4, 5, DFLAGS | CLK_DIVIDER_READ_ONLY, RK3288_CLKGATE_CON(12), 7, GFLAGS), COMPOSITE_NOMUX(0, "pclk_dbg_pre", "armclk", CLK_IGNORE_UNUSED, RK3288_CLKSEL_CON(37), 9, 5, DFLAGS | CLK_DIVIDER_READ_ONLY, RK3288_CLKGATE_CON(12), 8, GFLAGS), - GATE(0, "pclk_dbg", "pclk_dbg_pre", CLK_IGNORE_UNUSED, + GATE(0, "pclk_dbg", "pclk_dbg_pre", 0, RK3288_CLKGATE_CON(12), 9, GFLAGS), GATE(0, "cs_dbg", "pclk_dbg_pre", CLK_IGNORE_UNUSED, RK3288_CLKGATE_CON(12), 10, GFLAGS), @@ -647,7 +647,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[] __initdata = { INVERTER(SCLK_HSADC, "sclk_hsadc", "sclk_hsadc_out", RK3288_CLKSEL_CON(22), 7, IFLAGS), - GATE(0, "jtag", "ext_jtag", CLK_IGNORE_UNUSED, + GATE(0, "jtag", "ext_jtag", 0, RK3288_CLKGATE_CON(4), 14, GFLAGS), COMPOSITE_NODIV(SCLK_USBPHY480M_SRC, "usbphy480m_src", mux_usbphy480m_p, 0, @@ -656,7 +656,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[] __initdata = { COMPOSITE_NODIV(SCLK_HSICPHY480M, "sclk_hsicphy480m", mux_hsicphy480m_p, 0, RK3288_CLKSEL_CON(29), 0, 2, MFLAGS, RK3288_CLKGATE_CON(3), 6, GFLAGS), - GATE(0, "hsicphy12m_xin12m", "xin12m", CLK_IGNORE_UNUSED, + GATE(0, "hsicphy12m_xin12m", "xin12m", 0, RK3288_CLKGATE_CON(13), 9, GFLAGS), DIV(0, "hsicphy12m_usbphy", "sclk_hsicphy480m", 0, RK3288_CLKSEL_CON(11), 8, 6, DFLAGS), @@ -837,12 +837,6 @@ static const char *const rk3288_critical_clocks[] __initconst = { "pclk_alive_niu", "pclk_pd_pmu", "pclk_pmu_niu", - "pclk_core_niu", - "pclk_ddrupctl0", - "pclk_publ0", - "pclk_ddrupctl1", - "pclk_publ1", - "pmu_hclk_otg0", }; static void __iomem *rk3288_cru_base; -- 2.21.0.392.gf8f6787159e-goog
WARNING: multiple messages have this Message-ID (diff)
From: Douglas Anderson <dianders@chromium.org> To: Heiko Stuebner <heiko@sntech.de> Cc: Stephen Boyd <sboyd@kernel.org>, Michael Turquette <mturquette@baylibre.com>, Elaine Zhang <zhangqing@rock-chips.com>, Douglas Anderson <dianders@chromium.org>, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, mka@chromium.org, ryandcase@chromium.org, Caesar Wang <caesar.wang@rock-chips.com>, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org Subject: [PATCH 1/3] Revert "clk: rockchip: mark noc and some special clk as critical on rk3288" Date: Tue, 9 Apr 2019 13:47:05 -0700 [thread overview] Message-ID: <20190409204707.150347-2-dianders@chromium.org> (raw) In-Reply-To: <20190409204707.150347-1-dianders@chromium.org> This reverts commit 55bb6a633c33caf68ab470907ecf945289cb733d. The clocks that were enabled by that patch are pretty questionable. Specifically looking at what has been shipping on rk3288-veyron Chromebooks almost all of these clocks are safely turned off and cause no apparent problems. If some boards need these clocks turned on for some reason then it seems like we should figure out how to do that at a board level. NOTE: turning these clocks off doesn't seem to do a whole lot in terms of power savings (checking the power on the logic rail). It appears to save maybe 1-2mW. ...but still it seems like we should turn the clocks off if they aren't needed. Digging into the clocks here to describe why they shouldn't need to be left on: atclk: No documentation about this clock other than that it goes to the CPU. CPU functions fine without it on. jtag: Presumably this clock is only needed if you're debugging with JTAG. It doesn't seem like it makes sense to waste power for every rk3288 user. Perhaps this could be turned on with a CONFIG option? pclk_dbg, pclk_core_niu: On veyron Chromebooks we turn these two clocks on only during kernel panics in order to access some coresight registers. Since nothing in the upstream kernel does this we should be able to leave them off safely. hsicphy12m_xin12m: There is no indication of why this clock would need to be turned on for boards that don't use HSIC. pclk_ddrupctl[0-1], pclk_publ0[0-1]: On veyron Chromebooks we turn these 4 clocks on only when doing DDR transitions and they are off otherwise. I see no reason why they'd need to be on in the upstream kernel which doesn't support DDRFreq. pmu_hclk_otg0: A "chip design defect" is mentioned in the original patch but no details. This clock has always been gated in shipping veyron Chromebooks so presumably this chip defect doesn't affect all boards. Signed-off-by: Douglas Anderson <dianders@chromium.org> --- drivers/clk/rockchip/clk-rk3288.c | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/drivers/clk/rockchip/clk-rk3288.c b/drivers/clk/rockchip/clk-rk3288.c index 5a67b7869960..06287810474e 100644 --- a/drivers/clk/rockchip/clk-rk3288.c +++ b/drivers/clk/rockchip/clk-rk3288.c @@ -313,13 +313,13 @@ static struct rockchip_clk_branch rk3288_clk_branches[] __initdata = { COMPOSITE_NOMUX(0, "aclk_core_mp", "armclk", CLK_IGNORE_UNUSED, RK3288_CLKSEL_CON(0), 4, 4, DFLAGS | CLK_DIVIDER_READ_ONLY, RK3288_CLKGATE_CON(12), 6, GFLAGS), - COMPOSITE_NOMUX(0, "atclk", "armclk", CLK_IGNORE_UNUSED, + COMPOSITE_NOMUX(0, "atclk", "armclk", 0, RK3288_CLKSEL_CON(37), 4, 5, DFLAGS | CLK_DIVIDER_READ_ONLY, RK3288_CLKGATE_CON(12), 7, GFLAGS), COMPOSITE_NOMUX(0, "pclk_dbg_pre", "armclk", CLK_IGNORE_UNUSED, RK3288_CLKSEL_CON(37), 9, 5, DFLAGS | CLK_DIVIDER_READ_ONLY, RK3288_CLKGATE_CON(12), 8, GFLAGS), - GATE(0, "pclk_dbg", "pclk_dbg_pre", CLK_IGNORE_UNUSED, + GATE(0, "pclk_dbg", "pclk_dbg_pre", 0, RK3288_CLKGATE_CON(12), 9, GFLAGS), GATE(0, "cs_dbg", "pclk_dbg_pre", CLK_IGNORE_UNUSED, RK3288_CLKGATE_CON(12), 10, GFLAGS), @@ -647,7 +647,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[] __initdata = { INVERTER(SCLK_HSADC, "sclk_hsadc", "sclk_hsadc_out", RK3288_CLKSEL_CON(22), 7, IFLAGS), - GATE(0, "jtag", "ext_jtag", CLK_IGNORE_UNUSED, + GATE(0, "jtag", "ext_jtag", 0, RK3288_CLKGATE_CON(4), 14, GFLAGS), COMPOSITE_NODIV(SCLK_USBPHY480M_SRC, "usbphy480m_src", mux_usbphy480m_p, 0, @@ -656,7 +656,7 @@ static struct rockchip_clk_branch rk3288_clk_branches[] __initdata = { COMPOSITE_NODIV(SCLK_HSICPHY480M, "sclk_hsicphy480m", mux_hsicphy480m_p, 0, RK3288_CLKSEL_CON(29), 0, 2, MFLAGS, RK3288_CLKGATE_CON(3), 6, GFLAGS), - GATE(0, "hsicphy12m_xin12m", "xin12m", CLK_IGNORE_UNUSED, + GATE(0, "hsicphy12m_xin12m", "xin12m", 0, RK3288_CLKGATE_CON(13), 9, GFLAGS), DIV(0, "hsicphy12m_usbphy", "sclk_hsicphy480m", 0, RK3288_CLKSEL_CON(11), 8, 6, DFLAGS), @@ -837,12 +837,6 @@ static const char *const rk3288_critical_clocks[] __initconst = { "pclk_alive_niu", "pclk_pd_pmu", "pclk_pmu_niu", - "pclk_core_niu", - "pclk_ddrupctl0", - "pclk_publ0", - "pclk_ddrupctl1", - "pclk_publ1", - "pmu_hclk_otg0", }; static void __iomem *rk3288_cru_base; -- 2.21.0.392.gf8f6787159e-goog _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-04-09 20:47 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-09 20:47 [PATCH 0/3] rockchip: A few clock cleanups for rk3288 Douglas Anderson 2019-04-09 20:47 ` Douglas Anderson 2019-04-09 20:47 ` Douglas Anderson [this message] 2019-04-09 20:47 ` [PATCH 1/3] Revert "clk: rockchip: mark noc and some special clk as critical on rk3288" Douglas Anderson 2019-04-10 6:23 ` elaine.zhang 2019-04-10 6:23 ` elaine.zhang 2019-04-10 15:34 ` Doug Anderson 2019-04-10 15:34 ` Doug Anderson [not found] ` <1491b5f1-e9f9-5718-76e5-0a49814ed76d@rock-chips.com> 2019-04-11 15:26 ` Doug Anderson 2019-04-11 15:26 ` Doug Anderson 2019-04-11 22:05 ` Heiko Stübner 2019-04-11 22:05 ` Heiko Stübner 2019-04-12 1:43 ` elaine.zhang 2019-04-12 1:43 ` elaine.zhang 2019-04-12 15:41 ` Doug Anderson 2019-04-12 15:41 ` Doug Anderson 2019-04-09 20:47 ` [PATCH 2/3] clk: rockchip: Make rkpwm a critical clock on rk3288 Douglas Anderson 2019-04-09 20:47 ` Douglas Anderson 2019-04-09 20:47 ` Douglas Anderson 2019-04-10 6:42 ` elaine.zhang 2019-04-10 15:25 ` Doug Anderson 2019-04-10 15:25 ` Doug Anderson 2019-04-11 3:42 ` elaine.zhang 2019-04-11 3:42 ` elaine.zhang 2019-04-11 14:42 ` Doug Anderson 2019-04-11 14:42 ` Doug Anderson 2019-04-11 19:20 ` Heiko Stübner 2019-04-11 19:20 ` Heiko Stübner 2019-04-11 19:27 ` Heiko Stübner 2019-04-11 19:27 ` Heiko Stübner 2019-04-09 20:47 ` [PATCH 3/3] ARM: dts: rockchip: fix PWM clock found on RK3288 Socs Douglas Anderson 2019-04-09 20:47 ` Douglas Anderson 2019-04-11 19:29 ` Heiko Stübner 2019-04-11 19:29 ` Heiko Stübner
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190409204707.150347-2-dianders@chromium.org \ --to=dianders@chromium.org \ --cc=caesar.wang@rock-chips.com \ --cc=heiko@sntech.de \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-clk@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-rockchip@lists.infradead.org \ --cc=mka@chromium.org \ --cc=mturquette@baylibre.com \ --cc=ryandcase@chromium.org \ --cc=sboyd@kernel.org \ --cc=zhangqing@rock-chips.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.