linux-kernel - Re: [PATCH 1/2] arm64: dts: imx8mm-beacon: Fix HS400 USDHC clock speed

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: <CAJ+vNU2iY4V3yp_58NTSht2XbS_YiWU+T5jn7fcbrkBMGygzJA@mail.gmail.com>
Date: Fri, 27 Jun 2025 16:51:43 -0700
From: Tim Harvey <tharvey@...eworks.com>
To: Adam Ford <aford173@...il.com>
Cc: linux-arm-kernel@...ts.infradead.org, aford@...conembedded.com, 
	Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Shawn Guo <shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>, 
	Pengutronix Kernel Team <kernel@...gutronix.de>, Fabio Estevam <festevam@...il.com>, devicetree@...r.kernel.org, 
	imx@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] arm64: dts: imx8mm-beacon: Fix HS400 USDHC clock speed

On Fri, Jun 27, 2025 at 11:40 AM Adam Ford <aford173@...il.com> wrote:
>
> On Fri, Jun 27, 2025 at 12:56 PM Tim Harvey <tharvey@...eworks.com> wrote:
> >
> > On Fri, Jun 20, 2025 at 2:52 PM Adam Ford <aford173@...il.com> wrote:
> > >
> > > The reference manual for the i.MX8MM states the clock rate in
> > > MMC mode is 1/2 of the input clock, therefore to properly run
> > > at HS400 rates, the input clock must be 400MHz to operate at
> > > 200MHz.  Currently the clock is set to 200MHz which is half the
> > > rate it should be, so the throughput is half of what it should be
> > > for HS400 operation.
> > >
> > > Fixes: 593816fa2f35 ("arm64: dts: imx: Add Beacon i.MX8m-Mini development kit")
> > > Signed-off-by: Adam Ford <aford173@...il.com>
> > >
> > > diff --git a/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
> > > index 21bcd82fd092..8287a7f66ed3 100644
> > > --- a/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
> > > +++ b/arch/arm64/boot/dts/freescale/imx8mm-beacon-som.dtsi
> > > @@ -294,6 +294,8 @@ &usdhc3 {
> > >         pinctrl-0 = <&pinctrl_usdhc3>;
> > >         pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
> > >         pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
> > > +       assigned-clocks = <&clk IMX8MM_CLK_USDHC3>;
> > > +       assigned-clock-rates = <400000000>;
> > >         bus-width = <8>;
> > >         non-removable;
> > >         status = "okay";
> > > --
> > > 2.48.1
> > >
> > >
> >
> > Hi Adam,
> >
> > This caught my interest. Where in the IMX8MMRM do you see this and
> > would it also apply to the IMX8MP? (You've patched your IMX8MM and
> > IMX8MN boards).
>
> My 8MP board already appears to be running at 400MHz, but I did check.
> The reference I found was in the 8MM TRM, under 10.3.3.5 Clock
> generator, there is a note:
>
> CLK is different for the SDR and DDR modes.
> - In the SDR mode, CLK is equal to the internal working clock (card_clk).
> - In the DDR mode, CLK is equal to card_clk/2.
>
> >
> > Have you encountered any issues when running eMMC at HS400 due to this
> > or is it just something you noticed in the RM more recently like with
>
> One of my colleagues reported that the eMMC was running slower than he
> expected, and I looked at the reference clock and noticed the 200MHz.
> He asked if it needed to run 2x that since HS400 clocks on both edges.
> I looked it up and found the note from above.  When I increased the
> rate to 400MHz from 200MHz, the throughput doubled. I also noticed
> some other boards, including the reference from NXP had the clock rate
> set to 400MHz, so I don't think anything unreasonable.
>

Hi Adam,

The verbiage in the 'clock generator' section is not really easy to
understand but you're right, setting it to 400MHz also bumped the
performance on my boards. It looks like there are a lot of imx8m
boards that could likely benefit from this that are not already doing
so.

Check your imx8mp again, in my case (imx8mp-venice) sdhc3 was not
running at 400Mhz without the appropriate change - maybe yours is
running higher due to some other clock configuration you have.

I'll be patching my boards with this as well - thanks!

Best Regards,

Tim