On 12/07/21 17:33 Lucas Stach [off-list ref] wrote:

Am Montag, dem 12.07.2021 um 04:03 +0000 schrieb Robin Gong:

quoted

On 09/07/21 17:45 Lucas Stach [off-list ref] wrote:

quoted

Am Mittwoch, dem 07.04.2021 um 23:30 +0800 schrieb Robin Gong:

quoted

ECSPI issue fixed from i.mx6ul at hardware level, no need
ERR009165 anymore on those chips such as i.mx8mq.

Signed-off-by: Robin Gong <redacted>
Acked-by: Vinod Koul <vkoul@kernel.org>
---
 drivers/dma/imx-sdma.c | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c index

86bd383..af85116 100644

--- a/drivers/dma/imx-sdma.c
+++ b/drivers/dma/imx-sdma.c

@@ -422,6 +422,13 @@ struct sdma_driver_data {
 	int num_events;
 	struct sdma_script_start_addrs	*script_addrs;
 	bool check_ratio;
+	/*
+	 * ecspi ERR009165 fixed should be done in sdma script
+	 * and it has been fixed in soc from i.mx6ul.
+	 * please get more information from the below link:
+	 *

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
w.n

xp.com%2Fdocs%2Fen%2Ferrata%2FIMX6DQCE.pdf&data=04%7C01%7C

quoted

quoted

yibin.gong%40nxp.com%7Cc950b1bdb6544eda369408d942be35d9%7C686ea

quoted

quoted

1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637614206980361737%7CU

quoted

quoted

nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6

quoted

quoted

Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=6iT6%2FbzJHyWnkhkDynY

quoted

quoted

wmK9nn2hgCDy1GyzELeEk9K8%3D&reserved=0

quoted

+	 */
+	bool ecspi_fixed;
 };

 struct sdma_engine {

@@ -542,6 +549,13 @@ static struct sdma_driver_data sdma_imx6q = {
 	.script_addrs = &sdma_script_imx6q,  };

+static struct sdma_driver_data sdma_imx6ul = {
+	.chnenbl0 = SDMA_CHNENBL0_IMX35,
+	.num_events = 48,
+	.script_addrs = &sdma_script_imx6q,
+	.ecspi_fixed = true,
+};
+
 static struct sdma_script_start_addrs sdma_script_imx7d = {
 	.ap_2_ap_addr = 644,
 	.uart_2_mcu_addr = 819,

@@ -575,6 +589,7 @@ static const struct of_device_id sdma_dt_ids[] = {
 	{ .compatible = "fsl,imx31-sdma", .data = &sdma_imx31, },
 	{ .compatible = "fsl,imx25-sdma", .data = &sdma_imx25, },
 	{ .compatible = "fsl,imx7d-sdma", .data = &sdma_imx7d, },
+	{ .compatible = "fsl,imx6ul-sdma", .data = &sdma_imx6ul, },
 	{ .compatible = "fsl,imx8mq-sdma", .data = &sdma_imx8mq, },
 	{ /* sentinel */ }
 };

@@ -1144,8 +1159,17 @@ static int sdma_config_channel(struct

dma_chan

*chan)

quoted

 			if (sdmac->peripheral_type == IMX_DMATYPE_ASRC_SP ||
 			    sdmac->peripheral_type == IMX_DMATYPE_ASRC)
 				sdma_set_watermarklevel_for_p2p(sdmac);
-		} else
+		} else {
+			/*
+			 * ERR009165 fixed from i.mx6ul, no errata need,
+			 * set bit31 to let sdma script skip the errata.
+			 */
+			if (sdmac->peripheral_type == IMX_DMATYPE_CSPI &&
+			    sdmac->direction == DMA_MEM_TO_DEV &&
+			    sdmac->sdma->drvdata->ecspi_fixed)
+				__set_bit(31, &sdmac->watermark_level);

Hm, I don't care much either way, but couldn't we just return the
regular mcu_2_app script in sdma_get_pc when ecspi_fixed == true?
Seems like this would be a simpler and more targeted code change.

Yes, return mcu_2_app if ecspi_fixed == true also works, but since
sdma firmware have already been here to fix ERR009165 on most of
legacy i.mx6/7/8 chips, so choosing firmware/ram script to do like
ROM/mcu_2_app is okay too since both ram script and rom script in case of

ecspi_fixed are almost same.

quoted

Actually, while thinking some more about this: it is preferable to return
mcu_2_app in the ecspi_fixed case, as this allows proper DMA support on the
fixed SoCs without loading the firmware. The way you do it here still requires
the RAM firmware to be loaded in order to get DMA support at all.

Okay, will change to mcu_2_app v15.

quoted

quoted

quoted

 			__set_bit(sdmac->event_id0, sdmac->event_mask);
+		}

 		/* Address */
 		sdmac->shp_addr = sdmac->per_address;