Hi Haibo,

On Thu, Oct 21, 2021 at 08:00:43AM +0000, Bough Chen wrote:

quoted

-----Original Message-----
From: Chester Lin [mailto:clin@suse.com]
Sent: 2021年10月21日 15:31
To: Ulf Hansson <redacted>; dl-S32 <S32@nxp.com>; dl-linux-imx
[off-list ref]; Bough Chen [off-list ref]; Aisheng Dong
[off-list ref]; linux-mmc@vger.kernel.org
Cc: Rob Herring <robh+dt@kernel.org>; Shawn Guo <shawnguo@kernel.org>;
Sascha Hauer [off-list ref]; Pengutronix Kernel Team
[off-list ref]; Fabio Estevam [off-list ref];
devicetree@vger.kernel.org; linux-arm-kernel@lists.infradead.org;
linux-kernel@vger.kernel.org; Radu-nicolae Pirea (OSS)
[off-list ref]; Andreas Färber [off-list ref];
Matthias Brugger [off-list ref]; Ivan T . Ivanov [off-list ref];
Lee, Chun-Yi [off-list ref]
Subject: Re: [RFC PATCH 2/3] mmc: sdhci-esdhc-imx: add NXP S32G2 support

Hi NXP S32 and i.MX Linux teams,

On Thu, Oct 21, 2021 at 03:13:32PM +0800, Chester Lin wrote:

quoted

Support the SDHCI controller found on NXP S32G2 platform. The new flag
ESDHC_FLAG_SKIP_ERR004536 is used because the hardware erratum bit is
not applicable for S32G2.

Signed-off-by: Chester Lin <redacted>
---
 drivers/mmc/host/sdhci-esdhc-imx.c | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c

b/drivers/mmc/host/sdhci-esdhc-imx.c
index f18d169bc8ff..d0f7d46a0354 100644

--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c

@@ -196,6 +196,9 @@
  */
 #define ESDHC_FLAG_BROKEN_AUTO_CMD23	BIT(16)

+/* ERR004536 is not applicable for the IP  */
+#define ESDHC_FLAG_SKIP_ERR004536	BIT(17)
+
 enum wp_types {
 	ESDHC_WP_NONE,		/* no WP, neither controller nor gpio */
 	ESDHC_WP_CONTROLLER,	/* mmc controller internal WP */

@@ -289,6 +292,13 @@ static const struct esdhc_soc_data

usdhc_imx7d_data = {

quoted

 			| ESDHC_FLAG_BROKEN_AUTO_CMD23,
 };

+static struct esdhc_soc_data usdhc_s32g2_data = {
+	.flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_MAN_TUNING
+			| ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200
+			| ESDHC_FLAG_HS400 | ESDHC_FLAG_HS400_ES
+			| ESDHC_FLAG_SKIP_ERR004536,
+};
+
 static struct esdhc_soc_data usdhc_imx7ulp_data = {
 	.flags = ESDHC_FLAG_USDHC | ESDHC_FLAG_STD_TUNING
 			| ESDHC_FLAG_HAVE_CAP1 | ESDHC_FLAG_HS200 @@ -347,6

+357,7 @@

quoted

static const struct of_device_id imx_esdhc_dt_ids[] = {
 	{ .compatible = "fsl,imx7ulp-usdhc", .data = &usdhc_imx7ulp_data, },
 	{ .compatible = "fsl,imx8qxp-usdhc", .data = &usdhc_imx8qxp_data, },
 	{ .compatible = "fsl,imx8mm-usdhc", .data = &usdhc_imx8mm_data, },
+	{ .compatible = "nxp,s32g2-usdhc", .data = &usdhc_s32g2_data, },
 	{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, imx_esdhc_dt_ids); @@ -1359,8 +1370,10

@@

quoted

static void sdhci_esdhc_imx_hwinit(struct sdhci_host *host)
 		 * erratum ESDHC_FLAG_ERR004536 fix for MX6Q TO1.2 and MX6DL
 		 * TO1.1, it's harmless for MX6SL
 		 */
-		writel(readl(host->ioaddr + 0x6c) & ~BIT(7),
-			host->ioaddr + 0x6c);
+		if (!(imx_data->socdata->flags & ESDHC_FLAG_SKIP_ERR004536)) {
+			writel(readl(host->ioaddr + 0x6c) & ~BIT(7),
+				host->ioaddr + 0x6c);
+		}

Hope you don't might that I raise this question here. Is it really necessary to
unconditionally apply the erratum bit even if some SoCs might not need this
workaround? From the S32 implementation in CodeAurora[1], I noticed that
this bit is not required by S32V/S32G so I wonder if there's any better way to
refine this part?

I confirmed with IP owner before, for SoC contain this errata fixup, clear this bit 7
will enable the fixup, set the bit 7 will disable the fixup.
For SoC which do not contain this errata fixup, this bit 7 has no definition.
So it's okay to clear this bit 7 unconditionally.

Thanks for your reply. If I understand correctly, this bit should be almost the
same even if the IP can be used in different SoCs. Actually I haven't found an
issue even if I have tried to clear the bit-7 on S32G274A although this patch
just gets the driver working on S32G, which still has limited functions [e.g.
pins_100mhz and pins_200mhz are missing]. I just wonder if any case should
avoid touching this bit since the s32 downstream kernel has a specific handling
for this part.

@NXP S32 team:
Please let us know if any concern about this bit.

Thanks,
Chester

quoted

Thanks,
Chester

[1]
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsource.
codeaurora.org%2Fexternal%2Fautobsps32%2Flinux%2Ftree%2Fdrivers%2Fm
mc%2Fhost%2Fsdhci-esdhc-imx.c%3Fh%3Drelease%2Fbsp30.0-5.4-rt%23n1268
&data=04%7C01%7Chaibo.chen%40nxp.com%7Cec36a273354b4b66c45b
08d99464c449%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C63770
3982782606697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hvzsy
3W%2FpKXBmXxS8%2F73huzb157a%2FuHa5G4lFWj5ABQ%3D&reserved=
0

quoted

 		/* disable DLL_CTRL delay line settings */
 		writel(0x0, host->ioaddr + ESDHC_DLL_CTRL);
--
2.30.0

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel