[RFC PATCH 0/3] omap-serial high-speed fixes/improvements

[RFC PATCH 0/3] omap-serial high-speed fixes/improvements

[Frans Klaver]

Hi,

Here's a couple of patches that should improve the behavior of the omap serial
driver at high data rates and baud rates.

I was actually surprised to see that proper dma support isn't there yet, but
there you go. Anyone got news on that, by the way?

Thanks for reviewing this,
Frans


Frans Klaver (3):
  tty: omap-serial: prevent division by zero
  tty: omap-serial: use threaded interrupt handler
  tty: omap-serial: support setting of hardware flow control in dts

 .../devicetree/bindings/serial/omap_serial.txt     |  1 +
 drivers/tty/serial/omap-serial.c                   | 52 ++++++++++++++++------
 2 files changed, 40 insertions(+), 13 deletions(-)

-- 
1.9.3

[RFC PATCH 0/3] omap-serial high-speed fixes/improvements

[Frans Klaver]

Hi,

Here's a couple of patches that should improve the behavior of the omap serial
driver at high data rates and baud rates.

I was actually surprised to see that proper dma support isn't there yet, but
there you go. Anyone got news on that, by the way?

Thanks for reviewing this,
Frans


Frans Klaver (3):
  tty: omap-serial: prevent division by zero
  tty: omap-serial: use threaded interrupt handler
  tty: omap-serial: support setting of hardware flow control in dts

 .../devicetree/bindings/serial/omap_serial.txt     |  1 +
 drivers/tty/serial/omap-serial.c                   | 52 ++++++++++++++++------
 2 files changed, 40 insertions(+), 13 deletions(-)

-- 
1.9.3

[PATCH 1/3] tty: omap-serial: prevent division by zero

[Frans Klaver]

If the chosen baud rate is large enough (e.g. 3.5 megabaud), the
calculated n13 and n16 values in serial_omap_baud_is_mode16 may become
0. This causes a division by zero when calculating the difference
between calculated and desired baud rates. To prevent this, cap n13 and
n16 on 1.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
 drivers/tty/serial/omap-serial.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index d017cec..e454b7c 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -254,8 +254,16 @@ serial_omap_baud_is_mode16(struct uart_port *port, unsigned int baud)
 {
 	unsigned int n13 = port->uartclk / (13 * baud);
 	unsigned int n16 = port->uartclk / (16 * baud);
-	int baudAbsDiff13 = baud - (port->uartclk / (13 * n13));
-	int baudAbsDiff16 = baud - (port->uartclk / (16 * n16));
+	int baudAbsDiff13;
+	int baudAbsDiff16;
+
+	if (n13 == 0)
+		n13 = 1;
+	if (n16 == 0)
+		n16 = 1;
+
+	baudAbsDiff13 = baud - (port->uartclk / (13 * n13));
+	baudAbsDiff16 = baud - (port->uartclk / (16 * n16));
 	if (baudAbsDiff13 < 0)
 		baudAbsDiff13 = -baudAbsDiff13;
 	if (baudAbsDiff16 < 0)
-- 
1.9.3

Re: [PATCH 1/3] tty: omap-serial: prevent division by zero

[Frans Klaver]

Sorry, missed some CC's in git send-email.

On Tue, Jul 29, 2014 at 04:52:55PM +0200, Frans Klaver wrote:
> If the chosen baud rate is large enough (e.g. 3.5 megabaud), the
> calculated n13 and n16 values in serial_omap_baud_is_mode16 may become
> 0. This causes a division by zero when calculating the difference
> between calculated and desired baud rates. To prevent this, cap n13 and
> n16 on 1.
> 
> Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
> ---
>  drivers/tty/serial/omap-serial.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index d017cec..e454b7c 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -254,8 +254,16 @@ serial_omap_baud_is_mode16(struct uart_port *port, unsigned int baud)
>  {
>  	unsigned int n13 = port->uartclk / (13 * baud);
>  	unsigned int n16 = port->uartclk / (16 * baud);
> -	int baudAbsDiff13 = baud - (port->uartclk / (13 * n13));
> -	int baudAbsDiff16 = baud - (port->uartclk / (16 * n16));
> +	int baudAbsDiff13;
> +	int baudAbsDiff16;
> +
> +	if (n13 == 0)
> +		n13 = 1;
> +	if (n16 == 0)
> +		n16 = 1;
> +
> +	baudAbsDiff13 = baud - (port->uartclk / (13 * n13));
> +	baudAbsDiff16 = baud - (port->uartclk / (16 * n16));
>  	if (baudAbsDiff13 < 0)
>  		baudAbsDiff13 = -baudAbsDiff13;
>  	if (baudAbsDiff16 < 0)
> -- 
> 1.9.3
> 

Re: [PATCH 1/3] tty: omap-serial: prevent division by zero

[Frans Klaver]

Sorry, missed some CC's in git send-email.

On Tue, Jul 29, 2014 at 04:52:55PM +0200, Frans Klaver wrote:
> If the chosen baud rate is large enough (e.g. 3.5 megabaud), the
> calculated n13 and n16 values in serial_omap_baud_is_mode16 may become
> 0. This causes a division by zero when calculating the difference
> between calculated and desired baud rates. To prevent this, cap n13 and
> n16 on 1.
> 
> Signed-off-by: Frans Klaver <frans.klaver-MHHw4NDrbWwAvxtiuMwx3w@public.gmane.org>
> ---
>  drivers/tty/serial/omap-serial.c | 12 ++++++++++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index d017cec..e454b7c 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -254,8 +254,16 @@ serial_omap_baud_is_mode16(struct uart_port *port, unsigned int baud)
>  {
>  	unsigned int n13 = port->uartclk / (13 * baud);
>  	unsigned int n16 = port->uartclk / (16 * baud);
> -	int baudAbsDiff13 = baud - (port->uartclk / (13 * n13));
> -	int baudAbsDiff16 = baud - (port->uartclk / (16 * n16));
> +	int baudAbsDiff13;
> +	int baudAbsDiff16;
> +
> +	if (n13 == 0)
> +		n13 = 1;
> +	if (n16 == 0)
> +		n16 = 1;
> +
> +	baudAbsDiff13 = baud - (port->uartclk / (13 * n13));
> +	baudAbsDiff16 = baud - (port->uartclk / (16 * n16));
>  	if (baudAbsDiff13 < 0)
>  		baudAbsDiff13 = -baudAbsDiff13;
>  	if (baudAbsDiff16 < 0)
> -- 
> 1.9.3
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] tty: omap-serial: use threaded interrupt handler

[Frans Klaver]

At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
this to about 170 overflows in 10 minutes.

In practice this therefore reduces the need for hardware flow control,
meaning the sending side doesn't have to buffer as much either.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
 drivers/tty/serial/omap-serial.c | 37 ++++++++++++++++++++++++++-----------
 1 file changed, 26 insertions(+), 11 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index e454b7c..ff2d931 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -569,6 +569,21 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
 }
 
 /**
+ * serial_omap_fast_irq() - schedule interrupt handling
+ */
+static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
+{
+	struct uart_omap_port *up = dev_id;
+	unsigned int iir = serial_in(up, UART_IIR);
+	if (iir & UART_IIR_NO_INT) {
+		return IRQ_NONE;
+	}
+
+	disable_irq_nosync(up->port.irq);
+	return IRQ_WAKE_THREAD;
+}
+
+/**
  * serial_omap_irq() - This handles the interrupt from one port
  * @irq: uart port irq number
  * @dev_id: uart port info
@@ -578,18 +593,12 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 	struct uart_omap_port *up = dev_id;
 	unsigned int iir, lsr;
 	unsigned int type;
-	irqreturn_t ret = IRQ_NONE;
 	int max_count = 256;
 
 	spin_lock(&up->port.lock);
 	pm_runtime_get_sync(up->dev);
 
 	do {
-		iir = serial_in(up, UART_IIR);
-		if (iir & UART_IIR_NO_INT)
-			break;
-
-		ret = IRQ_HANDLED;
 		lsr = serial_in(up, UART_LSR);
 
 		/* extract IRQ type from IIR register */
@@ -618,17 +627,21 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 		default:
 			break;
 		}
+
+		iir = serial_in(up, UART_IIR);
 	} while (!(iir & UART_IIR_NO_INT) && max_count--);
 
 	spin_unlock(&up->port.lock);
 
 	tty_flip_buffer_push(&up->port.state->port);
 
+	enable_irq(up->port.irq);
+
 	pm_runtime_mark_last_busy(up->dev);
 	pm_runtime_put_autosuspend(up->dev);
 	up->port_activity = jiffies;
 
-	return ret;
+	return IRQ_HANDLED;
 }
 
 static unsigned int serial_omap_tx_empty(struct uart_port *port)
@@ -725,15 +738,17 @@ static int serial_omap_startup(struct uart_port *port)
 	/*
 	 * Allocate the IRQ
 	 */
-	retval = request_irq(up->port.irq, serial_omap_irq, up->port.irqflags,
-				up->name, up);
+	retval = request_threaded_irq(up->port.irq, serial_omap_fast_irq,
+					serial_omap_irq, up->port.irqflags,
+					up->name, up);
 	if (retval)
 		return retval;
 
 	/* Optional wake-up IRQ */
 	if (up->wakeirq) {
-		retval = request_irq(up->wakeirq, serial_omap_irq,
-				     up->port.irqflags, up->name, up);
+		retval = request_threaded_irq(up->wakeirq, serial_omap_fast_irq,
+					serial_omap_irq, up->port.irqflags,
+					up->name, up);
 		if (retval) {
 			free_irq(up->port.irq, up);
 			return retval;
-- 
1.9.3

[PATCH 3/3] tty: omap-serial: support setting of hardware flow control in dts

[Frans Klaver]

This makes hardware flow control availability configurable from the
device tree.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
 Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
 drivers/tty/serial/omap-serial.c                         | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 342eedd..1b629e9 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -8,3 +8,4 @@ Required properties:
 
 Optional properties:
 - clock-frequency : frequency of the clock input to the UART
+- has-hw-flow-control : the hardware has flow control capability
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index ff2d931..87df0ee 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1660,6 +1660,9 @@ static int serial_omap_probe(struct platform_device *pdev)
 			return -EPROBE_DEFER;
 		wakeirq = irq_of_parse_and_map(pdev->dev.of_node, 1);
 		omap_up_info = of_get_uart_port_info(&pdev->dev);
+		if (of_property_read_bool(pdev->dev.of_node,
+					"has-hw-flow-control"))
+			omap_up_info->flags |= UPF_HARD_FLOW;
 		pdev->dev.platform_data = omap_up_info;
 	} else {
 		uartirq = platform_get_irq(pdev, 0);
-- 
1.9.3

[RFC PATCH 0/3] omap-serial high-speed fixes/improvements

[Frans Klaver]

Hi,

Apologies, something went wrong. Here's a resend.

Here's a couple of patches that should improve the behavior of the omap serial
driver at high data rates and baud rates.

I was actually surprised to see that proper dma support isn't there yet, but
there you go. Anyone got news on that, by the way?

Thanks for reviewing this,
Frans


Frans Klaver (3):
  tty: omap-serial: prevent division by zero
  tty: omap-serial: use threaded interrupt handler
  tty: omap-serial: support setting of hardware flow control in dts

 .../devicetree/bindings/serial/omap_serial.txt     |  1 +
 drivers/tty/serial/omap-serial.c                   | 52 ++++++++++++++++------
 2 files changed, 40 insertions(+), 13 deletions(-)

-- 
1.9.3

[RFC PATCH 0/3] omap-serial high-speed fixes/improvements

[Frans Klaver]

Hi,

Apologies, something went wrong. Here's a resend.

Here's a couple of patches that should improve the behavior of the omap serial
driver at high data rates and baud rates.

I was actually surprised to see that proper dma support isn't there yet, but
there you go. Anyone got news on that, by the way?

Thanks for reviewing this,
Frans


Frans Klaver (3):
  tty: omap-serial: prevent division by zero
  tty: omap-serial: use threaded interrupt handler
  tty: omap-serial: support setting of hardware flow control in dts

 .../devicetree/bindings/serial/omap_serial.txt     |  1 +
 drivers/tty/serial/omap-serial.c                   | 52 ++++++++++++++++------
 2 files changed, 40 insertions(+), 13 deletions(-)

-- 
1.9.3

[PATCH 1/3] tty: omap-serial: prevent division by zero

[Frans Klaver]

If the chosen baud rate is large enough (e.g. 3.5 megabaud), the
calculated n13 and n16 values in serial_omap_baud_is_mode16 may become
0. This causes a division by zero when calculating the difference
between calculated and desired baud rates. To prevent this, cap n13 and
n16 on 1.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
 drivers/tty/serial/omap-serial.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index d017cec..e454b7c 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -254,8 +254,16 @@ serial_omap_baud_is_mode16(struct uart_port *port, unsigned int baud)
 {
 	unsigned int n13 = port->uartclk / (13 * baud);
 	unsigned int n16 = port->uartclk / (16 * baud);
-	int baudAbsDiff13 = baud - (port->uartclk / (13 * n13));
-	int baudAbsDiff16 = baud - (port->uartclk / (16 * n16));
+	int baudAbsDiff13;
+	int baudAbsDiff16;
+
+	if (n13 == 0)
+		n13 = 1;
+	if (n16 == 0)
+		n16 = 1;
+
+	baudAbsDiff13 = baud - (port->uartclk / (13 * n13));
+	baudAbsDiff16 = baud - (port->uartclk / (16 * n16));
 	if (baudAbsDiff13 < 0)
 		baudAbsDiff13 = -baudAbsDiff13;
 	if (baudAbsDiff16 < 0)
-- 
1.9.3

[PATCH 1/3] tty: omap-serial: prevent division by zero

[Frans Klaver]

If the chosen baud rate is large enough (e.g. 3.5 megabaud), the
calculated n13 and n16 values in serial_omap_baud_is_mode16 may become
0. This causes a division by zero when calculating the difference
between calculated and desired baud rates. To prevent this, cap n13 and
n16 on 1.

Signed-off-by: Frans Klaver <frans.klaver-MHHw4NDrbWwAvxtiuMwx3w@public.gmane.org>
---
 drivers/tty/serial/omap-serial.c | 12 ++++++++++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index d017cec..e454b7c 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -254,8 +254,16 @@ serial_omap_baud_is_mode16(struct uart_port *port, unsigned int baud)
 {
 	unsigned int n13 = port->uartclk / (13 * baud);
 	unsigned int n16 = port->uartclk / (16 * baud);
-	int baudAbsDiff13 = baud - (port->uartclk / (13 * n13));
-	int baudAbsDiff16 = baud - (port->uartclk / (16 * n16));
+	int baudAbsDiff13;
+	int baudAbsDiff16;
+
+	if (n13 == 0)
+		n13 = 1;
+	if (n16 == 0)
+		n16 = 1;
+
+	baudAbsDiff13 = baud - (port->uartclk / (13 * n13));
+	baudAbsDiff16 = baud - (port->uartclk / (16 * n16));
 	if (baudAbsDiff13 < 0)
 		baudAbsDiff13 = -baudAbsDiff13;
 	if (baudAbsDiff16 < 0)
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] tty: omap-serial: use threaded interrupt handler

[Frans Klaver]

At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
this to about 170 overflows in 10 minutes.

In practice this therefore reduces the need for hardware flow control,
meaning the sending side doesn't have to buffer as much either.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
 drivers/tty/serial/omap-serial.c | 37 ++++++++++++++++++++++++++-----------
 1 file changed, 26 insertions(+), 11 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index e454b7c..ff2d931 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -569,6 +569,21 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
 }
 
 /**
+ * serial_omap_fast_irq() - schedule interrupt handling
+ */
+static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
+{
+	struct uart_omap_port *up = dev_id;
+	unsigned int iir = serial_in(up, UART_IIR);
+	if (iir & UART_IIR_NO_INT) {
+		return IRQ_NONE;
+	}
+
+	disable_irq_nosync(up->port.irq);
+	return IRQ_WAKE_THREAD;
+}
+
+/**
  * serial_omap_irq() - This handles the interrupt from one port
  * @irq: uart port irq number
  * @dev_id: uart port info
@@ -578,18 +593,12 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 	struct uart_omap_port *up = dev_id;
 	unsigned int iir, lsr;
 	unsigned int type;
-	irqreturn_t ret = IRQ_NONE;
 	int max_count = 256;
 
 	spin_lock(&up->port.lock);
 	pm_runtime_get_sync(up->dev);
 
 	do {
-		iir = serial_in(up, UART_IIR);
-		if (iir & UART_IIR_NO_INT)
-			break;
-
-		ret = IRQ_HANDLED;
 		lsr = serial_in(up, UART_LSR);
 
 		/* extract IRQ type from IIR register */
@@ -618,17 +627,21 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 		default:
 			break;
 		}
+
+		iir = serial_in(up, UART_IIR);
 	} while (!(iir & UART_IIR_NO_INT) && max_count--);
 
 	spin_unlock(&up->port.lock);
 
 	tty_flip_buffer_push(&up->port.state->port);
 
+	enable_irq(up->port.irq);
+
 	pm_runtime_mark_last_busy(up->dev);
 	pm_runtime_put_autosuspend(up->dev);
 	up->port_activity = jiffies;
 
-	return ret;
+	return IRQ_HANDLED;
 }
 
 static unsigned int serial_omap_tx_empty(struct uart_port *port)
@@ -725,15 +738,17 @@ static int serial_omap_startup(struct uart_port *port)
 	/*
 	 * Allocate the IRQ
 	 */
-	retval = request_irq(up->port.irq, serial_omap_irq, up->port.irqflags,
-				up->name, up);
+	retval = request_threaded_irq(up->port.irq, serial_omap_fast_irq,
+					serial_omap_irq, up->port.irqflags,
+					up->name, up);
 	if (retval)
 		return retval;
 
 	/* Optional wake-up IRQ */
 	if (up->wakeirq) {
-		retval = request_irq(up->wakeirq, serial_omap_irq,
-				     up->port.irqflags, up->name, up);
+		retval = request_threaded_irq(up->wakeirq, serial_omap_fast_irq,
+					serial_omap_irq, up->port.irqflags,
+					up->name, up);
 		if (retval) {
 			free_irq(up->port.irq, up);
 			return retval;
-- 
1.9.3

[PATCH 2/3] tty: omap-serial: use threaded interrupt handler

[Frans Klaver]

At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
this to about 170 overflows in 10 minutes.

In practice this therefore reduces the need for hardware flow control,
meaning the sending side doesn't have to buffer as much either.

Signed-off-by: Frans Klaver <frans.klaver-MHHw4NDrbWwAvxtiuMwx3w@public.gmane.org>
---
 drivers/tty/serial/omap-serial.c | 37 ++++++++++++++++++++++++++-----------
 1 file changed, 26 insertions(+), 11 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index e454b7c..ff2d931 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -569,6 +569,21 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
 }
 
 /**
+ * serial_omap_fast_irq() - schedule interrupt handling
+ */
+static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
+{
+	struct uart_omap_port *up = dev_id;
+	unsigned int iir = serial_in(up, UART_IIR);
+	if (iir & UART_IIR_NO_INT) {
+		return IRQ_NONE;
+	}
+
+	disable_irq_nosync(up->port.irq);
+	return IRQ_WAKE_THREAD;
+}
+
+/**
  * serial_omap_irq() - This handles the interrupt from one port
  * @irq: uart port irq number
  * @dev_id: uart port info
@@ -578,18 +593,12 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 	struct uart_omap_port *up = dev_id;
 	unsigned int iir, lsr;
 	unsigned int type;
-	irqreturn_t ret = IRQ_NONE;
 	int max_count = 256;
 
 	spin_lock(&up->port.lock);
 	pm_runtime_get_sync(up->dev);
 
 	do {
-		iir = serial_in(up, UART_IIR);
-		if (iir & UART_IIR_NO_INT)
-			break;
-
-		ret = IRQ_HANDLED;
 		lsr = serial_in(up, UART_LSR);
 
 		/* extract IRQ type from IIR register */
@@ -618,17 +627,21 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 		default:
 			break;
 		}
+
+		iir = serial_in(up, UART_IIR);
 	} while (!(iir & UART_IIR_NO_INT) && max_count--);
 
 	spin_unlock(&up->port.lock);
 
 	tty_flip_buffer_push(&up->port.state->port);
 
+	enable_irq(up->port.irq);
+
 	pm_runtime_mark_last_busy(up->dev);
 	pm_runtime_put_autosuspend(up->dev);
 	up->port_activity = jiffies;
 
-	return ret;
+	return IRQ_HANDLED;
 }
 
 static unsigned int serial_omap_tx_empty(struct uart_port *port)
@@ -725,15 +738,17 @@ static int serial_omap_startup(struct uart_port *port)
 	/*
 	 * Allocate the IRQ
 	 */
-	retval = request_irq(up->port.irq, serial_omap_irq, up->port.irqflags,
-				up->name, up);
+	retval = request_threaded_irq(up->port.irq, serial_omap_fast_irq,
+					serial_omap_irq, up->port.irqflags,
+					up->name, up);
 	if (retval)
 		return retval;
 
 	/* Optional wake-up IRQ */
 	if (up->wakeirq) {
-		retval = request_irq(up->wakeirq, serial_omap_irq,
-				     up->port.irqflags, up->name, up);
+		retval = request_threaded_irq(up->wakeirq, serial_omap_fast_irq,
+					serial_omap_irq, up->port.irqflags,
+					up->name, up);
 		if (retval) {
 			free_irq(up->port.irq, up);
 			return retval;
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] tty: omap-serial: support setting of hardware flow control in dts

[Frans Klaver]

This makes hardware flow control availability configurable from the
device tree.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
 Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
 drivers/tty/serial/omap-serial.c                         | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 342eedd..1b629e9 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -8,3 +8,4 @@ Required properties:
 
 Optional properties:
 - clock-frequency : frequency of the clock input to the UART
+- has-hw-flow-control : the hardware has flow control capability
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index ff2d931..87df0ee 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1660,6 +1660,9 @@ static int serial_omap_probe(struct platform_device *pdev)
 			return -EPROBE_DEFER;
 		wakeirq = irq_of_parse_and_map(pdev->dev.of_node, 1);
 		omap_up_info = of_get_uart_port_info(&pdev->dev);
+		if (of_property_read_bool(pdev->dev.of_node,
+					"has-hw-flow-control"))
+			omap_up_info->flags |= UPF_HARD_FLOW;
 		pdev->dev.platform_data = omap_up_info;
 	} else {
 		uartirq = platform_get_irq(pdev, 0);
-- 
1.9.3

[PATCH 3/3] tty: omap-serial: support setting of hardware flow control in dts

[Frans Klaver]

This makes hardware flow control availability configurable from the
device tree.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
 Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
 drivers/tty/serial/omap-serial.c                         | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 342eedd..1b629e9 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -8,3 +8,4 @@ Required properties:
 
 Optional properties:
 - clock-frequency : frequency of the clock input to the UART
+- has-hw-flow-control : the hardware has flow control capability
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index ff2d931..87df0ee 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1660,6 +1660,9 @@ static int serial_omap_probe(struct platform_device *pdev)
 			return -EPROBE_DEFER;
 		wakeirq = irq_of_parse_and_map(pdev->dev.of_node, 1);
 		omap_up_info = of_get_uart_port_info(&pdev->dev);
+		if (of_property_read_bool(pdev->dev.of_node,
+					"has-hw-flow-control"))
+			omap_up_info->flags |= UPF_HARD_FLOW;
 		pdev->dev.platform_data = omap_up_info;
 	} else {
 		uartirq = platform_get_irq(pdev, 0);
-- 
1.9.3

Re: [RFC PATCH 0/3] omap-serial high-speed fixes/improvements

[Frans Klaver]

On Tue, Jul 29, 2014 at 05:02:29PM +0200, Frans Klaver wrote:
> Here's a couple of patches that should improve the behavior of the omap serial
> driver at high data rates and baud rates.

Anyone?

Re: [RFC PATCH 0/3] omap-serial high-speed fixes/improvements

[Frans Klaver]

On Tue, Jul 29, 2014 at 05:02:29PM +0200, Frans Klaver wrote:
> Here's a couple of patches that should improve the behavior of the omap serial
> driver at high data rates and baud rates.

Anyone?

Re: [RFC PATCH 0/3] omap-serial high-speed fixes/improvements

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

Hi,

On Tue, Jul 29, 2014 at 04:52:54PM +0200, Frans Klaver wrote:
> Hi,
> 
> Here's a couple of patches that should improve the behavior of the omap serial
> driver at high data rates and baud rates.
> 
> I was actually surprised to see that proper dma support isn't there yet, but
> there you go. Anyone got news on that, by the way?

please resend these patches and make sure you get the right Cc list.

You're missing linux-omap, Tony Lingren, linux-arm-kernel...
scripts/get_maintainer.pl would give you a more exaustive list of
people to Cc.

cheers

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RFC PATCH 0/3] omap-serial high-speed fixes/improvements

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 588 bytes --]

Hi,

On Tue, Jul 29, 2014 at 04:52:54PM +0200, Frans Klaver wrote:
> Hi,
> 
> Here's a couple of patches that should improve the behavior of the omap serial
> driver at high data rates and baud rates.
> 
> I was actually surprised to see that proper dma support isn't there yet, but
> there you go. Anyone got news on that, by the way?

please resend these patches and make sure you get the right Cc list.

You're missing linux-omap, Tony Lingren, linux-arm-kernel...
scripts/get_maintainer.pl would give you a more exaustive list of
people to Cc.

cheers

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RFC PATCH 0/3] omap-serial high-speed fixes/improvements

[Frans Klaver]

On Mon, Aug 18, 2014 at 08:45:08AM -0500, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Jul 29, 2014 at 04:52:54PM +0200, Frans Klaver wrote:
> > Hi,
> > 
> > Here's a couple of patches that should improve the behavior of the omap serial
> > driver at high data rates and baud rates.
> > 
> > I was actually surprised to see that proper dma support isn't there yet, but
> > there you go. Anyone got news on that, by the way?
> 
> please resend these patches and make sure you get the right Cc list.
> 
> You're missing linux-omap, Tony Lingren, linux-arm-kernel...
> scripts/get_maintainer.pl would give you a more exaustive list of
> people to Cc.

This CC list is what I got from get_maintainer.pl. I should have at
least remembered to add linux-omap, though. I take it everyone gets all
patches for consistency?

Thanks,
Frans

Re: [RFC PATCH 0/3] omap-serial high-speed fixes/improvements

[Frans Klaver]

On Mon, Aug 18, 2014 at 08:45:08AM -0500, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Jul 29, 2014 at 04:52:54PM +0200, Frans Klaver wrote:
> > Hi,
> > 
> > Here's a couple of patches that should improve the behavior of the omap serial
> > driver at high data rates and baud rates.
> > 
> > I was actually surprised to see that proper dma support isn't there yet, but
> > there you go. Anyone got news on that, by the way?
> 
> please resend these patches and make sure you get the right Cc list.
> 
> You're missing linux-omap, Tony Lingren, linux-arm-kernel...
> scripts/get_maintainer.pl would give you a more exaustive list of
> people to Cc.

This CC list is what I got from get_maintainer.pl. I should have at
least remembered to add linux-omap, though. I take it everyone gets all
patches for consistency?

Thanks,
Frans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCHv2 0/4] omap-serial high-speed fixes/improvements

[Frans Klaver]

Here's version 2 of the patches that should improve the behavior of the omap
serial port at high baud and data rates.

Differences with regard to v1 are:
  - centralize baud_is_mode16's calculation
  - fix/unbreak an uninitialized variable in "use threaded interrupt handler"
  - read has-hw-flow-control property in of_get_uart_port_info

Frans Klaver (4):
  tty: omap-serial: pull out calculation from baud_is_mode16
  tty: omap-serial: prevent division by zero
  tty: omap-serial: use threaded interrupt handler
  tty: omap-serial: support setting of hardware flow control in dts

 .../devicetree/bindings/serial/omap_serial.txt     |  1 +
 drivers/tty/serial/omap-serial.c                   | 65 +++++++++++++++++-----
 2 files changed, 51 insertions(+), 15 deletions(-)

-- 
1.9.3

[RFC PATCHv2 0/4] omap-serial high-speed fixes/improvements

[Frans Klaver]

Here's version 2 of the patches that should improve the behavior of the omap
serial port at high baud and data rates.

Differences with regard to v1 are:
  - centralize baud_is_mode16's calculation
  - fix/unbreak an uninitialized variable in "use threaded interrupt handler"
  - read has-hw-flow-control property in of_get_uart_port_info

Frans Klaver (4):
  tty: omap-serial: pull out calculation from baud_is_mode16
  tty: omap-serial: prevent division by zero
  tty: omap-serial: use threaded interrupt handler
  tty: omap-serial: support setting of hardware flow control in dts

 .../devicetree/bindings/serial/omap_serial.txt     |  1 +
 drivers/tty/serial/omap-serial.c                   | 65 +++++++++++++++++-----
 2 files changed, 51 insertions(+), 15 deletions(-)

-- 
1.9.3

[RFC PATCHv2 0/4] omap-serial high-speed fixes/improvements

[Frans Klaver]

Here's version 2 of the patches that should improve the behavior of the omap
serial port at high baud and data rates.

Differences with regard to v1 are:
  - centralize baud_is_mode16's calculation
  - fix/unbreak an uninitialized variable in "use threaded interrupt handler"
  - read has-hw-flow-control property in of_get_uart_port_info

Frans Klaver (4):
  tty: omap-serial: pull out calculation from baud_is_mode16
  tty: omap-serial: prevent division by zero
  tty: omap-serial: use threaded interrupt handler
  tty: omap-serial: support setting of hardware flow control in dts

 .../devicetree/bindings/serial/omap_serial.txt     |  1 +
 drivers/tty/serial/omap-serial.c                   | 65 +++++++++++++++++-----
 2 files changed, 51 insertions(+), 15 deletions(-)

-- 
1.9.3

[PATCH 1/4] tty: omap-serial: pull out calculation from baud_is_mode16

[Frans Klaver]

To determine the correct divisor, we need to know the difference between
the desired baud rate and the actual baud rate. The calculation for this
difference is implemented twice within omap_serial_baud_is_mode16().
Pull out the calculation for easier maintenance.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
 drivers/tty/serial/omap-serial.c | 26 ++++++++++++++++++--------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index d017cec..ae935ce 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -239,6 +239,22 @@ static void serial_omap_enable_wakeup(struct uart_omap_port *up, bool enable)
 }
 
 /*
+ * Calculate the absolute difference between the desired and actual baud
+ * rate for the given mode.
+ */
+static inline int calculate_baud_abs_diff(struct uart_port *port,
+				unsigned int baud, unsigned int mode)
+{
+	unsigned int n = port->uartclk / (mode * baud);
+	int abs_diff = baud - (port->uartclk / (mode * n));
+
+	if (abs_diff < 0)
+		abs_diff = -abs_diff;
+
+	return abs_diff;
+}
+
+/*
  * serial_omap_baud_is_mode16 - check if baud rate is MODE16X
  * @port: uart port info
  * @baud: baudrate for which mode needs to be determined
@@ -252,14 +268,8 @@ static void serial_omap_enable_wakeup(struct uart_omap_port *up, bool enable)
 static bool
 serial_omap_baud_is_mode16(struct uart_port *port, unsigned int baud)
 {
-	unsigned int n13 = port->uartclk / (13 * baud);
-	unsigned int n16 = port->uartclk / (16 * baud);
-	int baudAbsDiff13 = baud - (port->uartclk / (13 * n13));
-	int baudAbsDiff16 = baud - (port->uartclk / (16 * n16));
-	if (baudAbsDiff13 < 0)
-		baudAbsDiff13 = -baudAbsDiff13;
-	if (baudAbsDiff16 < 0)
-		baudAbsDiff16 = -baudAbsDiff16;
+	int baudAbsDiff13 = calculate_baud_abs_diff(port, baud, 13);
+	int baudAbsDiff16 = calculate_baud_abs_diff(port, baud, 16);
 
 	return (baudAbsDiff13 >= baudAbsDiff16);
 }
-- 
1.9.3

[PATCH 1/4] tty: omap-serial: pull out calculation from baud_is_mode16

[Frans Klaver]

To determine the correct divisor, we need to know the difference between
the desired baud rate and the actual baud rate. The calculation for this
difference is implemented twice within omap_serial_baud_is_mode16().
Pull out the calculation for easier maintenance.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
 drivers/tty/serial/omap-serial.c | 26 ++++++++++++++++++--------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index d017cec..ae935ce 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -239,6 +239,22 @@ static void serial_omap_enable_wakeup(struct uart_omap_port *up, bool enable)
 }
 
 /*
+ * Calculate the absolute difference between the desired and actual baud
+ * rate for the given mode.
+ */
+static inline int calculate_baud_abs_diff(struct uart_port *port,
+				unsigned int baud, unsigned int mode)
+{
+	unsigned int n = port->uartclk / (mode * baud);
+	int abs_diff = baud - (port->uartclk / (mode * n));
+
+	if (abs_diff < 0)
+		abs_diff = -abs_diff;
+
+	return abs_diff;
+}
+
+/*
  * serial_omap_baud_is_mode16 - check if baud rate is MODE16X
  * @port: uart port info
  * @baud: baudrate for which mode needs to be determined
@@ -252,14 +268,8 @@ static void serial_omap_enable_wakeup(struct uart_omap_port *up, bool enable)
 static bool
 serial_omap_baud_is_mode16(struct uart_port *port, unsigned int baud)
 {
-	unsigned int n13 = port->uartclk / (13 * baud);
-	unsigned int n16 = port->uartclk / (16 * baud);
-	int baudAbsDiff13 = baud - (port->uartclk / (13 * n13));
-	int baudAbsDiff16 = baud - (port->uartclk / (16 * n16));
-	if (baudAbsDiff13 < 0)
-		baudAbsDiff13 = -baudAbsDiff13;
-	if (baudAbsDiff16 < 0)
-		baudAbsDiff16 = -baudAbsDiff16;
+	int baudAbsDiff13 = calculate_baud_abs_diff(port, baud, 13);
+	int baudAbsDiff16 = calculate_baud_abs_diff(port, baud, 16);
 
 	return (baudAbsDiff13 >= baudAbsDiff16);
 }
-- 
1.9.3

[PATCH 1/4] tty: omap-serial: pull out calculation from baud_is_mode16

[Frans Klaver]

To determine the correct divisor, we need to know the difference between
the desired baud rate and the actual baud rate. The calculation for this
difference is implemented twice within omap_serial_baud_is_mode16().
Pull out the calculation for easier maintenance.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
 drivers/tty/serial/omap-serial.c | 26 ++++++++++++++++++--------
 1 file changed, 18 insertions(+), 8 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index d017cec..ae935ce 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -239,6 +239,22 @@ static void serial_omap_enable_wakeup(struct uart_omap_port *up, bool enable)
 }
 
 /*
+ * Calculate the absolute difference between the desired and actual baud
+ * rate for the given mode.
+ */
+static inline int calculate_baud_abs_diff(struct uart_port *port,
+				unsigned int baud, unsigned int mode)
+{
+	unsigned int n = port->uartclk / (mode * baud);
+	int abs_diff = baud - (port->uartclk / (mode * n));
+
+	if (abs_diff < 0)
+		abs_diff = -abs_diff;
+
+	return abs_diff;
+}
+
+/*
  * serial_omap_baud_is_mode16 - check if baud rate is MODE16X
  * @port: uart port info
  * @baud: baudrate for which mode needs to be determined
@@ -252,14 +268,8 @@ static void serial_omap_enable_wakeup(struct uart_omap_port *up, bool enable)
 static bool
 serial_omap_baud_is_mode16(struct uart_port *port, unsigned int baud)
 {
-	unsigned int n13 = port->uartclk / (13 * baud);
-	unsigned int n16 = port->uartclk / (16 * baud);
-	int baudAbsDiff13 = baud - (port->uartclk / (13 * n13));
-	int baudAbsDiff16 = baud - (port->uartclk / (16 * n16));
-	if (baudAbsDiff13 < 0)
-		baudAbsDiff13 = -baudAbsDiff13;
-	if (baudAbsDiff16 < 0)
-		baudAbsDiff16 = -baudAbsDiff16;
+	int baudAbsDiff13 = calculate_baud_abs_diff(port, baud, 13);
+	int baudAbsDiff16 = calculate_baud_abs_diff(port, baud, 16);
 
 	return (baudAbsDiff13 >= baudAbsDiff16);
 }
-- 
1.9.3

[PATCH 2/4] tty: omap-serial: prevent division by zero

[Frans Klaver]

If the chosen baud rate is large enough (e.g. 3.5 megabaud), the
calculated n values in calculate_baud_abs_diff may become 0. This causes
a division by zero when calculating the difference between calculated
and desired baud rates. To prevent this, cap n on 1.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
 drivers/tty/serial/omap-serial.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index ae935ce..14a0167 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -246,8 +246,12 @@ static inline int calculate_baud_abs_diff(struct uart_port *port,
 				unsigned int baud, unsigned int mode)
 {
 	unsigned int n = port->uartclk / (mode * baud);
-	int abs_diff = baud - (port->uartclk / (mode * n));
+	int abs_diff;
 
+	if (n == 0)
+		n = 1;
+
+	abs_diff = baud - (uartclk / (mode * n));
 	if (abs_diff < 0)
 		abs_diff = -abs_diff;
 
-- 
1.9.3

[PATCH 2/4] tty: omap-serial: prevent division by zero

[Frans Klaver]

If the chosen baud rate is large enough (e.g. 3.5 megabaud), the
calculated n values in calculate_baud_abs_diff may become 0. This causes
a division by zero when calculating the difference between calculated
and desired baud rates. To prevent this, cap n on 1.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
 drivers/tty/serial/omap-serial.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index ae935ce..14a0167 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -246,8 +246,12 @@ static inline int calculate_baud_abs_diff(struct uart_port *port,
 				unsigned int baud, unsigned int mode)
 {
 	unsigned int n = port->uartclk / (mode * baud);
-	int abs_diff = baud - (port->uartclk / (mode * n));
+	int abs_diff;
 
+	if (n == 0)
+		n = 1;
+
+	abs_diff = baud - (uartclk / (mode * n));
 	if (abs_diff < 0)
 		abs_diff = -abs_diff;
 
-- 
1.9.3

[PATCH 2/4] tty: omap-serial: prevent division by zero

[Frans Klaver]

If the chosen baud rate is large enough (e.g. 3.5 megabaud), the
calculated n values in calculate_baud_abs_diff may become 0. This causes
a division by zero when calculating the difference between calculated
and desired baud rates. To prevent this, cap n on 1.

Signed-off-by: Frans Klaver <frans.klaver-MHHw4NDrbWwAvxtiuMwx3w@public.gmane.org>
---
 drivers/tty/serial/omap-serial.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index ae935ce..14a0167 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -246,8 +246,12 @@ static inline int calculate_baud_abs_diff(struct uart_port *port,
 				unsigned int baud, unsigned int mode)
 {
 	unsigned int n = port->uartclk / (mode * baud);
-	int abs_diff = baud - (port->uartclk / (mode * n));
+	int abs_diff;
 
+	if (n == 0)
+		n = 1;
+
+	abs_diff = baud - (uartclk / (mode * n));
 	if (abs_diff < 0)
 		abs_diff = -abs_diff;
 
-- 
1.9.3

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Frans Klaver]

At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
this to about 170 overflows in 10 minutes.

In practice this therefore reduces the need for hardware flow control,
meaning the sending side doesn't have to buffer as much either.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
 drivers/tty/serial/omap-serial.c | 31 ++++++++++++++++++++++++-------
 1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 14a0167..57664b9 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
 }
 
 /**
+ * serial_omap_fast_irq() - schedule interrupt handling
+ */
+static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
+{
+	struct uart_omap_port *up = dev_id;
+	unsigned int iir = serial_in(up, UART_IIR);
+
+	if (iir & UART_IIR_NO_INT)
+		return IRQ_NONE;
+
+	disable_irq_nosync(up->port.irq);
+	return IRQ_WAKE_THREAD;
+}
+
+/**
  * serial_omap_irq() - This handles the interrupt from one port
  * @irq: uart port irq number
  * @dev_id: uart port info
@@ -584,7 +599,6 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 	struct uart_omap_port *up = dev_id;
 	unsigned int iir, lsr;
 	unsigned int type;
-	irqreturn_t ret = IRQ_NONE;
 	int max_count = 256;
 
 	spin_lock(&up->port.lock);
@@ -595,7 +609,6 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 		if (iir & UART_IIR_NO_INT)
 			break;
 
-		ret = IRQ_HANDLED;
 		lsr = serial_in(up, UART_LSR);
 
 		/* extract IRQ type from IIR register */
@@ -630,11 +643,13 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 
 	tty_flip_buffer_push(&up->port.state->port);
 
+	enable_irq(up->port.irq);
+
 	pm_runtime_mark_last_busy(up->dev);
 	pm_runtime_put_autosuspend(up->dev);
 	up->port_activity = jiffies;
 
-	return ret;
+	return IRQ_HANDLED;
 }
 
 static unsigned int serial_omap_tx_empty(struct uart_port *port)
@@ -731,15 +746,17 @@ static int serial_omap_startup(struct uart_port *port)
 	/*
 	 * Allocate the IRQ
 	 */
-	retval = request_irq(up->port.irq, serial_omap_irq, up->port.irqflags,
-				up->name, up);
+	retval = request_threaded_irq(up->port.irq, serial_omap_fast_irq,
+					serial_omap_irq, up->port.irqflags,
+					up->name, up);
 	if (retval)
 		return retval;
 
 	/* Optional wake-up IRQ */
 	if (up->wakeirq) {
-		retval = request_irq(up->wakeirq, serial_omap_irq,
-				     up->port.irqflags, up->name, up);
+		retval = request_threaded_irq(up->wakeirq, serial_omap_fast_irq,
+					serial_omap_irq, up->port.irqflags,
+					up->name, up);
 		if (retval) {
 			free_irq(up->port.irq, up);
 			return retval;
-- 
1.9.3

[RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Frans Klaver]

At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
this to about 170 overflows in 10 minutes.

In practice this therefore reduces the need for hardware flow control,
meaning the sending side doesn't have to buffer as much either.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
 drivers/tty/serial/omap-serial.c | 31 ++++++++++++++++++++++++-------
 1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 14a0167..57664b9 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
 }
 
 /**
+ * serial_omap_fast_irq() - schedule interrupt handling
+ */
+static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
+{
+	struct uart_omap_port *up = dev_id;
+	unsigned int iir = serial_in(up, UART_IIR);
+
+	if (iir & UART_IIR_NO_INT)
+		return IRQ_NONE;
+
+	disable_irq_nosync(up->port.irq);
+	return IRQ_WAKE_THREAD;
+}
+
+/**
  * serial_omap_irq() - This handles the interrupt from one port
  * @irq: uart port irq number
  * @dev_id: uart port info
@@ -584,7 +599,6 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 	struct uart_omap_port *up = dev_id;
 	unsigned int iir, lsr;
 	unsigned int type;
-	irqreturn_t ret = IRQ_NONE;
 	int max_count = 256;
 
 	spin_lock(&up->port.lock);
@@ -595,7 +609,6 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 		if (iir & UART_IIR_NO_INT)
 			break;
 
-		ret = IRQ_HANDLED;
 		lsr = serial_in(up, UART_LSR);
 
 		/* extract IRQ type from IIR register */
@@ -630,11 +643,13 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 
 	tty_flip_buffer_push(&up->port.state->port);
 
+	enable_irq(up->port.irq);
+
 	pm_runtime_mark_last_busy(up->dev);
 	pm_runtime_put_autosuspend(up->dev);
 	up->port_activity = jiffies;
 
-	return ret;
+	return IRQ_HANDLED;
 }
 
 static unsigned int serial_omap_tx_empty(struct uart_port *port)
@@ -731,15 +746,17 @@ static int serial_omap_startup(struct uart_port *port)
 	/*
 	 * Allocate the IRQ
 	 */
-	retval = request_irq(up->port.irq, serial_omap_irq, up->port.irqflags,
-				up->name, up);
+	retval = request_threaded_irq(up->port.irq, serial_omap_fast_irq,
+					serial_omap_irq, up->port.irqflags,
+					up->name, up);
 	if (retval)
 		return retval;
 
 	/* Optional wake-up IRQ */
 	if (up->wakeirq) {
-		retval = request_irq(up->wakeirq, serial_omap_irq,
-				     up->port.irqflags, up->name, up);
+		retval = request_threaded_irq(up->wakeirq, serial_omap_fast_irq,
+					serial_omap_irq, up->port.irqflags,
+					up->name, up);
 		if (retval) {
 			free_irq(up->port.irq, up);
 			return retval;
-- 
1.9.3

[RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Frans Klaver]

At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
this to about 170 overflows in 10 minutes.

In practice this therefore reduces the need for hardware flow control,
meaning the sending side doesn't have to buffer as much either.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
 drivers/tty/serial/omap-serial.c | 31 ++++++++++++++++++++++++-------
 1 file changed, 24 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 14a0167..57664b9 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
 }
 
 /**
+ * serial_omap_fast_irq() - schedule interrupt handling
+ */
+static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
+{
+	struct uart_omap_port *up = dev_id;
+	unsigned int iir = serial_in(up, UART_IIR);
+
+	if (iir & UART_IIR_NO_INT)
+		return IRQ_NONE;
+
+	disable_irq_nosync(up->port.irq);
+	return IRQ_WAKE_THREAD;
+}
+
+/**
  * serial_omap_irq() - This handles the interrupt from one port
  * @irq: uart port irq number
  * @dev_id: uart port info
@@ -584,7 +599,6 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 	struct uart_omap_port *up = dev_id;
 	unsigned int iir, lsr;
 	unsigned int type;
-	irqreturn_t ret = IRQ_NONE;
 	int max_count = 256;
 
 	spin_lock(&up->port.lock);
@@ -595,7 +609,6 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 		if (iir & UART_IIR_NO_INT)
 			break;
 
-		ret = IRQ_HANDLED;
 		lsr = serial_in(up, UART_LSR);
 
 		/* extract IRQ type from IIR register */
@@ -630,11 +643,13 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 
 	tty_flip_buffer_push(&up->port.state->port);
 
+	enable_irq(up->port.irq);
+
 	pm_runtime_mark_last_busy(up->dev);
 	pm_runtime_put_autosuspend(up->dev);
 	up->port_activity = jiffies;
 
-	return ret;
+	return IRQ_HANDLED;
 }
 
 static unsigned int serial_omap_tx_empty(struct uart_port *port)
@@ -731,15 +746,17 @@ static int serial_omap_startup(struct uart_port *port)
 	/*
 	 * Allocate the IRQ
 	 */
-	retval = request_irq(up->port.irq, serial_omap_irq, up->port.irqflags,
-				up->name, up);
+	retval = request_threaded_irq(up->port.irq, serial_omap_fast_irq,
+					serial_omap_irq, up->port.irqflags,
+					up->name, up);
 	if (retval)
 		return retval;
 
 	/* Optional wake-up IRQ */
 	if (up->wakeirq) {
-		retval = request_irq(up->wakeirq, serial_omap_irq,
-				     up->port.irqflags, up->name, up);
+		retval = request_threaded_irq(up->wakeirq, serial_omap_fast_irq,
+					serial_omap_irq, up->port.irqflags,
+					up->name, up);
 		if (retval) {
 			free_irq(up->port.irq, up);
 			return retval;
-- 
1.9.3

Re: [RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]

On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
> At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
> rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
> this to about 170 overflows in 10 minutes.

Can you try Sebastian Siewior's patches for 8250_omap and 8250 dma
support ? That should help you a lot.

> In practice this therefore reduces the need for hardware flow control,
> meaning the sending side doesn't have to buffer as much either.
> 
> Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
> ---
>  drivers/tty/serial/omap-serial.c | 31 ++++++++++++++++++++++++-------
>  1 file changed, 24 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index 14a0167..57664b9 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
>  }
>  
>  /**
> + * serial_omap_fast_irq() - schedule interrupt handling
> + */
> +static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
> +{
> +	struct uart_omap_port *up = dev_id;
> +	unsigned int iir = serial_in(up, UART_IIR);
> +
> +	if (iir & UART_IIR_NO_INT)
> +		return IRQ_NONE;
> +
> +	disable_irq_nosync(up->port.irq);

NAK. Either use IRQF_ONESHOT or actually mask the IRQs at the device's
registers (basically clearing IER).

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Felipe Balbi]

On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
> At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
> rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
> this to about 170 overflows in 10 minutes.

Can you try Sebastian Siewior's patches for 8250_omap and 8250 dma
support ? That should help you a lot.

> In practice this therefore reduces the need for hardware flow control,
> meaning the sending side doesn't have to buffer as much either.
> 
> Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
> ---
>  drivers/tty/serial/omap-serial.c | 31 ++++++++++++++++++++++++-------
>  1 file changed, 24 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index 14a0167..57664b9 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
>  }
>  
>  /**
> + * serial_omap_fast_irq() - schedule interrupt handling
> + */
> +static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
> +{
> +	struct uart_omap_port *up = dev_id;
> +	unsigned int iir = serial_in(up, UART_IIR);
> +
> +	if (iir & UART_IIR_NO_INT)
> +		return IRQ_NONE;
> +
> +	disable_irq_nosync(up->port.irq);

NAK. Either use IRQF_ONESHOT or actually mask the IRQs at the device's
registers (basically clearing IER).

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140819/4ef11b5a/attachment.sig>

Re: [RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1495 bytes --]

On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
> At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
> rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
> this to about 170 overflows in 10 minutes.

Can you try Sebastian Siewior's patches for 8250_omap and 8250 dma
support ? That should help you a lot.

> In practice this therefore reduces the need for hardware flow control,
> meaning the sending side doesn't have to buffer as much either.
> 
> Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
> ---
>  drivers/tty/serial/omap-serial.c | 31 ++++++++++++++++++++++++-------
>  1 file changed, 24 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> index 14a0167..57664b9 100644
> --- a/drivers/tty/serial/omap-serial.c
> +++ b/drivers/tty/serial/omap-serial.c
> @@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
>  }
>  
>  /**
> + * serial_omap_fast_irq() - schedule interrupt handling
> + */
> +static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
> +{
> +	struct uart_omap_port *up = dev_id;
> +	unsigned int iir = serial_in(up, UART_IIR);
> +
> +	if (iir & UART_IIR_NO_INT)
> +		return IRQ_NONE;
> +
> +	disable_irq_nosync(up->port.irq);

NAK. Either use IRQF_ONESHOT or actually mask the IRQs at the device's
registers (basically clearing IER).

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Frans Klaver]

On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
> On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
> > At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
> > rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
> > this to about 170 overflows in 10 minutes.
> 
> Can you try Sebastian Siewior's patches for 8250_omap and 8250 dma
> support ? That should help you a lot.

I'll have a look at that series. Thanks for pointing it out.

> >  drivers/tty/serial/omap-serial.c | 31 ++++++++++++++++++++++++-------
> >  1 file changed, 24 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> > index 14a0167..57664b9 100644
> > --- a/drivers/tty/serial/omap-serial.c
> > +++ b/drivers/tty/serial/omap-serial.c
> > @@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
> >  }
> >  
> >  /**
> > + * serial_omap_fast_irq() - schedule interrupt handling
> > + */
> > +static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
> > +{
> > +	struct uart_omap_port *up = dev_id;
> > +	unsigned int iir = serial_in(up, UART_IIR);
> > +
> > +	if (iir & UART_IIR_NO_INT)
> > +		return IRQ_NONE;
> > +
> > +	disable_irq_nosync(up->port.irq);
> 
> NAK. Either use IRQF_ONESHOT or actually mask the IRQs at the device's
> registers (basically clearing IER).

Given the work that's been done on the 8250 based driver, what are the
short-term chances omap-serial will be dropped? I'd be happy to improve
here if it makes sense to do so. If the 8250 based driver is going to
replace omap-serial anyway on the short term, I don't see the point of
further developing this patch. The others would still make sense in my
opinion.

Thanks,
Frans

[RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Frans Klaver]

On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
> On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
> > At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
> > rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
> > this to about 170 overflows in 10 minutes.
> 
> Can you try Sebastian Siewior's patches for 8250_omap and 8250 dma
> support ? That should help you a lot.

I'll have a look at that series. Thanks for pointing it out.

> >  drivers/tty/serial/omap-serial.c | 31 ++++++++++++++++++++++++-------
> >  1 file changed, 24 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> > index 14a0167..57664b9 100644
> > --- a/drivers/tty/serial/omap-serial.c
> > +++ b/drivers/tty/serial/omap-serial.c
> > @@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
> >  }
> >  
> >  /**
> > + * serial_omap_fast_irq() - schedule interrupt handling
> > + */
> > +static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
> > +{
> > +	struct uart_omap_port *up = dev_id;
> > +	unsigned int iir = serial_in(up, UART_IIR);
> > +
> > +	if (iir & UART_IIR_NO_INT)
> > +		return IRQ_NONE;
> > +
> > +	disable_irq_nosync(up->port.irq);
> 
> NAK. Either use IRQF_ONESHOT or actually mask the IRQs at the device's
> registers (basically clearing IER).

Given the work that's been done on the 8250 based driver, what are the
short-term chances omap-serial will be dropped? I'd be happy to improve
here if it makes sense to do so. If the 8250 based driver is going to
replace omap-serial anyway on the short term, I don't see the point of
further developing this patch. The others would still make sense in my
opinion.

Thanks,
Frans

Re: [RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Frans Klaver]

On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
> On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
> > At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
> > rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
> > this to about 170 overflows in 10 minutes.
> 
> Can you try Sebastian Siewior's patches for 8250_omap and 8250 dma
> support ? That should help you a lot.

I'll have a look at that series. Thanks for pointing it out.

> >  drivers/tty/serial/omap-serial.c | 31 ++++++++++++++++++++++++-------
> >  1 file changed, 24 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> > index 14a0167..57664b9 100644
> > --- a/drivers/tty/serial/omap-serial.c
> > +++ b/drivers/tty/serial/omap-serial.c
> > @@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
> >  }
> >  
> >  /**
> > + * serial_omap_fast_irq() - schedule interrupt handling
> > + */
> > +static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
> > +{
> > +	struct uart_omap_port *up = dev_id;
> > +	unsigned int iir = serial_in(up, UART_IIR);
> > +
> > +	if (iir & UART_IIR_NO_INT)
> > +		return IRQ_NONE;
> > +
> > +	disable_irq_nosync(up->port.irq);
> 
> NAK. Either use IRQF_ONESHOT or actually mask the IRQs at the device's
> registers (basically clearing IER).

Given the work that's been done on the 8250 based driver, what are the
short-term chances omap-serial will be dropped? I'd be happy to improve
here if it makes sense to do so. If the 8250 based driver is going to
replace omap-serial anyway on the short term, I don't see the point of
further developing this patch. The others would still make sense in my
opinion.

Thanks,
Frans

Re: [RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]

On Wed, Aug 20, 2014 at 08:40:28AM +0200, Frans Klaver wrote:
> On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
> > On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
> > > At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
> > > rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
> > > this to about 170 overflows in 10 minutes.
> > 
> > Can you try Sebastian Siewior's patches for 8250_omap and 8250 dma
> > support ? That should help you a lot.
> 
> I'll have a look at that series. Thanks for pointing it out.
> 
> > >  drivers/tty/serial/omap-serial.c | 31 ++++++++++++++++++++++++-------
> > >  1 file changed, 24 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> > > index 14a0167..57664b9 100644
> > > --- a/drivers/tty/serial/omap-serial.c
> > > +++ b/drivers/tty/serial/omap-serial.c
> > > @@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
> > >  }
> > >  
> > >  /**
> > > + * serial_omap_fast_irq() - schedule interrupt handling
> > > + */
> > > +static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
> > > +{
> > > +	struct uart_omap_port *up = dev_id;
> > > +	unsigned int iir = serial_in(up, UART_IIR);
> > > +
> > > +	if (iir & UART_IIR_NO_INT)
> > > +		return IRQ_NONE;
> > > +
> > > +	disable_irq_nosync(up->port.irq);
> > 
> > NAK. Either use IRQF_ONESHOT or actually mask the IRQs at the device's
> > registers (basically clearing IER).
> 
> Given the work that's been done on the 8250 based driver, what are the
> short-term chances omap-serial will be dropped? I'd be happy to improve
> here if it makes sense to do so. If the 8250 based driver is going to
> replace omap-serial anyway on the short term, I don't see the point of
> further developing this patch. The others would still make sense in my
> opinion.

if we find a way to maintain the same ttyO* naming scheme and make it
coexist with ttyS* naming, then we could drop as soon as 8250_omap is
ready for prime time.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Felipe Balbi]

On Wed, Aug 20, 2014 at 08:40:28AM +0200, Frans Klaver wrote:
> On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
> > On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
> > > At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
> > > rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
> > > this to about 170 overflows in 10 minutes.
> > 
> > Can you try Sebastian Siewior's patches for 8250_omap and 8250 dma
> > support ? That should help you a lot.
> 
> I'll have a look at that series. Thanks for pointing it out.
> 
> > >  drivers/tty/serial/omap-serial.c | 31 ++++++++++++++++++++++++-------
> > >  1 file changed, 24 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> > > index 14a0167..57664b9 100644
> > > --- a/drivers/tty/serial/omap-serial.c
> > > +++ b/drivers/tty/serial/omap-serial.c
> > > @@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
> > >  }
> > >  
> > >  /**
> > > + * serial_omap_fast_irq() - schedule interrupt handling
> > > + */
> > > +static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
> > > +{
> > > +	struct uart_omap_port *up = dev_id;
> > > +	unsigned int iir = serial_in(up, UART_IIR);
> > > +
> > > +	if (iir & UART_IIR_NO_INT)
> > > +		return IRQ_NONE;
> > > +
> > > +	disable_irq_nosync(up->port.irq);
> > 
> > NAK. Either use IRQF_ONESHOT or actually mask the IRQs at the device's
> > registers (basically clearing IER).
> 
> Given the work that's been done on the 8250 based driver, what are the
> short-term chances omap-serial will be dropped? I'd be happy to improve
> here if it makes sense to do so. If the 8250 based driver is going to
> replace omap-serial anyway on the short term, I don't see the point of
> further developing this patch. The others would still make sense in my
> opinion.

if we find a way to maintain the same ttyO* naming scheme and make it
coexist with ttyS* naming, then we could drop as soon as 8250_omap is
ready for prime time.

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140820/b79f43c6/attachment-0001.sig>

Re: [RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2166 bytes --]

On Wed, Aug 20, 2014 at 08:40:28AM +0200, Frans Klaver wrote:
> On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
> > On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
> > > At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
> > > rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
> > > this to about 170 overflows in 10 minutes.
> > 
> > Can you try Sebastian Siewior's patches for 8250_omap and 8250 dma
> > support ? That should help you a lot.
> 
> I'll have a look at that series. Thanks for pointing it out.
> 
> > >  drivers/tty/serial/omap-serial.c | 31 ++++++++++++++++++++++++-------
> > >  1 file changed, 24 insertions(+), 7 deletions(-)
> > > 
> > > diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> > > index 14a0167..57664b9 100644
> > > --- a/drivers/tty/serial/omap-serial.c
> > > +++ b/drivers/tty/serial/omap-serial.c
> > > @@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
> > >  }
> > >  
> > >  /**
> > > + * serial_omap_fast_irq() - schedule interrupt handling
> > > + */
> > > +static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
> > > +{
> > > +	struct uart_omap_port *up = dev_id;
> > > +	unsigned int iir = serial_in(up, UART_IIR);
> > > +
> > > +	if (iir & UART_IIR_NO_INT)
> > > +		return IRQ_NONE;
> > > +
> > > +	disable_irq_nosync(up->port.irq);
> > 
> > NAK. Either use IRQF_ONESHOT or actually mask the IRQs at the device's
> > registers (basically clearing IER).
> 
> Given the work that's been done on the 8250 based driver, what are the
> short-term chances omap-serial will be dropped? I'd be happy to improve
> here if it makes sense to do so. If the 8250 based driver is going to
> replace omap-serial anyway on the short term, I don't see the point of
> further developing this patch. The others would still make sense in my
> opinion.

if we find a way to maintain the same ttyO* naming scheme and make it
coexist with ttyS* naming, then we could drop as soon as 8250_omap is
ready for prime time.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Frans Klaver]

On Wed, Aug 20, 2014 at 11:06:05AM -0500, Felipe Balbi wrote:
> On Wed, Aug 20, 2014 at 08:40:28AM +0200, Frans Klaver wrote:
> > On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
> > > On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
> > > > At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
> > > > rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
> > > > this to about 170 overflows in 10 minutes.
> > > 
> > > Can you try Sebastian Siewior's patches for 8250_omap and 8250 dma
> > > support ? That should help you a lot.
> > 
> > I'll have a look at that series. Thanks for pointing it out.

I have had a look at Sebastian's series, but I'm not convinced
yet that we should use it. So far the serial console seems to be
missing data every now and then. I haven't gotten around to testing our
high traffic application yet.


> > > >  drivers/tty/serial/omap-serial.c | 31 ++++++++++++++++++++++++-------
> > > >  1 file changed, 24 insertions(+), 7 deletions(-)
> > > > 
> > > > diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> > > > index 14a0167..57664b9 100644
> > > > --- a/drivers/tty/serial/omap-serial.c
> > > > +++ b/drivers/tty/serial/omap-serial.c
> > > > @@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
> > > >  }
> > > >  
> > > >  /**
> > > > + * serial_omap_fast_irq() - schedule interrupt handling
> > > > + */
> > > > +static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
> > > > +{
> > > > +	struct uart_omap_port *up = dev_id;
> > > > +	unsigned int iir = serial_in(up, UART_IIR);
> > > > +
> > > > +	if (iir & UART_IIR_NO_INT)
> > > > +		return IRQ_NONE;
> > > > +
> > > > +	disable_irq_nosync(up->port.irq);
> > > 
> > > NAK. Either use IRQF_ONESHOT or actually mask the IRQs at the device's
> > > registers (basically clearing IER).
> > 
> > Given the work that's been done on the 8250 based driver, what are the
> > short-term chances omap-serial will be dropped? I'd be happy to improve
> > here if it makes sense to do so. If the 8250 based driver is going to
> > replace omap-serial anyway on the short term, I don't see the point of
> > further developing this patch. The others would still make sense in my
> > opinion.
> 
> if we find a way to maintain the same ttyO* naming scheme and make it
> coexist with ttyS* naming, then we could drop as soon as 8250_omap is
> ready for prime time.

With that in mind, for now I'll be betting on two horses.

I'll cook up a new version using oneshot.

Thanks,
Frans

[RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Frans Klaver]

On Wed, Aug 20, 2014 at 11:06:05AM -0500, Felipe Balbi wrote:
> On Wed, Aug 20, 2014 at 08:40:28AM +0200, Frans Klaver wrote:
> > On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
> > > On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
> > > > At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
> > > > rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
> > > > this to about 170 overflows in 10 minutes.
> > > 
> > > Can you try Sebastian Siewior's patches for 8250_omap and 8250 dma
> > > support ? That should help you a lot.
> > 
> > I'll have a look at that series. Thanks for pointing it out.

I have had a look at Sebastian's series, but I'm not convinced
yet that we should use it. So far the serial console seems to be
missing data every now and then. I haven't gotten around to testing our
high traffic application yet.


> > > >  drivers/tty/serial/omap-serial.c | 31 ++++++++++++++++++++++++-------
> > > >  1 file changed, 24 insertions(+), 7 deletions(-)
> > > > 
> > > > diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> > > > index 14a0167..57664b9 100644
> > > > --- a/drivers/tty/serial/omap-serial.c
> > > > +++ b/drivers/tty/serial/omap-serial.c
> > > > @@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
> > > >  }
> > > >  
> > > >  /**
> > > > + * serial_omap_fast_irq() - schedule interrupt handling
> > > > + */
> > > > +static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
> > > > +{
> > > > +	struct uart_omap_port *up = dev_id;
> > > > +	unsigned int iir = serial_in(up, UART_IIR);
> > > > +
> > > > +	if (iir & UART_IIR_NO_INT)
> > > > +		return IRQ_NONE;
> > > > +
> > > > +	disable_irq_nosync(up->port.irq);
> > > 
> > > NAK. Either use IRQF_ONESHOT or actually mask the IRQs at the device's
> > > registers (basically clearing IER).
> > 
> > Given the work that's been done on the 8250 based driver, what are the
> > short-term chances omap-serial will be dropped? I'd be happy to improve
> > here if it makes sense to do so. If the 8250 based driver is going to
> > replace omap-serial anyway on the short term, I don't see the point of
> > further developing this patch. The others would still make sense in my
> > opinion.
> 
> if we find a way to maintain the same ttyO* naming scheme and make it
> coexist with ttyS* naming, then we could drop as soon as 8250_omap is
> ready for prime time.

With that in mind, for now I'll be betting on two horses.

I'll cook up a new version using oneshot.

Thanks,
Frans

Re: [RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Frans Klaver]

On Wed, Aug 20, 2014 at 11:06:05AM -0500, Felipe Balbi wrote:
> On Wed, Aug 20, 2014 at 08:40:28AM +0200, Frans Klaver wrote:
> > On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
> > > On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
> > > > At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
> > > > rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
> > > > this to about 170 overflows in 10 minutes.
> > > 
> > > Can you try Sebastian Siewior's patches for 8250_omap and 8250 dma
> > > support ? That should help you a lot.
> > 
> > I'll have a look at that series. Thanks for pointing it out.

I have had a look at Sebastian's series, but I'm not convinced
yet that we should use it. So far the serial console seems to be
missing data every now and then. I haven't gotten around to testing our
high traffic application yet.


> > > >  drivers/tty/serial/omap-serial.c | 31 ++++++++++++++++++++++++-------
> > > >  1 file changed, 24 insertions(+), 7 deletions(-)
> > > > 
> > > > diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
> > > > index 14a0167..57664b9 100644
> > > > --- a/drivers/tty/serial/omap-serial.c
> > > > +++ b/drivers/tty/serial/omap-serial.c
> > > > @@ -575,6 +575,21 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
> > > >  }
> > > >  
> > > >  /**
> > > > + * serial_omap_fast_irq() - schedule interrupt handling
> > > > + */
> > > > +static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
> > > > +{
> > > > +	struct uart_omap_port *up = dev_id;
> > > > +	unsigned int iir = serial_in(up, UART_IIR);
> > > > +
> > > > +	if (iir & UART_IIR_NO_INT)
> > > > +		return IRQ_NONE;
> > > > +
> > > > +	disable_irq_nosync(up->port.irq);
> > > 
> > > NAK. Either use IRQF_ONESHOT or actually mask the IRQs at the device's
> > > registers (basically clearing IER).
> > 
> > Given the work that's been done on the 8250 based driver, what are the
> > short-term chances omap-serial will be dropped? I'd be happy to improve
> > here if it makes sense to do so. If the 8250 based driver is going to
> > replace omap-serial anyway on the short term, I don't see the point of
> > further developing this patch. The others would still make sense in my
> > opinion.
> 
> if we find a way to maintain the same ttyO* naming scheme and make it
> coexist with ttyS* naming, then we could drop as soon as 8250_omap is
> ready for prime time.

With that in mind, for now I'll be betting on two horses.

I'll cook up a new version using oneshot.

Thanks,
Frans

Re: [RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]

Hi,

On Thu, Aug 21, 2014 at 11:41:17PM +0200, Frans Klaver wrote:
> On Wed, Aug 20, 2014 at 11:06:05AM -0500, Felipe Balbi wrote:
> > On Wed, Aug 20, 2014 at 08:40:28AM +0200, Frans Klaver wrote:
> > > On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
> > > > On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
> > > > > At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
> > > > > rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
> > > > > this to about 170 overflows in 10 minutes.
> > > > 
> > > > Can you try Sebastian Siewior's patches for 8250_omap and 8250 dma
> > > > support ? That should help you a lot.
> > > 
> > > I'll have a look at that series. Thanks for pointing it out.
> 
> I have had a look at Sebastian's series, but I'm not convinced
> yet that we should use it. So far the serial console seems to be
> missing data every now and then. I haven't gotten around to testing our
> high traffic application yet.

as any new driver, there are bugs to be fixed. How about reporting the
ones you found together with a way of reproducing them so they can be
fixed ?

cheers

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Felipe Balbi]

Hi,

On Thu, Aug 21, 2014 at 11:41:17PM +0200, Frans Klaver wrote:
> On Wed, Aug 20, 2014 at 11:06:05AM -0500, Felipe Balbi wrote:
> > On Wed, Aug 20, 2014 at 08:40:28AM +0200, Frans Klaver wrote:
> > > On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
> > > > On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
> > > > > At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
> > > > > rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
> > > > > this to about 170 overflows in 10 minutes.
> > > > 
> > > > Can you try Sebastian Siewior's patches for 8250_omap and 8250 dma
> > > > support ? That should help you a lot.
> > > 
> > > I'll have a look at that series. Thanks for pointing it out.
> 
> I have had a look at Sebastian's series, but I'm not convinced
> yet that we should use it. So far the serial console seems to be
> missing data every now and then. I haven't gotten around to testing our
> high traffic application yet.

as any new driver, there are bugs to be fixed. How about reporting the
ones you found together with a way of reproducing them so they can be
fixed ?

cheers

-- 
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140821/636428fd/attachment.sig>

Re: [RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]

Hi,

On Thu, Aug 21, 2014 at 11:41:17PM +0200, Frans Klaver wrote:
> On Wed, Aug 20, 2014 at 11:06:05AM -0500, Felipe Balbi wrote:
> > On Wed, Aug 20, 2014 at 08:40:28AM +0200, Frans Klaver wrote:
> > > On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
> > > > On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
> > > > > At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
> > > > > rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
> > > > > this to about 170 overflows in 10 minutes.
> > > > 
> > > > Can you try Sebastian Siewior's patches for 8250_omap and 8250 dma
> > > > support ? That should help you a lot.
> > > 
> > > I'll have a look at that series. Thanks for pointing it out.
> 
> I have had a look at Sebastian's series, but I'm not convinced
> yet that we should use it. So far the serial console seems to be
> missing data every now and then. I haven't gotten around to testing our
> high traffic application yet.

as any new driver, there are bugs to be fixed. How about reporting the
ones you found together with a way of reproducing them so they can be
fixed ?

cheers

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Frans Klaver]

On August 21, 2014 11:48:40 PM CEST, Felipe Balbi <balbi@ti.com> wrote:
>Hi,
>
>On Thu, Aug 21, 2014 at 11:41:17PM +0200, Frans Klaver wrote:
>> On Wed, Aug 20, 2014 at 11:06:05AM -0500, Felipe Balbi wrote:
>> > On Wed, Aug 20, 2014 at 08:40:28AM +0200, Frans Klaver wrote:
>> > > On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
>> > > > On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
>> > > > > At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we
>see 1600 uart
>> > > > > rx buffer overflows within 30 seconds. Threading the
>interrupt handling reduces
>> > > > > this to about 170 overflows in 10 minutes.
>> > > > 
>> > > > Can you try Sebastian Siewior's patches for 8250_omap and 8250
>dma
>> > > > support ? That should help you a lot.
>> > > 
>> > > I'll have a look at that series. Thanks for pointing it out.
>> 
>> I have had a look at Sebastian's series, but I'm not convinced
>> yet that we should use it. So far the serial console seems to be
>> missing data every now and then. I haven't gotten around to testing
>our
>> high traffic application yet.
>
>as any new driver, there are bugs to be fixed. How about reporting the
>ones you found together with a way of reproducing them so they can be
>fixed ?

Yes, definitely.

Cheers, 
Frans

[RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Frans Klaver]

On August 21, 2014 11:48:40 PM CEST, Felipe Balbi <balbi@ti.com> wrote:
>Hi,
>
>On Thu, Aug 21, 2014 at 11:41:17PM +0200, Frans Klaver wrote:
>> On Wed, Aug 20, 2014 at 11:06:05AM -0500, Felipe Balbi wrote:
>> > On Wed, Aug 20, 2014 at 08:40:28AM +0200, Frans Klaver wrote:
>> > > On Tue, Aug 19, 2014 at 01:57:02PM -0500, Felipe Balbi wrote:
>> > > > On Tue, Aug 19, 2014 at 02:14:47PM +0200, Frans Klaver wrote:
>> > > > > At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we
>see 1600 uart
>> > > > > rx buffer overflows within 30 seconds. Threading the
>interrupt handling reduces
>> > > > > this to about 170 overflows in 10 minutes.
>> > > > 
>> > > > Can you try Sebastian Siewior's patches for 8250_omap and 8250
>dma
>> > > > support ? That should help you a lot.
>> > > 
>> > > I'll have a look at that series. Thanks for pointing it out.
>> 
>> I have had a look at Sebastian's series, but I'm not convinced
>> yet that we should use it. So far the serial console seems to be
>> missing data every now and then. I haven't gotten around to testing
>our
>> high traffic application yet.
>
>as any new driver, there are bugs to be fixed. How about reporting the
>ones you found together with a way of reproducing them so they can be
>fixed ?

Yes, definitely.

Cheers, 
Frans

[RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Frans Klaver]

At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
this to about 170 overflows in 10 minutes.

In practice this therefore reduces the need for hardware flow control,
meaning the sending side doesn't have to buffer as much either.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
 drivers/tty/serial/omap-serial.c | 30 +++++++++++++++++++++++-------
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 14a0167..1671443a 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -575,6 +575,20 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
 }
 
 /**
+ * serial_omap_fast_irq() - schedule interrupt handling
+ */
+static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
+{
+	struct uart_omap_port *up = dev_id;
+	unsigned int iir = serial_in(up, UART_IIR);
+
+	if (iir & UART_IIR_NO_INT)
+		return IRQ_NONE;
+
+	return IRQ_WAKE_THREAD;
+}
+
+/**
  * serial_omap_irq() - This handles the interrupt from one port
  * @irq: uart port irq number
  * @dev_id: uart port info
@@ -584,7 +598,6 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 	struct uart_omap_port *up = dev_id;
 	unsigned int iir, lsr;
 	unsigned int type;
-	irqreturn_t ret = IRQ_NONE;
 	int max_count = 256;
 
 	spin_lock(&up->port.lock);
@@ -595,7 +608,6 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 		if (iir & UART_IIR_NO_INT)
 			break;
 
-		ret = IRQ_HANDLED;
 		lsr = serial_in(up, UART_LSR);
 
 		/* extract IRQ type from IIR register */
@@ -634,7 +646,7 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 	pm_runtime_put_autosuspend(up->dev);
 	up->port_activity = jiffies;
 
-	return ret;
+	return IRQ_HANDLED;
 }
 
 static unsigned int serial_omap_tx_empty(struct uart_port *port)
@@ -731,15 +743,19 @@ static int serial_omap_startup(struct uart_port *port)
 	/*
 	 * Allocate the IRQ
 	 */
-	retval = request_irq(up->port.irq, serial_omap_irq, up->port.irqflags,
-				up->name, up);
+	retval = request_threaded_irq(up->port.irq, serial_omap_fast_irq,
+						serial_omap_irq,
+						IRQF_ONESHOT | up->port.irqflags,
+						up->name, up);
 	if (retval)
 		return retval;
 
 	/* Optional wake-up IRQ */
 	if (up->wakeirq) {
-		retval = request_irq(up->wakeirq, serial_omap_irq,
-				     up->port.irqflags, up->name, up);
+		retval = request_threaded_irq(up->wakeirq, serial_omap_fast_irq,
+						serial_omap_irq,
+						IRQF_ONESHOT | up->port.irqflags,
+						up->name, up);
 		if (retval) {
 			free_irq(up->port.irq, up);
 			return retval;
-- 
1.9.3

[RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Frans Klaver]

At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
this to about 170 overflows in 10 minutes.

In practice this therefore reduces the need for hardware flow control,
meaning the sending side doesn't have to buffer as much either.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
 drivers/tty/serial/omap-serial.c | 30 +++++++++++++++++++++++-------
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 14a0167..1671443a 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -575,6 +575,20 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
 }
 
 /**
+ * serial_omap_fast_irq() - schedule interrupt handling
+ */
+static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
+{
+	struct uart_omap_port *up = dev_id;
+	unsigned int iir = serial_in(up, UART_IIR);
+
+	if (iir & UART_IIR_NO_INT)
+		return IRQ_NONE;
+
+	return IRQ_WAKE_THREAD;
+}
+
+/**
  * serial_omap_irq() - This handles the interrupt from one port
  * @irq: uart port irq number
  * @dev_id: uart port info
@@ -584,7 +598,6 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 	struct uart_omap_port *up = dev_id;
 	unsigned int iir, lsr;
 	unsigned int type;
-	irqreturn_t ret = IRQ_NONE;
 	int max_count = 256;
 
 	spin_lock(&up->port.lock);
@@ -595,7 +608,6 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 		if (iir & UART_IIR_NO_INT)
 			break;
 
-		ret = IRQ_HANDLED;
 		lsr = serial_in(up, UART_LSR);
 
 		/* extract IRQ type from IIR register */
@@ -634,7 +646,7 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 	pm_runtime_put_autosuspend(up->dev);
 	up->port_activity = jiffies;
 
-	return ret;
+	return IRQ_HANDLED;
 }
 
 static unsigned int serial_omap_tx_empty(struct uart_port *port)
@@ -731,15 +743,19 @@ static int serial_omap_startup(struct uart_port *port)
 	/*
 	 * Allocate the IRQ
 	 */
-	retval = request_irq(up->port.irq, serial_omap_irq, up->port.irqflags,
-				up->name, up);
+	retval = request_threaded_irq(up->port.irq, serial_omap_fast_irq,
+						serial_omap_irq,
+						IRQF_ONESHOT | up->port.irqflags,
+						up->name, up);
 	if (retval)
 		return retval;
 
 	/* Optional wake-up IRQ */
 	if (up->wakeirq) {
-		retval = request_irq(up->wakeirq, serial_omap_irq,
-				     up->port.irqflags, up->name, up);
+		retval = request_threaded_irq(up->wakeirq, serial_omap_fast_irq,
+						serial_omap_irq,
+						IRQF_ONESHOT | up->port.irqflags,
+						up->name, up);
 		if (retval) {
 			free_irq(up->port.irq, up);
 			return retval;
-- 
1.9.3

[RFC PATCH 3/4] tty: omap-serial: use threaded interrupt handler

[Frans Klaver]

At 3.6Mbaud, with slightly over 2Mbit/s data coming in, we see 1600 uart
rx buffer overflows within 30 seconds. Threading the interrupt handling reduces
this to about 170 overflows in 10 minutes.

In practice this therefore reduces the need for hardware flow control,
meaning the sending side doesn't have to buffer as much either.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
 drivers/tty/serial/omap-serial.c | 30 +++++++++++++++++++++++-------
 1 file changed, 23 insertions(+), 7 deletions(-)

diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 14a0167..1671443a 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -575,6 +575,20 @@ static void serial_omap_rdi(struct uart_omap_port *up, unsigned int lsr)
 }
 
 /**
+ * serial_omap_fast_irq() - schedule interrupt handling
+ */
+static irqreturn_t serial_omap_fast_irq(int irq, void *dev_id)
+{
+	struct uart_omap_port *up = dev_id;
+	unsigned int iir = serial_in(up, UART_IIR);
+
+	if (iir & UART_IIR_NO_INT)
+		return IRQ_NONE;
+
+	return IRQ_WAKE_THREAD;
+}
+
+/**
  * serial_omap_irq() - This handles the interrupt from one port
  * @irq: uart port irq number
  * @dev_id: uart port info
@@ -584,7 +598,6 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 	struct uart_omap_port *up = dev_id;
 	unsigned int iir, lsr;
 	unsigned int type;
-	irqreturn_t ret = IRQ_NONE;
 	int max_count = 256;
 
 	spin_lock(&up->port.lock);
@@ -595,7 +608,6 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 		if (iir & UART_IIR_NO_INT)
 			break;
 
-		ret = IRQ_HANDLED;
 		lsr = serial_in(up, UART_LSR);
 
 		/* extract IRQ type from IIR register */
@@ -634,7 +646,7 @@ static irqreturn_t serial_omap_irq(int irq, void *dev_id)
 	pm_runtime_put_autosuspend(up->dev);
 	up->port_activity = jiffies;
 
-	return ret;
+	return IRQ_HANDLED;
 }
 
 static unsigned int serial_omap_tx_empty(struct uart_port *port)
@@ -731,15 +743,19 @@ static int serial_omap_startup(struct uart_port *port)
 	/*
 	 * Allocate the IRQ
 	 */
-	retval = request_irq(up->port.irq, serial_omap_irq, up->port.irqflags,
-				up->name, up);
+	retval = request_threaded_irq(up->port.irq, serial_omap_fast_irq,
+						serial_omap_irq,
+						IRQF_ONESHOT | up->port.irqflags,
+						up->name, up);
 	if (retval)
 		return retval;
 
 	/* Optional wake-up IRQ */
 	if (up->wakeirq) {
-		retval = request_irq(up->wakeirq, serial_omap_irq,
-				     up->port.irqflags, up->name, up);
+		retval = request_threaded_irq(up->wakeirq, serial_omap_fast_irq,
+						serial_omap_irq,
+						IRQF_ONESHOT | up->port.irqflags,
+						up->name, up);
 		if (retval) {
 			free_irq(up->port.irq, up);
 			return retval;
-- 
1.9.3

[PATCH 4/4] tty: omap-serial: support setting of hardware flow control in dts

[Frans Klaver]

This makes hardware flow control availability configurable from the
device tree.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
 Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
 drivers/tty/serial/omap-serial.c                         | 4 ++++
 2 files changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 342eedd..1b629e9 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -8,3 +8,4 @@ Required properties:
 
 Optional properties:
 - clock-frequency : frequency of the clock input to the UART
+- has-hw-flow-control : the hardware has flow control capability
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 57664b9..7d3b3d2 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1598,6 +1598,10 @@ static struct omap_uart_port_info *of_get_uart_port_info(struct device *dev)
 
 	of_property_read_u32(dev->of_node, "clock-frequency",
 					 &omap_up_info->uartclk);
+
+	if (of_property_read_bool(dev->of_node, "has-hw-flow-control"))
+		omap_up_info->flags |= UPF_HARD_FLOW;
+
 	return omap_up_info;
 }
 
-- 
1.9.3

[PATCH 4/4] tty: omap-serial: support setting of hardware flow control in dts

[Frans Klaver]

This makes hardware flow control availability configurable from the
device tree.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
 Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
 drivers/tty/serial/omap-serial.c                         | 4 ++++
 2 files changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 342eedd..1b629e9 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -8,3 +8,4 @@ Required properties:
 
 Optional properties:
 - clock-frequency : frequency of the clock input to the UART
+- has-hw-flow-control : the hardware has flow control capability
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 57664b9..7d3b3d2 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1598,6 +1598,10 @@ static struct omap_uart_port_info *of_get_uart_port_info(struct device *dev)
 
 	of_property_read_u32(dev->of_node, "clock-frequency",
 					 &omap_up_info->uartclk);
+
+	if (of_property_read_bool(dev->of_node, "has-hw-flow-control"))
+		omap_up_info->flags |= UPF_HARD_FLOW;
+
 	return omap_up_info;
 }
 
-- 
1.9.3

[PATCH 4/4] tty: omap-serial: support setting of hardware flow control in dts

[Frans Klaver]

This makes hardware flow control availability configurable from the
device tree.

Signed-off-by: Frans Klaver <frans.klaver@xsens.com>
---
 Documentation/devicetree/bindings/serial/omap_serial.txt | 1 +
 drivers/tty/serial/omap-serial.c                         | 4 ++++
 2 files changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt
index 342eedd..1b629e9 100644
--- a/Documentation/devicetree/bindings/serial/omap_serial.txt
+++ b/Documentation/devicetree/bindings/serial/omap_serial.txt
@@ -8,3 +8,4 @@ Required properties:
 
 Optional properties:
 - clock-frequency : frequency of the clock input to the UART
+- has-hw-flow-control : the hardware has flow control capability
diff --git a/drivers/tty/serial/omap-serial.c b/drivers/tty/serial/omap-serial.c
index 57664b9..7d3b3d2 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1598,6 +1598,10 @@ static struct omap_uart_port_info *of_get_uart_port_info(struct device *dev)
 
 	of_property_read_u32(dev->of_node, "clock-frequency",
 					 &omap_up_info->uartclk);
+
+	if (of_property_read_bool(dev->of_node, "has-hw-flow-control"))
+		omap_up_info->flags |= UPF_HARD_FLOW;
+
 	return omap_up_info;
 }
 
-- 
1.9.3