* Re: [PATCH] usb: cp210x: Added support for GPIO (CP2103/4/5)
From: Greg KH @ 2012-05-16 23:41 UTC (permalink / raw)
To: Alan Cox
Cc: Preston Fick, linux-usb-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
preston.fick-S6d6foEdJf7QT0dZR+AlfA,
linux-arm-kernel-xIg/pKzrS19vn6HldHNs0ANdhmdF6hFW@public.gmane.org
In-Reply-To: <20120516163347.1721406e-38n7/U1jhRXW96NNrWNlrekiAK3p4hvP@public.gmane.org>
On Wed, May 16, 2012 at 04:33:47PM +0100, Alan Cox wrote:
> So the patch looks like this, which seems nice and compact (UNTESTED)
>
> commit 4164f9b7074e682fe71dad3b57e78521ef9df492
> Author: Alan Cox <alan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
> Date: Wed May 16 15:13:02 2012 +0100
>
> tty: Add a gpio helper set
>
> Various tty devices have additional control lines which are sometimes used
> as GPIO pins and sometimes also tied with the serial port to implement
> protocols such as ISO7816.
>
> This code provides a kernel interface for querying the GPIO range of a tty,
> and to describe the mapping between GPIO pins and control lines. The latter
> will be needed for some upcoming line discipline support.
>
> [Proposal do not merge yet]
>
> Not-Signed-off-by: Alan Cox <alan-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
Wow, that looks really nice and tiny, if that's all that is needed in
the core, that's great.
> diff --git a/drivers/tty/tty_ioctl.c b/drivers/tty/tty_ioctl.c
> index a1b9a2f..60550e7 100644
> --- a/drivers/tty/tty_ioctl.c
> +++ b/drivers/tty/tty_ioctl.c
> @@ -1071,6 +1071,39 @@ int tty_mode_ioctl(struct tty_struct *tty, struct file *file,
> case TCSETXF:
> return set_termiox(real_tty, p, TERMIOS_FLUSH);
> #endif
> +#ifdef TCGGPIO
> + case TCGGPIO: {
> + struct tcgpio gpio;
> +
> + if (tty->gpio == NULL)
> + return -EOPNOTSUPP;
> + mutex_lock(&real_tty->termios_mutex);
> + memset(&gpio, 0, sizeof(gpio));
> + gpio.base = tty->gpio->base;
> + gpio.num = tty->gpio->num;
> + memcpy(gpio.map, tty->gpio->map, sizeof(gpio.map));
> + mutex_unlock(&real_tty->termios_mutex);
> + if (copy_to_user(p, &gpio, sizeof(gpio)))
> + return -EFAULT;
> + return 0;
> + }
> + case TCSGPIO:
> + {
> + struct tcgpio gpio;
> +
> + if (tty->gpio == NULL)
> + return -EOPNOTSUPP;
> + if (copy_from_user(&gpio, p, sizeof(gpio)))
> + return -EFAULT;
> + mutex_lock(&real_tty->termios_mutex);
> + memcpy(tty->gpio->map, gpio.map, sizeof(tty->gpio->map));
> + /* An ldisc can see this by watching the ioctl go through
> + but we may want to add a hook */
> + mutex_unlock(&real_tty->termios_mutex);
> + return 0;
So how would the lower tty driver get the ioctl to know to now set these
values to the hardware? I think we at least need a hook for that,
right? Or would that go through the ldisc?
> + }
> +
> +#endif
> case TIOCGSOFTCAR:
> copy_termios(real_tty, &kterm);
> ret = put_user((kterm.c_cflag & CLOCAL) ? 1 : 0,
> diff --git a/include/asm-generic/ioctls.h b/include/asm-generic/ioctls.h
> index 199975f..fee17d3 100644
> --- a/include/asm-generic/ioctls.h
> +++ b/include/asm-generic/ioctls.h
> @@ -74,6 +74,8 @@
> #define TCSETXW 0x5435
> #define TIOCSIG _IOW('T', 0x36, int) /* pty: generate signal */
> #define TIOCVHANGUP 0x5437
> +#define TCGGPIO _IOR('T', 0x38, struct tcgpio)
> +#define TCSGPIO _IOW('T', 0x39, struct tcgpio)
>
> #define FIONCLEX 0x5450
> #define FIOCLEX 0x5451
> diff --git a/include/asm-generic/termios.h b/include/asm-generic/termios.h
> index d0922ad..3adda38 100644
> --- a/include/asm-generic/termios.h
> +++ b/include/asm-generic/termios.h
> @@ -18,6 +18,18 @@ struct winsize {
> unsigned short ws_ypixel;
> };
>
> +
> +/* GPIO handling */
> +#define NR_TTY_GPIOMAP 8
> +struct tcgpio /* User copied version */
> +{
> + u32 base;
> + u16 num;
> + u16 reserved;
> + u32 map[NR_TTY_GPIOMAP];
> + u32 reserved2[6];
> +};
__u32 and friends instead?
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: kmscon: replacing CONFIG_VT
From: Alan Cox @ 2012-05-16 16:14 UTC (permalink / raw)
To: David Herrmann; +Cc: linux-serial, Greg Kroah-Hartman
In-Reply-To: <CANq1E4SGoRZaGjNZqPOA6g4COQmXxNr4kFBPMhxAonZqO_aOtQ@mail.gmail.com>
> That's just some of my ideas on this topic. Maybe you can give me some
> hints whether it actually makes sense ;)
For a lot of hardware it may not matter. If it goes bang you boot with a
debugging kernel (one containing a vt driver)
If your user space goes castors up early then you are going to need input
facilities anyway (consider the fedora rescue mode in dracut for example)
As far as compatibility goes we have the ttyprintk driver which just
provides a fake tty which types nothing and whose output goes to the
console.
Alan
^ permalink raw reply
* kmscon: replacing CONFIG_VT
From: David Herrmann @ 2012-05-16 15:58 UTC (permalink / raw)
To: linux-serial; +Cc: Greg Kroah-Hartman, Alan Cox
Hi
I am currently working on replacing the VT layer with a user-space
implementation called "kmscon". It is based on KMS/DRM to control the
video display. I can now successfully run it with CONFIG_VT disabled
and a few hacks to avoid using /dev/ttyX in kmscon.
The idea is to move UI code out of the kernel and getting a full VT520
terminal (full Unicode/font support) implemented in user-space. There
are some other advantages that I will skip here.
I am now working on replacing missing features of the kernel VT. I've
had some deeper look into drivers/tty/vt/ and drivers/video/console/.
The main feature that is missing with CONFIG_VT=n is definitely an
(early-)boot console driver. fbcon and vgacon both provide the consw
driver which then provides the console driver. However, without consw
(tied to VTs) there will also be no
console driver.
I was wondering what the best way to replace them is. I could rewrite
fbcon.c to provide a "struct console" driver instead of a whole consw
driver. Or I could write a drmcon driver that uses the drm api to
provide a console driver. As KMSCON currently runs with DRM only, it
wouldn't matter that drmcon would depend on DRM, too. In short: I need
some shortcut from vgacon/fbcon directly to "struct console" and
dropping the VT-layer in between.
The driver itself would be pretty simply. It would have a ring-buffer
for the messages that are currently printed to the screen and rotate
it as new messages come in. It could then print it via drm
mode-setting if there is currently no other drm application running.
That is, if X/wayland/kmscon shows up, the drmcon driver will go to
sleep and do nothing. kmscon can then read /dev/kmsg and print the
messages if it wants to. If kmscon exits, drmcon will take over and
print the messages again.
Other parts missing with CONFIG_VT=n are probably some ioctls which
won't work with pty. However, all applications that run in xterm will
also run in kmscon. Only applications that use linux ioctl's will not.
However, I don't think that these are needed, but I will watch
carefully while testing it.
That's just some of my ideas on this topic. Maybe you can give me some
hints whether it actually makes sense ;)
Regards
David
^ permalink raw reply
* Re: [PATCH] usb: cp210x: Added support for GPIO (CP2103/4/5)
From: Alan Cox @ 2012-05-16 15:33 UTC (permalink / raw)
To: Greg KH
Cc: Preston Fick, linux-usb, linux-kernel, linux-serial, preston.fick,
linux-arm-kernel@lists.arm.linux.org.uk
In-Reply-To: <20120505003208.GA30718@kroah.com>
So the patch looks like this, which seems nice and compact (UNTESTED)
commit 4164f9b7074e682fe71dad3b57e78521ef9df492
Author: Alan Cox <alan@linux.intel.com>
Date: Wed May 16 15:13:02 2012 +0100
tty: Add a gpio helper set
Various tty devices have additional control lines which are sometimes used
as GPIO pins and sometimes also tied with the serial port to implement
protocols such as ISO7816.
This code provides a kernel interface for querying the GPIO range of a tty,
and to describe the mapping between GPIO pins and control lines. The latter
will be needed for some upcoming line discipline support.
[Proposal do not merge yet]
Not-Signed-off-by: Alan Cox <alan@linux.intel.com>
diff --git a/drivers/tty/tty_ioctl.c b/drivers/tty/tty_ioctl.c
index a1b9a2f..60550e7 100644
--- a/drivers/tty/tty_ioctl.c
+++ b/drivers/tty/tty_ioctl.c
@@ -1071,6 +1071,39 @@ int tty_mode_ioctl(struct tty_struct *tty, struct file *file,
case TCSETXF:
return set_termiox(real_tty, p, TERMIOS_FLUSH);
#endif
+#ifdef TCGGPIO
+ case TCGGPIO: {
+ struct tcgpio gpio;
+
+ if (tty->gpio == NULL)
+ return -EOPNOTSUPP;
+ mutex_lock(&real_tty->termios_mutex);
+ memset(&gpio, 0, sizeof(gpio));
+ gpio.base = tty->gpio->base;
+ gpio.num = tty->gpio->num;
+ memcpy(gpio.map, tty->gpio->map, sizeof(gpio.map));
+ mutex_unlock(&real_tty->termios_mutex);
+ if (copy_to_user(p, &gpio, sizeof(gpio)))
+ return -EFAULT;
+ return 0;
+ }
+ case TCSGPIO:
+ {
+ struct tcgpio gpio;
+
+ if (tty->gpio == NULL)
+ return -EOPNOTSUPP;
+ if (copy_from_user(&gpio, p, sizeof(gpio)))
+ return -EFAULT;
+ mutex_lock(&real_tty->termios_mutex);
+ memcpy(tty->gpio->map, gpio.map, sizeof(tty->gpio->map));
+ /* An ldisc can see this by watching the ioctl go through
+ but we may want to add a hook */
+ mutex_unlock(&real_tty->termios_mutex);
+ return 0;
+ }
+
+#endif
case TIOCGSOFTCAR:
copy_termios(real_tty, &kterm);
ret = put_user((kterm.c_cflag & CLOCAL) ? 1 : 0,
diff --git a/include/asm-generic/ioctls.h b/include/asm-generic/ioctls.h
index 199975f..fee17d3 100644
--- a/include/asm-generic/ioctls.h
+++ b/include/asm-generic/ioctls.h
@@ -74,6 +74,8 @@
#define TCSETXW 0x5435
#define TIOCSIG _IOW('T', 0x36, int) /* pty: generate signal */
#define TIOCVHANGUP 0x5437
+#define TCGGPIO _IOR('T', 0x38, struct tcgpio)
+#define TCSGPIO _IOW('T', 0x39, struct tcgpio)
#define FIONCLEX 0x5450
#define FIOCLEX 0x5451
diff --git a/include/asm-generic/termios.h b/include/asm-generic/termios.h
index d0922ad..3adda38 100644
--- a/include/asm-generic/termios.h
+++ b/include/asm-generic/termios.h
@@ -18,6 +18,18 @@ struct winsize {
unsigned short ws_ypixel;
};
+
+/* GPIO handling */
+#define NR_TTY_GPIOMAP 8
+struct tcgpio /* User copied version */
+{
+ u32 base;
+ u16 num;
+ u16 reserved;
+ u32 map[NR_TTY_GPIOMAP];
+ u32 reserved2[6];
+};
+
#define NCC 8
struct termio {
unsigned short c_iflag; /* input mode flags */
diff --git a/include/linux/tty.h b/include/linux/tty.h
index 9f47ab5..19daf03 100644
--- a/include/linux/tty.h
+++ b/include/linux/tty.h
@@ -243,6 +243,18 @@ struct tty_port {
};
/*
+ * GPIO block, optional
+ */
+
+struct tty_kgpio /* Kernel gpio struct */
+{
+ u32 base;
+ u16 num;
+ u16 reserved;
+ u32 map[NR_TTY_GPIOMAP];
+};
+
+/*
* Where all of the state associated with a tty is kept while the tty
* is open. Since the termios state should be kept even if the tty
* has been closed --- for things like the baud rate, etc --- it is
@@ -331,6 +343,8 @@ struct tty_struct {
/* If the tty has a pending do_SAK, queue it here - akpm */
struct work_struct SAK_work;
struct tty_port *port;
+
+ struct tty_kgpio *gpio; /* Optional */
};
/* Each of a tty's open files has private_data pointing to tty_file_private */
^ permalink raw reply related
* Re: Excessive logging causing rcu_sched_state stall (wait_for_xmitr 8250.c)
From: Greg KH @ 2012-05-16 15:12 UTC (permalink / raw)
To: joe shmoe; +Cc: linux-serial
In-Reply-To: <1337128888.46194.YahooMailNeo@web160804.mail.bf1.yahoo.com>
On Tue, May 15, 2012 at 05:41:28PM -0700, joe shmoe wrote:
> Hi,
> It's been more than a week since I am stuck with this. I am relatively a newbie venturing into linux
> kernel, so please be gentle.
>
> I have a non-tained 2.6.35.14 kernel that needs to output a lot using the serial console. To reproduce I
> simply run klogd -2 -c 7 and this causes rcu_sched_state to detect stall with a trace such as pasted
> below.
Does running 3.3, or 3.4-rc6 show the same problems? I ask as 2.6.35
really is very old and not supported much at all, and tens of thousands
of changes to the kernel have happened since then.
So if you could check the latest kernel, that would be great.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/2] serial/imx: add DMA support
From: Huang Shijie @ 2012-05-16 9:42 UTC (permalink / raw)
To: Philippe Rétornaz
Cc: linux-arm-kernel, Sascha Hauer, B20596, B20223, gregkh, r58066,
linux-serial, shawn.guo, alan
In-Reply-To: <4474267.dxHCC3PlP5@laptop>
于 2012年05月16日 17:37, Philippe Rétornaz 写道:
> Does this mean that there is no hope for a working uart dma on imx31 ?
yes.
only works in mx6q now.
BR
Huang Shijie
--
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 1/2] serial/imx: add DMA support
From: Philippe Rétornaz @ 2012-05-16 9:37 UTC (permalink / raw)
To: linux-arm-kernel
Cc: B20596, B20223, gregkh, Sascha Hauer, Huang Shijie, linux-serial,
shawn.guo, r58066, alan
In-Reply-To: <4F9A3831.1020203@freescale.com>
Le vendredi 27 avril 2012 14:09:53 Huang Shijie a écrit :
> Hi,
>
> >> +/* see the "i.MX61 SDMA Scripts User Manual.doc" for the parameters */
> >
> > I can't see how the manual helps here.
>
> sorry, the comment is in the wrong place. it should placed at
> configuring the `slave_config`.
>
> > Please test this patch at least on one more SoC. There should be nothing
> > i.MX6 specific in here, the fact that the i.MX6 is mentioned several
> > times in the comments make me suspicious.
>
> There are bugs in the UART DMA code in the firmware before the imx6q.
> So we can not test the UART DMA except the imx6q arm2 board.
Does this mean that there is no hope for a working uart dma on imx31 ?
Thanks,
Philippe
^ permalink raw reply
* [PATCH 3/4] serial: bfin_uart: RTS and CTS MMRs can be either 16-bit width or 32-bit width.
From: Sonic Zhang @ 2012-05-16 6:22 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-serial
Cc: LKML, uclinux-dist-devel, Sonic Zhang, Bob Liu
In-Reply-To: <1337149346-5277-1-git-send-email-sonic.adi@gmail.com>
From: Sonic Zhang <sonic.zhang@analog.com>
Change hardware flow control code to adapt to both bf5xx and bf60x.
Disabled serial device before set termios for bf60x.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Bob Liu <lliubbo@gmail.com>
---
drivers/tty/serial/bfin_uart.c | 22 ++++++++++------------
1 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/tty/serial/bfin_uart.c b/drivers/tty/serial/bfin_uart.c
index 56b95b0..7924ba6 100644
--- a/drivers/tty/serial/bfin_uart.c
+++ b/drivers/tty/serial/bfin_uart.c
@@ -549,7 +549,7 @@ static irqreturn_t bfin_serial_dma_tx_int(int irq, void *dev_id)
static irqreturn_t bfin_serial_dma_rx_int(int irq, void *dev_id)
{
struct bfin_serial_port *uart = dev_id;
- unsigned short irqstat;
+ unsigned int irqstat;
int x_pos, pos;
spin_lock(&uart->rx_lock);
@@ -582,7 +582,7 @@ static irqreturn_t bfin_serial_dma_rx_int(int irq, void *dev_id)
static unsigned int bfin_serial_tx_empty(struct uart_port *port)
{
struct bfin_serial_port *uart = (struct bfin_serial_port *)port;
- unsigned short lsr;
+ unsigned int lsr;
lsr = UART_GET_LSR(uart);
if (lsr & TEMT)
@@ -741,7 +741,7 @@ static int bfin_serial_startup(struct uart_port *port)
}
/* CTS RTS PINs are negative assertive. */
- UART_PUT_MCR(uart, ACTS);
+ UART_PUT_MCR(uart, UART_GET_MCR(uart) | ACTS);
UART_SET_IER(uart, EDSSI);
}
#endif
@@ -799,7 +799,7 @@ bfin_serial_set_termios(struct uart_port *port, struct ktermios *termios,
struct bfin_serial_port *uart = (struct bfin_serial_port *)port;
unsigned long flags;
unsigned int baud, quot;
- unsigned short val, ier, lcr = 0;
+ unsigned int ier, lcr = 0;
switch (termios->c_cflag & CSIZE) {
case CS8:
@@ -871,6 +871,7 @@ bfin_serial_set_termios(struct uart_port *port, struct ktermios *termios,
/* Disable UART */
ier = UART_GET_IER(uart);
+ UART_PUT_GCTL(uart, UART_GET_GCTL(uart) & ~UCEN);
UART_DISABLE_INTS(uart);
/* Set DLAB in LCR to Access CLK */
@@ -882,14 +883,11 @@ bfin_serial_set_termios(struct uart_port *port, struct ktermios *termios,
/* Clear DLAB in LCR to Access THR RBR IER */
UART_CLEAR_DLAB(uart);
- UART_PUT_LCR(uart, lcr);
+ UART_PUT_LCR(uart, (UART_GET_LCR(uart) & ~LCR_MASK) | lcr);
/* Enable UART */
UART_ENABLE_INTS(uart, ier);
-
- val = UART_GET_GCTL(uart);
- val |= UCEN;
- UART_PUT_GCTL(uart, val);
+ UART_PUT_GCTL(uart, UART_GET_GCTL(uart) | UCEN);
/* Port speed changed, update the per-port timeout. */
uart_update_timeout(port, termios->c_cflag, baud);
@@ -949,7 +947,7 @@ bfin_serial_verify_port(struct uart_port *port, struct serial_struct *ser)
static void bfin_serial_set_ldisc(struct uart_port *port, int ld)
{
struct bfin_serial_port *uart = (struct bfin_serial_port *)port;
- unsigned short val;
+ unsigned int val;
switch (ld) {
case N_IRDA:
@@ -967,7 +965,7 @@ static void bfin_serial_set_ldisc(struct uart_port *port, int ld)
static void bfin_serial_reset_irda(struct uart_port *port)
{
struct bfin_serial_port *uart = (struct bfin_serial_port *)port;
- unsigned short val;
+ unsigned int val;
val = UART_GET_GCTL(uart);
val &= ~(UMOD_MASK | RPOLC);
@@ -1065,7 +1063,7 @@ static void __init
bfin_serial_console_get_options(struct bfin_serial_port *uart, int *baud,
int *parity, int *bits)
{
- unsigned short status;
+ unsigned int status;
status = UART_GET_IER(uart) & (ERBFI | ETBEI);
if (status == (ERBFI | ETBEI)) {
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/4] serial: bfin_uart: narrow the reboot condition in DMA tx interrupt
From: Sonic Zhang @ 2012-05-16 6:22 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-serial; +Cc: LKML, uclinux-dist-devel, Sonic Zhang
In-Reply-To: <1337149346-5277-1-git-send-email-sonic.adi@gmail.com>
From: Sonic Zhang <sonic.zhang@analog.com>
Check if xmit buffer pointers are set to zero.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
---
drivers/tty/serial/bfin_uart.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/bfin_uart.c b/drivers/tty/serial/bfin_uart.c
index 9acab11..56b95b0 100644
--- a/drivers/tty/serial/bfin_uart.c
+++ b/drivers/tty/serial/bfin_uart.c
@@ -532,7 +532,7 @@ static irqreturn_t bfin_serial_dma_tx_int(int irq, void *dev_id)
*/
UART_CLEAR_IER(uart, ETBEI);
uart->port.icount.tx += uart->tx_count;
- if (!uart_circ_empty(xmit)) {
+ if (!(xmit->tail == 0 && xmit->head == 0)) {
xmit->tail = (xmit->tail + uart->tx_count) & (UART_XMIT_SIZE - 1);
if (uart_circ_chars_pending(xmit) < WAKEUP_CHARS)
--
1.7.0.4
^ permalink raw reply related
* [PATCH 4/4] serial: bfin_uart: Make MMR access compatible with 32 bits bf609 style controller.
From: Sonic Zhang @ 2012-05-16 6:22 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-serial; +Cc: LKML, uclinux-dist-devel, Sonic Zhang
In-Reply-To: <1337149346-5277-1-git-send-email-sonic.adi@gmail.com>
From: Sonic Zhang <sonic.zhang@analog.com>
Simplify serial data width calculation and adapt to bf609 LCR bit mask.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
---
drivers/tty/serial/bfin_uart.c | 20 ++++----------------
1 files changed, 4 insertions(+), 16 deletions(-)
diff --git a/drivers/tty/serial/bfin_uart.c b/drivers/tty/serial/bfin_uart.c
index 7924ba6..bd97db2 100644
--- a/drivers/tty/serial/bfin_uart.c
+++ b/drivers/tty/serial/bfin_uart.c
@@ -594,7 +594,7 @@ static unsigned int bfin_serial_tx_empty(struct uart_port *port)
static void bfin_serial_break_ctl(struct uart_port *port, int break_state)
{
struct bfin_serial_port *uart = (struct bfin_serial_port *)port;
- u16 lcr = UART_GET_LCR(uart);
+ u32 lcr = UART_GET_LCR(uart);
if (break_state)
lcr |= SB;
else
@@ -1068,7 +1068,7 @@ bfin_serial_console_get_options(struct bfin_serial_port *uart, int *baud,
status = UART_GET_IER(uart) & (ERBFI | ETBEI);
if (status == (ERBFI | ETBEI)) {
/* ok, the port was enabled */
- u16 lcr, clk;
+ u32 lcr, clk;
lcr = UART_GET_LCR(uart);
@@ -1079,20 +1079,8 @@ bfin_serial_console_get_options(struct bfin_serial_port *uart, int *baud,
else
*parity = 'o';
}
- switch (lcr & 0x03) {
- case 0:
- *bits = 5;
- break;
- case 1:
- *bits = 6;
- break;
- case 2:
- *bits = 7;
- break;
- case 3:
- *bits = 8;
- break;
- }
+ *bits = ((lcr & WLS_MASK) >> WLS_OFFSET) + 5;
+
/* Set DLAB in LCR to Access CLK */
UART_SET_DLAB(uart);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/4] serial:bfin_uart: Adapt bf5xx serial driver to bf60x serial4 controller.
From: Sonic Zhang @ 2012-05-16 6:22 UTC (permalink / raw)
To: Greg Kroah-Hartman, linux-serial
Cc: LKML, uclinux-dist-devel, Sonic Zhang, Bob Liu
From: Sonic Zhang <sonic.zhang@analog.com>
The serial4 controller on bf60x is an enhanced version of serial controller
on bf5xx. MMR size is 32 bits other than 16 bits. MMR GCTL, MCR and LCR are
combined into one control MMR. MSR and LSR are combined into one status MMR.
This patch adapts current bf5xx serial driver to serial4 controller on bf60x.
Signed-off-by: Sonic Zhang <sonic.zhang@analog.com>
Signed-off-by: Bob Liu <lliubbo@gmail.com>
---
drivers/tty/serial/bfin_uart.c | 32 +++++++++++++-------------------
1 files changed, 13 insertions(+), 19 deletions(-)
diff --git a/drivers/tty/serial/bfin_uart.c b/drivers/tty/serial/bfin_uart.c
index 5832fde..9acab11 100644
--- a/drivers/tty/serial/bfin_uart.c
+++ b/drivers/tty/serial/bfin_uart.c
@@ -1,7 +1,7 @@
/*
* Blackfin On-Chip Serial Driver
*
- * Copyright 2006-2010 Analog Devices Inc.
+ * Copyright 2006-2011 Analog Devices Inc.
*
* Enter bugs at http://blackfin.uclinux.org/
*
@@ -35,10 +35,6 @@
#include <asm/portmux.h>
#include <asm/cacheflush.h>
#include <asm/dma.h>
-
-#define port_membase(uart) (((struct bfin_serial_port *)(uart))->port.membase)
-#define get_lsr_cache(uart) (((struct bfin_serial_port *)(uart))->lsr)
-#define put_lsr_cache(uart, v) (((struct bfin_serial_port *)(uart))->lsr = (v))
#include <asm/bfin_serial.h>
#ifdef CONFIG_SERIAL_BFIN_MODULE
@@ -166,7 +162,7 @@ static void bfin_serial_stop_tx(struct uart_port *port)
uart->tx_count = 0;
uart->tx_done = 1;
#else
-#ifdef CONFIG_BF54x
+#if defined(CONFIG_BF54x) || defined(CONFIG_BF60x)
/* Clear TFI bit */
UART_PUT_LSR(uart, TFI);
#endif
@@ -337,7 +333,7 @@ static void bfin_serial_tx_chars(struct bfin_serial_port *uart)
struct circ_buf *xmit = &uart->port.state->xmit;
if (uart_circ_empty(xmit) || uart_tx_stopped(&uart->port)) {
-#ifdef CONFIG_BF54x
+#if defined(CONFIG_BF54x) || defined(CONFIG_BF60x)
/* Clear TFI bit */
UART_PUT_LSR(uart, TFI);
#endif
@@ -877,11 +873,10 @@ bfin_serial_set_termios(struct uart_port *port, struct ktermios *termios,
ier = UART_GET_IER(uart);
UART_DISABLE_INTS(uart);
- /* Set DLAB in LCR to Access DLL and DLH */
+ /* Set DLAB in LCR to Access CLK */
UART_SET_DLAB(uart);
- UART_PUT_DLL(uart, quot & 0xFF);
- UART_PUT_DLH(uart, (quot >> 8) & 0xFF);
+ UART_PUT_CLK(uart, quot);
SSYNC();
/* Clear DLAB in LCR to Access THR RBR IER */
@@ -959,12 +954,12 @@ static void bfin_serial_set_ldisc(struct uart_port *port, int ld)
switch (ld) {
case N_IRDA:
val = UART_GET_GCTL(uart);
- val |= (IREN | RPOLC);
+ val |= (UMOD_IRDA | RPOLC);
UART_PUT_GCTL(uart, val);
break;
default:
val = UART_GET_GCTL(uart);
- val &= ~(IREN | RPOLC);
+ val &= ~(UMOD_MASK | RPOLC);
UART_PUT_GCTL(uart, val);
}
}
@@ -975,10 +970,10 @@ static void bfin_serial_reset_irda(struct uart_port *port)
unsigned short val;
val = UART_GET_GCTL(uart);
- val &= ~(IREN | RPOLC);
+ val &= ~(UMOD_MASK | RPOLC);
UART_PUT_GCTL(uart, val);
SSYNC();
- val |= (IREN | RPOLC);
+ val |= (UMOD_IRDA | RPOLC);
UART_PUT_GCTL(uart, val);
SSYNC();
}
@@ -1075,7 +1070,7 @@ bfin_serial_console_get_options(struct bfin_serial_port *uart, int *baud,
status = UART_GET_IER(uart) & (ERBFI | ETBEI);
if (status == (ERBFI | ETBEI)) {
/* ok, the port was enabled */
- u16 lcr, dlh, dll;
+ u16 lcr, clk;
lcr = UART_GET_LCR(uart);
@@ -1100,16 +1095,15 @@ bfin_serial_console_get_options(struct bfin_serial_port *uart, int *baud,
*bits = 8;
break;
}
- /* Set DLAB in LCR to Access DLL and DLH */
+ /* Set DLAB in LCR to Access CLK */
UART_SET_DLAB(uart);
- dll = UART_GET_DLL(uart);
- dlh = UART_GET_DLH(uart);
+ clk = UART_GET_CLK(uart);
/* Clear DLAB in LCR to Access THR RBR IER */
UART_CLEAR_DLAB(uart);
- *baud = get_sclk() / (16*(dll | dlh << 8));
+ *baud = get_sclk() / (16*clk);
}
pr_debug("%s:baud = %d, parity = %c, bits= %d\n", __func__, *baud, *parity, *bits);
}
--
1.7.0.4
^ permalink raw reply related
* Excessive logging causing rcu_sched_state stall (wait_for_xmitr 8250.c)
From: joe shmoe @ 2012-05-16 0:41 UTC (permalink / raw)
To: linux-serial
Hi,
It's been more than a week since I am stuck with this. I am relatively a newbie venturing into linux
kernel, so please be gentle.
I have a non-tained 2.6.35.14 kernel that needs to output a lot using the serial console. To reproduce I
simply run klogd -2 -c 7 and this causes rcu_sched_state to detect stall with a trace such as pasted
below.
Please note that I had enabled CONFIG_PROVE_RCU, CONFIG_RCU_TRACE and related flags as well as
bumped RCU_STALL_RAT_DELAY to 20 while debugging. This makes RCU wait 15020 jiffies until it
complains. Otherwise, it complains in 10002 jiffies (with default config).
The trace points to the wait_for_xmitr() loop in 8250.c (from another run):
(gdb) list *(wait_for_xmitr+0x56)
0x5ae is in wait_for_xmitr (drivers/serial/8250.c:1863).
1858 {
1859 unsigned int status, tmout = 10000;
1860
1861 /* Wait up to 10ms for the character(s) to be sent. */
1862 do {
1863 status = serial_in(up, UART_LSR);
1864
1865 up->lsr_saved_flags |= status & LSR_SAVE_FLAGS;
1866
1867 if (--tmout == 0)
(gdb)
AFAICT, this piece of code is run with interrupts disabled. So is the issue here simply that too much
output is causing wait_for_xmitr() loop to run for longer than rcu_sched_state() is happy with?
In rcu/stallwarn.txt, Paul notes that rcu_sched_state() will get unhappy should the CPU loop with
interrupts disabled.
IF this is indeed the case, what would be a potential fix for this? Any help/guidance much appreciated.
Thank you!
[ 346.664471] INFO: rcu_sched_state detected stalls on CPUs/tasks: { 5} (detected by 0, t=15020 jiffies)
[ 346.664477] sending NMI to all CPUs:
[ 346.666532] NMI backtrace for cpu 5
[ 346.666534] CPU 5
[ 346.666535] Modules linked in: ipmi_devintf ipmi_si
ipmi_msghandler iscsi_scst crc32c_intel iptable_filter xt_NOTRACK
iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4
iptable_raw ip_tables x_tables bonding qla2x00tgt qla2xxx
scsi_transport_fc scst_vdisk scst vtms softdog coretemp hwmon dm_mod
video backlight output serio_raw rtc_cmos rtc_core rtc_lib button ixgbe
i2c_i801 i2c_core uhci_hcd pcspkr
[ 346.666559]
[ 346.666562] Pid: 0, comm: swapper Not tainted 2.6.35-14EIsmp X8DTH/X8DTH-i/6/iF/6F
[ 346.666565] RIP: 0010:[<ffffffff812939b4>] [<ffffffff812939b4>] io_serial_in+0x10/0x15
[ 346.666571] RSP: 0018:ffff880144223a70 EFLAGS: 00000002
[ 346.666574] RAX: 0000000000000900 RBX: ffffffff82a5c8c0 RCX: 0000000000000000
[ 346.666576] RDX: 00000000000003fd RSI: 0000000000000005 RDI: ffffffff82a5c8c0
[ 346.666579] RBP: ffff880144223a70 R08: 0000000098a41ff0 R09: ffffffff81293831
[ 346.666581] R10: ffffffff81d4db2b R11: 0000000000000000 R12: 0000000000000000
[ 346.666583] R13: 00000000000025af R14: 0000000000000020 R15: 000000000000003e
[ 346.666586] FS: 0000000000000000(0000) GS:ffff880144220000(0000) knlGS:0000000000000000
[ 346.666589] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 346.666591] CR2: 00007fff5f13d464 CR3: 0000000074531000 CR4: 00000000000006e0
[ 346.666594] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 346.666596] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 346.666599] Process swapper (pid: 0, threadinfo ffff88013fb44000, task ffff88023fb1e000)
[ 346.666600] Stack:
[ 346.666602] ffff880144223aa0 ffffffff81291b6d ffffffff82a5c8c0 000000000000000a
[ 346.666605] <0> ffffffff81291bd6 ffffffff82a5c8c0 ffff880144223ac0 ffffffff81291bf5
[ 346.666608] <0> ffffffff81d4dc59 000000000000003e ffff880144223b00 ffffffff8128e79b
[ 346.666612] Call Trace:
[ 346.666614] <IRQ>
[ 346.666617] [<ffffffff81291b6d>] wait_for_xmitr+0x38/0xa1
[ 346.666621] [<ffffffff81291bd6>] ? serial8250_console_putchar+0x0/0x34
[ 346.666624] [<ffffffff81291bf5>] serial8250_console_putchar+0x1f/0x34
[ 346.666627] [<ffffffff8128e79b>] uart_console_write+0x41/0x52
[ 346.666631] [<ffffffff8129388c>] serial8250_console_write+0xb2/0x116
[ 346.666635] [<ffffffff8103e4dd>] __call_console_drivers+0x67/0x79
[ 346.666638] [<ffffffff8103e54a>] _call_console_drivers+0x5b/0x5f
[ 346.666641] [<ffffffff8103e937>] release_console_sem+0x12a/0x1c5
[ 346.666644] [<ffffffff8103efaf>] vprintk+0x373/0x3a3
[ 346.666648] [<ffffffff8103f046>] ? printk+0x67/0x69
[ 346.666651] [<ffffffff8103f046>] printk+0x67/0x69
[ 346.666655] [<ffffffff81214645>] ? __delay+0xa/0xc
[ 346.666659] [<ffffffff8105b3ef>] ? up+0xf/0x39
[ 346.666663] [<ffffffff8106597e>] ? trace_hardirqs_on+0xd/0xf
[ 346.666692] [<ffffffffa011b2d2>] ? debug_print_prefix+0x135/0x146 [scst]
[ 346.666706] [<ffffffffa00f6ad3>] scst_process_redirect_cmd+0x97/0x323 [scst]
[ 346.666720] [<ffffffffa00f8807>] scst_cmd_done_local+0x227/0x280 [scst]
[ 346.666726] [<ffffffffa0186d61>] blockio_endio+0xcf/0xee [scst_vdisk]
[ 346.666733] [<ffffffffa0085324>] ? end_io_acct+0x0/0x147 [dm_mod]
[ 346.666736] [<ffffffff811026a7>] bio_endio+0x26/0x28
[ 346.666742] [<ffffffffa00855c5>] dec_pending+0x15a/0x163 [dm_mod]
[ 346.666748] [<ffffffffa008576a>] clone_endio+0xa1/0xae [dm_mod]
[ 346.666752] [<ffffffff811026a7>] bio_endio+0x26/0x28
[ 346.666759] [<ffffffffa00bff51>] vtms_softirq_done+0xeb/0x107 [vtms]
[ 346.666764] [<ffffffff8120127f>] blk_done_softirq+0x6d/0x7e
[ 346.666767] [<ffffffff810439fc>] __do_softirq+0xe9/0x1c7
[ 346.666771] [<ffffffff8100384c>] call_softirq+0x1c/0x34
[ 346.666774] [<ffffffff81004e15>] do_softirq+0x38/0x83
[ 346.666777] [<ffffffff81043911>] irq_exit+0x45/0x47
[ 346.666780] [<ffffffff81017c43>] smp_call_function_single_interrupt+0x2f/0x31
[ 346.666784] [<ffffffff810034b3>] call_function_single_interrupt+0x13/0x20
[ 346.666786] <EOI>
--
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
* Excessive logging causing rcu_sched_state stall (wait_for_xmitr 8250.c)
From: helpmelearn @ 2012-05-16 0:02 UTC (permalink / raw)
To: linux-serial
Hi,
It's been more than a week since I am stuck with this. I am relatively a
newbie venturing into linux
kernel, so please be gentle.
I have a non-tained 2.6.35.14 kernel that needs to output a lot using the
serial console. To reproduce I
simply run klogd -2 -c 7 and this causes rcu_sched_state to detect stall
with a trace such as pasted
below.
Please note that I had enabled CONFIG_PROVE_RCU, CONFIG_RCU_TRACE and
related flags as well as
bumped RCU_STALL_RAT_DELAY to 20 while debugging. This makes RCU wait 15020
jiffies until it
complains. Otherwise, it complains in 10002 jiffies (with default config).
The trace points to the wait_for_xmitr() loop in 8250.c (from another run):
(gdb) list *(wait_for_xmitr+0x56)
0x5ae is in wait_for_xmitr (drivers/serial/8250.c:1863).
1858 {
1859 unsigned int status, tmout = 10000;
1860
1861 /* Wait up to 10ms for the character(s) to be sent. */
1862 do {
1863 status = serial_in(up, UART_LSR);
1864
1865 up->lsr_saved_flags |= status & LSR_SAVE_FLAGS;
1866
1867 if (--tmout == 0)
(gdb)
AFAICT, this piece of code is run with interrupts disabled. So is the issue
here simply that too much
output is causing wait_for_xmitr() loop to run for longer than
rcu_sched_state() is happy with?
In rcu/stallwarn.txt, Paul notes that rcu_sched_state() will get unhappy
should the CPU loop with
interrupts disabled.
IF this is indeed the case, what would be a potential fix for this? Any
help/guidance much appreciated.
Thank you!
[ 346.664471] INFO: rcu_sched_state detected stalls on CPUs/tasks: { 5}
(detected by 0, t=15020 jiffies)
[ 346.664477] sending NMI to all CPUs:
[ 346.666532] NMI backtrace for cpu 5
[ 346.666534] CPU 5
[ 346.666535] Modules linked in: ipmi_devintf ipmi_si ipmi_msghandler
iscsi_scst crc32c_intel iptable_filter xt_NOTRACK iptable_nat nf_nat
nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 iptable_raw ip_tables x_tables
bonding qla2x00tgt qla2xxx scsi_transport_fc scst_vdisk scst vtms softdog
coretemp hwmon dm_mod video backlight output serio_raw rtc_cmos rtc_core
rtc_lib button ixgbe i2c_i801 i2c_core uhci_hcd pcspkr
[ 346.666559]
[ 346.666562] Pid: 0, comm: swapper Not tainted 2.6.35-14EIsmp
X8DTH/X8DTH-i/6/iF/6F
[ 346.666565] RIP: 0010:[<ffffffff812939b4>] [<ffffffff812939b4>]
io_serial_in+0x10/0x15
[ 346.666571] RSP: 0018:ffff880144223a70 EFLAGS: 00000002
[ 346.666574] RAX: 0000000000000900 RBX: ffffffff82a5c8c0 RCX:
0000000000000000
[ 346.666576] RDX: 00000000000003fd RSI: 0000000000000005 RDI:
ffffffff82a5c8c0
[ 346.666579] RBP: ffff880144223a70 R08: 0000000098a41ff0 R09:
ffffffff81293831
[ 346.666581] R10: ffffffff81d4db2b R11: 0000000000000000 R12:
0000000000000000
[ 346.666583] R13: 00000000000025af R14: 0000000000000020 R15:
000000000000003e
[ 346.666586] FS: 0000000000000000(0000) GS:ffff880144220000(0000)
knlGS:0000000000000000
[ 346.666589] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 346.666591] CR2: 00007fff5f13d464 CR3: 0000000074531000 CR4:
00000000000006e0
[ 346.666594] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
0000000000000000
[ 346.666596] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7:
0000000000000400
[ 346.666599] Process swapper (pid: 0, threadinfo ffff88013fb44000, task
ffff88023fb1e000)
[ 346.666600] Stack:
[ 346.666602] ffff880144223aa0 ffffffff81291b6d ffffffff82a5c8c0
000000000000000a
[ 346.666605] <0> ffffffff81291bd6 ffffffff82a5c8c0 ffff880144223ac0
ffffffff81291bf5
[ 346.666608] <0> ffffffff81d4dc59 000000000000003e ffff880144223b00
ffffffff8128e79b
[ 346.666612] Call Trace:
[ 346.666614] <IRQ>
[ 346.666617] [<ffffffff81291b6d>] wait_for_xmitr+0x38/0xa1
[ 346.666621] [<ffffffff81291bd6>] ? serial8250_console_putchar+0x0/0x34
[ 346.666624] [<ffffffff81291bf5>] serial8250_console_putchar+0x1f/0x34
[ 346.666627] [<ffffffff8128e79b>] uart_console_write+0x41/0x52
[ 346.666631] [<ffffffff8129388c>] serial8250_console_write+0xb2/0x116
[ 346.666635] [<ffffffff8103e4dd>] __call_console_drivers+0x67/0x79
[ 346.666638] [<ffffffff8103e54a>] _call_console_drivers+0x5b/0x5f
[ 346.666641] [<ffffffff8103e937>] release_console_sem+0x12a/0x1c5
[ 346.666644] [<ffffffff8103efaf>] vprintk+0x373/0x3a3
[ 346.666648] [<ffffffff8103f046>] ? printk+0x67/0x69
[ 346.666651] [<ffffffff8103f046>] printk+0x67/0x69
[ 346.666655] [<ffffffff81214645>] ? __delay+0xa/0xc
[ 346.666659] [<ffffffff8105b3ef>] ? up+0xf/0x39
[ 346.666663] [<ffffffff8106597e>] ? trace_hardirqs_on+0xd/0xf
[ 346.666692] [<ffffffffa011b2d2>] ? debug_print_prefix+0x135/0x146 [scst]
[ 346.666706] [<ffffffffa00f6ad3>] scst_process_redirect_cmd+0x97/0x323
[scst]
[ 346.666720] [<ffffffffa00f8807>] scst_cmd_done_local+0x227/0x280 [scst]
[ 346.666726] [<ffffffffa0186d61>] blockio_endio+0xcf/0xee [scst_vdisk]
[ 346.666733] [<ffffffffa0085324>] ? end_io_acct+0x0/0x147 [dm_mod]
[ 346.666736] [<ffffffff811026a7>] bio_endio+0x26/0x28
[ 346.666742] [<ffffffffa00855c5>] dec_pending+0x15a/0x163 [dm_mod]
[ 346.666748] [<ffffffffa008576a>] clone_endio+0xa1/0xae [dm_mod]
[ 346.666752] [<ffffffff811026a7>] bio_endio+0x26/0x28
[ 346.666759] [<ffffffffa00bff51>] vtms_softirq_done+0xeb/0x107 [vtms]
[ 346.666764] [<ffffffff8120127f>] blk_done_softirq+0x6d/0x7e
[ 346.666767] [<ffffffff810439fc>] __do_softirq+0xe9/0x1c7
[ 346.666771] [<ffffffff8100384c>] call_softirq+0x1c/0x34
[ 346.666774] [<ffffffff81004e15>] do_softirq+0x38/0x83
[ 346.666777] [<ffffffff81043911>] irq_exit+0x45/0x47
[ 346.666780] [<ffffffff81017c43>]
smp_call_function_single_interrupt+0x2f/0x31
[ 346.666784] [<ffffffff810034b3>]
call_function_single_interrupt+0x13/0x20
[ 346.666786] <EOI>
--
View this message in context: http://old.nabble.com/Excessive-logging-causing-rcu_sched_state-stall-%28wait_for_xmitr-8250.c%29-tp33854911p33854911.html
Sent from the linux-serial mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH 1/1] serial_core: Update buffer overrun statistics.
From: Corbin @ 2012-05-15 22:46 UTC (permalink / raw)
To: Alan Cox; +Cc: Alan Cox, Greg Kroah-Hartman, linux-serial, Corbin Atkinson
In-Reply-To: <20120515220831.11f04213@bob.linux.org.uk>
On Tue, May 15, 2012 at 4:08 PM, Alan Cox <alan@linux.intel.com> wrote:
>> it appears that the software buffer is actually artificially limited
>> to 65536 bytes in the tty_buffer_alloc function in tty_buffer.c. I
>
> Yes although you shouldn't be able to hit this with flow control
> enabled. Without flow control we didn't overrun at that level.
>
> it's really a semantics question - do we count stuff dumped
> intentionally without flow control as an overrun.
>
> I'm not fundamentally opposed to the idea but it is a change of meaning.
>
> Other views ?
>
> Alan
While I agree on normal use cases this won't be hit due to flow
control, I think it is still important to somehow know data was lost
in the case where flow control isn't used. Calling it a buffer overrun
was the way I thought was most fitting. I'm not sure what the
alternatives would be.
On a side note, If this isn't considered a buffer overrun I'm also not
too sure what the buf_overrun field of the port's icount struct is
for. While the "overrun" field is incremented in most drivers to
indicate a hardware overrun, the "buf_overrun" field isn't really
used. It appears that at least one of the few drivers using
buf_overrun (cyclades.c) is interpreting it in the same way that I am,
incrementing it when tty_buffer_request_room returns 0.
Thanks again,
Corbin
^ permalink raw reply
* Re: [PATCH 1/1] serial_core: Update buffer overrun statistics.
From: Jason Smith @ 2012-05-15 19:34 UTC (permalink / raw)
To: Corbin
Cc: Alan Cox, Alan Cox, Corbin Atkinson, Greg Kroah-Hartman,
linux-serial, linux-serial-owner
In-Reply-To: <CAA0x6_9dTE6zFaJOAqsrj2OcehARKG9KgicQPdf1yv2RjDbZwA@mail.gmail.com>
On Tue, May 15, 2012 at 1:41 PM, Corbin <corbinat@gmail.com> wrote:
> Maybe I don't have a complete understanding of what is happening, but
> it appears that the software buffer is actually artificially limited
> to 65536 bytes in the tty_buffer_alloc function in tty_buffer.c. I
...
> On Tue, May 15, 2012 at 11:27 AM, Alan Cox <alan@lxorguk.ukuu.org.uk>
wrote:
>>
>> It'll occur when the machine cannot even allocate a free page of
memory.
>> So you'll get GFP spews in the kernel log to go with it.
It seems to me that it would be undesirable to allow an ignored TTY device
to consume all memory on the system.
It makes sense that the TTY layer would limit it to 64K, which is what
Corbin observed in his test, but then there should be a mechanism to
report that data had been discarded.
-Jason Smith
^ permalink raw reply
* Re: [PATCH 1/1] serial_core: Update buffer overrun statistics.
From: Alan Cox @ 2012-05-15 21:08 UTC (permalink / raw)
To: Corbin; +Cc: Alan Cox, Greg Kroah-Hartman, linux-serial, Corbin Atkinson
In-Reply-To: <CAA0x6_9dTE6zFaJOAqsrj2OcehARKG9KgicQPdf1yv2RjDbZwA@mail.gmail.com>
> it appears that the software buffer is actually artificially limited
> to 65536 bytes in the tty_buffer_alloc function in tty_buffer.c. I
Yes although you shouldn't be able to hit this with flow control
enabled. Without flow control we didn't overrun at that level.
it's really a semantics question - do we count stuff dumped
intentionally without flow control as an overrun.
I'm not fundamentally opposed to the idea but it is a change of meaning.
Other views ?
Alan
^ permalink raw reply
* Re: [PATCH 1/1] serial_core: Update buffer overrun statistics.
From: Corbin @ 2012-05-15 18:41 UTC (permalink / raw)
To: Alan Cox; +Cc: Greg Kroah-Hartman, Alan Cox, linux-serial, Corbin Atkinson
In-Reply-To: <20120515172710.0d0ce47b@pyramind.ukuu.org.uk>
Maybe I don't have a complete understanding of what is happening, but
it appears that the software buffer is actually artificially limited
to 65536 bytes in the tty_buffer_alloc function in tty_buffer.c. I
wrote a quick application to test this. The test opens two 8250 ports
on my computer and sends 69632 (68Kib) of data from one port to the
other. After the write, the test performs a read from the other port,
which only receives 69376 bytes. I believe the extra space over 64KiB
is coming from the line discipline (n_tty.c), but the test still shows
data being lost. Neither the overrun or buf_overrun field in the
port's icount structure were incremented during the test.
Here is the section of code I'm referencing from tty_buffer.c. This
code was pulled from linux-next.
static struct tty_buffer *tty_buffer_alloc(struct tty_struct *tty, size_t size)
{
struct tty_buffer *p;
if (tty->buf.memory_used + size > 65536)
return NULL;
p = kmalloc(sizeof(struct tty_buffer) + 2 * size, GFP_ATOMIC);
if (p == NULL)
return NULL;
p->used = 0;
p->size = size;
p->next = NULL;
p->commit = 0;
p->read = 0;
p->char_buf_ptr = (char *)(p->data);
p->flag_buf_ptr = (unsigned char *)p->char_buf_ptr + size;
tty->buf.memory_used += size;
return p;
}
Corbin
On Tue, May 15, 2012 at 11:27 AM, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> On Tue, 15 May 2012 11:20:19 -0500
> Corbin <corbinat@gmail.com> wrote:
>
>> I agree that losing bytes in the software layer wouldn't happen under
>> normal circumstances, but it is still important to know when it
>> happens. My understanding was that the overrun field in the port's
>> icount was for logging hardware overruns, while the buf_overrun field
>> should be used for software overruns. If this is not the case then is
>> there another method for determining when the software layer is losing
>> bytes?
>
> It'll occur when the machine cannot even allocate a free page of memory.
> So you'll get GFP spews in the kernel log to go with it.
>
> Alan
^ permalink raw reply
* Re: [PATCH 1/1] serial_core: Update buffer overrun statistics.
From: Alan Cox @ 2012-05-15 16:27 UTC (permalink / raw)
To: Corbin; +Cc: Greg Kroah-Hartman, Alan Cox, linux-serial, Corbin Atkinson
In-Reply-To: <CAA0x6_-6tAHspcjFmD9Gz7NV4dUwP6St-UtivXTTQiANfBcX7A@mail.gmail.com>
On Tue, 15 May 2012 11:20:19 -0500
Corbin <corbinat@gmail.com> wrote:
> I agree that losing bytes in the software layer wouldn't happen under
> normal circumstances, but it is still important to know when it
> happens. My understanding was that the overrun field in the port's
> icount was for logging hardware overruns, while the buf_overrun field
> should be used for software overruns. If this is not the case then is
> there another method for determining when the software layer is losing
> bytes?
It'll occur when the machine cannot even allocate a free page of memory.
So you'll get GFP spews in the kernel log to go with it.
Alan
^ permalink raw reply
* Re: [PATCH 1/1] serial_core: Update buffer overrun statistics.
From: Corbin @ 2012-05-15 16:20 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Alan Cox, Alan Cox, linux-serial, Corbin Atkinson
In-Reply-To: <20120515155833.GA24878@kroah.com>
I agree that losing bytes in the software layer wouldn't happen under
normal circumstances, but it is still important to know when it
happens. My understanding was that the overrun field in the port's
icount was for logging hardware overruns, while the buf_overrun field
should be used for software overruns. If this is not the case then is
there another method for determining when the software layer is losing
bytes?
Thanks,
Corbin
On Tue, May 15, 2012 at 10:58 AM, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Tue, May 15, 2012 at 04:53:39PM +0100, Alan Cox wrote:
> > On Fri, 4 May 2012 12:35:10 -0500
> > Corbin Atkinson <corbinat@gmail.com> wrote:
> >
> > > Currently, serial drivers don't report buffer overruns. When a buffer
> > > overrun
> > > occurs, tty_insert_flip_char returns 0, and no attempt is made to
> > > insert that
> > > same character again (i.e. it is lost). This patch reports buffer
> > > overruns via
> > > the buf_overrun field in the port's icount structure.
> >
> > I think this is mostly a misunderstanding - it's always been interpreted
> > as logging hardware reported overrruns. The case of the software layer
> > losing bytes is a "doesn't happen in normal circumstances" situation. At
> > least it should be.
>
> Hm, I applied this already, should I revert it?
>
> thanks,
>
> greg k-h
--
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 1/1] serial_core: Update buffer overrun statistics.
From: Greg Kroah-Hartman @ 2012-05-15 15:58 UTC (permalink / raw)
To: Alan Cox; +Cc: Corbin Atkinson, Alan Cox, linux-serial, Corbin Atkinson
In-Reply-To: <20120515165339.6b142cd2@pyramind.ukuu.org.uk>
On Tue, May 15, 2012 at 04:53:39PM +0100, Alan Cox wrote:
> On Fri, 4 May 2012 12:35:10 -0500
> Corbin Atkinson <corbinat@gmail.com> wrote:
>
> > Currently, serial drivers don't report buffer overruns. When a buffer overrun
> > occurs, tty_insert_flip_char returns 0, and no attempt is made to insert that
> > same character again (i.e. it is lost). This patch reports buffer overruns via
> > the buf_overrun field in the port's icount structure.
>
> I think this is mostly a misunderstanding - it's always been interpreted
> as logging hardware reported overrruns. The case of the software layer
> losing bytes is a "doesn't happen in normal circumstances" situation. At
> least it should be.
Hm, I applied this already, should I revert it?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH 1/1] serial_core: Update buffer overrun statistics.
From: Alan Cox @ 2012-05-15 15:53 UTC (permalink / raw)
To: Corbin Atkinson
Cc: Greg Kroah-Hartman, Alan Cox, linux-serial, Corbin Atkinson
In-Reply-To: <1336152910-5276-1-git-send-email-corbin.atkinson@ni.com>
On Fri, 4 May 2012 12:35:10 -0500
Corbin Atkinson <corbinat@gmail.com> wrote:
> Currently, serial drivers don't report buffer overruns. When a buffer overrun
> occurs, tty_insert_flip_char returns 0, and no attempt is made to insert that
> same character again (i.e. it is lost). This patch reports buffer overruns via
> the buf_overrun field in the port's icount structure.
I think this is mostly a misunderstanding - it's always been interpreted
as logging hardware reported overrruns. The case of the software layer
losing bytes is a "doesn't happen in normal circumstances" situation. At
least it should be.
Alan
^ permalink raw reply
* [PATCH v2 RESEND] serial: 8250: Add cpufreq support
From: Shankarmurthy, Akshay @ 2012-05-15 15:10 UTC (permalink / raw)
To: linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
swarren-DDmLM1+adcrQT0dZR+AlfA,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
dianders-F7+t8E8rja9g9hUCZPvPmw,
paul.gortmaker-CWA4WttNNZF54TAoqtyWWQ,
jamie-wmLquQDDieKakBO8gow8eQ,
dan.j.williams-ral2JQCrhuEAvxtiuMwx3w,
alan-VuQAYsv1563Yd54FQh9/CA
This patch adds cpufreq support for 8250 serial driver. A clk structure
member has been added to the platform and port data structures. This
member is used by the cpufreq notifier callback to get the updated
clock rate. Also adds a member 'enable_cpufreq' to the plat_serial8250_port
and uart_port structures which decides the requirement of cpufreq registration
for each individual ports. If the port requires registration then
'enable_cpufreq' should be passed as TRUE from the board file.
Tested on TI DA850/OMAP-L138 EVM.
Signed-off-by: Chaithrika U S <chaithrika-l0cyMroinI0@public.gmane.org>
Signed-off-by: Shankarmurthy, Akshay <akshay.s-l0cyMroinI0@public.gmane.org>
---
v2 includes following changes :
1. Used "tty_port_tty_get" API to get the tty struct instead of accesing it
directly from the uart_port structure.
2. Added a boolean member "enable_cpufreq" to the uart_port and
serial8250_port structures. This indicates the requirement of cpu freq
registration for each individual ports.
3. Renamed the function from "serial8250_cpufreq_deregister" to
"serial8250_cpufreq_unregister".
Changes are as per these discussions
http://www.mail-archive.com/davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org/msg22841.html
drivers/tty/serial/8250/8250.c | 79 ++++++++++++++++++++++++++++++++++++++++
drivers/tty/serial/8250/8250.h | 4 ++
include/linux/serial_8250.h | 2 +
include/linux/serial_core.h | 1 +
4 files changed, 86 insertions(+), 0 deletions(-)
diff --git a/drivers/tty/serial/8250/8250.c b/drivers/tty/serial/8250/8250.c
index 5c27f7e..83b5585 100644
--- a/drivers/tty/serial/8250/8250.c
+++ b/drivers/tty/serial/8250/8250.c
@@ -38,6 +38,8 @@
#include <linux/nmi.h>
#include <linux/mutex.h>
#include <linux/slab.h>
+#include <linux/cpufreq.h>
+#include <linux/clk.h>
#ifdef CONFIG_SPARC
#include <linux/sunserialcore.h>
#endif
@@ -3005,6 +3007,70 @@ void serial8250_resume_port(int line)
uart_resume_port(&serial8250_reg, port);
}
+#ifdef CONFIG_CPU_FREQ
+static int serial8250_cpufreq_transition(struct notifier_block *nb,
+ unsigned long val, void *data)
+{
+ struct uart_8250_port *p;
+ struct uart_port *uport;
+
+ p = container_of(nb, struct uart_8250_port, freq_transition);
+ uport = &p->port;
+
+ if (IS_ERR(p->clk))
+ goto cpu_freq_exit;
+
+ if (p->port.uartclk == clk_get_rate(p->clk))
+ goto cpu_freq_exit;
+
+ p->port.uartclk = clk_get_rate(p->clk);
+ if (val == CPUFREQ_POSTCHANGE) {
+ struct ktermios *termios;
+ struct tty_struct *tty;
+ if (uport->state == NULL)
+ goto cpu_freq_exit;
+
+ tty = tty_port_tty_get(&uport->state->port);
+ if (tty == NULL)
+ goto cpu_freq_exit;
+
+ termios = tty->termios;
+ if (termios == NULL) {
+ printk(KERN_WARNING "%s: no termios?\n", __func__);
+ goto cpu_freq_exit;
+ }
+
+ serial8250_set_termios(uport, termios, NULL);
+ }
+
+cpu_freq_exit:
+ return 0;
+}
+
+static inline int serial8250_cpufreq_register(struct uart_8250_port *p)
+{
+ p->freq_transition.notifier_call = serial8250_cpufreq_transition;
+
+ return cpufreq_register_notifier(&p->freq_transition,
+ CPUFREQ_TRANSITION_NOTIFIER);
+}
+
+static inline void serial8250_cpufreq_unregister(struct uart_8250_port *p)
+{
+ cpufreq_unregister_notifier(&p->freq_transition,
+ CPUFREQ_TRANSITION_NOTIFIER);
+}
+#else
+static inline int serial8250_cpufreq_register(struct uart_8250_port *p)
+{
+ return 0;
+}
+
+static inline void serial8250_cpufreq_unregister(struct uart_8250_port *p)
+{
+}
+#endif
+
/*
* Register a set of serial devices attached to a platform device. The
* list is terminated with a zero flags entry, which means we expect
@@ -3041,6 +3107,10 @@ static int __devinit serial8250_probe(struct platform_device *dev)
port.pm = p->pm;
port.dev = &dev->dev;
port.irqflags |= irqflag;
+ port.enable_cpufreq = p->enable_cpufreq;
+ if (p->clk)
+ serial8250_ports[i].clk = p->clk;
+
ret = serial8250_register_port(&port);
if (ret < 0) {
dev_err(&dev->dev, "unable to register port at index %d "
@@ -3217,6 +3287,13 @@ int serial8250_register_port(struct uart_port *port)
ret = uart_add_one_port(&serial8250_reg, &uart->port);
if (ret == 0)
ret = uart->port.line;
+
+ if (port->enable_cpufreq) {
+ ret = serial8250_cpufreq_register(uart);
+ if (ret < 0)
+ printk(KERN_ERR
+ "Failed to add cpufreq notifier\n");
+ }
}
mutex_unlock(&serial_mutex);
@@ -3236,6 +3313,8 @@ void serial8250_unregister_port(int line)
struct uart_8250_port *uart = &serial8250_ports[line];
mutex_lock(&serial_mutex);
+ if (uart->port.enable_cpufreq)
+ serial8250_cpufreq_unregister(uart);
uart_remove_one_port(&serial8250_reg, &uart->port);
if (serial8250_isa_devs) {
uart->port.flags &= ~UPF_BOOT_AUTOCONF;
diff --git a/drivers/tty/serial/8250/8250.h b/drivers/tty/serial/8250/8250.h
index 2868a1d..77d5876 100644
--- a/drivers/tty/serial/8250/8250.h
+++ b/drivers/tty/serial/8250/8250.h
@@ -37,6 +37,10 @@ struct uart_8250_port {
unsigned char lsr_saved_flags;
#define MSR_SAVE_FLAGS UART_MSR_ANY_DELTA
unsigned char msr_saved_flags;
+ struct clk *clk;
+#ifdef CONFIG_CPU_FREQ
+ struct notifier_block freq_transition;
+#endif
};
struct old_serial_port {
diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index 8f012f8..fa30b81 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -23,6 +23,8 @@ struct plat_serial8250_port {
resource_size_t mapbase; /* resource base */
unsigned int irq; /* interrupt number */
unsigned long irqflags; /* request_irq flags */
+ struct clk *clk;
+ bool enable_cpufreq; /* CPU freq status */
unsigned int uartclk; /* UART clock rate */
void *private_data;
unsigned char regshift; /* register shift */
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index 2db407a..5db67a6 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -380,6 +380,7 @@ struct uart_port {
unsigned char suspended;
unsigned char irq_wake;
unsigned char unused[2];
+ bool enable_cpufreq; /* CPU freq status */
void *private_data; /* generic platform data pointer */
};
--
1.7.1
^ permalink raw reply related
* Re: [PATCH 1/3] RFC: Solved unnecessary schedule latency in the TTY layer (1/3)
From: Steven Rostedt @ 2012-05-15 15:04 UTC (permalink / raw)
To: Ivo Sieben; +Cc: Alan Cox, Greg KH, linux-serial, RT
In-Reply-To: <CAMSQXEG5okiqKasmh3_niGh_WCKNvekiwK9oSDnQkokcMPqArg@mail.gmail.com>
On Mon, 2012-05-14 at 14:25 +0200, Ivo Sieben wrote:
> void tty_flip_buffer_push(struct tty_struct *tty)
> {
> unsigned long flags;
> spin_lock_irqsave(&tty->buf.lock, flags);
> if (tty->buf.tail != NULL)
> tty->buf.tail->commit = tty->buf.tail->used;
> spin_unlock_irqrestore(&tty->buf.lock, flags);
>
> #ifndef CONFIG_PREEMPT_RT_FULL
> if (tty->low_latency)
> flush_to_ldisc(&tty->buf.work);
> else
> schedule_work(&tty->buf.work);
> #else
> flush_to_ldisc(&tty->buf.work);
> #endif
> }
>
Note, just to keep ugly #ifdefs out of C code, or at least C functions,
it is usually better to wrap the above in something like:
#ifdef CONFIG_PREEMPT_RT_FULL
static inline void tty_flush_work(struct tty_struct *tty)
{
flush_to_ldisc(&tty->buf.work);
}
#else
static inline void tty_flush_work(struct tty_struct *tty)
{
if (tty->low_latency)
flush_to_ldisc(&tty->buf.work);
else
schedule_work(&tty->buf.work);
}
#endif
Then the C function would just look like:
void tty_flip_buffer_push(struct tty_struct *tty)
{
unsigned long flags;
spin_lock_irqsave(&tty->buf.lock, flags);
if (tty->buf.tail != NULL)
tty->buf.tail->commit = tty->buf.tail->used;
spin_unlock_irqrestore(&tty->buf.lock, flags);
tty_flush_work(tty);
}
-- Steve
^ permalink raw reply
* RE: [PATCH v2] serial: 8250: Add cpufreq support
From: Shankarmurthy, Akshay @ 2012-05-15 13:57 UTC (permalink / raw)
To: Alan Cox
Cc: linux-serial@vger.kernel.org, gregkh@linuxfoundation.org,
paul.gortmaker@windriver.com, jamie@jamieiles.com,
swarren@nvidia.com, dianders@chromium.org,
davinci-linux-open-source@linux.davincidsp.com
In-Reply-To: <20120515144414.23065741@bob.linux.org.uk>
On Tue, May 15, 2012 at 19:14:14, Alan Cox wrote:
> > > Changes are as per these discussions
> > > http://www.mail-archive.com/davinci-linux-open-source@linux.davincid
> > > sp.com/msg22841.html
> > >
> >
> > Please let me know if there are any comments on this patch?
>
> It never got here for some reason. Last I have in my mailbox is the discussion of the 17th April ?
>
Ok, I will resend the patch.
Regards,
Akshay
^ permalink raw reply
* Re: [PATCH v2] serial: 8250: Add cpufreq support
From: Alan Cox @ 2012-05-15 13:44 UTC (permalink / raw)
To: Shankarmurthy, Akshay
Cc: linux-serial@vger.kernel.org, gregkh@linuxfoundation.org,
paul.gortmaker@windriver.com, jamie@jamieiles.com,
swarren@nvidia.com, dianders@chromium.org,
davinci-linux-open-source@linux.davincidsp.com
In-Reply-To: <6F6B80BD2E18844D97BB4B51FE3705C83E935014@DBDE01.ent.ti.com>
> > Changes are as per these discussions
> > http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg22841.html
> >
>
> Please let me know if there are any comments on this patch?
It never got here for some reason. Last I have in my mailbox is the
discussion of the 17th April ?
^ 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