[EXT] Re: [PATCH 02/11] dts: mvebu: Update A8K AP806 SDHCI settings

Marcin Wojtas mw at semihalf.com
Fri Feb 5 04:33:18 EST 2021


Hi Kosta,

Let me chime in.

śr., 3 lut 2021 o 17:57 Kostya Porotchkin <kostap at marvell.com> napisał(a):
>
> Hello, Russell,
> I agree that this patch needs rework.
> I will definitely do it and issue a new version.
>
> > On Wed, Feb 03, 2021 at 02:50:45PM +0000, Kostya Porotchkin wrote:
> > > [KP] So for older systems this "slow mode" parameter could be set on the
> > board level.
> > > When it is set in ap80x,dtsi file it downgrades all systems to HS-SDR52, even
> > if they support HS400 on AP side.
> > > MacchiatoBIN AP eMMC is connected to 3.3v regulator and has "no-1-8-v"
> > flag set, so it should remain in low speed anyway.
> >
> > Your reasoning does not make sense.
> >
> > The ap80x.dtsi file does not specify "marvell,xenon-phy-slow-mode".
> > It is not specified at this level. It is already specified at board level.
> [KP] it does. In current armada-ap80x.dtsi File this specification is on row 260:
>                         ap_sdhci0: sdhci at 6e0000 {
>                                 compatible = "marvell,armada-ap806-sdhci";
>                                 reg = <0x6e0000 0x300>;
>                                 interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>;
>                                 clock-names = "core";
>                                 clocks = <&ap_clk 4>;
>                                 dma-coherent;
>                                 marvell,xenon-phy-slow-mode;
>                                 status = "disabled";
>                         };
> So I would like to remove this row.
>
> > Given that Macchiatobin will still use slow mode, why remove the
> > marvell,xenon-phy-slow-mode property from this file?
> [KP] Agree, I will keep this property in Macchiatobin DTS file.
>

Please do it another way around.
1. We need to leave the device tree bindings intact as much as
possible -  specifically for Armada 7k8k changes in this area have
been causing enough problems in the past, breaking compatibility
between kernel revisions. Moving the property to board level can be
good here, but forces all other board dts files to adjust.
Unfortunately Linux is a source of truth for the arm64 device tree
bindings, but please note other OS's use those files as well - let's
minimize the impact for existing HW and drivers.

2. What I propose is to remove `marvell,xenon-phy-slow-mode` from
armada-ap80x.dtsi and add below in armada-ap806.dtsi:
&ap_sdhci0 {
         marvell,xenon-phy-slow-mode;
 };

This way AP807 becomes free from the unwanted slow mode setting. Also
any user of Armada 7k8k the B0 revision can add below to the board
file:

&ap_sdhci0 {
+      /delete-property/marvell,xenon-phy-slow-mode;
 };

3. Contrary to the SDK version, sdhci-xenon.c is not capable of
checking the SoC revision. HS200 is disabled for all versions of AP806
there - I believe this place requires revisiting, to start relying
explicitly on the `marvell,xenon-phy-slow-mode` setting, rather than
the compatible string. I can handle this one.

4. Please move armada-8040-db.dts changes to a separate patch, please.

Thanks,
Marcin



> >
> > Also, if you're upgrading ap80x.dtsi to use a bus-width of 8, why keep the bus-
> > width specifier of 8 in the board files?
> [KP] The bus width is updated in A8040 DB DTS. This board utilizes 8-bit interface.
> The armada-ap80x.dtsi file does not specifies the bus width since it is board-specific.
>
> >
> > This patch just doesn't make sense, and your responses to our points seem to
> > add to the confusion.
> [KP] I am sorry about it. Hope my last response clarifies it.
>
> Kosta
> >
> > --
> > RMK's Patch system: https://urldefense.proofpoint.com/v2/url?u=https-
> > 3A__www.armlinux.org.uk_developer_patches_&d=DwIBAg&c=nKjWec2b6R0
> > mOyPaz7xtfQ&r=-
> > N9sN4p5NSr0JGQoQ_2UCOgAqajG99W1EbSOww0WU8o&m=V27OOcgNqKN2
> > WrlW2YFvHm_D_dXoP44wPd5zyOKvEBk&s=o3OrmStt1ZuXVNlYklTV_b1wY35
> > NvPPrdLqwGgtxRZU&e=
> > FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!



More information about the linux-arm-kernel mailing list