2021-06-25 06:11:24

by Andrew Jeffery

[permalink] [raw]
Subject: [PATCH] ARM: dts: tacoma: Add phase corrections for eMMC

The degree values were reversed out from the magic tap values of 7 (in)
and 15 + inversion (out) initially suggested by Aspeed.

With the patch tacoma survives several gigabytes of reads and writes
using dd while without it locks up randomly during the boot process.

Signed-off-by: Andrew Jeffery <[email protected]>
---
arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts | 1 +
1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts b/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
index c1478d2db602..670080bb80eb 100644
--- a/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
+++ b/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
@@ -189,6 +189,7 @@ &emmc_controller {

&emmc {
status = "okay";
+ clk-phase-mmc-hs200 = <36>, <270>;
};

&fsim0 {
--
2.30.2


2021-07-01 03:43:25

by Joel Stanley

[permalink] [raw]
Subject: Re: [PATCH] ARM: dts: tacoma: Add phase corrections for eMMC

On Fri, 25 Jun 2021 at 06:10, Andrew Jeffery <[email protected]> wrote:
>
> The degree values were reversed out from the magic tap values of 7 (in)
> and 15 + inversion (out) initially suggested by Aspeed.
>
> With the patch tacoma survives several gigabytes of reads and writes
> using dd while without it locks up randomly during the boot process.
>
> Signed-off-by: Andrew Jeffery <[email protected]>

Thanks for the fix. Is this required due to "mmc: sdhci-of-aspeed: Add
AST2600 bus clock support" or "mmc: sdhci-of-aspeed: Expose clock
phase controls"?

On the topic of those patches, it would be good if we could operate
the devices (with the slower speed?) when the device tree does not
provide the phase values. Think about system bringup, or where you
need the system booting in order to determine the phase calculations.

What changes would be required to the host driver for it to work out of the box?


> ---
> arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts b/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> index c1478d2db602..670080bb80eb 100644
> --- a/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> +++ b/arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
> @@ -189,6 +189,7 @@ &emmc_controller {
>
> &emmc {
> status = "okay";
> + clk-phase-mmc-hs200 = <36>, <270>;
> };
>
> &fsim0 {
> --
> 2.30.2
>

2021-07-01 05:09:55

by Andrew Jeffery

[permalink] [raw]
Subject: Re: [PATCH] ARM: dts: tacoma: Add phase corrections for eMMC



On Thu, 1 Jul 2021, at 13:10, Joel Stanley wrote:
> On Fri, 25 Jun 2021 at 06:10, Andrew Jeffery <[email protected]> wrote:
> >
> > The degree values were reversed out from the magic tap values of 7 (in)
> > and 15 + inversion (out) initially suggested by Aspeed.
> >
> > With the patch tacoma survives several gigabytes of reads and writes
> > using dd while without it locks up randomly during the boot process.
> >
> > Signed-off-by: Andrew Jeffery <[email protected]>
>
> Thanks for the fix. Is this required due to "mmc: sdhci-of-aspeed: Add
> AST2600 bus clock support" or "mmc: sdhci-of-aspeed: Expose clock
> phase controls"?

Sort of neither, it's really a bug with the devicetrees.

>
> On the topic of those patches, it would be good if we could operate
> the devices (with the slower speed?) when the device tree does not
> provide the phase values. Think about system bringup, or where you
> need the system booting in order to determine the phase calculations.

You can use the maximum-frequency binding to make things go slow enough
to paper over phase issues. This helped us limp along early on.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/mmc/mmc-controller.yaml?h=v5.13#n90

But really it depends on how bad the issues are at a given speed.

>
> What changes would be required to the host driver for it to work out of the box?

Maybe the above is enough of a crutch?

Andrew