[PATCH v3 0/4] omap-serial high-speed fixes/improvements

[PATCH v3 0/4] omap-serial high-speed fixes/improvements

[Frans Klaver]

Hi,

Here's version 3 of my fixes for high speed usage of the omap serial driver.
Sebastian's 8250 based implementation doesn't seem to be quite there yet. As
long as that's the case, I'd like to go ahead with improving this series.

v2..v3
  - fix an undefined variable in "prevent division by zero"
  - use IRQ_ONESHOT for the threaded irq in "use threaded interrupt handler"

v1..v2
  - 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                   | 64 +++++++++++++++++-----
 2 files changed, 50 insertions(+), 15 deletions(-)

-- 
2.1.0

[PATCH v3 0/4] omap-serial high-speed fixes/improvements

[Frans Klaver]

Hi,

Here's version 3 of my fixes for high speed usage of the omap serial driver.
Sebastian's 8250 based implementation doesn't seem to be quite there yet. As
long as that's the case, I'd like to go ahead with improving this series.

v2..v3
  - fix an undefined variable in "prevent division by zero"
  - use IRQ_ONESHOT for the threaded irq in "use threaded interrupt handler"

v1..v2
  - 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                   | 64 +++++++++++++++++-----
 2 files changed, 50 insertions(+), 15 deletions(-)

-- 
2.1.0

[PATCH v3 0/4] omap-serial high-speed fixes/improvements

[Frans Klaver]

Hi,

Here's version 3 of my fixes for high speed usage of the omap serial driver.
Sebastian's 8250 based implementation doesn't seem to be quite there yet. As
long as that's the case, I'd like to go ahead with improving this series.

v2..v3
  - fix an undefined variable in "prevent division by zero"
  - use IRQ_ONESHOT for the threaded irq in "use threaded interrupt handler"

v1..v2
  - 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                   | 64 +++++++++++++++++-----
 2 files changed, 50 insertions(+), 15 deletions(-)

-- 
2.1.0

[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);
 }
-- 
2.1.0

[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);
 }
-- 
2.1.0

[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);
 }
-- 
2.1.0

[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..7d3f557 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 - (port->uartclk / (mode * n));
 	if (abs_diff < 0)
 		abs_diff = -abs_diff;
 
-- 
2.1.0

[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..7d3f557 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 - (port->uartclk / (mode * n));
 	if (abs_diff < 0)
 		abs_diff = -abs_diff;
 
-- 
2.1.0

[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..7d3f557 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 - (port->uartclk / (mode * n));
 	if (abs_diff < 0)
 		abs_diff = -abs_diff;
 
-- 
2.1.0

[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 7d3f557..398139a 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;
-- 
2.1.0

[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 7d3f557..398139a 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;
-- 
2.1.0

[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 7d3f557..398139a 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;
-- 
2.1.0

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

[Peter Hurley]

On 09/15/2014 10:00 AM, 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.

Why is the threadirqs kernel boot option not sufficient?
Or conversely, shouldn't this be selectable?

Regards,
Peter Hurley

PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
latency in excess of 250us?

> 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 7d3f557..398139a 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;
> 

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

[Peter Hurley]

On 09/15/2014 10:00 AM, 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.

Why is the threadirqs kernel boot option not sufficient?
Or conversely, shouldn't this be selectable?

Regards,
Peter Hurley

PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
latency in excess of 250us?

> 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 7d3f557..398139a 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;
> 

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

[Peter Hurley]

On 09/15/2014 11:39 AM, Peter Hurley wrote:
> On 09/15/2014 10:00 AM, 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.
> 
> Why is the threadirqs kernel boot option not sufficient?
> Or conversely, shouldn't this be selectable?

Also, do you see the same performance differential when you implement this
in the 8250 driver (that is, on top of Sebastian's omap->8250 conversion)?


> Regards,
> Peter Hurley
> 
> PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
> latency in excess of 250us?
> 
>> 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 | 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 7d3f557..398139a 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;
>>


--
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

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

[Peter Hurley]

On 09/15/2014 11:39 AM, Peter Hurley wrote:
> On 09/15/2014 10:00 AM, 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.
> 
> Why is the threadirqs kernel boot option not sufficient?
> Or conversely, shouldn't this be selectable?

Also, do you see the same performance differential when you implement this
in the 8250 driver (that is, on top of Sebastian's omap->8250 conversion)?


> Regards,
> Peter Hurley
> 
> PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
> latency in excess of 250us?
> 
>> 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 7d3f557..398139a 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;
>>

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

[Peter Hurley]

On 09/15/2014 11:39 AM, Peter Hurley wrote:
> On 09/15/2014 10:00 AM, 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.
> 
> Why is the threadirqs kernel boot option not sufficient?
> Or conversely, shouldn't this be selectable?

Also, do you see the same performance differential when you implement this
in the 8250 driver (that is, on top of Sebastian's omap->8250 conversion)?


> Regards,
> Peter Hurley
> 
> PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
> latency in excess of 250us?
> 
>> 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 7d3f557..398139a 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;
>>

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

[Frans Klaver]

On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
> On 09/15/2014 11:39 AM, Peter Hurley wrote:
> > On 09/15/2014 10:00 AM, 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.
> > 
> > Why is the threadirqs kernel boot option not sufficient?
> > Or conversely, shouldn't this be selectable?
> 

I wasn't aware of the threadirqs boot option. I also wouldn't know if
this should be selectable. What would be a reason to favor the
non-threaded irq over the threaded irq?

> Also, do you see the same performance differential when you implement this
> in the 8250 driver (that is, on top of Sebastian's omap->8250 conversion)?
> 

I haven't gotten Sebastian's driver to work properly yet on the console.
There was no reason for me yet to throw my omap changes on top of
Sebastian's queue.

> > PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
> > latency in excess of 250us?

At 3686400 baud it should take about 174 us to fill a 64 byte buffer. I
haven't done any measurements on the interrupt latency though. If you
consider that we're sending about 1kB of data, 240 times a second, we're
spending a lot of time reading data from the uart. I can imagine the
system has other work to do as well.

This doesn't mean that we're not interested in Sebastian's driver
anymore though. We really want that dma support.

Thanks,
Frans

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

[Frans Klaver]

On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
> On 09/15/2014 11:39 AM, Peter Hurley wrote:
> > On 09/15/2014 10:00 AM, 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.
> > 
> > Why is the threadirqs kernel boot option not sufficient?
> > Or conversely, shouldn't this be selectable?
> 

I wasn't aware of the threadirqs boot option. I also wouldn't know if
this should be selectable. What would be a reason to favor the
non-threaded irq over the threaded irq?

> Also, do you see the same performance differential when you implement this
> in the 8250 driver (that is, on top of Sebastian's omap->8250 conversion)?
> 

I haven't gotten Sebastian's driver to work properly yet on the console.
There was no reason for me yet to throw my omap changes on top of
Sebastian's queue.

> > PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
> > latency in excess of 250us?

At 3686400 baud it should take about 174 us to fill a 64 byte buffer. I
haven't done any measurements on the interrupt latency though. If you
consider that we're sending about 1kB of data, 240 times a second, we're
spending a lot of time reading data from the uart. I can imagine the
system has other work to do as well.

This doesn't mean that we're not interested in Sebastian's driver
anymore though. We really want that dma support.

Thanks,
Frans

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

[Frans Klaver]

On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
> On 09/15/2014 11:39 AM, Peter Hurley wrote:
> > On 09/15/2014 10:00 AM, 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.
> > 
> > Why is the threadirqs kernel boot option not sufficient?
> > Or conversely, shouldn't this be selectable?
> 

I wasn't aware of the threadirqs boot option. I also wouldn't know if
this should be selectable. What would be a reason to favor the
non-threaded irq over the threaded irq?

> Also, do you see the same performance differential when you implement this
> in the 8250 driver (that is, on top of Sebastian's omap->8250 conversion)?
> 

I haven't gotten Sebastian's driver to work properly yet on the console.
There was no reason for me yet to throw my omap changes on top of
Sebastian's queue.

> > PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
> > latency in excess of 250us?

At 3686400 baud it should take about 174 us to fill a 64 byte buffer. I
haven't done any measurements on the interrupt latency though. If you
consider that we're sending about 1kB of data, 240 times a second, we're
spending a lot of time reading data from the uart. I can imagine the
system has other work to do as well.

This doesn't mean that we're not interested in Sebastian's driver
anymore though. We really want that dma support.

Thanks,
Frans

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

[Peter Hurley]

On 09/16/2014 04:50 AM, Frans Klaver wrote:
> On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
>> On 09/15/2014 11:39 AM, Peter Hurley wrote:
>>> On 09/15/2014 10:00 AM, 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.
>>>
>>> Why is the threadirqs kernel boot option not sufficient?
>>> Or conversely, shouldn't this be selectable?
>>
> 
> I wasn't aware of the threadirqs boot option. I also wouldn't know if
> this should be selectable. What would be a reason to favor the
> non-threaded irq over the threaded irq?

Not everyone cares enough about serial to dedicate kthreads to it :)

>> Also, do you see the same performance differential when you implement this
>> in the 8250 driver (that is, on top of Sebastian's omap->8250 conversion)?
>>
> 
> I haven't gotten Sebastian's driver to work properly yet on the console.
> There was no reason for me yet to throw my omap changes on top of
> Sebastian's queue.
> 
>>> PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
>>> latency in excess of 250us?
> 
> At 3686400 baud it should take about 174 us to fill a 64 byte buffer. I
> haven't done any measurements on the interrupt latency though. If you
> consider that we're sending about 1kB of data, 240 times a second, we're
> spending a lot of time reading data from the uart. I can imagine the
> system has other work to do as well.

System work should not keep irqs from being serviced. Even 174us is a long
time not to service an interrupt. Maybe console writes are keeping the isr
from running?

Regards,
Peter Hurley

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

[Peter Hurley]

On 09/16/2014 04:50 AM, Frans Klaver wrote:
> On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
>> On 09/15/2014 11:39 AM, Peter Hurley wrote:
>>> On 09/15/2014 10:00 AM, 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.
>>>
>>> Why is the threadirqs kernel boot option not sufficient?
>>> Or conversely, shouldn't this be selectable?
>>
> 
> I wasn't aware of the threadirqs boot option. I also wouldn't know if
> this should be selectable. What would be a reason to favor the
> non-threaded irq over the threaded irq?

Not everyone cares enough about serial to dedicate kthreads to it :)

>> Also, do you see the same performance differential when you implement this
>> in the 8250 driver (that is, on top of Sebastian's omap->8250 conversion)?
>>
> 
> I haven't gotten Sebastian's driver to work properly yet on the console.
> There was no reason for me yet to throw my omap changes on top of
> Sebastian's queue.
> 
>>> PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
>>> latency in excess of 250us?
> 
> At 3686400 baud it should take about 174 us to fill a 64 byte buffer. I
> haven't done any measurements on the interrupt latency though. If you
> consider that we're sending about 1kB of data, 240 times a second, we're
> spending a lot of time reading data from the uart. I can imagine the
> system has other work to do as well.

System work should not keep irqs from being serviced. Even 174us is a long
time not to service an interrupt. Maybe console writes are keeping the isr
from running?

Regards,
Peter Hurley

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

[Frans Klaver]

On Wed, Sep 17, 2014 at 08:01:08AM -0400, Peter Hurley wrote:
> On 09/16/2014 04:50 AM, Frans Klaver wrote:
> > On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
> >> On 09/15/2014 11:39 AM, Peter Hurley wrote:
> >>> On 09/15/2014 10:00 AM, 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.
> >>>
> >>> Why is the threadirqs kernel boot option not sufficient?
> >>> Or conversely, shouldn't this be selectable?
> >>
> > 
> > I wasn't aware of the threadirqs boot option. I also wouldn't know if
> > this should be selectable. What would be a reason to favor the
> > non-threaded irq over the threaded irq?
> 
> Not everyone cares enough about serial to dedicate kthreads to it :)

Fair enough. In that light, we might not care enough about other
subsystems to dedicate kthreads to it :). Selectable seems reasonable in
that case.


> >> Also, do you see the same performance differential when you implement this
> >> in the 8250 driver (that is, on top of Sebastian's omap->8250 conversion)?
> >>
> > 
> > I haven't gotten Sebastian's driver to work properly yet on the console.
> > There was no reason for me yet to throw my omap changes on top of
> > Sebastian's queue.
> > 
> >>> PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
> >>> latency in excess of 250us?
> > 
> > At 3686400 baud it should take about 174 us to fill a 64 byte buffer. I
> > haven't done any measurements on the interrupt latency though. If you
> > consider that we're sending about 1kB of data, 240 times a second, we're
> > spending a lot of time reading data from the uart. I can imagine the
> > system has other work to do as well.
> 
> System work should not keep irqs from being serviced. Even 174us is a long
> time not to service an interrupt. Maybe console writes are keeping the isr
> from running?

That's quite possible. I'll have to redo the test setup I had for this to
give you a decent answer. I'll have to do that anyway as Sebastian's
8250 conversion improves.

Thanks for the comments,
Frans

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

[Frans Klaver]

On Wed, Sep 17, 2014 at 08:01:08AM -0400, Peter Hurley wrote:
> On 09/16/2014 04:50 AM, Frans Klaver wrote:
> > On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
> >> On 09/15/2014 11:39 AM, Peter Hurley wrote:
> >>> On 09/15/2014 10:00 AM, 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.
> >>>
> >>> Why is the threadirqs kernel boot option not sufficient?
> >>> Or conversely, shouldn't this be selectable?
> >>
> > 
> > I wasn't aware of the threadirqs boot option. I also wouldn't know if
> > this should be selectable. What would be a reason to favor the
> > non-threaded irq over the threaded irq?
> 
> Not everyone cares enough about serial to dedicate kthreads to it :)

Fair enough. In that light, we might not care enough about other
subsystems to dedicate kthreads to it :). Selectable seems reasonable in
that case.


> >> Also, do you see the same performance differential when you implement this
> >> in the 8250 driver (that is, on top of Sebastian's omap->8250 conversion)?
> >>
> > 
> > I haven't gotten Sebastian's driver to work properly yet on the console.
> > There was no reason for me yet to throw my omap changes on top of
> > Sebastian's queue.
> > 
> >>> PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
> >>> latency in excess of 250us?
> > 
> > At 3686400 baud it should take about 174 us to fill a 64 byte buffer. I
> > haven't done any measurements on the interrupt latency though. If you
> > consider that we're sending about 1kB of data, 240 times a second, we're
> > spending a lot of time reading data from the uart. I can imagine the
> > system has other work to do as well.
> 
> System work should not keep irqs from being serviced. Even 174us is a long
> time not to service an interrupt. Maybe console writes are keeping the isr
> from running?

That's quite possible. I'll have to redo the test setup I had for this to
give you a decent answer. I'll have to do that anyway as Sebastian's
8250 conversion improves.

Thanks for the comments,
Frans

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

[Frans Klaver]

On Wed, Sep 17, 2014 at 08:01:08AM -0400, Peter Hurley wrote:
> On 09/16/2014 04:50 AM, Frans Klaver wrote:
> > On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
> >> On 09/15/2014 11:39 AM, Peter Hurley wrote:
> >>> On 09/15/2014 10:00 AM, 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.
> >>>
> >>> Why is the threadirqs kernel boot option not sufficient?
> >>> Or conversely, shouldn't this be selectable?
> >>
> > 
> > I wasn't aware of the threadirqs boot option. I also wouldn't know if
> > this should be selectable. What would be a reason to favor the
> > non-threaded irq over the threaded irq?
> 
> Not everyone cares enough about serial to dedicate kthreads to it :)

Fair enough. In that light, we might not care enough about other
subsystems to dedicate kthreads to it :). Selectable seems reasonable in
that case.


> >> Also, do you see the same performance differential when you implement this
> >> in the 8250 driver (that is, on top of Sebastian's omap->8250 conversion)?
> >>
> > 
> > I haven't gotten Sebastian's driver to work properly yet on the console.
> > There was no reason for me yet to throw my omap changes on top of
> > Sebastian's queue.
> > 
> >>> PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
> >>> latency in excess of 250us?
> > 
> > At 3686400 baud it should take about 174 us to fill a 64 byte buffer. I
> > haven't done any measurements on the interrupt latency though. If you
> > consider that we're sending about 1kB of data, 240 times a second, we're
> > spending a lot of time reading data from the uart. I can imagine the
> > system has other work to do as well.
> 
> System work should not keep irqs from being serviced. Even 174us is a long
> time not to service an interrupt. Maybe console writes are keeping the isr
> from running?

That's quite possible. I'll have to redo the test setup I had for this to
give you a decent answer. I'll have to do that anyway as Sebastian's
8250 conversion improves.

Thanks for the comments,
Frans

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

[Frans Klaver]

On Wed, Sep 17, 2014 at 02:13:03PM +0200, Frans Klaver wrote:
> On Wed, Sep 17, 2014 at 08:01:08AM -0400, Peter Hurley wrote:
> > On 09/16/2014 04:50 AM, Frans Klaver wrote:
> > > On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
> > >> On 09/15/2014 11:39 AM, Peter Hurley wrote:
> > >>> On 09/15/2014 10:00 AM, 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.
> > >>>
> > >>> Why is the threadirqs kernel boot option not sufficient?
> > >>> Or conversely, shouldn't this be selectable?
> > >>
> > > 
> > > I wasn't aware of the threadirqs boot option. I also wouldn't know if
> > > this should be selectable. What would be a reason to favor the
> > > non-threaded irq over the threaded irq?
> > 
> > Not everyone cares enough about serial to dedicate kthreads to it :)
> 
> Fair enough. In that light, we might not care enough about other
> subsystems to dedicate kthreads to it :). Selectable seems reasonable in
> that case.
> 
> 
> > >> Also, do you see the same performance differential when you implement this
> > >> in the 8250 driver (that is, on top of Sebastian's omap->8250 conversion)?
> > >>
> > > 
> > > I haven't gotten Sebastian's driver to work properly yet on the console.
> > > There was no reason for me yet to throw my omap changes on top of
> > > Sebastian's queue.

Doing the threaded interrupt change on the 8250 driver doesn't seem as
trivial. Unless I'm mistaken, that version of this patch would mess with
all other 8250 based serial drivers, if it's done properly. Incidentally
I did try using threadirqs, but that didn't give my any significant
results. I mostly noticed a difference in the console.


> > > 
> > >>> PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
> > >>> latency in excess of 250us?
> > > 
> > > At 3686400 baud it should take about 174 us to fill a 64 byte buffer. I
> > > haven't done any measurements on the interrupt latency though. If you
> > > consider that we're sending about 1kB of data, 240 times a second, we're
> > > spending a lot of time reading data from the uart. I can imagine the
> > > system has other work to do as well.
> > 
> > System work should not keep irqs from being serviced. Even 174us is a long
> > time not to service an interrupt. Maybe console writes are keeping the isr
> > from running?
> 
> That's quite possible. I'll have to redo the test setup I had for this to
> give you a decent answer. I'll have to do that anyway as Sebastian's
> 8250 conversion improves.

I haven't had time yet to look into this any further. I'll accept that
this patch may fix a case most people aren't the least interested in.
I'll also happily accept that I probably need a better argumentation
than "this works better for us".Would it make sense to drop this patch
and resubmit the other three? As I mentioned in the previous run, I
think these are useful in any case.

Thanks,
Frans

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

[Frans Klaver]

On Wed, Sep 17, 2014 at 02:13:03PM +0200, Frans Klaver wrote:
> On Wed, Sep 17, 2014 at 08:01:08AM -0400, Peter Hurley wrote:
> > On 09/16/2014 04:50 AM, Frans Klaver wrote:
> > > On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
> > >> On 09/15/2014 11:39 AM, Peter Hurley wrote:
> > >>> On 09/15/2014 10:00 AM, 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.
> > >>>
> > >>> Why is the threadirqs kernel boot option not sufficient?
> > >>> Or conversely, shouldn't this be selectable?
> > >>
> > > 
> > > I wasn't aware of the threadirqs boot option. I also wouldn't know if
> > > this should be selectable. What would be a reason to favor the
> > > non-threaded irq over the threaded irq?
> > 
> > Not everyone cares enough about serial to dedicate kthreads to it :)
> 
> Fair enough. In that light, we might not care enough about other
> subsystems to dedicate kthreads to it :). Selectable seems reasonable in
> that case.
> 
> 
> > >> Also, do you see the same performance differential when you implement this
> > >> in the 8250 driver (that is, on top of Sebastian's omap->8250 conversion)?
> > >>
> > > 
> > > I haven't gotten Sebastian's driver to work properly yet on the console.
> > > There was no reason for me yet to throw my omap changes on top of
> > > Sebastian's queue.

Doing the threaded interrupt change on the 8250 driver doesn't seem as
trivial. Unless I'm mistaken, that version of this patch would mess with
all other 8250 based serial drivers, if it's done properly. Incidentally
I did try using threadirqs, but that didn't give my any significant
results. I mostly noticed a difference in the console.


> > > 
> > >>> PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
> > >>> latency in excess of 250us?
> > > 
> > > At 3686400 baud it should take about 174 us to fill a 64 byte buffer. I
> > > haven't done any measurements on the interrupt latency though. If you
> > > consider that we're sending about 1kB of data, 240 times a second, we're
> > > spending a lot of time reading data from the uart. I can imagine the
> > > system has other work to do as well.
> > 
> > System work should not keep irqs from being serviced. Even 174us is a long
> > time not to service an interrupt. Maybe console writes are keeping the isr
> > from running?
> 
> That's quite possible. I'll have to redo the test setup I had for this to
> give you a decent answer. I'll have to do that anyway as Sebastian's
> 8250 conversion improves.

I haven't had time yet to look into this any further. I'll accept that
this patch may fix a case most people aren't the least interested in.
I'll also happily accept that I probably need a better argumentation
than "this works better for us".Would it make sense to drop this patch
and resubmit the other three? As I mentioned in the previous run, I
think these are useful in any case.

Thanks,
Frans

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

[Frans Klaver]

On Wed, Sep 17, 2014 at 02:13:03PM +0200, Frans Klaver wrote:
> On Wed, Sep 17, 2014 at 08:01:08AM -0400, Peter Hurley wrote:
> > On 09/16/2014 04:50 AM, Frans Klaver wrote:
> > > On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
> > >> On 09/15/2014 11:39 AM, Peter Hurley wrote:
> > >>> On 09/15/2014 10:00 AM, 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.
> > >>>
> > >>> Why is the threadirqs kernel boot option not sufficient?
> > >>> Or conversely, shouldn't this be selectable?
> > >>
> > > 
> > > I wasn't aware of the threadirqs boot option. I also wouldn't know if
> > > this should be selectable. What would be a reason to favor the
> > > non-threaded irq over the threaded irq?
> > 
> > Not everyone cares enough about serial to dedicate kthreads to it :)
> 
> Fair enough. In that light, we might not care enough about other
> subsystems to dedicate kthreads to it :). Selectable seems reasonable in
> that case.
> 
> 
> > >> Also, do you see the same performance differential when you implement this
> > >> in the 8250 driver (that is, on top of Sebastian's omap->8250 conversion)?
> > >>
> > > 
> > > I haven't gotten Sebastian's driver to work properly yet on the console.
> > > There was no reason for me yet to throw my omap changes on top of
> > > Sebastian's queue.

Doing the threaded interrupt change on the 8250 driver doesn't seem as
trivial. Unless I'm mistaken, that version of this patch would mess with
all other 8250 based serial drivers, if it's done properly. Incidentally
I did try using threadirqs, but that didn't give my any significant
results. I mostly noticed a difference in the console.


> > > 
> > >>> PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
> > >>> latency in excess of 250us?
> > > 
> > > At 3686400 baud it should take about 174 us to fill a 64 byte buffer. I
> > > haven't done any measurements on the interrupt latency though. If you
> > > consider that we're sending about 1kB of data, 240 times a second, we're
> > > spending a lot of time reading data from the uart. I can imagine the
> > > system has other work to do as well.
> > 
> > System work should not keep irqs from being serviced. Even 174us is a long
> > time not to service an interrupt. Maybe console writes are keeping the isr
> > from running?
> 
> That's quite possible. I'll have to redo the test setup I had for this to
> give you a decent answer. I'll have to do that anyway as Sebastian's
> 8250 conversion improves.

I haven't had time yet to look into this any further. I'll accept that
this patch may fix a case most people aren't the least interested in.
I'll also happily accept that I probably need a better argumentation
than "this works better for us".Would it make sense to drop this patch
and resubmit the other three? As I mentioned in the previous run, I
think these are useful in any case.

Thanks,
Frans

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

[Peter Hurley]

On 09/23/2014 04:24 AM, Frans Klaver wrote:
> On Wed, Sep 17, 2014 at 02:13:03PM +0200, Frans Klaver wrote:
>> On Wed, Sep 17, 2014 at 08:01:08AM -0400, Peter Hurley wrote:
>>> On 09/16/2014 04:50 AM, Frans Klaver wrote:
>>>> On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
>>>>> On 09/15/2014 11:39 AM, Peter Hurley wrote:
>>>>>> On 09/15/2014 10:00 AM, 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.
>>>>>>
>>>>>> Why is the threadirqs kernel boot option not sufficient?
>>>>>> Or conversely, shouldn't this be selectable?
>>>>>
>>>>
>>>> I wasn't aware of the threadirqs boot option. I also wouldn't know if
>>>> this should be selectable. What would be a reason to favor the
>>>> non-threaded irq over the threaded irq?
>>>
>>> Not everyone cares enough about serial to dedicate kthreads to it :)
>>
>> Fair enough. In that light, we might not care enough about other
>> subsystems to dedicate kthreads to it :). Selectable seems reasonable in
>> that case.
>>
>>
>>>>> Also, do you see the same performance differential when you implement this
>>>>> in the 8250 driver (that is, on top of Sebastian's omap->8250 conversion)?
>>>>>
>>>>
>>>> I haven't gotten Sebastian's driver to work properly yet on the console.
>>>> There was no reason for me yet to throw my omap changes on top of
>>>> Sebastian's queue.
> 
> Doing the threaded interrupt change on the 8250 driver doesn't seem as
> trivial. Unless I'm mistaken, that version of this patch would mess with
> all other 8250 based serial drivers, if it's done properly. Incidentally
> I did try using threadirqs, but that didn't give my any significant
> results. I mostly noticed a difference in the console.
> 
> 
>>>>
>>>>>> PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
>>>>>> latency in excess of 250us?
>>>>
>>>> At 3686400 baud it should take about 174 us to fill a 64 byte buffer. I
>>>> haven't done any measurements on the interrupt latency though. If you
>>>> consider that we're sending about 1kB of data, 240 times a second, we're
>>>> spending a lot of time reading data from the uart. I can imagine the
>>>> system has other work to do as well.
>>>
>>> System work should not keep irqs from being serviced. Even 174us is a long
>>> time not to service an interrupt. Maybe console writes are keeping the isr
>>> from running?
>>
>> That's quite possible. I'll have to redo the test setup I had for this to
>> give you a decent answer. I'll have to do that anyway as Sebastian's
>> 8250 conversion improves.
> 
> I haven't had time yet to look into this any further. I'll accept that
> this patch may fix a case most people aren't the least interested in.
> I'll also happily accept that I probably need a better argumentation
> than "this works better for us".Would it make sense to drop this patch
> and resubmit the other three? As I mentioned in the previous run, I
> think these are useful in any case.

I would've thought the first 2 patches had already been picked up because
they fix div-by-zero faults.

I don't really have a problem with the patch (except for it should be
selectable, even if that's just a CONFIG_ setting). At the same time,
the performance results don't really make sense; so if there's actually
an underlying problem, I'd rather that get addressed (and the long
interrupt latency may be the underlying problem).

As far as the 8250 driver and threaded irqs go, I just was hoping for
another data point with a simple hard-coded test jig, not a full-blown
patch series for all of them. Sorry for the misunderstanding.

Regards,
Peter Hurley
--
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

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

[Peter Hurley]

On 09/23/2014 04:24 AM, Frans Klaver wrote:
> On Wed, Sep 17, 2014 at 02:13:03PM +0200, Frans Klaver wrote:
>> On Wed, Sep 17, 2014 at 08:01:08AM -0400, Peter Hurley wrote:
>>> On 09/16/2014 04:50 AM, Frans Klaver wrote:
>>>> On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
>>>>> On 09/15/2014 11:39 AM, Peter Hurley wrote:
>>>>>> On 09/15/2014 10:00 AM, 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.
>>>>>>
>>>>>> Why is the threadirqs kernel boot option not sufficient?
>>>>>> Or conversely, shouldn't this be selectable?
>>>>>
>>>>
>>>> I wasn't aware of the threadirqs boot option. I also wouldn't know if
>>>> this should be selectable. What would be a reason to favor the
>>>> non-threaded irq over the threaded irq?
>>>
>>> Not everyone cares enough about serial to dedicate kthreads to it :)
>>
>> Fair enough. In that light, we might not care enough about other
>> subsystems to dedicate kthreads to it :). Selectable seems reasonable in
>> that case.
>>
>>
>>>>> Also, do you see the same performance differential when you implement this
>>>>> in the 8250 driver (that is, on top of Sebastian's omap->8250 conversion)?
>>>>>
>>>>
>>>> I haven't gotten Sebastian's driver to work properly yet on the console.
>>>> There was no reason for me yet to throw my omap changes on top of
>>>> Sebastian's queue.
> 
> Doing the threaded interrupt change on the 8250 driver doesn't seem as
> trivial. Unless I'm mistaken, that version of this patch would mess with
> all other 8250 based serial drivers, if it's done properly. Incidentally
> I did try using threadirqs, but that didn't give my any significant
> results. I mostly noticed a difference in the console.
> 
> 
>>>>
>>>>>> PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
>>>>>> latency in excess of 250us?
>>>>
>>>> At 3686400 baud it should take about 174 us to fill a 64 byte buffer. I
>>>> haven't done any measurements on the interrupt latency though. If you
>>>> consider that we're sending about 1kB of data, 240 times a second, we're
>>>> spending a lot of time reading data from the uart. I can imagine the
>>>> system has other work to do as well.
>>>
>>> System work should not keep irqs from being serviced. Even 174us is a long
>>> time not to service an interrupt. Maybe console writes are keeping the isr
>>> from running?
>>
>> That's quite possible. I'll have to redo the test setup I had for this to
>> give you a decent answer. I'll have to do that anyway as Sebastian's
>> 8250 conversion improves.
> 
> I haven't had time yet to look into this any further. I'll accept that
> this patch may fix a case most people aren't the least interested in.
> I'll also happily accept that I probably need a better argumentation
> than "this works better for us".Would it make sense to drop this patch
> and resubmit the other three? As I mentioned in the previous run, I
> think these are useful in any case.

I would've thought the first 2 patches had already been picked up because
they fix div-by-zero faults.

I don't really have a problem with the patch (except for it should be
selectable, even if that's just a CONFIG_ setting). At the same time,
the performance results don't really make sense; so if there's actually
an underlying problem, I'd rather that get addressed (and the long
interrupt latency may be the underlying problem).

As far as the 8250 driver and threaded irqs go, I just was hoping for
another data point with a simple hard-coded test jig, not a full-blown
patch series for all of them. Sorry for the misunderstanding.

Regards,
Peter Hurley

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

[Peter Hurley]

On 09/23/2014 04:24 AM, Frans Klaver wrote:
> On Wed, Sep 17, 2014 at 02:13:03PM +0200, Frans Klaver wrote:
>> On Wed, Sep 17, 2014 at 08:01:08AM -0400, Peter Hurley wrote:
>>> On 09/16/2014 04:50 AM, Frans Klaver wrote:
>>>> On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
>>>>> On 09/15/2014 11:39 AM, Peter Hurley wrote:
>>>>>> On 09/15/2014 10:00 AM, 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.
>>>>>>
>>>>>> Why is the threadirqs kernel boot option not sufficient?
>>>>>> Or conversely, shouldn't this be selectable?
>>>>>
>>>>
>>>> I wasn't aware of the threadirqs boot option. I also wouldn't know if
>>>> this should be selectable. What would be a reason to favor the
>>>> non-threaded irq over the threaded irq?
>>>
>>> Not everyone cares enough about serial to dedicate kthreads to it :)
>>
>> Fair enough. In that light, we might not care enough about other
>> subsystems to dedicate kthreads to it :). Selectable seems reasonable in
>> that case.
>>
>>
>>>>> Also, do you see the same performance differential when you implement this
>>>>> in the 8250 driver (that is, on top of Sebastian's omap->8250 conversion)?
>>>>>
>>>>
>>>> I haven't gotten Sebastian's driver to work properly yet on the console.
>>>> There was no reason for me yet to throw my omap changes on top of
>>>> Sebastian's queue.
> 
> Doing the threaded interrupt change on the 8250 driver doesn't seem as
> trivial. Unless I'm mistaken, that version of this patch would mess with
> all other 8250 based serial drivers, if it's done properly. Incidentally
> I did try using threadirqs, but that didn't give my any significant
> results. I mostly noticed a difference in the console.
> 
> 
>>>>
>>>>>> PS - To overflow the 64 byte RX FIFO at those data rates means interrupt
>>>>>> latency in excess of 250us?
>>>>
>>>> At 3686400 baud it should take about 174 us to fill a 64 byte buffer. I
>>>> haven't done any measurements on the interrupt latency though. If you
>>>> consider that we're sending about 1kB of data, 240 times a second, we're
>>>> spending a lot of time reading data from the uart. I can imagine the
>>>> system has other work to do as well.
>>>
>>> System work should not keep irqs from being serviced. Even 174us is a long
>>> time not to service an interrupt. Maybe console writes are keeping the isr
>>> from running?
>>
>> That's quite possible. I'll have to redo the test setup I had for this to
>> give you a decent answer. I'll have to do that anyway as Sebastian's
>> 8250 conversion improves.
> 
> I haven't had time yet to look into this any further. I'll accept that
> this patch may fix a case most people aren't the least interested in.
> I'll also happily accept that I probably need a better argumentation
> than "this works better for us".Would it make sense to drop this patch
> and resubmit the other three? As I mentioned in the previous run, I
> think these are useful in any case.

I would've thought the first 2 patches had already been picked up because
they fix div-by-zero faults.

I don't really have a problem with the patch (except for it should be
selectable, even if that's just a CONFIG_ setting). At the same time,
the performance results don't really make sense; so if there's actually
an underlying problem, I'd rather that get addressed (and the long
interrupt latency may be the underlying problem).

As far as the 8250 driver and threaded irqs go, I just was hoping for
another data point with a simple hard-coded test jig, not a full-blown
patch series for all of them. Sorry for the misunderstanding.

Regards,
Peter Hurley

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

[Frans Klaver]

On 23 September 2014 19:17:20 CEST, Peter Hurley <peter-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org> wrote:
>On 09/23/2014 04:24 AM, Frans Klaver wrote:
>> On Wed, Sep 17, 2014 at 02:13:03PM +0200, Frans Klaver wrote:
>>> On Wed, Sep 17, 2014 at 08:01:08AM -0400, Peter Hurley wrote:
>>>> On 09/16/2014 04:50 AM, Frans Klaver wrote:
>>>>> On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
>>>>>> On 09/15/2014 11:39 AM, Peter Hurley wrote:
>>>>>>> On 09/15/2014 10:00 AM, 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.
>>>>>>>
>>>>>>> Why is the threadirqs kernel boot option not sufficient?
>>>>>>> Or conversely, shouldn't this be selectable?
>>>>>>
>>>>>
>>>>> I wasn't aware of the threadirqs boot option. I also wouldn't know
>if
>>>>> this should be selectable. What would be a reason to favor the
>>>>> non-threaded irq over the threaded irq?
>>>>
>>>> Not everyone cares enough about serial to dedicate kthreads to it
>:)
>>>
>>> Fair enough. In that light, we might not care enough about other
>>> subsystems to dedicate kthreads to it :). Selectable seems
>reasonable in
>>> that case.
>>>
>>>
>>>>>> Also, do you see the same performance differential when you
>implement this
>>>>>> in the 8250 driver (that is, on top of Sebastian's omap->8250
>conversion)?
>>>>>>
>>>>>
>>>>> I haven't gotten Sebastian's driver to work properly yet on the
>console.
>>>>> There was no reason for me yet to throw my omap changes on top of
>>>>> Sebastian's queue.
>> 
>> Doing the threaded interrupt change on the 8250 driver doesn't seem
>as
>> trivial. Unless I'm mistaken, that version of this patch would mess
>with
>> all other 8250 based serial drivers, if it's done properly.
>Incidentally
>> I did try using threadirqs, but that didn't give my any significant
>> results. I mostly noticed a difference in the console.
>> 
>> 
>>>>>
>>>>>>> PS - To overflow the 64 byte RX FIFO at those data rates means
>interrupt
>>>>>>> latency in excess of 250us?
>>>>>
>>>>> At 3686400 baud it should take about 174 us to fill a 64 byte
>buffer. I
>>>>> haven't done any measurements on the interrupt latency though. If
>you
>>>>> consider that we're sending about 1kB of data, 240 times a second,
>we're
>>>>> spending a lot of time reading data from the uart. I can imagine
>the
>>>>> system has other work to do as well.
>>>>
>>>> System work should not keep irqs from being serviced. Even 174us is
>a long
>>>> time not to service an interrupt. Maybe console writes are keeping
>the isr
>>>> from running?
>>>
>>> That's quite possible. I'll have to redo the test setup I had for
>this to
>>> give you a decent answer. I'll have to do that anyway as Sebastian's
>>> 8250 conversion improves.
>> 
>> I haven't had time yet to look into this any further. I'll accept
>that
>> this patch may fix a case most people aren't the least interested in.
>> I'll also happily accept that I probably need a better argumentation
>> than "this works better for us".Would it make sense to drop this
>patch
>> and resubmit the other three? As I mentioned in the previous run, I
>> think these are useful in any case.
>
>I would've thought the first 2 patches had already been picked up
>because
>they fix div-by-zero faults.

I've had no confirmation of that happening so far. I also don't know if I should expect one. Who'd take these patches? Tony? 


>I don't really have a problem with the patch (except for it should be
>selectable, even if that's just a CONFIG_ setting). At the same time,
>the performance results don't really make sense; so if there's actually
>an underlying problem, I'd rather that get addressed (and the long
>interrupt latency may be the underlying problem).

Your questions got me thinking a bit more. I concluded that it's hard to define why this difference in performance is so big. I only got to it by just trying and seeing what would happen. 


>As far as the 8250 driver and threaded irqs go, I just was hoping for
>another data point with a simple hard-coded test jig, not a full-blown
>patch series for all of them. Sorry for the misunderstanding.

Ah yes. I'll see what I can do about it. It does make sense to get that data point somehow. 

Thanks, 
Frans 

>
>Regards,
>Peter Hurley
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


--
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

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

[Frans Klaver]

On 23 September 2014 19:17:20 CEST, Peter Hurley <peter@hurleysoftware.com> wrote:
>On 09/23/2014 04:24 AM, Frans Klaver wrote:
>> On Wed, Sep 17, 2014 at 02:13:03PM +0200, Frans Klaver wrote:
>>> On Wed, Sep 17, 2014 at 08:01:08AM -0400, Peter Hurley wrote:
>>>> On 09/16/2014 04:50 AM, Frans Klaver wrote:
>>>>> On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
>>>>>> On 09/15/2014 11:39 AM, Peter Hurley wrote:
>>>>>>> On 09/15/2014 10:00 AM, 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.
>>>>>>>
>>>>>>> Why is the threadirqs kernel boot option not sufficient?
>>>>>>> Or conversely, shouldn't this be selectable?
>>>>>>
>>>>>
>>>>> I wasn't aware of the threadirqs boot option. I also wouldn't know
>if
>>>>> this should be selectable. What would be a reason to favor the
>>>>> non-threaded irq over the threaded irq?
>>>>
>>>> Not everyone cares enough about serial to dedicate kthreads to it
>:)
>>>
>>> Fair enough. In that light, we might not care enough about other
>>> subsystems to dedicate kthreads to it :). Selectable seems
>reasonable in
>>> that case.
>>>
>>>
>>>>>> Also, do you see the same performance differential when you
>implement this
>>>>>> in the 8250 driver (that is, on top of Sebastian's omap->8250
>conversion)?
>>>>>>
>>>>>
>>>>> I haven't gotten Sebastian's driver to work properly yet on the
>console.
>>>>> There was no reason for me yet to throw my omap changes on top of
>>>>> Sebastian's queue.
>> 
>> Doing the threaded interrupt change on the 8250 driver doesn't seem
>as
>> trivial. Unless I'm mistaken, that version of this patch would mess
>with
>> all other 8250 based serial drivers, if it's done properly.
>Incidentally
>> I did try using threadirqs, but that didn't give my any significant
>> results. I mostly noticed a difference in the console.
>> 
>> 
>>>>>
>>>>>>> PS - To overflow the 64 byte RX FIFO at those data rates means
>interrupt
>>>>>>> latency in excess of 250us?
>>>>>
>>>>> At 3686400 baud it should take about 174 us to fill a 64 byte
>buffer. I
>>>>> haven't done any measurements on the interrupt latency though. If
>you
>>>>> consider that we're sending about 1kB of data, 240 times a second,
>we're
>>>>> spending a lot of time reading data from the uart. I can imagine
>the
>>>>> system has other work to do as well.
>>>>
>>>> System work should not keep irqs from being serviced. Even 174us is
>a long
>>>> time not to service an interrupt. Maybe console writes are keeping
>the isr
>>>> from running?
>>>
>>> That's quite possible. I'll have to redo the test setup I had for
>this to
>>> give you a decent answer. I'll have to do that anyway as Sebastian's
>>> 8250 conversion improves.
>> 
>> I haven't had time yet to look into this any further. I'll accept
>that
>> this patch may fix a case most people aren't the least interested in.
>> I'll also happily accept that I probably need a better argumentation
>> than "this works better for us".Would it make sense to drop this
>patch
>> and resubmit the other three? As I mentioned in the previous run, I
>> think these are useful in any case.
>
>I would've thought the first 2 patches had already been picked up
>because
>they fix div-by-zero faults.

I've had no confirmation of that happening so far. I also don't know if I should expect one. Who'd take these patches? Tony? 


>I don't really have a problem with the patch (except for it should be
>selectable, even if that's just a CONFIG_ setting). At the same time,
>the performance results don't really make sense; so if there's actually
>an underlying problem, I'd rather that get addressed (and the long
>interrupt latency may be the underlying problem).

Your questions got me thinking a bit more. I concluded that it's hard to define why this difference in performance is so big. I only got to it by just trying and seeing what would happen. 


>As far as the 8250 driver and threaded irqs go, I just was hoping for
>another data point with a simple hard-coded test jig, not a full-blown
>patch series for all of them. Sorry for the misunderstanding.

Ah yes. I'll see what I can do about it. It does make sense to get that data point somehow. 

Thanks, 
Frans 

>
>Regards,
>Peter Hurley
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel@lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Frans Klaver]

On 23 September 2014 19:17:20 CEST, Peter Hurley <peter@hurleysoftware.com> wrote:
>On 09/23/2014 04:24 AM, Frans Klaver wrote:
>> On Wed, Sep 17, 2014 at 02:13:03PM +0200, Frans Klaver wrote:
>>> On Wed, Sep 17, 2014 at 08:01:08AM -0400, Peter Hurley wrote:
>>>> On 09/16/2014 04:50 AM, Frans Klaver wrote:
>>>>> On Mon, Sep 15, 2014 at 01:31:56PM -0400, Peter Hurley wrote:
>>>>>> On 09/15/2014 11:39 AM, Peter Hurley wrote:
>>>>>>> On 09/15/2014 10:00 AM, 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.
>>>>>>>
>>>>>>> Why is the threadirqs kernel boot option not sufficient?
>>>>>>> Or conversely, shouldn't this be selectable?
>>>>>>
>>>>>
>>>>> I wasn't aware of the threadirqs boot option. I also wouldn't know
>if
>>>>> this should be selectable. What would be a reason to favor the
>>>>> non-threaded irq over the threaded irq?
>>>>
>>>> Not everyone cares enough about serial to dedicate kthreads to it
>:)
>>>
>>> Fair enough. In that light, we might not care enough about other
>>> subsystems to dedicate kthreads to it :). Selectable seems
>reasonable in
>>> that case.
>>>
>>>
>>>>>> Also, do you see the same performance differential when you
>implement this
>>>>>> in the 8250 driver (that is, on top of Sebastian's omap->8250
>conversion)?
>>>>>>
>>>>>
>>>>> I haven't gotten Sebastian's driver to work properly yet on the
>console.
>>>>> There was no reason for me yet to throw my omap changes on top of
>>>>> Sebastian's queue.
>> 
>> Doing the threaded interrupt change on the 8250 driver doesn't seem
>as
>> trivial. Unless I'm mistaken, that version of this patch would mess
>with
>> all other 8250 based serial drivers, if it's done properly.
>Incidentally
>> I did try using threadirqs, but that didn't give my any significant
>> results. I mostly noticed a difference in the console.
>> 
>> 
>>>>>
>>>>>>> PS - To overflow the 64 byte RX FIFO at those data rates means
>interrupt
>>>>>>> latency in excess of 250us?
>>>>>
>>>>> At 3686400 baud it should take about 174 us to fill a 64 byte
>buffer. I
>>>>> haven't done any measurements on the interrupt latency though. If
>you
>>>>> consider that we're sending about 1kB of data, 240 times a second,
>we're
>>>>> spending a lot of time reading data from the uart. I can imagine
>the
>>>>> system has other work to do as well.
>>>>
>>>> System work should not keep irqs from being serviced. Even 174us is
>a long
>>>> time not to service an interrupt. Maybe console writes are keeping
>the isr
>>>> from running?
>>>
>>> That's quite possible. I'll have to redo the test setup I had for
>this to
>>> give you a decent answer. I'll have to do that anyway as Sebastian's
>>> 8250 conversion improves.
>> 
>> I haven't had time yet to look into this any further. I'll accept
>that
>> this patch may fix a case most people aren't the least interested in.
>> I'll also happily accept that I probably need a better argumentation
>> than "this works better for us".Would it make sense to drop this
>patch
>> and resubmit the other three? As I mentioned in the previous run, I
>> think these are useful in any case.
>
>I would've thought the first 2 patches had already been picked up
>because
>they fix div-by-zero faults.

I've had no confirmation of that happening so far. I also don't know if I should expect one. Who'd take these patches? Tony? 


>I don't really have a problem with the patch (except for it should be
>selectable, even if that's just a CONFIG_ setting). At the same time,
>the performance results don't really make sense; so if there's actually
>an underlying problem, I'd rather that get addressed (and the long
>interrupt latency may be the underlying problem).

Your questions got me thinking a bit more. I concluded that it's hard to define why this difference in performance is so big. I only got to it by just trying and seeing what would happen. 


>As far as the 8250 driver and threaded irqs go, I just was hoping for
>another data point with a simple hard-coded test jig, not a full-blown
>patch series for all of them. Sorry for the misunderstanding.

Ah yes. I'll see what I can do about it. It does make sense to get that data point somehow. 

Thanks, 
Frans 

>
>Regards,
>Peter Hurley
>
>_______________________________________________
>linux-arm-kernel mailing list
>linux-arm-kernel at lists.infradead.org
>http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

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

[Tony Lindgren]

* Frans Klaver <fransklaver@gmail.com> [140923 11:12]:
> On 23 September 2014 19:17:20 CEST, Peter Hurley <peter@hurleysoftware.com> wrote:
> >
> >I would've thought the first 2 patches had already been picked up
> >because
> >they fix div-by-zero faults.
> 
> I've had no confirmation of that happening so far. I also don't
> know if I should expect one. Who'd take these patches? Tony? 

$ scripts/get_maintainer.pl -f drivers/tty/serial/omap-serial.c

Shows they should be sent to Greg and linux-serial. Please also Cc
linux-omap. And if it's a fix, please make sure the subject has the
magic word fix :)

Regards,

Tony

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

[Tony Lindgren]

* Frans Klaver <fransklaver@gmail.com> [140923 11:12]:
> On 23 September 2014 19:17:20 CEST, Peter Hurley <peter@hurleysoftware.com> wrote:
> >
> >I would've thought the first 2 patches had already been picked up
> >because
> >they fix div-by-zero faults.
> 
> I've had no confirmation of that happening so far. I also don't
> know if I should expect one. Who'd take these patches? Tony? 

$ scripts/get_maintainer.pl -f drivers/tty/serial/omap-serial.c

Shows they should be sent to Greg and linux-serial. Please also Cc
linux-omap. And if it's a fix, please make sure the subject has the
magic word fix :)

Regards,

Tony

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

[Frans Klaver]

On Tue, Sep 23, 2014 at 8:38 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Frans Klaver <fransklaver@gmail.com> [140923 11:12]:
>> On 23 September 2014 19:17:20 CEST, Peter Hurley <peter@hurleysoftware.com> wrote:
>> >
>> >I would've thought the first 2 patches had already been picked up
>> >because
>> >they fix div-by-zero faults.
>>
>> I've had no confirmation of that happening so far. I also don't
>> know if I should expect one. Who'd take these patches? Tony?
>
> $ scripts/get_maintainer.pl -f drivers/tty/serial/omap-serial.c
>
> Shows they should be sent to Greg and linux-serial. Please also Cc
> linux-omap. And if it's a fix, please make sure the subject has the
> magic word fix :)

Done. Thanks.

Frans

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

[Frans Klaver]

On Tue, Sep 23, 2014 at 8:38 PM, Tony Lindgren <tony@atomide.com> wrote:
> * Frans Klaver <fransklaver@gmail.com> [140923 11:12]:
>> On 23 September 2014 19:17:20 CEST, Peter Hurley <peter@hurleysoftware.com> wrote:
>> >
>> >I would've thought the first 2 patches had already been picked up
>> >because
>> >they fix div-by-zero faults.
>>
>> I've had no confirmation of that happening so far. I also don't
>> know if I should expect one. Who'd take these patches? Tony?
>
> $ scripts/get_maintainer.pl -f drivers/tty/serial/omap-serial.c
>
> Shows they should be sent to Greg and linux-serial. Please also Cc
> linux-omap. And if it's a fix, please make sure the subject has the
> magic word fix :)

Done. Thanks.

Frans

[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 398139a..bff6874 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1597,6 +1597,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;
 }
 
-- 
2.1.0

[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 398139a..bff6874 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1597,6 +1597,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;
 }
 
-- 
2.1.0

[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 398139a..bff6874 100644
--- a/drivers/tty/serial/omap-serial.c
+++ b/drivers/tty/serial/omap-serial.c
@@ -1597,6 +1597,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;
 }
 
-- 
2.1.0