lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<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

Powered by Openwall GNU/*/Linux Powered by OpenVZ