[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241031120857.60bc0d94@donnerap.manchester.arm.com>
Date: Thu, 31 Oct 2024 12:08:57 +0000
From: Andre Przywara <andre.przywara@....com>
To: Cody Eksal <masterr3c0rd@...chal.quest>
Cc: Michael Turquette <mturquette@...libre.com>, Stephen Boyd
<sboyd@...nel.org>, Chen-Yu Tsai <wens@...e.org>, Jernej Skrabec
<jernej.skrabec@...il.com>, Samuel Holland <samuel@...lland.org>, Conor
Dooley <conor+dt@...nel.org>, Greg Kroah-Hartman
<gregkh@...uxfoundation.org>, Kishon Vijay Abraham I <kishon@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Maxime Ripard
<mripard@...nel.org>, Nishanth Menon <nm@...com>, "Rafael J. Wysocki"
<rafael@...nel.org>, Rob Herring <robh@...nel.org>, Vinod Koul
<vkoul@...nel.org>, Viresh Kumar <vireshk@...nel.org>, Viresh Kumar
<viresh.kumar@...aro.org>, Yangtao Li <tiny.windzz@...il.com>, Parthiban
<parthiban@...umiz.com>, linux-clk@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-sunxi@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 08/13] clk: sunxi-ng: a100: enable MMC clock
reparenting
On Thu, 31 Oct 2024 04:02:21 -0300
Cody Eksal <masterr3c0rd@...chal.quest> wrote:
> During testing, it was noted that MMC would fail to initialize, with
> "mmc: fatal err update clk timeout" being printed in the log. It was
> found that CLK_SET_RATE_NO_REPARENT was set on the MMC controllers, and
> that removing this allows MMC to initialize. Therefore, remove
> CLK_SET_RATE_NO_REPARENT from mmc0/1/2.
Well, while this change indeed prevented that error message you mentioned,
but the SD card still doesn't work for me: it probes and I can mount a
filesystem on it, but then it hangs, for instance when running an "ls" on
it. It could be my setup (lacking DT or device issue or missing kernel
config), though, and the eMMC works for me this way, but it would be good
to have that sorted.
Also it would be good to know why CLK_SET_RATE_NO_REPARENT was put there
in the first place: I don't see it in any other MMC clocks in sunxi-ng, so
it wasn't just copied&pasted.
So was there a problem that this flag was supposed to fix? Is that
something that only applied to older kernels (back when the MMC patches
were first posted), and which has now been fixed/changed elsewhere?
I feel a bit uneasy of just removing this just because it works(TM),
especially if it doesn't really (SD card for me, for instance).
Cheers,
Andre
> Signed-off-by: Cody Eksal <masterr3c0rd@...chal.quest>
> ---
> drivers/clk/sunxi-ng/ccu-sun50i-a100.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a100.c b/drivers/clk/sunxi-ng/ccu-sun50i-a100.c
> index bbaa82978716..a59e420b195d 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun50i-a100.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun50i-a100.c
> @@ -436,7 +436,7 @@ static SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(mmc0_clk, "mmc0", mmc_parents, 0x830,
> 24, 2, /* mux */
> BIT(31), /* gate */
> 2, /* post-div */
> - CLK_SET_RATE_NO_REPARENT);
> + 0);
>
> static SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(mmc1_clk, "mmc1", mmc_parents, 0x834,
> 0, 4, /* M */
> @@ -444,7 +444,7 @@ static SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(mmc1_clk, "mmc1", mmc_parents, 0x834,
> 24, 2, /* mux */
> BIT(31), /* gate */
> 2, /* post-div */
> - CLK_SET_RATE_NO_REPARENT);
> + 0);
>
> static SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(mmc2_clk, "mmc2", mmc_parents, 0x838,
> 0, 4, /* M */
> @@ -452,7 +452,7 @@ static SUNXI_CCU_MP_WITH_MUX_GATE_POSTDIV(mmc2_clk, "mmc2", mmc_parents, 0x838,
> 24, 2, /* mux */
> BIT(31), /* gate */
> 2, /* post-div */
> - CLK_SET_RATE_NO_REPARENT);
> + 0);
>
> static SUNXI_CCU_GATE(bus_mmc0_clk, "bus-mmc0", "ahb3", 0x84c, BIT(0), 0);
> static SUNXI_CCU_GATE(bus_mmc1_clk, "bus-mmc1", "ahb3", 0x84c, BIT(1), 0);
Powered by blists - more mailing lists