serial: imx: Revert "initialized DMA w/o HW flow enabled"

PATCH Superseded Sebastian Andrzej Siewior 3 participants 11 messages May 7, 2015 – Jun 12, 2015

Subsystems (2)

Arm i.MX and Layerscape TTY layer and serial drivers

lore

Share & tools

lore

Sebastian Andrzej Siewior

author

2015-05-07 20:24 UTC #0 lore raw

PATCH 1/1 serial: imx: Revert "initialized DMA w/o HW flow enabled"

From: Sebastian Andrzej Siewior <[email protected]>

This basically reverts commit 068500e08dc8 ("serial: imx: initialized DMA w/o HW flow enabled") simply because it does not work as expected without additional magic which I am not aware of. The DMA mode is only used for non-console UARTs so the "standard" boot test won't notice this.

I tested it on various IMX6 (S and Q) boards and the default SDMA firmware that is included in ROM does work properly. The SDMA interrupt counter does not stop increment (which means the SDMA does not stop working or the ACK is working) and I see a lot of 0x00 (sometimes other bytes) which are added to the tty buffer which are not part of the data transfer. Jiada claimed that there is a firmware which makes it work but failed to provide me a link to the firmware. All he said was that it can not be shipped as part of the kernel due to license issues. I've found a firmware blob in the FSL-tree but this firmware causes only TTY-overflows an *no* data is transmitted.

Currently I see no other way out.

Fixes 068500e08dc8 ("serial: imx: initialized DMA w/o HW flow enabled")

Cc Fabio Estevam <[email protected]>

Cc Jiada Wang <[email protected]>

Cc [email protected]

Signed-off-by Sebastian Andrzej Siewior <[email protected]>

---
 drivers/tty/serial/imx.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

drivers/tty/serial/imx.c +13 -5

index 8aff0b4d8ddf..e686c75fa4dc 100644
@@ -1113,11 +1113,6 @@ static int imx_startup(struct uart_port *port)
 
 	writel(temp & ~UCR4_DREN, sport->port.membase + UCR4);
 
-	/* Can we enable the DMA support? */
-	if (is_imx6q_uart(sport) && !uart_console(port) &&
-	    !sport->dma_is_inited)
-		imx_uart_dma_init(sport);
-
 	spin_lock_irqsave(&sport->port.lock, flags);
 	/* Reset fifo's and state machines */
 	i = 100;

@@ -1308,6 +1303,17 @@ imx_set_termios(struct uart_port *port, struct ktermios *termios,
 			} else {
 				ucr2 |= UCR2_CTSC;
 			}
+
+			/*
+			 * Can we enable the DMA support? Be aware that
+			 * at least IMX6 needs to load external SDMA firmware in
+			 * order work properly. The in-ROM firmware is not
+			 * wokring properly.
+			 */
+			if ((ucr2 & UCR2_CTSC) && is_imx6q_uart(sport) &&
+			    !uart_console(port) && !sport->dma_is_inited)
+				imx_uart_dma_init(sport);
+
 		} else {
 			termios->c_cflag &= ~CRTSCTS;
 		}

@@ -1424,6 +1430,8 @@ imx_set_termios(struct uart_port *port, struct ktermios *termios,
 	if (UART_ENABLE_MS(&sport->port, termios->c_cflag))
 		imx_enable_ms(&sport->port);
 
+	if (sport->dma_is_inited && !sport->dma_is_enabled)
+		imx_enable_dma(sport);
 	spin_unlock_irqrestore(&sport->port.lock, flags);
 }

Signature · 1 line

2.1.4

Fabio Estevam

reviewer

2015-05-07 20:54 UTC #1 lore raw

Quoted 18 lines · Sebastian Andrzej Siewior

From: Sebastian Andrzej Siewior <[email protected]>
This basically reverts commit 068500e08dc8 ("serial: imx: initialized DMA w/o HW flow enabled") simply because it does not work as expected without additional magic which I am not aware of. The DMA mode is only used for non-console UARTs so the "standard" boot test won't notice this.
I tested it on various IMX6 (S and Q) boards and the default SDMA firmware that is included in ROM does work properly. The SDMA interrupt counter does not stop increment (which means the SDMA does not stop working or the ACK is working) and I see a lot of 0x00 (sometimes other bytes) which are added to the tty buffer which are not part of the data transfer. Jiada claimed that there is a firmware which makes it work but failed to provide me a link to the firmware. All he said was that it can not be shipped as part of the kernel due to license issues. I've found a firmware blob in the FSL-tree but this firmware causes only TTY-overflows an *no* data is transmitted.

Quoted 7 lines

Currently I see no other way out.
Fixes 068500e08dc8 ("serial: imx: initialized DMA w/o HW flow enabled")
Cc Fabio Estevam <[email protected]>
Cc Jiada Wang <[email protected]>
Cc [email protected]
Signed-off-by Sebastian Andrzej Siewior <[email protected]>

Thanks, this fixes Bluetooth operation on a imx6sl-warp running without SDMA firmware.

Two suggestions:

1. You should Cc stable as it affects 4.0 also

2. It doesn't apply cleanly against linux-next, so I think Greg will have problems applying it.

Sebastian Andrzej Siewior

author

2015-05-07 21:16 UTC #2 lore raw

Quoted 6 lines · Fabio Estevam

Thanks, this fixes Bluetooth operation on a imx6sl-warp running without SDMA firmware.
Two suggestions:
1. You should Cc stable as it affects 4.0 also

I have the Fixes tag, doesn't this count?

Quoted 2 lines

2. It doesn't apply cleanly against linux-next, so I think Greg will have problems applying it.

It is on top of Greg's tty-next tree. Shouldn't this work?

Sebastian

Fabio Estevam

reviewer

2015-05-07 22:11 UTC #3 lore raw

Quoted 9 lines · Sebastian Andrzej Siewior

Quoted 6 lines · Fabio Estevam
Thanks, this fixes Bluetooth operation on a imx6sl-warp running without SDMA firmware.
Two suggestions:
1. You should Cc stable as it affects 4.0 also
I have the Fixes tag, doesn't this count?

According to Documentation/stable_kernel_rules.txt you need to Cc stable so that it can go to the stable tree.

Quoted 4 lines

Quoted 2 lines
2. It doesn't apply cleanly against linux-next, so I think Greg will have problems applying it.
It is on top of Greg's tty-next tree. Shouldn't this work?

Yes, this should be fine.

Fabio Estevam

reviewer Reviewed-by Tested-by on v1 1/1

2015-05-07 23:17 UTC #4 lore raw

In reply to Sebastian Andrzej Siewior

Quoted 9 lines · Sebastian Andrzej Siewior

From: Sebastian Andrzej Siewior <[email protected]>
This basically reverts commit 068500e08dc8 ("serial: imx: initialized DMA w/o HW flow enabled") simply because it does not work as expected without additional magic which I am not aware of. The DMA mode is only used for non-console UARTs so the "standard" boot test won't notice this.
I tested it on various IMX6 (S and Q) boards and the default SDMA firmware that is included in ROM does work properly. The SDMA interrupt counter does

Here you say that the ROM SDMA works properly.

Quoted 37 lines

not stop increment (which means the SDMA does not stop working or the ACK is working) and I see a lot of 0x00 (sometimes other bytes) which are added to the tty buffer which are not part of the data transfer. Jiada claimed that there is a firmware which makes it work but failed to provide me a link to the firmware. All he said was that it can not be shipped as part of the kernel due to license issues. I've found a firmware blob in the FSL-tree but this firmware causes only TTY-overflows an *no* data is transmitted.
Currently I see no other way out.
Fixes 068500e08dc8 ("serial: imx: initialized DMA w/o HW flow enabled")
Cc Fabio Estevam <[email protected]>
Cc Jiada Wang <[email protected]>
Cc [email protected]
Signed-off-by Sebastian Andrzej Siewior <[email protected]>
---
 drivers/tty/serial/imx.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)
drivers/tty/serial/imx.c +0 -5
index 8aff0b4d8ddf..e686c75fa4dc 100644
@@ -1113,11 +1113,6 @@ static int imx_startup(struct uart_port *port)
 
        writel(temp & ~UCR4_DREN, sport->port.membase + UCR4);
 
-       /* Can we enable the DMA support? */
-       if (is_imx6q_uart(sport) && !uart_console(port) &&
-           !sport->dma_is_inited)
-               imx_uart_dma_init(sport);
-
        spin_lock_irqsave(&sport->port.lock, flags);
        /* Reset fifo's and state machines */
        i = 100;

drivers/tty/serial/imx.c imx_set_termios(struct uart_port *port, struct ktermios *termios, · line 1311

Quoted 9 lines

drivers/tty/serial/imx.c +6 -0

@@ -1308,6 +1303,17 @@ imx_set_termios(struct uart_port *port, struct ktermios *termios,
                        } else {
                                ucr2 |= UCR2_CTSC;
                        }
+
+                       /*
+                        * Can we enable the DMA support? Be aware that
+                        * at least IMX6 needs to load external SDMA firmware in
+                        * order work properly. The in-ROM firmware is not
+                        * wokring properly.

,but here you say the contrary.

With this fixed (and please also Cc stable):

Reviewed-by Fabio Estevam <[email protected]>

Tested-by Fabio Estevam <[email protected]>

Sebastian Andrzej Siewior

author

2015-05-08 07:13 UTC #5 lore raw

PATCH v2 1/1 serial: imx: Revert "initialized DMA w/o HW flow enabled"

From: Sebastian Andrzej Siewior <[email protected]>

This basically reverts commit 068500e08dc8 ("serial: imx: initialized DMA w/o HW flow enabled") simply because it does not work.
I tested it on various IMX6 boards and the default SDMA firmware, that is included in ROM, does not work properly. The SDMA interrupt counter does not stop increment (which means the SDMA does not stop working) and I see a lot of 0x00 (sometimes other bytes) which are added to the tty buffer which are not part of the data transfer.
Jiada claimed that there is a firmware which makes it work but failed to provide me a link to the firmware. All he said was that it can not be shipped as part of the kernel due to license issues. I've found one firmware in the FSL-tree but this firmware causes only TTY-overflows and *no* data is transmitted.

Currently I see no other way out.

Fixes 068500e08dc8 ("serial: imx: initialized DMA w/o HW flow enabled")

Cc [email protected]

Reviewed-by Fabio Estevam <[email protected]>

Tested-by Fabio Estevam <[email protected]>

Cc Jiada Wang <[email protected]>

Cc [email protected]

Signed-off-by Sebastian Andrzej Siewior <[email protected]>

---
v1…v2: wording

 drivers/tty/serial/imx.c | 18 +++++++++++++-----
 1 file changed, 13 insertions(+), 5 deletions(-)

drivers/tty/serial/imx.c +13 -5

index 8aff0b4d8ddf..e686c75fa4dc 100644
@@ -1113,11 +1113,6 @@ static int imx_startup(struct uart_port *port)
 
 	writel(temp & ~UCR4_DREN, sport->port.membase + UCR4);
 
-	/* Can we enable the DMA support? */
-	if (is_imx6q_uart(sport) && !uart_console(port) &&
-	    !sport->dma_is_inited)
-		imx_uart_dma_init(sport);
-
 	spin_lock_irqsave(&sport->port.lock, flags);
 	/* Reset fifo's and state machines */
 	i = 100;

@@ -1308,6 +1303,17 @@ imx_set_termios(struct uart_port *port, struct ktermios *termios,
 			} else {
 				ucr2 |= UCR2_CTSC;
 			}
+
+			/*
+			 * Can we enable the DMA support? Be aware that
+			 * at least IMX6 needs to load external SDMA firmware in
+			 * order work properly. The in-ROM firmware is not
+			 * wokring properly.
+			 */
+			if ((ucr2 & UCR2_CTSC) && is_imx6q_uart(sport) &&
+			    !uart_console(port) && !sport->dma_is_inited)
+				imx_uart_dma_init(sport);
+
 		} else {
 			termios->c_cflag &= ~CRTSCTS;
 		}

@@ -1424,6 +1430,8 @@ imx_set_termios(struct uart_port *port, struct ktermios *termios,
 	if (UART_ENABLE_MS(&sport->port, termios->c_cflag))
 		imx_enable_ms(&sport->port);
 
+	if (sport->dma_is_inited && !sport->dma_is_enabled)
+		imx_enable_dma(sport);
 	spin_unlock_irqrestore(&sport->port.lock, flags);
 }

Signature · 1 line

2.1.4

Fabio Estevam

reviewer

2015-05-08 11:30 UTC #6 lore raw

drivers/tty/serial/imx.c imx_set_termios(struct uart_port *port, struct ktermios *termios, · line 1312

Quoted 7 lines · Sebastian Andrzej Siewior

drivers/tty/serial/imx.c +7 -0

+
+                       /*
+                        * Can we enable the DMA support? Be aware that
+                        * at least IMX6 needs to load external SDMA firmware in
+                        * order work properly. The in-ROM firmware is not
+                        * wokring properly.
+                        */

On my tests:

Prior to this patch: with the internal ROM SDMA firmware I got UART issues when communicating through a Bluetooth module. With external SDMA firmware (version 3.1) it worked fine.

With your patch applied: Bluetooth worked fine even with no external SDMA firmware, which does not match the comments you added.

Can't you just remove these comments?

Thanks

Sebastian Andrzej Siewior

2015-05-08 11:50 UTC #7 lore raw

Quoted 11 lines · Fabio Estevam

drivers/tty/serial/imx.c imx_set_termios(struct uart_port *port, struct ktermios *termios, · line 1312

Quoted 7 lines · Sebastian Andrzej Siewior

drivers/tty/serial/imx.c +7 -0

+
+                       /*
+                        * Can we enable the DMA support? Be aware that
+                        * at least IMX6 needs to load external SDMA firmware in
+                        * order work properly. The in-ROM firmware is not
+                        * wokring properly.
+                        */

Quoted 8 lines

On my tests:
Prior to this patch: with the internal ROM SDMA firmware I got UART issues when communicating through a Bluetooth module. With external SDMA firmware (version 3.1) it worked fine.
With your patch applied: Bluetooth worked fine even with no external SDMA firmware, which does not match the comments you added.

Why doesn't it match the comment? The patch disables DMA so the SDMA firmware does not matter.

Quoted 3 lines

Can't you just remove these comments?
Thanks

Sebastian

Fabio Estevam

reviewer

2015-05-08 12:24 UTC #8 lore raw

Quoted 2 lines · Sebastian Andrzej Siewior

Why doesn't it match the comment? The patch disables DMA so the SDMA firmware does not matter.

Got it. It is clear now, thanks.

Fabio Estevam

reviewer

2015-05-19 12:18 UTC #9 lore raw

In reply to Sebastian Andrzej Siewior

Hi Sebastian,

Quoted 15 lines · Sebastian Andrzej Siewior

From: Sebastian Andrzej Siewior <[email protected]>
This basically reverts commit 068500e08dc8 ("serial: imx: initialized DMA w/o HW flow enabled") simply because it does not work.
I tested it on various IMX6 boards and the default SDMA firmware, that is included in ROM, does not work properly. The SDMA interrupt counter does not stop increment (which means the SDMA does not stop working) and I see a lot of 0x00 (sometimes other bytes) which are added to the tty buffer which are not part of the data transfer.
Jiada claimed that there is a firmware which makes it work but failed to provide me a link to the firmware. All he said was that it can not be shipped as part of the kernel due to license issues. I've found one firmware in the FSL-tree but this firmware causes only TTY-overflows and *no* data is transmitted.

Quoted 1 line

Currently I see no other way out.

Could you please test Philipp's patch?
http://marc.info/?l=linux-serial&m=143202566332128&q=raw

It worked on my tests and DMA still works with his patch, so I would prefer his solution.

Thanks,

Fabio Estevam

Sebastian Andrzej Siewior

2015-06-12 13:30 UTC #10 lore raw

Quoted 1 line · Fabio Estevam

Hi Sebastian,

Hi Fabio,

Quoted 5 lines

Could you please test Philipp's patch?
http://marc.info/?l=linux-serial&m=143202566332128&q=raw
It worked on my tests and DMA still works with his patch, so I would prefer his solution.

It seems to work here, too. Thanks.

Quoted 4 lines

Thanks,
Fabio Estevam

Sebastian