On 2020/03/10 Sascha Hauer [off-list ref] wrote:

On Tue, Mar 10, 2020 at 08:59:03AM +0000, Robin Gong wrote:

quoted

On 2020/03/10 Sascha Hauer [off-list ref] wrote:

quoted

On Tue, Mar 10, 2020 at 07:31:58PM +0800, Robin Gong wrote:

quoted

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

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

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

56288d8..5ae7237 100644

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

@@ -419,6 +419,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.nx

p.com%2Fdocs%2Fen%2Ferrata%2FIMX6DQCE.pdf&data=02%7C01%7Cyi

quoted

quoted

bin.gong%40nxp.com%7C91d42046e6894501d48508d7c4cbcae2%7C686ea1d3

quoted

quoted

bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637194251876090170&sdata=

quoted

quoted

T6LA4xz9CUFlNpnyjHSThEQb8i1rhbY9e1nUyxIGD5Q%3D&reserved=0

quoted

+	 */
+	bool ecspi_fixed;
 };

 struct sdma_engine {

@@ -539,6 +546,31 @@ static struct sdma_driver_data sdma_imx6q = {
 	.script_addrs = &sdma_script_imx6q,  };

+static struct sdma_script_start_addrs sdma_script_imx6sx = {
+	.ap_2_ap_addr = 642,
+	.uart_2_mcu_addr = 817,
+	.mcu_2_app_addr = 747,
+	.uartsh_2_mcu_addr = 1032,
+	.mcu_2_shp_addr = 960,
+	.app_2_mcu_addr = 683,
+	.shp_2_mcu_addr = 891,
+	.spdif_2_mcu_addr = 1100,
+	.mcu_2_spdif_addr = 1134,
+};
+
+static struct sdma_driver_data sdma_imx6sx = {
+	.chnenbl0 = SDMA_CHNENBL0_IMX35,
+	.num_events = 48,
+	.script_addrs = &sdma_script_imx6sx, };
+
+static struct sdma_driver_data sdma_imx6ul = {
+	.chnenbl0 = SDMA_CHNENBL0_IMX35,
+	.num_events = 48,
+	.script_addrs = &sdma_script_imx6sx,
+	.ecspi_fixed = true,
+};
+
 static struct sdma_script_start_addrs sdma_script_imx7d = {
 	.ap_2_ap_addr = 644,
 	.uart_2_mcu_addr = 819,

@@ -584,9 +616,15 @@ static const struct platform_device_id

sdma_devtypes[] = {

quoted

 		.name = "imx6q-sdma",
 		.driver_data = (unsigned long)&sdma_imx6q,
 	}, {
+		.name = "imx6sx-sdma",
+		.driver_data = (unsigned long)&sdma_imx6sx,
+	}, {

Now the i.MX6sx uses a new sdma_script_start_addrs entry which is
the same as the i.MX6q one we used before with one exception: it
lacks the per_2_per_addr = 6331 entry. This is only used for
IMX_DMATYPE_ASRC and

Totally same script for i.mx6 chips whatever i.MX6sx, i.MX6q or i.MX6ul.

When it's the same then use it.

quoted

quoted

IMX_DMATYPE_ASRC_SP, both are entirely unused in the mainline
kernel. So why must the i.MX6sx changed here and what has this to do with

ECSPI?

quoted

i.MX6ul is based on i.MX6sx, so adding i.MX6sx could keep good shape on our

i.MX family evolution.

My point is that there is no difference between i.MX6q and i.MX6sx here, so do
not artificially introduce i.MX6sx support when all you do is copying the i.MX6q
support.

Okay, will remove i.MX6sx now.

--
Pengutronix e.K.                           |
|
Steuerwalder Str. 21                       |
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.pe
ngutronix.de%2F&data=02%7C01%7Cyibin.gong%40nxp.com%7C02af95d
81bf745b7b2cc08d7c4d55ed2%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0
%7C0%7C637194293001547060&sdata=cN13LuC6Bgs1m9W6oKc2q03j5rf
KvsMbonpd1JALA%2Fk%3D&reserved=0  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0
|
Amtsgericht Hildesheim, HRA 2686           | Fax:
+49-5121-206917-5555 |

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