tty: serial: 8250_omap: do not defer termios changes

drivers/tty/serial/8250/8250_omap.c +8 -0

index 6f76051..9459b4d 100644
@@ -460,6 +451,24 @@ static void omap_8250_set_termios(struct uart_port *port,
 			priv->efr |= OMAP_UART_SW_TX;
 		}
 	}
+
+	if (dma && dma->tx_running) {
+		/*
+		 * TCSANOW requests the change to occur immediately, however
+		 * if we have a TX-DMA operation in progress then it has been
+		 * observed that it might stall and never complete. Therefore
+		 * we wait until DMA completes to prevent this hang from
+		 * happening.

drivers/tty/serial/8250/8250_omap.c +5 -0

+		 * TCSANOW requests the change to occur immediately, however
+		 * if we have a TX-DMA operation in progress then it has been
+		 * observed that it might stall and never complete. Therefore
+		 * we wait until DMA completes to prevent this hang from
+		 * happening.

From: Sebastian Andrzej Siewior <[email protected]>

It has been observed that the TX-DMA can stall

if termios changes
occur while a TX-DMA operation is in progress. Previously this was handled by allowing set_termios to return immediately and deferring the change until the operation is completed. Now set_termios will block until the operation is completed, proceed with the changes, then schedule any pending next operation.

Commit message and forward port by John Ogness.

Tested-by John Ogness <[email protected]>

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

---
Patch against next-20160331.

 drivers/tty/serial/8250/8250_omap.c |   57 ++++++++++++++++----------
 1 file changed, 37 insertions(+), 20 deletions(-)

drivers/tty/serial/8250/8250_omap.c +37 -20

index 6f76051..9459b4d 100644
@@ -100,9 +100,9 @@ struct omap8250_priv {
 	u8 wer;
 	u8 xon;
 	u8 xoff;
-	u8 delayed_restore;
 	u16 quot;
 
+	wait_queue_head_t termios_wait;
 	bool is_suspending;
 	int wakeirq;
 	int wakeups_enabled;

@@ -257,18 +257,6 @@ static void omap8250_update_mdr1(struct uart_8250_port *up,
 static void omap8250_restore_regs(struct uart_8250_port *up)
 {
 	struct omap8250_priv *priv = up->port.private_data;
-	struct uart_8250_dma	*dma = up->dma;
-
-	if (dma && dma->tx_running) {
-		/*
-		 * TCSANOW requests the change to occur immediately however if
-		 * we have a TX-DMA operation in progress then it has been
-		 * observed that it might stall and never complete. Therefore we
-		 * delay DMA completes to prevent this hang from happen.
-		 */
-		priv->delayed_restore = 1;
-		return;
-	}
 
 	serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
 	serial_out(up, UART_EFR, UART_EFR_ECB);

@@ -310,6 +298,7 @@ static void omap8250_restore_regs(struct uart_8250_port *up)
 	up->port.ops->set_mctrl(&up->port, up->port.mctrl);
 }
 
+static void omap_8250_dma_tx_complete(void *param);
 /*
  * OMAP can use "CLK / (16 or 13) / div" for baud rate. And then we have have
  * some differences in how we want to handle flow control.

@@ -320,6 +309,8 @@ static void omap_8250_set_termios(struct uart_port *port,
 {
 	struct uart_8250_port *up = up_to_u8250p(port);
 	struct omap8250_priv *priv = up->port.private_data;
+	struct uart_8250_dma *dma = up->dma;
+	unsigned int complete_dma = 0;
 	unsigned char cval = 0;
 	unsigned int baud;
 

@@ -430,7 +421,7 @@ static void omap_8250_set_termios(struct uart_port *port,
 	priv->scr = OMAP_UART_SCR_RX_TRIG_GRANU1_MASK | OMAP_UART_SCR_TX_EMPTY |
 		OMAP_UART_SCR_TX_TRIG_GRANU1_MASK;
 
-	if (up->dma)
+	if (dma)
 		priv->scr |= OMAP_UART_SCR_DMAMODE_1 |
 			OMAP_UART_SCR_DMAMODE_CTL;
 

@@ -460,6 +451,24 @@ static void omap_8250_set_termios(struct uart_port *port,
 			priv->efr |= OMAP_UART_SW_TX;
 		}
 	}
+
+	if (dma && dma->tx_running) {
+		/*
+		 * TCSANOW requests the change to occur immediately, however
+		 * if we have a TX-DMA operation in progress then it has been
+		 * observed that it might stall and never complete. Therefore
+		 * we wait until DMA completes to prevent this hang from
+		 * happening.
+		 */
+
+		dma->tx_running = 2;
+
+		spin_unlock_irq(&up->port.lock);
+		wait_event_interruptible(priv->termios_wait,
+					 dma->tx_running == 3);
+		spin_lock_irq(&up->port.lock);
+		complete_dma = 1;
+	}
 	omap8250_restore_regs(up);
 
 	spin_unlock_irq(&up->port.lock);

@@ -475,6 +484,8 @@ static void omap_8250_set_termios(struct uart_port *port,
 	/* Don't rewrite B0 */
 	if (tty_termios_baud_rate(termios))
 		tty_termios_encode_baud_rate(termios, baud, baud);
+	if (complete_dma)
+		omap_8250_dma_tx_complete(up);
 }
 
 /* same as 8250 except that we may have extra flow bits set in EFR */

@@ -893,17 +904,18 @@ static void omap_8250_dma_tx_complete(void *param)
 
 	spin_lock_irqsave(&p->port.lock, flags);
 
+	if (dma->tx_running == 2) {
+		dma->tx_running = 3;
+		wake_up(&priv->termios_wait);
+		goto out;
+	}
+
 	dma->tx_running = 0;
 
 	xmit->tail += dma->tx_size;
 	xmit->tail &= UART_XMIT_SIZE - 1;
 	p->port.icount.tx += dma->tx_size;
 
-	if (priv->delayed_restore) {
-		priv->delayed_restore = 0;
-		omap8250_restore_regs(p);
-	}
-
 	if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
 		uart_write_wakeup(&p->port);
 

@@ -923,7 +935,7 @@ static void omap_8250_dma_tx_complete(void *param)
 		p->ier |= UART_IER_THRI;
 		serial_port_out(&p->port, UART_IER, p->ier);
 	}
-
+out:
 	spin_unlock_irqrestore(&p->port.lock, flags);
 }
 

@@ -1088,6 +1100,10 @@ static inline int omap_8250_rx_dma(struct uart_8250_port *p, unsigned int iir)
 {
 	return -EINVAL;
 }
+
+static void omap_8250_dma_tx_complete(void *param)
+{
+}
 #endif
 
 static int omap8250_no_handle_irq(struct uart_port *port)

@@ -1241,6 +1257,7 @@ static int omap8250_probe(struct platform_device *pdev)
 			priv->omap8250_dma.rx_size = RX_TRIGGER;
 			priv->omap8250_dma.rxconf.src_maxburst = RX_TRIGGER;
 			priv->omap8250_dma.txconf.dst_maxburst = TX_TRIGGER;
+			init_waitqueue_head(&priv->termios_wait);
 
 			if (of_machine_is_compatible("ti,am33xx"))
 				priv->habit |= OMAP_DMA_TX_KICK;

Quoted 1 line · John Ogness

It has been observed that the TX-DMA can stall

Does this happen on any other OMAP part besides am335x? I looked back over the LKML history of this and didn't see any other design implicated in this problem.

Quoted 6 lines · Peter Hurley

Quoted 1 line · John Ogness

It has been observed that the TX-DMA can stall

Does this happen on any other OMAP part besides am335x? I looked back over the LKML history of this and didn't see any other design implicated in this problem.

I just ran the tests again using 4.6-rc2. I am able to reproduce the dma-tx stall with am335x/edma and dra7/sdma.

Note: To achieve the stall, both the delayed_restore and the
rx_dma_broken features of the mainline 8250_omap driver needed to be removed.

John Ogness

Quoted 8 lines · John Ogness

Quoted 6 lines · Peter Hurley

Quoted 1 line · John Ogness

It has been observed that the TX-DMA can stall

Does this happen on any other OMAP part besides am335x? I looked back over the LKML history of this and didn't see any other design implicated in this problem.

Quoted 2 lines

I just ran the tests again using 4.6-rc2. I am able to reproduce the dma-tx stall with am335x/edma and dra7/sdma.

I thought we already established sdma was not to be used since the hardware does not actually support pausing without data loss.

http://www.spinics.net/lists/linux-serial/msg18503.html

So I'm wondering if we're carrying all this extra DMA complexity and workarounds for just am335x?

Quoted 9 lines · Peter Hurley

Quoted 8 lines · John Ogness

Quoted 6 lines · Peter Hurley

Quoted 1 line · John Ogness

It has been observed that the TX-DMA can stall

Does this happen on any other OMAP part besides am335x? I looked back over the LKML history of this and didn't see any other design implicated in this problem.

Quoted 5 lines

Quoted 2 lines

I just ran the tests again using 4.6-rc2. I am able to reproduce the dma-tx stall with am335x/edma and dra7/sdma.

I thought we already established sdma was not to be used since the hardware does not actually support pausing without data loss.

This workaround was not invented for sdma but for edma (with am335x).

Quoted 1 line

http://www.spinics.net/lists/linux-serial/msg18503.html

This could be fixed. See
http://www.spinics.net/lists/linux-serial/msg18517.html
http://www.spinics.net/lists/linux-serial/msg18531.html

rmk was fine with it from what I read. So what is missing is just refurbish the patch (update the comment according to rmk replay) and then we could re-enable DMA again.

Quoted 3 lines

So I'm wondering if we're carrying all this extra DMA complexity and workarounds for just am335x?

Sebastian

Quoted 13 lines · Sebastian Andrzej Siewior

Quoted 12 lines · Peter Hurley

Quoted 10 lines · John Ogness

Quoted 6 lines · Peter Hurley

Quoted 1 line · John Ogness

It has been observed that the TX-DMA can stall

Does this happen on any other OMAP part besides am335x? I looked back over the LKML history of this and didn't see any other design implicated in this problem.

I just ran the tests again using 4.6-rc2. I am able to reproduce the dma-tx stall with am335x/edma and dra7/sdma.

Quoted 4 lines

Quoted 2 lines

I thought we already established sdma was not to be used since the hardware does not actually support pausing without data loss.

This workaround was not invented for sdma but for edma (with am335x).

According to John above, dra7/sdma requires this workaround.

Quoted 9 lines

Quoted 1 line

http://www.spinics.net/lists/linux-serial/msg18503.html

This could be fixed. See
http://www.spinics.net/lists/linux-serial/msg18517.html
http://www.spinics.net/lists/linux-serial/msg18531.html

rmk was fine with it from what I read. So what is missing is just refurbish the patch (update the comment according to rmk replay) and then we could re-enable DMA again.

That's hardly all that is required.

1. edma pause returns an error if the descriptor has already been retired when a pause is attempted. This makes distinguishing between reporting an error for unsupported feature indistinguishable from a transient dma error that can simply be logged.
2. The question of a spurious uart interrupt with every dma transaction on am335x is still unanswered.

3. Handling XON/XOFF transmit is mandatory; I don't see a way to do that without pause/resume.

4. Since virt-dma uses tasklets which since 3.8 are no longer serviced in a timely manner, rx dma is unreliable, since it's often kicked out to regular interrupts.

5. omap dma maintenance is not keeping up with baseline dma.

IOW, omap dma has turned into one big tangle of workarounds.

Let's start with making a list of which TI designs need which workarounds.

*am335x*

- requires write to tx fifo to trigger tx dma (ie. OMAP_DMA_TX_KICK workaround necessitating completely different tx dma completion handler)

- requires rx dma already queued before UART data ready interrupt (ie., necessitates completely different irq handler and rx dma completion handler)

- hangs changing some unknown register if tx dma in progress (ie., this termios change workaround)

- generates spurious uart interrupt for every rx dma transaction (ie., necessitates acking every UART interrupt, even UART_IIR_NO_INT) _Even with this workaround_, it still generates spurious interrupt warning which shuts off interrupts for several ms while logging the error message to the console, virtually guaranteeing lost data.

Can any TI design use the baseline 8250 tx dma transaction flow without workarounds? I know the am335x can't; any others?

Can any TI design use the baseline 8250 rx dma transaction flow without workarounds? Again, I know the am335x can't; any others?

Quoted 14 lines · Peter Hurley

Quoted 13 lines · Sebastian Andrzej Siewior

Quoted 12 lines · Peter Hurley

Quoted 10 lines · John Ogness

Quoted 6 lines · Peter Hurley

Quoted 1 line · John Ogness

It has been observed that the TX-DMA can stall

Does this happen on any other OMAP part besides am335x? I looked back over the LKML history of this and didn't see any other design implicated in this problem.

I just ran the tests again using 4.6-rc2. I am able to reproduce the dma-tx stall with am335x/edma and dra7/sdma.

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

I thought we already established sdma was not to be used since the hardware does not actually support pausing without data loss.

This workaround was not invented for sdma but for edma (with am335x).

According to John above, dra7/sdma requires this workaround.

It was reported by Frans Klaver against am335x
http://lkml.kernel.org/r/[email protected]

and I managed to reproduce this with his yocto image on dra7 and am335x:
http://lkml.kernel.org/r/[email protected]

Quoted 2 lines

- hangs changing some unknown register if tx dma in progress (ie., this termios change workaround)

I think some registers are the baud-rate registers which pause engine.

Quoted 6 lines · Sebastian Andrzej Siewior

Quoted 5 lines · Peter Hurley

Quoted 4 lines · Sebastian Andrzej Siewior

Quoted 3 lines · Peter Hurley

Quoted 2 lines · John Ogness

Quoted 1 line · Peter Hurley

On 03/31/2016 01:41 AM, John Ogness wrote:

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 8 lines

Quoted 5 lines

Quoted 1 line

It has been observed that the TX-DMA can stall

Does this happen on any other OMAP part besides am335x? I looked back over the LKML history of this and didn't see any other design implicated in this problem.

I just ran the tests again using 4.6-rc2. I am able to reproduce the dma-tx stall with am335x/edma and dra7/sdma.

Quoted 5 lines

Quoted 5 lines

Quoted 4 lines

Quoted 2 lines

I thought we already established sdma was not to be used since the hardware does not actually support pausing without data loss.

This workaround was not invented for sdma but for edma (with am335x).

Quoted 7 lines

Quoted 1 line

According to John above, dra7/sdma requires this workaround.

It was reported by Frans Klaver against am335x
http://lkml.kernel.org/r/[email protected]

and I managed to reproduce this with his yocto image on dra7 and am335x:
http://lkml.kernel.org/r/[email protected]

[...]

Quoted 4 lines

Quoted 2 lines

- hangs changing some unknown register if tx dma in progress (ie., this termios change workaround)

I think some registers are the baud-rate registers which pause engine.

Let's back up here and focus on just this problem for now.

Since this is observable on dra7/sdma, then it's not related to the OMAP_DMA_TX_KICK problem. IOW, dropping tx dma support for am335x does not make this go away, which is what I was asking.

Now, if the DLL/DLH/MDR1 register writes are causing dma to stall, then skipping those if they're unchanged should fix this, and then pause/terminating in-progress DMA if any of these registers are being written would be acceptable since some data loss is to be expected when changing the baud rate without waiting.

Quoted 2 lines · Peter Hurley

Quoted 1 line · Sebastian Andrzej Siewior

On 04/11/2016 07:53 PM, Peter Hurley wrote:

Quoted 2 lines

2. The question of a spurious uart interrupt with every dma transaction on am335x is still unanswered.

This is correct. If I remember correctly, the Intel people see the same thing and I *think* John told me that the Intel manual says that RDI should be disabled if DMA is used.

Quoted 2 lines

3. Handling XON/XOFF transmit is mandatory; I don't see a way to do that without pause/resume.

Yes, not doing XON/XOFF with DMA is not good. Using hardware flow control is one workaround but the user has no chance of knowing that XON/XOFF has been silently disabled.

You could send the x_char after TX transfer completed. After all you need to ensure that you have some space in the TX-FIFO. However if you send a 4KiB of data you might want to send x_char rather sooner than later. I *think* even with pause the hardware will complete the last burst before stopping but is probably better than waiting for the 4KiB to complete.

Quoted 3 lines

4. Since virt-dma uses tasklets which since 3.8 are no longer serviced in a timely manner, rx dma is unreliable, since it's often kicked out to regular interrupts.

Is this only the delay in omap_dma_callback() (which you don't have !cyclic) or something else? omap_dma_issue_pending() seems to program the transfer right away. Oh now I see the same thing in edma_completion_handler(). Okay but this affects now everyone that relies on low latency?

Quoted 1 line

5. omap dma maintenance is not keeping up with baseline dma.

John switched to cylic mode so he was not effected very much non-pause problem.

Quoted 3 lines

- requires rx dma already queued before UART data ready interrupt (ie., necessitates completely different irq handler and rx dma completion handler)

true. But is this something that would work for others, too?

Quoted 6 lines

Quoted 2 lines

3. Handling XON/XOFF transmit is mandatory; I don't see a way to do that without pause/resume.

Yes, not doing XON/XOFF with DMA is not good. Using hardware flow control is one workaround but the user has no chance of knowing that XON/XOFF has been silently disabled.

Quoted 3 lines

the transfer right away. Oh now I see the same thing in edma_completion_handler(). Okay but this affects now everyone that relies on low latency?

Well, the real problem is that only one rx buffer is being used serially, first filled by the dma h/w, then emptied by the driver, then resubmitted. This creates a gap of time between the dma h/w completion interrupt and the resubmission where data loss is possible (and happens).

But that's why I'd like to bring the two implementations closer, so that maybe both can be replaced with a single rx dma transaction flow. [ And perhaps extending tty buffer to perform direct fill, skipping the
buffer copy ]

Quoted 6 lines

Quoted 6 lines

Quoted 2 lines

3. Handling XON/XOFF transmit is mandatory; I don't see a way to do that without pause/resume.

Yes, not doing XON/XOFF with DMA is not good. Using hardware flow control is one workaround but the user has no chance of knowing that XON/XOFF has been silently disabled.

You can clear the bits in the termios when the termios is set and the application *should* interpret that as not supported. I doubt many applications do for the XON/XOFF case. Equally you can just say that soft flow control turns off DMA or reduces buffering depending upon the data rate. We have plenty of hardware in the kernel that is more optimal in some configurations than others.

This also shouldn't be about whether 4K is a lot - it's about time to respond. Thus the _time_ latency of getting the ^S/^Q out is what matters at higher rates. At low speed (1200-9600 etc) you want to be able to respond within a few characters because the chances are the device the other end is not very bright.

Quoted 8 lines

Quoted 3 lines

the transfer right away. Oh now I see the same thing in edma_completion_handler(). Okay but this affects now everyone that relies on low latency?

Well, the real problem is that only one rx buffer is being used serially, first filled by the dma h/w, then emptied by the driver, then resubmitted. This creates a gap of time between the dma h/w completion interrupt and the resubmission where data loss is possible (and happens).

Most low latency users are concerned about the latency between transmit and receive.

The usual case is windowless protocols like firmware downloaders. For higher speed that tends to be driven by the DMA timeouts, for lower baud rates you can perhaps mitigate this by using chains of very small buffers or just turning off DMA just as we turn off some of the FIFOs at very low speed ?

Quoted 4 lines

But that's why I'd like to bring the two implementations closer, so that maybe both can be replaced with a single rx dma transaction flow. [ And perhaps extending tty buffer to perform direct fill, skipping the
buffer copy ]

For the general case what IMHO is needed is probably not a direct fill of the tty buffer (which is surprisingly locking hard - we used to have one but it was broken) but rather a fastpath around it. With the specific exception of N_TTY I think every single other line discipline we have is capable of accepting a pointer and length to a block of data that ceases to be valid the moment the function returns. All the networking ones certainly are and it would speed up the usual culprits (3G modems over USB, bluetooth over onboard 3.3v uart etc).

So a way to call

	port->fast_rx(data, flags, len);

with a rule that you never mix fast and tty buffers, and with an atomic swap of port->fast_rx between tty_buffer queueing logic, discard and ldisc->fast_rx pointers done when the ldisc is set or changes.

There are very few cases where n_tty is the one that needs the optimized
path: uucp died a long time ago 8)

Alan

Quoted 6 lines · Peter Hurley

Quoted 5 lines · Sebastian Andrzej Siewior

Quoted 4 lines · Peter Hurley

Quoted 3 lines · John Ogness

Quoted 2 lines · Peter Hurley

Quoted 1 line · John Ogness

It has been observed that the TX-DMA can stall

Quoted 6 lines

Quoted 6 lines

Quoted 1 line

http://www.spinics.net/lists/linux-serial/msg18503.html

This could be fixed. See
http://www.spinics.net/lists/linux-serial/msg18517.html
http://www.spinics.net/lists/linux-serial/msg18531.html

Quoted 5 lines

Quoted 3 lines

rmk was fine with it from what I read. So what is missing is just refurbish the patch (update the comment according to rmk replay) and then we could re-enable DMA again.

That's hardly all that is required.

well it would enable pause of RX transfers.

TX would not work (unless TI's HW people can confirm that it will).

Quoted 4 lines

1. edma pause returns an error if the descriptor has already been retired when a pause is attempted. This makes distinguishing between reporting an error for unsupported feature indistinguishable from a transient dma error that can simply be logged.

Quoted 1 line

IOW, omap dma has turned into one big tangle of workarounds.

Most of them are hardware shortcomings.

I think disabling RX-DMA due to missing pause in omap-dma is the only workaround that could be avoided if the driver would be changed.

Quoted 3 lines

Let's start with making a list of which TI designs need which workarounds.

*am335x*

I am not sure if the limitations are based on the DMA engine or the

Quoted 2 lines

- requires write to tx fifo to trigger tx dma (ie. OMAP_DMA_TX_KICK workaround necessitating completely different tx dma completion handler)

This one for instance I don't see on BeagleBoard xM / omap36xx and DRA7x. Both (not affected) use SDMA instead EDMA.

It would be interesting to see if DRA7x is affected once it uses EDMA.

Quoted 5 lines

- generates spurious uart interrupt for every rx dma transaction (ie., necessitates acking every UART interrupt, even UART_IIR_NO_INT) _Even with this workaround_, it still generates spurious interrupt warning which shuts off interrupts for several ms while logging the error message to the console, virtually guaranteeing lost data.

as I wrote in my other email I think RDI should be disabled with DMA

according the Intel manual and I *think* someone here reported that they see the same problem.

Quoted 2 lines

Can any TI design use the baseline 8250 tx dma transaction flow without workarounds? I know the am335x can't; any others?

Am335x. Has edma and so has dm814x. According to the code, dm814x based HW does not need it, can this be confirmed? Sekhar, TOny?

Quoted 2 lines

Can any TI design use the baseline 8250 rx dma transaction flow without workarounds? Again, I know the am335x can't; any others?

Is dra7 out? Because that one needs to enqueue RX transfers asap. And omap36xx (aka BeagleBoard-xm) as well. I don't kown anything about later SoCs (like am437x and so on) but I would assume so.

Quoted 7 lines

Quoted 5 lines

- generates spurious uart interrupt for every rx dma transaction (ie., necessitates acking every UART interrupt, even UART_IIR_NO_INT) _Even with this workaround_, it still generates spurious interrupt warning which shuts off interrupts for several ms while logging the error message to the console, virtually guaranteeing lost data.

as I wrote in my other email I think RDI should be disabled with DMA

I'll test to see if disabling RDI eliminates the UART_IIR_NO_INT spurious interrupts.

Quoted 2 lines

according the Intel manual and I *think* someone here reported that they see the same problem.

Let's confirm with the Intel folks that this is true, which would argue for using the omap-style rx dma flow.

Quoted 6 lines · Peter Hurley

Quoted 6 lines

Quoted 5 lines

- generates spurious uart interrupt for every rx dma transaction (ie., necessitates acking every UART interrupt, even UART_IIR_NO_INT) _Even with this workaround_, it still generates spurious interrupt warning which shuts off interrupts for several ms while logging the error message to the console, virtually guaranteeing lost data.

Quoted 5 lines

Quoted 1 line

as I wrote in my other email I think RDI should be disabled with DMA

I'll test to see if disabling RDI eliminates the UART_IIR_NO_INT spurious interrupts.

Quoted 5 lines

Quoted 2 lines

according the Intel manual and I *think* someone here reported that they see the same problem.

Let's confirm with the Intel folks that this is true, which would argue for using the omap-style rx dma flow.

Andy Shevchenko pointed this out here: https://lkml.org/lkml/2016/2/23/588

The problem is that we have no separate bit to control timeout interrupts from UART.

Quoted 5 lines · Peter Hurley

Quoted 4 lines · Sebastian Andrzej Siewior

Quoted 3 lines · Peter Hurley

Quoted 2 lines · John Ogness

Quoted 1 line · Peter Hurley

On 03/31/2016 01:41 AM, John Ogness wrote:

Quoted 1 line

*am335x*

I am not sure if the limitations are based on the DMA engine or the

Quoted 2 lines

- requires write to tx fifo to trigger tx dma (ie. OMAP_DMA_TX_KICK workaround necessitating completely different tx dma completion handler)

This one for instance I don't see on BeagleBoard xM / omap36xx and DRA7x. Both (not affected) use SDMA instead EDMA. It would be interesting to see if DRA7x is affected once it uses EDMA.