* Re: [PATCH 02/12] usb: fix sillies in the metro USB driver
From: Alan Cox @ 2012-07-23 16:32 UTC (permalink / raw)
To: Jiri Slaby; +Cc: greg, linux-kernel, linux-serial, Jiri Slaby
In-Reply-To: <4FE78B62.4090106@suse.cz>
On Sun, 24 Jun 2012 23:49:22 +0200
Jiri Slaby <jslaby@suse.cz> wrote:
> On 06/22/2012 05:38 PM, Alan Cox wrote:
> > Bits noticed doing the termios conversion
> >
> > Signed-off-by: Alan Cox <alan@linux.intel.com>
> > ---
> >
> > drivers/usb/serial/metro-usb.c | 8 +-------
> > 1 file changed, 1 insertion(+), 7 deletions(-)
> >
> > diff --git a/drivers/usb/serial/metro-usb.c b/drivers/usb/serial/metro-usb.c
> > index 81423f7..bad5f0c 100644
> > --- a/drivers/usb/serial/metro-usb.c
> > +++ b/drivers/usb/serial/metro-usb.c
> > @@ -130,20 +130,14 @@ static void metrousb_read_int_callback(struct urb *urb)
> ...
> > if (tty && urb->actual_length) {
> > /* Loop through the data copying each byte to the tty layer. */
> > tty_insert_flip_string(tty, data, urb->actual_length);
> >
> > /* Force the data to the tty layer. */
> > tty_flip_buffer_push(tty);
> > + tty_kref_put(tty);
> > }
> > - tty_kref_put(tty);
>
> This doesn't seem right. (Depends on whether tty is non-null iff
> urb->actual_length is non-zero.)
Doh fixed.. queued
^ permalink raw reply
* Re: [PATCH 03/25] serial/imx: make imx_port.devdata member point to const data
From: Greg Kroah-Hartman @ 2012-07-23 15:31 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Grant Likely, Arnd Bergmann, Rob Herring, Alan Cox, kernel,
linux-arm-kernel, linux-serial
In-Reply-To: <1343034810-3386-4-git-send-email-u.kleine-koenig@pengutronix.de>
On Mon, Jul 23, 2012 at 11:13:08AM +0200, Uwe Kleine-König wrote:
> This prepares *of_device_id.data becoming const. Without this change the
> following warning would occur:
>
> drivers/tty/serial/imx.c: In function 'serial_imx_probe_dt':
> drivers/tty/serial/imx.c:1430:17: warning: assignment discards 'const' qualifier from pointer target type [enabled by default]
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 04/25] serial/mpc52xx_uart: add a const qualifier
From: Greg Kroah-Hartman @ 2012-07-23 15:31 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Grant Likely, Arnd Bergmann, Rob Herring, Alan Cox, kernel,
linux-arm-kernel, linux-serial, Frank Benkert
In-Reply-To: <1343034810-3386-5-git-send-email-u.kleine-koenig@pengutronix.de>
On Mon, Jul 23, 2012 at 11:13:09AM +0200, Uwe Kleine-König wrote:
> This prepares *of_device_id.data becoming const. Without this change
> the following warning would occur:
>
> drivers/tty/serial/mpc52xx_uart.c: In function 'mpc52xx_uart_of_enumerate':
> drivers/tty/serial/mpc52xx_uart.c:1440:11: warning: assignment discards 'const' qualifier from pointer target type [enabled by default]
>
> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 03/25] serial/imx: make imx_port.devdata member point to const data
From: Uwe Kleine-König @ 2012-07-23 9:13 UTC (permalink / raw)
To: Grant Likely, Arnd Bergmann, Rob Herring, Alan Cox,
Greg Kroah-Hartman
Cc: kernel, linux-arm-kernel, linux-serial
In-Reply-To: <1343034810-3386-1-git-send-email-u.kleine-koenig@pengutronix.de>
This prepares *of_device_id.data becoming const. Without this change the
following warning would occur:
drivers/tty/serial/imx.c: In function 'serial_imx_probe_dt':
drivers/tty/serial/imx.c:1430:17: warning: assignment discards 'const' qualifier from pointer target type [enabled by default]
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/tty/serial/imx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/imx.c b/drivers/tty/serial/imx.c
index 4ef7473..0af4eec 100644
--- a/drivers/tty/serial/imx.c
+++ b/drivers/tty/serial/imx.c
@@ -207,7 +207,7 @@ struct imx_port {
unsigned short trcv_delay; /* transceiver delay */
struct clk *clk_ipg;
struct clk *clk_per;
- struct imx_uart_data *devdata;
+ const struct imx_uart_data *devdata;
};
struct imx_port_ucrs {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 04/25] serial/mpc52xx_uart: add a const qualifier
From: Uwe Kleine-König @ 2012-07-23 9:13 UTC (permalink / raw)
To: Grant Likely, Arnd Bergmann, Rob Herring, Alan Cox,
Greg Kroah-Hartman
Cc: kernel, linux-arm-kernel, linux-serial, Frank Benkert
In-Reply-To: <1343034810-3386-1-git-send-email-u.kleine-koenig@pengutronix.de>
This prepares *of_device_id.data becoming const. Without this change
the following warning would occur:
drivers/tty/serial/mpc52xx_uart.c: In function 'mpc52xx_uart_of_enumerate':
drivers/tty/serial/mpc52xx_uart.c:1440:11: warning: assignment discards 'const' qualifier from pointer target type [enabled by default]
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
---
drivers/tty/serial/mpc52xx_uart.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/tty/serial/mpc52xx_uart.c b/drivers/tty/serial/mpc52xx_uart.c
index bedac0d..b131f2d 100644
--- a/drivers/tty/serial/mpc52xx_uart.c
+++ b/drivers/tty/serial/mpc52xx_uart.c
@@ -598,7 +598,7 @@ static struct psc_ops mpc512x_psc_ops = {
};
#endif
-static struct psc_ops *psc_ops;
+static const struct psc_ops *psc_ops;
/* ======================================================================== */
/* UART operations */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCHv2 2/2] ARM: vt8500: Minor update to vt8500-uart for devicetree support
From: Tony Prisk @ 2012-07-21 11:22 UTC (permalink / raw)
To: Alan Cox
Cc: rtc-linux-/JYPxA39Uh5TLH3MbocFFw, Greg Kroah-Hartman,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
linux-serial-u79uwXL29TY76Z2rM5mHXA, VT8500 mailing list
Signed-off-by: Tony Prisk <linux-ci5G2KO2hbZ+pU9mqzGVBQ@public.gmane.org>
Acked-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
---
v2:
Split single patch into seperate patches.
.../devicetree/bindings/tty/serial/vt8500-uart.txt | 14 ++++++++++++++
drivers/tty/serial/vt8500_serial.c | 8 ++++++++
2 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/tty/serial/vt8500-uart.txt
diff --git a/Documentation/devicetree/bindings/tty/serial/vt8500-uart.txt b/Documentation/devicetree/bindings/tty/serial/vt8500-uart.txt
new file mode 100644
index 0000000..745070a
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/vt8500-uart.txt
@@ -0,0 +1,14 @@
+* VIA/Wondermedia Universal Asynchronous Receiver/Transmitter (UART)
+
+Required properties:
+- compatible: Should be "via,vt8500-uart"
+- reg: Should contain registers location and length
+- interrupts: Should contain interrupt
+
+Example:
+ uart0: serial@d8200000 {
+ compatible = "via,vt8500-uart";
+ reg = <0xd8200000 0x1040>;
+ interrupts = <32>;
+ };
+
diff --git a/drivers/tty/serial/vt8500_serial.c b/drivers/tty/serial/vt8500_serial.c
index 2be006f..b9ea0b9 100644
--- a/drivers/tty/serial/vt8500_serial.c
+++ b/drivers/tty/serial/vt8500_serial.c
@@ -34,6 +34,7 @@
#include <linux/slab.h>
#include <linux/clk.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
/*
* UART Register offsets
@@ -603,12 +604,18 @@ static int __devexit vt8500_serial_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id vt8500_uart_ids[] = {
+ { .compatible = "via,vt8500-uart", },
+ {}
+};
+
static struct platform_driver vt8500_platform_driver = {
.probe = vt8500_serial_probe,
.remove = __devexit_p(vt8500_serial_remove),
.driver = {
.name = "vt8500_serial",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(vt8500_uart_ids),
},
};
@@ -643,3 +650,4 @@ module_exit(vt8500_serial_exit);
MODULE_AUTHOR("Alexey Charkov <alchark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>");
MODULE_DESCRIPTION("Driver for vt8500 serial device");
MODULE_LICENSE("GPL");
+MODULE_DEVICE_TABLE(of, vt8500_uart_ids);
--
1.7.2.5
^ permalink raw reply related
* [PATCH 2/2] ARM: vt8500: Minor update to vt8500-uart for devicetree support
From: Tony Prisk @ 2012-07-21 11:20 UTC (permalink / raw)
To: Alessandro Zumoo, Alan Cox
Cc: Tony Prisk, Grant Likely, Rob Herring, rtc-linux, linux-kernel,
devicetree-discuss, VT8500 mailing list, Greg Kroah-Hartman,
linux-serial
In-Reply-To: <1342869622-11171-1-git-send-email-linux@prisktech.co.nz>
Signed-off-by: Tony Prisk <linux@prisktech.co.nz>
Acked-by: Arnd Bergmann <arnd@arndb.de>
---
v2:
Split single patch into seperate patches.
.../devicetree/bindings/tty/serial/vt8500-uart.txt | 14 ++++++++++++++
drivers/tty/serial/vt8500_serial.c | 8 ++++++++
2 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/tty/serial/vt8500-uart.txt
diff --git a/Documentation/devicetree/bindings/tty/serial/vt8500-uart.txt b/Documentation/devicetree/bindings/tty/serial/vt8500-uart.txt
new file mode 100644
index 0000000..745070a
--- /dev/null
+++ b/Documentation/devicetree/bindings/tty/serial/vt8500-uart.txt
@@ -0,0 +1,14 @@
+* VIA/Wondermedia Universal Asynchronous Receiver/Transmitter (UART)
+
+Required properties:
+- compatible: Should be "via,vt8500-uart"
+- reg: Should contain registers location and length
+- interrupts: Should contain interrupt
+
+Example:
+ uart0: serial@d8200000 {
+ compatible = "via,vt8500-uart";
+ reg = <0xd8200000 0x1040>;
+ interrupts = <32>;
+ };
+
diff --git a/drivers/tty/serial/vt8500_serial.c b/drivers/tty/serial/vt8500_serial.c
index 2be006f..b9ea0b9 100644
--- a/drivers/tty/serial/vt8500_serial.c
+++ b/drivers/tty/serial/vt8500_serial.c
@@ -34,6 +34,7 @@
#include <linux/slab.h>
#include <linux/clk.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
/*
* UART Register offsets
@@ -603,12 +604,18 @@ static int __devexit vt8500_serial_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id vt8500_uart_ids[] = {
+ { .compatible = "via,vt8500-uart", },
+ {}
+};
+
static struct platform_driver vt8500_platform_driver = {
.probe = vt8500_serial_probe,
.remove = __devexit_p(vt8500_serial_remove),
.driver = {
.name = "vt8500_serial",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(vt8500_uart_ids),
},
};
@@ -643,3 +650,4 @@ module_exit(vt8500_serial_exit);
MODULE_AUTHOR("Alexey Charkov <alchark@gmail.com>");
MODULE_DESCRIPTION("Driver for vt8500 serial device");
MODULE_LICENSE("GPL");
+MODULE_DEVICE_TABLE(of, vt8500_uart_ids);
--
1.7.2.5
^ permalink raw reply related
* [PATCHv2 1/2] ARM: vt8500: Minor update to vt8500-rtc for devicetree support
From: Tony Prisk @ 2012-07-21 11:20 UTC (permalink / raw)
To: Alessandro Zumoo, Alan Cox
Cc: rtc-linux-/JYPxA39Uh5TLH3MbocFFw, Greg Kroah-Hartman,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Rob Herring,
linux-serial-u79uwXL29TY76Z2rM5mHXA, VT8500 mailing list
Signed-off-by: Tony Prisk <linux-ci5G2KO2hbZ+pU9mqzGVBQ@public.gmane.org>
Acked-by: Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
---
v2:
Split single patch into seperate patches.
Correct documentation.
.../devicetree/bindings/rtc/vt8500-rtc.txt | 14 ++++++++++++++
drivers/rtc/rtc-vt8500.c | 8 ++++++++
2 files changed, 22 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/rtc/vt8500-rtc.txt
diff --git a/Documentation/devicetree/bindings/rtc/vt8500-rtc.txt b/Documentation/devicetree/bindings/rtc/vt8500-rtc.txt
new file mode 100644
index 0000000..c764d4d
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/vt8500-rtc.txt
@@ -0,0 +1,14 @@
+* VIA VT8500 and Wondermedia WM8xxx SoC Real-time clock (RTC) Controller
+
+Required properties:
+- compatible : "via,vt8500-rtc"
+- reg : Address range of the rtc registers
+- interrupt: Should contain the rtc interrupt number
+
+Example:
+
+ rtc@d8100000 {
+ compatible = "via,vt8500-rtc";
+ reg = <0xd8100000 0x2c>;
+ interrupts = <48>;
+ };
diff --git a/drivers/rtc/rtc-vt8500.c b/drivers/rtc/rtc-vt8500.c
index 9e94fb1..d21fcd3 100644
--- a/drivers/rtc/rtc-vt8500.c
+++ b/drivers/rtc/rtc-vt8500.c
@@ -23,6 +23,7 @@
#include <linux/bcd.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
+#include <linux/of.h>
/*
* Register definitions
@@ -302,12 +303,18 @@ static int __devexit vt8500_rtc_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id vt8500_rtc_ids[] = {
+ { .compatible = "via,vt8500-rtc", },
+ {}
+};
+
static struct platform_driver vt8500_rtc_driver = {
.probe = vt8500_rtc_probe,
.remove = __devexit_p(vt8500_rtc_remove),
.driver = {
.name = "vt8500-rtc",
.owner = THIS_MODULE,
+ .of_match_table = of_match_ptr(vt8500_rtc_ids),
},
};
@@ -317,3 +324,4 @@ MODULE_AUTHOR("Alexey Charkov <alchark-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>");
MODULE_DESCRIPTION("VIA VT8500 SoC Realtime Clock Driver (RTC)");
MODULE_LICENSE("GPL");
MODULE_ALIAS("platform:vt8500-rtc");
+MODULE_DEVICE_TABLE(of, vt8500_rtc_ids);
--
1.7.2.5
^ permalink raw reply related
* Re: Patch for panic in n_tty_read()
From: Alan Cox @ 2012-07-20 15:11 UTC (permalink / raw)
To: Stanislav Kozina; +Cc: Greg Kroah-Hartman, linux-serial
In-Reply-To: <50094C8E.5010308@redhat.com>
> You mean call to tty_put_user(), correct? Thanks for this catch.
> So what about to unlock the lock for this time? Because we need to hold
> the lock while checking tty->read_cnt in the while loop condition, correct?
I think you are right on that yes.
Alan
^ permalink raw reply
* Re: Patch for panic in n_tty_read()
From: Stanislav Kozina @ 2012-07-20 12:18 UTC (permalink / raw)
To: Alan Cox; +Cc: Greg Kroah-Hartman, linux-serial
In-Reply-To: <20120626152159.2a34dcaf@pyramind.ukuu.org.uk>
Alan,
My apologizes for really late response, I completely missed your email:-/
>> We had few customers who met panics in n_tty_read() with following
>> backtrace:
>>
>> #8 [ffff880018b8dcd0] page_fault at ffffffff814ddfe5
>> [exception RIP: n_tty_read+0x2c9]
>> <register output removed>
>> #9 [ffff880018b8dea0] tty_read at ffffffff81300b16
>> #10 [ffff880018b8def0] vfs_read at ffffffff81172f85
>> #11 [ffff880018b8df30] sys_read at ffffffff811730c1
>> #12 [ffff880018b8df80] system_call_fastpath at ffffffff8100b172
> What serial driver are they using when they hit this ?
From kernel log:
kernel: Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
kernel: serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
kernel: serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
kernel: 00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
kernel: 00:0a: ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
>
>> My patch for this panic is attached (tty_panic.patch), in short - I
>> believe that we need to hold&tty->read_lock while checking
>> tty->read_cnt in while-loop condition in n_tty_read() here:
> We can't hold the lock for the loop because we touch user space memory.
You mean call to tty_put_user(), correct? Thanks for this catch.
So what about to unlock the lock for this time? Because we need to hold
the lock while checking tty->read_cnt in the while loop condition, correct?
Thanks and regards,
-Stanislav Kozina
^ permalink raw reply
* Re: ST16C654 stoppes transmitting after a while
From: Tobias Arp @ 2012-07-20 10:10 UTC (permalink / raw)
To: Tobias Arp, alan; +Cc: linux-serial
In-Reply-To: <20120718063704.130240@gmx.net>
I could track down the problem:
The interrupt if the MSR change (DCTS) gets lost on this point:
An interrupt is handled and CTS changes during transmit_chars() and this change is not recognized.
Is spin_lock_irqsave() too slow (on my platform and this circumstanmces? How can i avoid this ?
in 8250.c:
/*
* This handles the interrupt from one port.
*/
static void serial8250_handle_port(struct uart_8250_port *up)
{
unsigned int status;
unsigned int status2;
unsigned long flags;
spin_lock_irqsave(&up->port.lock, flags);
status = serial_inp(up, UART_LSR);
DEBUG_INTR("status = %x...", status);
if (status & (UART_LSR_DR | UART_LSR_BI))
receive_chars(up, &status);
check_modem_status(up);
if (status & UART_LSR_THRE)
transmit_chars(up);
spin_unlock_irqrestore(&up->port.lock, flags);
}
Thanks
Tobias
-------- Original-Nachricht --------
> Datum: Wed, 18 Jul 2012 08:37:04 +0200
> Von: "Tobias Arp" <tobiasarp@gmx.de>
> An: Alan Cox <alan@lxorguk.ukuu.org.uk>
> CC: linux-serial@vger.kernel.org
> Betreff: Re: ST16C654 stoppes transmitting after a while
> The serial links are all set up to 115200 baud.
>
> Dumping out the tty-struct when it hangs shows me this:
>
> magic: 0x5401
> name: ttyS0
> flags: 0x00000A00
> count: 1
> stopped: 0
> hw_stopped: 1
> flow_stopped: 0
> packet: 0
> low_latency: 0
> warned: 0
> ctrl_status: 0x00
> receive_room: 4095
> ...
>
> It is a little bit strange that always the null modem connection shows
> this behaviour. May be it's because it has the highest data transfer rate (all
> other connections are made by isdn modems / 1-channel isdn)?
>
>
>
>
> -------- Original-Nachricht --------
> > Datum: Tue, 17 Jul 2012 17:38:47 +0100
> > Von: Alan Cox <alan@lxorguk.ukuu.org.uk>
> > An: "Tobias Arp" <tobiasarp@gmx.de>
> > CC: linux-serial@vger.kernel.org
> > Betreff: Re: ST16C654 stoppes transmitting after a while
>
> > On Tue, 17 Jul 2012 13:36:03 +0200
> > "Tobias Arp" <tobiasarp@gmx.de> wrote:
> >
> > > This is a single core arm processor (Cirrus EP9315), could this race
> > condition happen in this case?
> >
> > In theory, otoh it ought to be quite easy to test for.
> >
> > How fast are your links - would it be fair to characterise your
> > environment as a fairly slow CPU handling a lot of fast serial links
> >
> > (just trying to understand what the likely places to look might be)
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-serial"
> in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: ST16C654 stoppes transmitting after a while
From: Tobias Arp @ 2012-07-20 4:25 UTC (permalink / raw)
To: Tobias Arp, alan; +Cc: linux-serial
In-Reply-To: <20120718063704.130240@gmx.net>
BTW:
all interfaces work fine with our old kernel version 2.6.15.
Tobias
-------- Original-Nachricht --------
> Datum: Wed, 18 Jul 2012 08:37:04 +0200
> Von: "Tobias Arp" <tobiasarp@gmx.de>
> An: Alan Cox <alan@lxorguk.ukuu.org.uk>
> CC: linux-serial@vger.kernel.org
> Betreff: Re: ST16C654 stoppes transmitting after a while
> The serial links are all set up to 115200 baud.
>
> Dumping out the tty-struct when it hangs shows me this:
>
> magic: 0x5401
> name: ttyS0
> flags: 0x00000A00
> count: 1
> stopped: 0
> hw_stopped: 1
> flow_stopped: 0
> packet: 0
> low_latency: 0
> warned: 0
> ctrl_status: 0x00
> receive_room: 4095
> ...
>
> It is a little bit strange that always the null modem connection shows
> this behaviour. May be it's because it has the highest data transfer rate (all
> other connections are made by isdn modems / 1-channel isdn)?
>
>
>
>
> -------- Original-Nachricht --------
> > Datum: Tue, 17 Jul 2012 17:38:47 +0100
> > Von: Alan Cox <alan@lxorguk.ukuu.org.uk>
> > An: "Tobias Arp" <tobiasarp@gmx.de>
> > CC: linux-serial@vger.kernel.org
> > Betreff: Re: ST16C654 stoppes transmitting after a while
>
> > On Tue, 17 Jul 2012 13:36:03 +0200
> > "Tobias Arp" <tobiasarp@gmx.de> wrote:
> >
> > > This is a single core arm processor (Cirrus EP9315), could this race
> > condition happen in this case?
> >
> > In theory, otoh it ought to be quite easy to test for.
> >
> > How fast are your links - would it be fair to characterise your
> > environment as a fairly slow CPU handling a lot of fast serial links
> >
> > (just trying to understand what the likely places to look might be)
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-serial"
> in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: ST16C654 stoppes transmitting after a while
From: Tobias Arp @ 2012-07-18 11:16 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-serial
In-Reply-To: <20120718120842.6bdc0fd8@pyramind.ukuu.org.uk>
On Wed, 18 Jul 2012 09:45:30 +0200 "Tobias Arp" <tobiasarp@gmx.de> wrote:
>> The problem occurs very quick by setting the baud rate to 230400 on a single null modem connection (without usunign the orher ports of the quad uart). So i would say you are right with your guess...
>>> magic: 0x5401
>>> name: ttyS0
>>> flags: 0x00000A00
>>> count: 1
>>> stopped: 0
>>> hw_stopped: 1
>>> flow_stopped: 0
>>> packet: 0
>>> low_latency: 0
>>> warned: 0
>>> ctrl_status: 0x00
>>> receive_room: 4095
> Ok that's not quite what I had expected to see
>
> So the port is in use, not stopped at the higher levels and has lots of
> receiver room as expected.
>
> The hw_stopped flag is the hardware state - so somehow we've missed a
> transition on the flow control or the UART hasn't bothered reporting it
> or the IRQ got lost.
>
> When it jams transmitting does it unjam if you send a single character
> the other way ?
>
> Alan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
No it doesn't unjam be sending a single character from the remote side.
It only unjams after plug out and plugin the
null modem cable (so an IRQ is generated caused by the DCD change or CTS
change while replugin the cable).
^ permalink raw reply
* Re: ST16C654 stoppes transmitting after a while
From: Alan Cox @ 2012-07-18 11:08 UTC (permalink / raw)
To: Tobias Arp; +Cc: linux-serial
In-Reply-To: <20120718074530.17620@gmx.net>
On Wed, 18 Jul 2012 09:45:30 +0200
"Tobias Arp" <tobiasarp@gmx.de> wrote:
> The problem occurs very quick by setting the baud rate to 230400 on a single null modem connection (without usunign the orher ports of the quad uart). So i would say you are right with your guess...
> > magic: 0x5401
> > name: ttyS0
> > flags: 0x00000A00
> > count: 1
> > stopped: 0
> > hw_stopped: 1
> > flow_stopped: 0
> > packet: 0
> > low_latency: 0
> > warned: 0
> > ctrl_status: 0x00
> > receive_room: 4095
Ok that's not quite what I had expected to see
So the port is in use, not stopped at the higher levels and has lots of
receiver room as expected.
The hw_stopped flag is the hardware state - so somehow we've missed a
transition on the flow control or the UART hasn't bothered reporting it
or the IRQ got lost.
When it jams transmitting does it unjam if you send a single character
the other way ?
Alan
^ permalink raw reply
* Re: ST16C654 stoppes transmitting after a while
From: Tobias Arp @ 2012-07-18 7:45 UTC (permalink / raw)
To: Tobias Arp, alan; +Cc: linux-serial
In-Reply-To: <20120718063704.130240@gmx.net>
The problem occurs very quick by setting the baud rate to 230400 on a single null modem connection (without usunign the orher ports of the quad uart). So i would say you are right with your guess...
-------- Original-Nachricht --------
> Datum: Wed, 18 Jul 2012 08:37:04 +0200
> Von: "Tobias Arp" <tobiasarp@gmx.de>
> An: Alan Cox <alan@lxorguk.ukuu.org.uk>
> CC: linux-serial@vger.kernel.org
> Betreff: Re: ST16C654 stoppes transmitting after a while
> The serial links are all set up to 115200 baud.
>
> Dumping out the tty-struct when it hangs shows me this:
>
> magic: 0x5401
> name: ttyS0
> flags: 0x00000A00
> count: 1
> stopped: 0
> hw_stopped: 1
> flow_stopped: 0
> packet: 0
> low_latency: 0
> warned: 0
> ctrl_status: 0x00
> receive_room: 4095
> ...
>
> It is a little bit strange that always the null modem connection shows
> this behaviour. May be it's because it has the highest data transfer rate (all
> other connections are made by isdn modems / 1-channel isdn)?
>
>
>
>
> -------- Original-Nachricht --------
> > Datum: Tue, 17 Jul 2012 17:38:47 +0100
> > Von: Alan Cox <alan@lxorguk.ukuu.org.uk>
> > An: "Tobias Arp" <tobiasarp@gmx.de>
> > CC: linux-serial@vger.kernel.org
> > Betreff: Re: ST16C654 stoppes transmitting after a while
>
> > On Tue, 17 Jul 2012 13:36:03 +0200
> > "Tobias Arp" <tobiasarp@gmx.de> wrote:
> >
> > > This is a single core arm processor (Cirrus EP9315), could this race
> > condition happen in this case?
> >
> > In theory, otoh it ought to be quite easy to test for.
> >
> > How fast are your links - would it be fair to characterise your
> > environment as a fairly slow CPU handling a lot of fast serial links
> >
> > (just trying to understand what the likely places to look might be)
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-serial"
> in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: ST16C654 stoppes transmitting after a while
From: Tobias Arp @ 2012-07-18 6:37 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-serial
In-Reply-To: <20120717173847.1c5b4863@pyramind.ukuu.org.uk>
The serial links are all set up to 115200 baud.
Dumping out the tty-struct when it hangs shows me this:
magic: 0x5401
name: ttyS0
flags: 0x00000A00
count: 1
stopped: 0
hw_stopped: 1
flow_stopped: 0
packet: 0
low_latency: 0
warned: 0
ctrl_status: 0x00
receive_room: 4095
...
It is a little bit strange that always the null modem connection shows this behaviour. May be it's because it has the highest data transfer rate (all other connections are made by isdn modems / 1-channel isdn)?
-------- Original-Nachricht --------
> Datum: Tue, 17 Jul 2012 17:38:47 +0100
> Von: Alan Cox <alan@lxorguk.ukuu.org.uk>
> An: "Tobias Arp" <tobiasarp@gmx.de>
> CC: linux-serial@vger.kernel.org
> Betreff: Re: ST16C654 stoppes transmitting after a while
> On Tue, 17 Jul 2012 13:36:03 +0200
> "Tobias Arp" <tobiasarp@gmx.de> wrote:
>
> > This is a single core arm processor (Cirrus EP9315), could this race
> condition happen in this case?
>
> In theory, otoh it ought to be quite easy to test for.
>
> How fast are your links - would it be fair to characterise your
> environment as a fairly slow CPU handling a lot of fast serial links
>
> (just trying to understand what the likely places to look might be)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: ST16C654 stoppes transmitting after a while
From: Alan Cox @ 2012-07-17 16:38 UTC (permalink / raw)
To: Tobias Arp; +Cc: linux-serial
In-Reply-To: <20120717113603.9830@gmx.net>
On Tue, 17 Jul 2012 13:36:03 +0200
"Tobias Arp" <tobiasarp@gmx.de> wrote:
> This is a single core arm processor (Cirrus EP9315), could this race condition happen in this case?
In theory, otoh it ought to be quite easy to test for.
How fast are your links - would it be fair to characterise your
environment as a fairly slow CPU handling a lot of fast serial links
(just trying to understand what the likely places to look might be)
^ permalink raw reply
* Re: [PATCH v2 11/11] MAINTAINERS: add fblog entry
From: David Herrmann @ 2012-07-17 13:15 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: linux-serial, linux-kernel, florianschandinat, linux-fbdev,
gregkh, alan, bonbons
In-Reply-To: <CAMuHMdXFfMv-DV-89nueyDJ5AvFN3AXR_6ysWOfCMDFL46s-Cg@mail.gmail.com>
Hi Geert
On Tue, Jul 17, 2012 at 2:57 PM, Geert Uytterhoeven
<geert@linux-m68k.org> wrote:
> On Mon, Jul 9, 2012 at 8:38 PM, David Herrmann
> <dh.herrmann@googlemail.com> wrote:
>>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>>> index ae8fe46..249b02a 100644
>>>> --- a/MAINTAINERS
>>>> +++ b/MAINTAINERS
>>>> @@ -2854,6 +2854,12 @@ F: drivers/video/
>>>> F: include/video/
>>>> F: include/linux/fb.h
>>>>
>>>> +FRAMEBUFFER LOG DRIVER
>>>> +M: David Herrmann <dh.herrmann@googlemail.com>
>>>> +L: linux-serial@vger.kernel.org
>>>
>>> Why linux-serial, and not linux-fbdev?
>>
>> I thought fbcon was maintained on linux-serial as it is very related
>
> It has always been maintained on linux-fbdev.
Thanks! Then I will change this to linux-fbdev.
Regards
David
^ permalink raw reply
* Re: [PATCH v2 11/11] MAINTAINERS: add fblog entry
From: Geert Uytterhoeven @ 2012-07-17 12:57 UTC (permalink / raw)
To: David Herrmann
Cc: linux-serial, linux-kernel, florianschandinat, linux-fbdev,
gregkh, alan, bonbons
In-Reply-To: <CANq1E4RyFpqxH=uG+dDA1=kfc3r8rCoEesZ31op9rCLjxyk6mQ@mail.gmail.com>
On Mon, Jul 9, 2012 at 8:38 PM, David Herrmann
<dh.herrmann@googlemail.com> wrote:
>>> diff --git a/MAINTAINERS b/MAINTAINERS
>>> index ae8fe46..249b02a 100644
>>> --- a/MAINTAINERS
>>> +++ b/MAINTAINERS
>>> @@ -2854,6 +2854,12 @@ F: drivers/video/
>>> F: include/video/
>>> F: include/linux/fb.h
>>>
>>> +FRAMEBUFFER LOG DRIVER
>>> +M: David Herrmann <dh.herrmann@googlemail.com>
>>> +L: linux-serial@vger.kernel.org
>>
>> Why linux-serial, and not linux-fbdev?
>
> I thought fbcon was maintained on linux-serial as it is very related
It has always been maintained on linux-fbdev.
> to the vt/tty layer. If linux-fbdev is the better place, I can move
> this. I CC'ed both lists, anyway.
> I have actually no idea where it fits in best.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* CONGRATULATIONS
From: ANGLO AMERICAN SA ONLINE @ 2012-07-17 11:56 UTC (permalink / raw)
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: ANGLO AMERICA SA ONLNE.doc --]
[-- Type: application/msword, Size: 21504 bytes --]
^ permalink raw reply
* Re: ST16C654 stoppes transmitting after a while
From: Tobias Arp @ 2012-07-17 11:36 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-serial
In-Reply-To: <20120717122140.075aa7ae@pyramind.ukuu.org.uk>
This is a single core arm processor (Cirrus EP9315), could this race condition happen in this case?
But i have CONFIG PRREMPT set. Shall i take a stab on it by switching it to off?
Tobias
-------- Original-Nachricht --------
> Datum: Tue, 17 Jul 2012 12:21:40 +0100
> Von: Alan Cox <alan@lxorguk.ukuu.org.uk>
> An: "Tobias Arp" <tobiasarp@gmx.de>
> CC: linux-serial@vger.kernel.org
> Betreff: Re: ST16C654 stoppes transmitting after a while
> On Tue, 17 Jul 2012 12:05:21 +0200
> "Tobias Arp" <tobiasarp@gmx.de> wrote:
>
> > I run kernel 3.2. Upgrading to a newer kernel would be not se easy at
> the moment.
>
> 3.2 is certainly new enough that it should have all the major fixes in.
>
> > I am not sure how to check if this change is really lost.
>
> With a debugger dump the state of the port structures one the hung port
> once it has hung. Something like Red Hat's systemtap might also be very
> helpful in doing this kind of monitoring.
>
> My first guess would be that you hit a race between the port stopping on
> one processor and the flow control event on another. We have one known
> case there still being debugged but I thought it could only be hit if you
> were using ttys in low latency mode.
>
> Alan
^ permalink raw reply
* Re: ST16C654 stoppes transmitting after a while
From: Alan Cox @ 2012-07-17 11:21 UTC (permalink / raw)
To: Tobias Arp; +Cc: linux-serial
In-Reply-To: <20120717100521.219440@gmx.net>
On Tue, 17 Jul 2012 12:05:21 +0200
"Tobias Arp" <tobiasarp@gmx.de> wrote:
> I run kernel 3.2. Upgrading to a newer kernel would be not se easy at the moment.
3.2 is certainly new enough that it should have all the major fixes in.
> I am not sure how to check if this change is really lost.
With a debugger dump the state of the port structures one the hung port
once it has hung. Something like Red Hat's systemtap might also be very
helpful in doing this kind of monitoring.
My first guess would be that you hit a race between the port stopping on
one processor and the flow control event on another. We have one known
case there still being debugged but I thought it could only be hit if you
were using ttys in low latency mode.
Alan
^ permalink raw reply
* Re: ST16C654 stoppes transmitting after a while
From: Tobias Arp @ 2012-07-17 10:05 UTC (permalink / raw)
To: Alan Cox; +Cc: linux-serial
In-Reply-To: <20120717105229.17b578a5@pyramind.ukuu.org.uk>
I run kernel 3.2. Upgrading to a newer kernel would be not se easy at the moment.
I am not sure how to check if this change is really lost.
-------- Original-Nachricht --------
> Datum: Tue, 17 Jul 2012 10:52:29 +0100
> Von: Alan Cox <alan@lxorguk.ukuu.org.uk>
> An: "Tobias Arp" <tobiasarp@gmx.de>
> CC: linux-serial@vger.kernel.org
> Betreff: Re: ST16C654 stoppes transmitting after a while
> > I found out that the hw_stopped flag is set to 1 but not set to 0 again
> although CTS is set (measuring with the oscilloscope and reading out the
> modem status register are confirming this / i modified the
> serial8250_get_mctrl function to print out these values).
> >
> > It seems to me that an CTS change (UART_MSR_DCTS) is lost.
> > Could this cause this behaviour?
>
> Possibly you'd need to instrument your kernel as well to prove it. It
> could also be a race in the kernel drivers somewhere. We certainly had
> those in old kernels here and there.
>
> > Any suggestions for a workaround are appreciated.
>
> What kernel are you running ?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-serial" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: ST16C654 stoppes transmitting after a while
From: Alan Cox @ 2012-07-17 9:52 UTC (permalink / raw)
To: Tobias Arp; +Cc: linux-serial
In-Reply-To: <20120717074355.80180@gmx.net>
> I found out that the hw_stopped flag is set to 1 but not set to 0 again although CTS is set (measuring with the oscilloscope and reading out the modem status register are confirming this / i modified the serial8250_get_mctrl function to print out these values).
>
> It seems to me that an CTS change (UART_MSR_DCTS) is lost.
> Could this cause this behaviour?
Possibly you'd need to instrument your kernel as well to prove it. It
could also be a race in the kernel drivers somewhere. We certainly had
those in old kernels here and there.
> Any suggestions for a workaround are appreciated.
What kernel are you running ?
^ permalink raw reply
* ST16C654 stoppes transmitting after a while
From: Tobias Arp @ 2012-07-17 7:43 UTC (permalink / raw)
To: linux-serial
Hi,
we use on our system (ARM board Processor EP9315) a quad uart (ST16C654) with kernel 3.2 (the quad uart is connected only to one irq, so the four interfaces of the quad uart have to share this irq). Multiple simultanous connections are working fine for some hours (3 Modem connections and one null modem connection / transferring data in both directions with hardware handshake (CRTSCTS) enabled). Then one connection can't send data to the remote host anymore (often the null modem connection). The driver is the 8250 serial driver.
I found out that the hw_stopped flag is set to 1 but not set to 0 again although CTS is set (measuring with the oscilloscope and reading out the modem status register are confirming this / i modified the serial8250_get_mctrl function to print out these values).
It seems to me that an CTS change (UART_MSR_DCTS) is lost.
Could this cause this behaviour?
Any suggestions for a workaround are appreciated.
Thanks in advance
Tobias
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox