| Message ID | 20210908111337.v2.1.I006bb36063555079b1a88f01d20e38d7e4705ae0@changeid (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2,1/3] clk: rockchip: rk3399: make CPU clocks critical | expand |
Hi, On Wed, Sep 8, 2021 at 11:14 AM Brian Norris <briannorris@chromium.org> wrote: > > The CPU clocks don't currently have any owner (e.g., cpufreq-dt doesn't > enable() them -- and even if it did, it's not early enough compared to > other consumers -- nor does arch/arm64/kernel/smp.c), and instead are > simply assumed to be "on" all the time. > > They are also parents of a few other clocks which haven't been > previously exposed for other devices to consume. If we want to expose > those clocks, then the common clock framework may eventually choose to > disable their parents (including the CPU PLLs) -- which is no fun for > anyone. > > Thus, mark the CPU clocks as critical, to prevent them from being > disabled implicitly. > > Signed-off-by: Brian Norris <briannorris@chromium.org> > --- > > Changes in v2: > - New, split from the patch that requires this change > > drivers/clk/rockchip/clk-rk3399.c | 11 +++++++---- > 1 file changed, 7 insertions(+), 4 deletions(-) Reviewed-by: Douglas Anderson <dianders@chromium.org>
On Thu, Sep 9, 2021 at 3:44 AM Doug Anderson <dianders@chromium.org> wrote: > > Hi, > > On Wed, Sep 8, 2021 at 11:14 AM Brian Norris <briannorris@chromium.org> wrote: > > > > The CPU clocks don't currently have any owner (e.g., cpufreq-dt doesn't > > enable() them -- and even if it did, it's not early enough compared to > > other consumers -- nor does arch/arm64/kernel/smp.c), and instead are > > simply assumed to be "on" all the time. > > > > They are also parents of a few other clocks which haven't been > > previously exposed for other devices to consume. If we want to expose > > those clocks, then the common clock framework may eventually choose to > > disable their parents (including the CPU PLLs) -- which is no fun for > > anyone. > > > > Thus, mark the CPU clocks as critical, to prevent them from being > > disabled implicitly. > > > > Signed-off-by: Brian Norris <briannorris@chromium.org> > > --- > > > > Changes in v2: > > - New, split from the patch that requires this change > > > > drivers/clk/rockchip/clk-rk3399.c | 11 +++++++---- > > 1 file changed, 7 insertions(+), 4 deletions(-) > > Reviewed-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
On Wed, 8 Sep 2021 11:13:38 -0700, Brian Norris wrote: > The CPU clocks don't currently have any owner (e.g., cpufreq-dt doesn't > enable() them -- and even if it did, it's not early enough compared to > other consumers -- nor does arch/arm64/kernel/smp.c), and instead are > simply assumed to be "on" all the time. > > They are also parents of a few other clocks which haven't been > previously exposed for other devices to consume. If we want to expose > those clocks, then the common clock framework may eventually choose to > disable their parents (including the CPU PLLs) -- which is no fun for > anyone. > > [...] Applied, thanks! [1/3] clk: rockchip: rk3399: make CPU clocks critical commit: ef087b7ecf8aaeb08a17ae825f10cd94e116616e [2/3] clk: rockchip: rk3399: expose PCLK_COREDBG_{B,L} commit: bd2c1f664ea647d8f66fbe083f9256511d4f2b9a [3/3] arm64: dts: rockchip: add Coresight debug range for RK3399 commit: 75dccea503b8e176ad044175e891d7bb291b6ba0 Best regards,
diff --git a/drivers/clk/rockchip/clk-rk3399.c b/drivers/clk/rockchip/clk-rk3399.c index 62a4f2543960..0ac9c72c4ee8 100644 --- a/drivers/clk/rockchip/clk-rk3399.c +++ b/drivers/clk/rockchip/clk-rk3399.c @@ -1514,7 +1514,10 @@ static const char *const rk3399_cru_critical_clocks[] __initconst = { "aclk_vio_noc", /* ddrc */ - "sclk_ddrc" + "sclk_ddrc", + + "armclkl", + "armclkb", }; static const char *const rk3399_pmucru_critical_clocks[] __initconst = { @@ -1549,9 +1552,6 @@ static void __init rk3399_clk_init(struct device_node *np) rockchip_clk_register_branches(ctx, rk3399_clk_branches, ARRAY_SIZE(rk3399_clk_branches)); - rockchip_clk_protect_critical(rk3399_cru_critical_clocks, - ARRAY_SIZE(rk3399_cru_critical_clocks)); - rockchip_clk_register_armclk(ctx, ARMCLKL, "armclkl", mux_armclkl_p, ARRAY_SIZE(mux_armclkl_p), &rk3399_cpuclkl_data, rk3399_cpuclkl_rates, @@ -1562,6 +1562,9 @@ static void __init rk3399_clk_init(struct device_node *np) &rk3399_cpuclkb_data, rk3399_cpuclkb_rates, ARRAY_SIZE(rk3399_cpuclkb_rates)); + rockchip_clk_protect_critical(rk3399_cru_critical_clocks, + ARRAY_SIZE(rk3399_cru_critical_clocks)); + rockchip_register_softrst(np, 21, reg_base + RK3399_SOFTRST_CON(0), ROCKCHIP_SOFTRST_HIWORD_MASK);
The CPU clocks don't currently have any owner (e.g., cpufreq-dt doesn't enable() them -- and even if it did, it's not early enough compared to other consumers -- nor does arch/arm64/kernel/smp.c), and instead are simply assumed to be "on" all the time. They are also parents of a few other clocks which haven't been previously exposed for other devices to consume. If we want to expose those clocks, then the common clock framework may eventually choose to disable their parents (including the CPU PLLs) -- which is no fun for anyone. Thus, mark the CPU clocks as critical, to prevent them from being disabled implicitly. Signed-off-by: Brian Norris <briannorris@chromium.org> --- Changes in v2: - New, split from the patch that requires this change drivers/clk/rockchip/clk-rk3399.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)