[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <58b64e74466a572d472a13515dd481600dd2c63d.camel@icenowy.me>
Date: Thu, 29 Dec 2022 13:22:56 +0800
From: Icenowy Zheng <uwu@...nowy.me>
To: Samuel Holland <samuel@...lland.org>, Chen-Yu Tsai <wens@...e.org>,
Jernej Skrabec <jernej.skrabec@...il.com>
Cc: Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
linux-arm-kernel@...ts.infradead.org, linux-clk@...r.kernel.org,
linux-kernel@...r.kernel.org, linux-sunxi@...ts.linux.dev
Subject: Re: [PATCH] clk: sunxi-ng: h3/h5: Model H3 CLK_DRAM as a fixed clock
在 2022-12-28星期三的 22:22 -0600,Samuel Holland写道:
> The DRAM controller clock is only allowed to change frequency while
> the
> DRAM chips are in self-refresh. To support this, changes to the
> CLK_DRAM
> mux and divider have no effect until acknowledged by the memory
> dynamic
> frequency scaling (MDFS) hardware inside the DRAM controller. (There
> is
> a SDRCLK_UPD bit in DRAM_CFG_REG which should serve a similar
> purpose,
> but this bit actually does nothing.)
>
> However, the MDFS hardware in H3 appears to be broken. Triggering a
> frequency change using the procedure from similar SoCs (A64/H5) hangs
> the hardware. Additionally, the vendor BSP specifically avoids using
> the
> MDFS hardware on H3, instead performing all DRAM PHY parameter
> updates
> and resets in software.
>
> Thus, it is effectively impossible to change the CLK_DRAM
> mux/divider,
> so those features should not be modeled. Add CLK_SET_RATE_PARENT so
> frequency changes apply to PLL_DDR instead.
>
> Signed-off-by: Samuel Holland <samuel@...lland.org>
> ---
>
> drivers/clk/sunxi-ng/ccu-sun8i-h3.c | 15 ++++++++++-----
> 1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c b/drivers/clk/sunxi-
> ng/ccu-sun8i-h3.c
> index d3fcb983c17c..bfebe8dbbe65 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun8i-h3.c
> @@ -434,8 +434,13 @@ static SUNXI_CCU_GATE(usb_ohci2_clk, "usb-
> ohci2", "osc24M",
> static SUNXI_CCU_GATE(usb_ohci3_clk, "usb-ohci3", "osc24M",
> 0x0cc, BIT(19), 0);
>
> -static const char * const dram_parents[] = { "pll-ddr", "pll-
> periph0-2x" };
> -static SUNXI_CCU_M_WITH_MUX(dram_clk, "dram", dram_parents,
> +/* H3 has broken MDFS hardware, so the mux/divider cannot be
> changed. */
> +static CLK_FIXED_FACTOR_HW(h3_dram_clk, "dram",
> + &pll_ddr_clk.common.hw,
> + 1, 1, CLK_SET_RATE_PARENT |
> CLK_IS_CRITICAL);
Should we do some sanity check on the values when probing CCU?
> +
> +static const char * const h5_dram_parents[] = { "pll-ddr", "pll-
> periph0-2x" };
> +static SUNXI_CCU_M_WITH_MUX(h5_dram_clk, "dram", h5_dram_parents,
> 0x0f4, 0, 4, 20, 2, CLK_IS_CRITICAL);
>
> static SUNXI_CCU_GATE(dram_ve_clk, "dram-ve", "dram",
> @@ -592,7 +597,7 @@ static struct ccu_common *sun8i_h3_ccu_clks[] = {
> &usb_ohci1_clk.common,
> &usb_ohci2_clk.common,
> &usb_ohci3_clk.common,
> - &dram_clk.common,
> + &h5_dram_clk.common,
> &dram_ve_clk.common,
> &dram_csi_clk.common,
> &dram_deinterlace_clk.common,
> @@ -732,7 +737,7 @@ static struct clk_hw_onecell_data
> sun8i_h3_hw_clks = {
> [CLK_USB_OHCI1] = &usb_ohci1_clk.common.hw,
> [CLK_USB_OHCI2] = &usb_ohci2_clk.common.hw,
> [CLK_USB_OHCI3] = &usb_ohci3_clk.common.hw,
> - [CLK_DRAM] = &dram_clk.common.hw,
> + [CLK_DRAM] = &h3_dram_clk.hw,
> [CLK_DRAM_VE] = &dram_ve_clk.common.hw,
> [CLK_DRAM_CSI] = &dram_csi_clk.common.hw,
> [CLK_DRAM_DEINTERLACE] =
> &dram_deinterlace_clk.common.hw,
> @@ -848,7 +853,7 @@ static struct clk_hw_onecell_data
> sun50i_h5_hw_clks = {
> [CLK_USB_OHCI1] = &usb_ohci1_clk.common.hw,
> [CLK_USB_OHCI2] = &usb_ohci2_clk.common.hw,
> [CLK_USB_OHCI3] = &usb_ohci3_clk.common.hw,
> - [CLK_DRAM] = &dram_clk.common.hw,
> + [CLK_DRAM] = &h5_dram_clk.common.hw,
> [CLK_DRAM_VE] = &dram_ve_clk.common.hw,
> [CLK_DRAM_CSI] = &dram_csi_clk.common.hw,
> [CLK_DRAM_DEINTERLACE] =
> &dram_deinterlace_clk.common.hw,
Powered by blists - more mailing lists