gmane.linux.serial

[PATCH 0/6] Bridging PCI to amba

Alessandro Rubini — 2012-05-25T15:47:48

This patch set introduces use of the pl011 AMBA serial port under a
PCI bridge.  To compile AMBA under x86, though I need <asm/sizes.h>,
which is moved to <linux/sizes.h> as suggested earlier.

I'm hereby volunteering to handle the moving of the various users
of <asm/sizes.h> to <linux/sizes.h>; this set only moves the ARM core
files and the ones that I need under x86.

The whole patch set is sent to the same set of recipients:
all relevant lists, Russell King (for arm), Greg-KH (for uart) and
Arnd Bergmann (for generic include).

With this set in place (plus a clok API not included here) I have
4 serial ports working. We have a number of other devices that can
use existing drivers, but we definitely need <linux/sizes.h> first.

  spusa.root# uname -r
  3.4.0-next-20120524-00014-gae0c129

  spusa.root# dmesg | grep ttyA
  pl011-pci-03:0005: ttyAMA0 at MMIO 0xcf400000 (irq = 46) is a PL011 rev3
  pl011-pci-03:0006: ttyAMA1 at MMIO 0xcec00000 (irq = 47) is a PL011 rev3
  pl011-pci-03:0007: ttyAMA2 at MMIO 0xce

[PATCH] serial/amba-pl011: move custom pin control to driver

Linus Walleij — 2012-05-23T19:18:46

From: Linus Walleij <linus.walleij< at >linaro.org>

We had a boot regression in Ux500 in the merge window because
two orthogonal pin control schemes for the PL011 were merged
at the same time:

- One using the .init() and .exit() hooks into the platform
  for Ux500 putting the pins into default vs sleep state
  respectively as the port was started/stopped.
  commit a09806607fd20bed2f8c41fe22793386790a14aa
  "ARM: ux500: switch to using pinctrl for uart0"

- One hogging the default setting at PL011 probe()
  commit 258e055111d3cde2607e0d04eb91da2f7a59b591
  "serial: amba-pl011: adopt pinctrl support"

To get a solution that works for both let's scrap the stuff
in the platform callbacks, instead have the driver itself
select default and sleep states when the port is
started/stopped. Hopefully this works for all clients.
Platform callbacks are bad for device tree migration anyway,
so this rids us of another problem in Ux500.

Cc: linux-serial< at >vger.kernel.org
Cc: Greg Kroah-Hartman <gregkh< at >linuxfoundation.org>
Cc: S

[GIT PATCH] TTY/serial patches for 3.5-rc1 - try 2

Greg KH — 2012-05-22T15:15:27

The following changes since commit 66f75a5d028beaf67c931435fdc3e7823125730c:

  Linux 3.4-rc4 (2012-04-21 14:47:52 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tags/tty-3.5-rc1

for you to fetch changes up to 59bd234b72fc29887839d792b7d6c7e8d2a577a6:

  serial: bfin_uart: Make MMR access compatible with 32 bits bf609 style controller. (2012-05-17 13:25:56 -0700)

----------------------------------------------------------------
TTY pull request for 3.5-rc1

Here's the big TTY/serial driver pull request for the 3.5-rc1 merge window.

Nothing major in here, just lots of incremental changes from Alan and
Jiri reworking some tty core things to behave better and to get a more
solid grasp on some of the nasty tty locking issues.

There are a few tty and serial driver updates in here as well.

All of this has been in the linux-next releases for a while with no problems.

Signed-off-by: Greg Kroah-Hartman <gregkh< at >linuxfoundation.org>

---------------

[GIT PATCH] TTY/serial patches for 3.5-rc1

Greg KH — 2012-05-22T13:20:06

The following changes since commit d48b97b403d23f6df0b990cee652bdf9a52337a3:

  Linux 3.4-rc6 (2012-05-06 15:07:32 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tags/tty-3.5-rc1

for you to fetch changes up to d48b97b403d23f6df0b990cee652bdf9a52337a3:

  Linux 3.4-rc6 (2012-05-06 15:07:32 -0700)

----------------------------------------------------------------
TTY pull request for 3.5-rc1

Here's the big TTY/serial driver pull request for the 3.5-rc1 merge window.

Nothing major in here, just lots of incremental changes from Alan and
Jiri reworking some tty core things to behave better and to get a more
solid grasp on some of the nasty tty locking issues.

There are a few tty and serial driver updates in here as well.

All of this has been in the linux-next releases for a while with no problems.

Signed-off-by: Greg Kroah-Hartman <gregkh< at >linuxfoundation.org>

----------------------------------------------------------------

 Documentation/ABI

[PATCH V2] serial: pxa: add spin lock for console write

Chao Xie — 2012-05-22T04:43:00

at UP mode, when cpu want to print message in kernel, it will invoke
peempt_disable and disable irq. So it is safe for UP mode.
For SMP mode, it is not safe to protect the HW reigsters.
one CPU will run a program which will invoke printf.
another CPU will run a program in kernel that invoke printk.
So when second CPU is trying to printk, it will do
1. save ier register
2. enable uue bit of ier register
3. push buffer to uart fifo
4 .restore ier register
when first CPU want to printf, and it happens between 1 and 4, it will
enable thre bit of ier, and waiting for transmit intterupt. while step 4
will make the ier lost thre bit.
add spin lock here to protect the ier register for console write.

Signed-off-by: Chao Xie <chao.xie< at >marvell.com>
---
 drivers/tty/serial/pxa.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/tty/serial/pxa.c b/drivers/tty/serial/pxa.c
index 5847a4b..aca62f6 100644
--- a/drivers/tty/serial/pxa.c
+++ b/drivers/tty/serial/pxa.c
< at >< at > -670,9 +6

Questions regarding adding a patch in linux/drivers/char/8250.c

Donald — 2012-05-21T06:19:34

Hi,

This is Donald from ASIX Electronics Corp. My company has three PCI to Serial controllers, including MCS9845, MCS9835, and MCS9820.
Currently those serial devices using these three chips can directly use the Linux kernel's serial driver in
linux/drivers/char/8250.c. Recently we find these three chips have a hardware bug relating to parity error count function. We have a
software workaround for this issue. Below for reference is a pseudo code for this workaround.

serial8250_do_set_termios() {
If ((PID == MCS9845 || PID == MCS935 || PID == MCS9820) && ((termios->c_cflag & PARENB))) {
port->fifosize = 1; /* Change RX FIFO size to 1 byte */
up->ier &= ~UART_IER_RLSI; /* Disable RLSI interrupt */
}
}

Is it possible to add a patch into linux/drivers/char/8250.c for our chips' hardware issue? If it's not feasible to add a patch into
linux/drivers/char/8250.c, could we submit a new driver (e.g., mcs78xx_8250.c) to Linux kernel for devices using these three chips
(i.e., those devices can use new driver

[PATCH] serial: pxa: add spin lock for console write

Chao Xie — 2012-05-21T02:33:48

at UP mode, when cpu want to print message in kernel, it will invoke
peempt_disable and disable irq. So it is safe for UP mode.
For SMP mode, it is not safe to protect the HW reigsters.
one CPU will run a program which will invoke printf.
another CPU will run a program in kernel that invoke printk.
So when second CPU is trying to printk, it will do
1. save ier register
2. enable uue bit of ier register
3. push buffer to uart fifo
4 .restore ier register
when first CPU want to printf, and it happens between 1 and 4, it will
enable thre bit of ier, and waiting for transmit intterupt. while step 4
will make the ier lost thre bit.
add spin lock here to protect the ier register for console write.

Signed-off-by: Chao Xie <chao.xie< at >marvell.com>
---
 drivers/tty/serial/pxa.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

diff --git a/drivers/tty/serial/pxa.c b/drivers/tty/serial/pxa.c
index 5847a4b..d94387f 100644
--- a/drivers/tty/serial/pxa.c
+++ b/drivers/tty/serial/pxa.c
< at >< at > -670,6 +6

kmscon: replacing CONFIG_VT

David Herrmann — 2012-05-16T15:58:11

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 drm

Excessive logging causing rcu_sched_state stall (wait_for_xmitr 8250.c)

joe shmoe — 2012-05-16T00:41:28

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

Excessive logging causing rcu_sched_state stall (wait_for_xmitr 8250.c)

helpmelearn — 2012-05-16T00:02:36

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

[PATCH v2] serial: samsung: Fixed wrong comparison for baudclk_rate

Kyoungil Kim — 2012-05-15T12:37:16

port->baudclk_rate should be compared to the rate of port->baudclk,
because port->baudclk_rate was assigned as the rate of port->baudclk previously.
So to check that the current baudclk rate is same as previous rate,
the target of comparison sholud be the rate of port->baudclk.

Signed-off-by: Jun-Ho, Yoon <junho78.yoon< at >samsung.com>
Signed-off-by: Kyoungil Kim <ki0351.kim< at >samsung.com>
---
 drivers/tty/serial/samsung.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index d8b0aee..6a6a86a 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
< at >< at > -1014,10 +1014,10 < at >< at > static int s3c24xx_serial_cpufreq_transition(struct notifier_block *nb,
  * a disturbance in the clock-rate over the change.
  */
 
-if (IS_ERR(port->clk))
+if (IS_ERR(port->baudclk) || port->baudclk == NULL)
 goto exit;
 
-if (port->baudclk_rate == clk_get_rate(port->clk))
+if (port->baudclk_rate == clk_get_rate(port->baudclk))

[PATCH] serial: samsung: Fixed wrong comparison for baudclk_rate

Kyoungil Kim — 2012-05-15T10:13:28

port->baudclk_rate should be compared to the rate of port->baudclk,
because port->baudclk_rate was assigned as the rate of port->baudclk previously.
So to check that the current baudclk rate is same as previous rate,
the target of comparison sholud be the rate of port->baudclk.

Signed-off-by: Jun-Ho, Yoon <junho78.yoon< at >samsung.com>
Signed-off-by: Kyoungil Kim <ki0351.kim< at >samsung.com>
---
 drivers/tty/serial/samsung.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index d8b0aee..c4867ea 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
< at >< at > -1014,10 +1014,10 < at >< at > static int s3c24xx_serial_cpufreq_transition(struct notifier_block *nb,
  * a disturbance in the clock-rate over the change.
  */
 
-if (IS_ERR(port->clk))
+if (IS_ERR_OR_NULL(port->baudclk))
 goto exit;
 
-if (port->baudclk_rate == clk_get_rate(port->clk))
+if (port->baudclk_rate == clk_get_rate(port->baudclk))
 goto exit;

[PATCH] tty: Allow uart_register/unregister/register

Alan Cox — 2012-05-14T13:51:22

From: Alan Cox <alan< at >linux.intel.com>

This is legitimate but because we don't clear the drv->state pointer in the
unregister code causes a bogus BUG().

Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=42880
Signed-off-by: Alan Cox <alan< at >linux.intel.com>
---

 drivers/tty/serial/serial_core.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 9c4c05b..246b823 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
< at >< at > -2282,6 +2282,7 < at >< at > void uart_unregister_driver(struct uart_driver *drv)
 tty_unregister_driver(p);
 put_tty_driver(p);
 kfree(drv->state);
+drv->state = NULL;
 drv->tty_driver = NULL;
 }
 

--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Dedicated server rental

2012-05-14T04:14:05

Dear Sir/Madam,

Please see below our Server Rental Package,

HKD1980/month + one-time setup fee HKD2000

Dell? PowerEdge? Enterprise Rack Mount Server
-          Intel(R) Xeon(R) E3-1220 Processor (3.10GHz, 8M Cache, Turbo, 4C/4T, 80W)
-          4GB RAM, 1x4GB, 1333MHz, DDR-3, Single Ranked UDIMMs
-          500GB, 3.5", SATA II x 1 Enterprise Hard Disk
-          Remote KVM (iDRAC6 Enterprise)
-          8x SATA slim DVD-ROM Drive 
-          Dell OpenManage
-          Broadcom 5716 dual-port Gigabit Ethernet without TOE enabled
-          Dell BMC Info Mod

Software Specification
-     CentOS 5/6 Linux Operating System


Data Center Facilities
-          1Gbps Share Internet Connectivity with 10/BASE-T
-          One IP Addresses Allocation
-          Un-interruptible Power Supply (UPS) backed up by private diesel generator
-          FM200 gas¡Vbased fire suppression system
-          24x7 CRAC Air Conditioning and Humidity Control
-          24x7 Security Control

Should you have any query, please fee

haalloo,

abi — 2012-05-12T16:54:45

haalloo,
how are you doing,i hope you are fine,my name is miss abi okom i got your
contact and want us to be a good friend,
please try and write back to me so that i will give you my pictures and tell
you more about me,
--
To unsubscribe from this list: send the line "unsubscribe linux-serial" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

auto-RTS and TL16C754C

grego rigolo — 2012-05-11T12:18:27

Hi all,
I am using a TL16C754C in my design and i was wondering why the Auto-RTS was not enabled.
Indeed in the 8250.c source code we can read

FIXME:
         * - TI16C752 requires control thresholds to be set.
         * - UART_MCR_RTS is ineffective if auto-RTS mode is enabled

In the serial-omap.c, i saw that auto-rts had been enabled:
/* Hardware Flow Control Configuration */

    if (termios->c_cflag & CRTSCTS)
 {
        efr |= (UART_EFR_CTS | UART_EFR_RTS);
        serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);

        up->mcr = serial_in(up, UART_MCR);
        serial_out(up, UART_MCR, up->mcr | UART_MCR_TCRTLR);

        serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
        up->efr = serial_in(up, UART_EFR);
        serial_out(up, UART_EFR, up->efr | UART_EFR_ECB);

        serial_out(up, UART_TI752_TCR, OMAP_UART_TCR_TRIG);
        serial_out(up, UART_EFR, efr); /* Enable AUTORTS and AUTOCTS */
        serial_out(up, U

[PATCH] cris: fix missing tty arg in wait_event_interruptible_tty call

Paul Gortmaker — 2012-05-08T15:17:55

Commit d29f3ef39be4eec0362b985305fc526d9be318cf

    "tty_lock: Localise the lock"

added a tty arg to wait_event_interruptible_tty() but it missed
this arch specific instance for cris, causing a compile failure.

Cc: Mikael Starvik <starvik< at >axis.com>
Cc: Jesper Nilsson <jesper.nilsson< at >axis.com>
Cc: Alan Cox <alan< at >linux.intel.com>
Cc: Arnd Bergmann <arnd< at >arndb.de>
Cc: Greg Kroah-Hartman <gregkh< at >linuxfoundation.org>
Signed-off-by: Paul Gortmaker <paul.gortmaker< at >windriver.com>

diff --git a/drivers/tty/serial/crisv10.c b/drivers/tty/serial/crisv10.c
index b431a51..7264d4d 100644
--- a/drivers/tty/serial/crisv10.c
+++ b/drivers/tty/serial/crisv10.c
< at >< at > -3976,7 +3976,7 < at >< at > block_til_ready(struct tty_struct *tty, struct file * filp,
  */
 if (tty_hung_up_p(filp) ||
     (info->flags & ASYNC_CLOSING)) {
-wait_event_interruptible_tty(info->close_wait,
+wait_event_interruptible_tty(tty, info->close_wait,
 !(info->flags & ASYNC_CLOSING));
 #ifdef SERIAL_DO_RESTART
 if (info->flags & ASYNC_HUP_NOTIFY)
< at >< at > -41

What's the rationale behind sending a Xoff character when the port is stopped ?

Karthik Manamcheri — 2012-05-07T20:00:50

Hi,

I noticed in drivers/tty/serial/8250.c that when we transmit
characters (by calling transmit_chars), we check for uart_tx_stopped
only after sending the x_char (if any). What's the rationale behind
this ? I would expect the uart not to send ANY characters (including a
Xoff character) if its throttled (or stopped).

[PATCH RESEND 0/9] Enable pinctrl support for mach-mxs

Shawn Guo — 2012-05-07T01:16:05

[Resend to have subsystem lists Cc-ed]

With pinctrl-mxs driver (DT only) applied on pinctrl tree, the mxs
device tree conversion can start basing on that support.  This series
adopts pinctrl support for mxs device drivers with a dummy pinctrl
state provided for non-DT boot, so that the pinctrl call in the device
drivers will be bypassed for non-DT probe while it starts working for
DT probe.

To ease the merge process, I would like to ask Arnd and Olof to pull
pinctrl tree as a dependency in arm-soc and have this series go through
arm-soc.

Regards,
Shawn

Shawn Guo (9):
  ARM: mxs: enable pinctrl dummy states
  serial: amba-pl011: adopt pinctrl support
  serial: mxs-auart: adopt pinctrl support
  mmc: mxs-mmc: adopt pinctrl support
  mtd: nand: gpmi: adopt pinctrl support
  i2c: mxs: adopt pinctrl support
  ASoC: mxs-saif: adopt pinctrl support
  video: mxsfb: adopt pinctrl support
  ARM: mxs: enable pinctrl support

 arch/arm/Kconfig                        |    1 +
 arch/arm/mach-mxs/Kconfig

[PATCH RESEND 0/5] Adopt pinctrl support for a few outstanding imx drivers

Shawn Guo — 2012-05-07T00:53:55

With patch 5b3aa5f (pinctrl: add pinctrl_provide_dummies interface for
platforms to use) applied on pinctrl tree, and patch "ARM: imx: enable
pinctrl dummy states" [1] being there, we are ready to adopt pinctrl
API for imx drivers.  So let's start from a few outstanding ones.

I would expect to ask Arnd and Olof to pull pinctrl tree into arm-soc
as a dependency and then have series [1] and this patch set go through
arm-soc tree to ease the merge process.

Resend to have subsystem lists Cc-ed.

Regards,
Shawn

[1] http://thread.gmane.org/gmane.linux.kernel.mmc/14180

Shawn Guo (5):
  tty: serial: imx: adopt pinctrl support
  net: fec: adopt pinctrl support
  can: flexcan: adopt pinctrl support
  i2c: imx: adopt pinctrl support
  spi/imx: adopt pinctrl support

 drivers/i2c/busses/i2c-imx.c         |    8 ++++++++
 drivers/net/can/flexcan.c            |    6 ++++++
 drivers/net/ethernet/freescale/fec.c |    9 +++++++++
 drivers/spi/spi-imx.c                |    8 ++++++++
 drivers/tty/serial/imx.c

[PATCH 1/1] serial_core: Update buffer overrun statistics.

Corbin Atkinson — 2012-05-04T17:35:10

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.

Signed-off-by: Corbin Atkinson <corbin.atkinson< at >ni.com>
---
 drivers/tty/serial/serial_core.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 9c4c05b..59fb3ba 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
< at >< at > -2526,14 +2526,16 < at >< at > void uart_insert_char(struct uart_port *port, unsigned int status,
 struct tty_struct *tty = port->state->port.tty;
 
 if ((status & port->ignore_status_mask & ~overrun) == 0)
-tty_insert_flip_char(tty, ch, flag);
+if (tty_insert_flip_char(tty, ch, flag) == 0)
+++port->icount.buf_overrun;
 
 /*
  * Overrun is special.  Since it's reported immediate