Richard Andrysek | 16 Apr 17:59 2014

How can I setup a baudrate geater then 4Mbd?

I am using a following command :

BAUDRATE=8000000
stty -F /dev/ttyS6 ispeed $BAUDRATE ospeed $BAUDRATE -ignpar cs8 -cstopb –echo

However it does not allow me to set anything above 4Mbd or at least it is
not shown with a following command:

$ sudo stty -a -F /dev/ttyS6
[sudo] password for ran:
-bash: c$: command not found
speed 4000000 baud; rows 0; columns 0; line = 0;
ran <at> rg-debian-09:~/src$ [sudo] password for ran:
intr = <undef>; quit = <undef>; erase = <undef>; kill = <undef>; eof = <undef>;
-bash: [sudo]: command not found
eol = <undef>; eol2 = <undef>; swtch = <undef>; start = <undef>; stop = <undef>;
susp = <undef>; rprnt = <undef>; werase = <undef>; lnext = <undef>

 As you can see a speed is a last one from a settings before. Why?

My system:

RS232 card: Jetway ADMPEOX4CA
Linux kernel :  3.2.53-rgm-rt75-nodebug #2 SMP PREEMPT RT

By

Richard

--
(Continue reading)

Doug Anderson | 21 Apr 18:40 2014

[PATCH 1/3] serial: samsung: Use the passed in "port", fixing kgdb w/ no console

The two functions in the samsung serial driver used for writing
characters out to the port were inconsistent about whether they used
the passed in "port" or the global "cons_uart".  There was no reason
to use the global and the use of the global in
s3c24xx_serial_put_poll_char() caused a crash in the case where you
used the serial port for kgdboc but not for console.

Fix it so we used the passed in variable.

Note that this doesn't fix all problems with the samsung serial
driver.  Specifically:
* s3c24xx_serial_console_putchar() is still 99% identical to
  s3c24xx_serial_put_poll_char() (the function signature is different,
  but that's about it).  A future patch will make them slightly less
  identical and judging by other serial drivers we may need yet more
  differences eventually.
* The samsung serial driver still doesn't allow you to have more than
  one console port since it still uses the global cons_uart in
  s3c24xx_serial_console_write().

Signed-off-by: Doug Anderson <dianders <at> chromium.org>
---
 drivers/tty/serial/samsung.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/tty/serial/samsung.c b/drivers/tty/serial/samsung.c
index 23f4596..a8e8b79 100644
--- a/drivers/tty/serial/samsung.c
+++ b/drivers/tty/serial/samsung.c
 <at>  <at>  -1446,8 +1446,8  <at>  <at>  static int s3c24xx_serial_get_poll_char(struct uart_port *port)
(Continue reading)

Rob Herring | 19 Apr 00:19 2014
Picon

[PATCH v2 0/7] Generic serial earlycon

From: Rob Herring <robh <at> kernel.org>

This started out as an attempt to add arm64's earlyprintk support to ARM
in order to get an earlier, runtime setup console on multi-platform
kernels. The first issue was needing the fixmap support which
conveniently Mark Salter was working on and is mostly in place now. Like
many things on ARM and arm64 now, it then became where do I put the now
common, shared code. After digging more into various early console/printk
support, it turns out the 8250_early.c setup code was the best starting
point. 

This is tested on arm64 and ARM with pl011 and 8250. The ARM support
also requires fixmap and fixed mapping support which are not yet in place.
I have some patches in my tree to support fixmap, but they need some more
work. Fortunately, once fixmap is in place, it is just a Kconfig option
to enable earlycon support on ARM. A git tree is available here[1].

I'm also working on a follow on series which adds DT based earlycon
setup, but that is dependent on some FDT improvements to support FDT
based address translation.

Rob

[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git earlycon

Rob Herring (7):
  x86: move FIX_EARLYCON_MEM kconfig into x86
  tty/serial: add generic serial earlycon
  tty/serial: convert 8250 to generic earlycon
  tty/serial: pl011: add generic earlycon support
(Continue reading)

Larry Baker | 18 Apr 23:53 2014
Picon

How can I help?

Greg and Johan (via linux-serial <at> vger.kernel.org),

I am hoping you will have some good advice for me, and maybe I can help you.

I am migrating a serial data acquisition app from a PC platform to a lower cost/lower power ARM SoC platform. 
The data come from the instrument over an RS-232 link that requires RTS/CTS handshaking.  It also uses a
packet-based handshaking protocol in software.  Serial ports with hardware handshaking have been
difficult to find on the SoC platforms I'm experimenting with, so I bought a USB-to-Serial adapter.  The
one I bought is identified as an FTDI FT232RL.  It sort of works.  What happens is, after about 8 or 9 hours, the
RX to the TTY port times out.  Sometimes it happens in only an hour, other times it takes about 14 hours.  After
about 10 seconds, it seems to recover.  Too late, though, for the application; it has already started its
abort sequence by then.

On the ARM SoC platform (CompuLab Utilite, Linux utilite 3.0.35-cm-fx6-5.5-rtscts-00002-g39389d3
#102 SMP Tue Apr 1 18:52:11 IDT 2014 armv7l armv7l armv7l GNU/Linux), the ftdi_sio driver is v1.6.0. To
eliminate the possibility it was a Linux ARM bug, I ran the same setup on an AtomPC.  I got the same result.  The
AtomPC runs CentOS 6.5 (CompuLab fit-PC2i, Linux fit-pc2i.wr.usgs.gov 2.6.32-431.5.1.el6.i686 #1
SMP Tue Feb 11 21:56:33 UTC 2014 i686 i686 i386 GNU/Linux), which has ftdi_sio driver v1.5.0.  I was blaming
the instrument, until I hooked it up to the COM1 port on the AtomPC and everything ran fine.  (The full
software handshaking protocol handling in my app is new; the other mode of operation is the device
continuously streams its data.  This last test confirmed that my software ha
 ndshaking was not at fault.)

I have seen people complain about problems using FTDI chips and questions about ARM compatibility.  I think
those were either pilot error or have been fixed by now.  (Though, I was surprised by a very recent post and a
patch as a result to add parity support to one of the non-FTDI drivers.  I would have taken parity support for
granted -- it seems pretty fundamental to serial data comm.)  The FTDI-based adapters seem to be the ones
that most people like.  I just ordered a couple adapters with Prolific chips to try.

Your names are at the top of the ftdi_sio driver source in the latest Linux kernel source tree, and I've seen
(Continue reading)

Greg KH | 18 Apr 23:37 2014

[GIT PULL] TTY/Serial fixes for 3.15-rc2

The following changes since commit c9eaa447e77efe77b7fa4c953bd62de8297fd6c5:

  Linux 3.15-rc1 (2014-04-13 14:18:35 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git/ tags/tty-3.15-rc2

for you to fetch changes up to 12de375ec493ab1767d4a07dde823e63ae5edc21:

  Revert "serial: 8250, disable "too much work" messages" (2014-04-17 09:33:19 -0700)

----------------------------------------------------------------
TTY/Serial driver fixes for 3.15-rc2

Here are a number of small tty/serial driver fixes for 3.15-rc2.  Also
in here are some Documentation file removals for drivers that we removed
a long time ago, no need to keep it around any longer.

All of these have been in linux-next for a bit.

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

----------------------------------------------------------------
Alexander Shiyan (1):
      Revert "serial: clps711x: Give a chance to perform useful tasks during wait loop"

Chen Tingjie (1):
      tty: fix memleak in alloc_pid

(Continue reading)

Loic Poulain | 18 Apr 15:56 2014
Picon

[PATCH] serial: 8250: Fix thread unsafe __dma_tx_complete function

__dma_tx_complete is not protected against concurrent
call of serial8250_tx_dma. it can lead to circular tail
index corruption or parallel call of serial_tx_dma on the
same data portion.

This patch fixes this issue by taking port lock before
call of serial8250_tx_dma.
Moreover it moves the "dma->tx_running = 0" after updating
tail index to avoid any dma tx with obsolete data.

The best solution should consist in locking the port for
all the function life. however, doing this leads to random
platform freezes. don't know why.

While waiting to get a better fix, this patch does the
job and avoid any perilous concurrent dma tx.

Signed-off-by: Loic Poulain <loic.poulain <at> intel.com>
---
 drivers/tty/serial/8250/8250_dma.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_dma.c b/drivers/tty/serial/8250/8250_dma.c
index 7046769..3a7b89f 100644
--- a/drivers/tty/serial/8250/8250_dma.c
+++ b/drivers/tty/serial/8250/8250_dma.c
 <at>  <at>  -20,8 +20,7  <at>  <at>  static void __dma_tx_complete(void *param)
 	struct uart_8250_port	*p = param;
 	struct uart_8250_dma	*dma = p->dma;
 	struct circ_buf		*xmit = &p->port.state->xmit;
(Continue reading)

Loic Poulain | 18 Apr 11:00 2014
Picon

[PATCHv2] 8250_dw: Support all baudrates on baytrail

In the same manner as 8250_pci, 8250_dw needs some
baytrail specific quirks to be used. The reference
clock needs to be adjusted before divided in order
to have the minimum error rate on the baudrate.

The specific byt set termios function is stored in
the driver_data field of the acpi device id via the
dw8250_acpi_desc structure.

Remove the uartclk field which is no longer delivered
as driver data.

Signed-off-by: Loic Poulain <loic.poulain <at> intel.com>
---
 v2: point directly to byt_set_termios
     remove uartclk driver data field

 drivers/tty/serial/8250/8250_dw.c | 81 +++++++++++++++++++++++++++++++++++++--
 1 file changed, 77 insertions(+), 4 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_dw.c b/drivers/tty/serial/8250/8250_dw.c
index ed31135..51b307a 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
 <at>  <at>  -62,6 +62,70  <at>  <at>  struct dw8250_data {
 	struct uart_8250_dma	dma;
 };

+struct dw8250_acpi_desc {
+	void (*set_termios)(struct uart_port *p, struct ktermios *termios,
(Continue reading)

Johannes Thumshirn | 17 Apr 11:44 2014
Picon

[PATCH] tty: serial: Add driver for MEN's 16z135 High Speed UART.

Add driver for MEN's 16z135 High Speed UART.

The 16z135 is a memory mapped UART Core on an MCB FPGA and has 1024 byte
deep FIFO buffers for the RX and TX path. It also has configurable FIFO
fill level IRQs and data copied to and from the hardware has to be
acknowledged.

Signed-off-by: Johannes Thumshirn <johannes.thumshirn <at> men.de>
---
 drivers/tty/serial/Kconfig         |  10 +
 drivers/tty/serial/Makefile        |   1 +
 drivers/tty/serial/men_z135_uart.c | 848 +++++++++++++++++++++++++++++++++++++
 include/uapi/linux/serial_core.h   |   3 +
 4 files changed, 862 insertions(+)
 create mode 100644 drivers/tty/serial/men_z135_uart.c

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 2e6d8dd..4cd81e2 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
 <at>  <at>  -1507,6 +1507,16  <at>  <at>  config SERIAL_ST_ASC_CONSOLE
 	depends on SERIAL_ST_ASC=y
 	select SERIAL_CORE_CONSOLE

+config SERIAL_MEN_Z135
+	tristate "MEN 16z135 Support"
+	depends on MCB
+	help
+	  Say yes here to enable support for the MEN 16z135 High Speed UART IP-Core
+	  on a MCB carrier.
(Continue reading)

Yoshihiro YUNOMAE | 17 Apr 08:06 2014
Picon

[PATCH V6] serial/uart/8250: Add tunable RX interrupt trigger I/F of FIFO buffers

Add tunable RX interrupt trigger I/F of FIFO buffers.
Serial devices are used as not only message communication devices but control
or sending communication devices. For the latter uses, normally small data
will be exchanged, so user applications want to receive data unit as soon as
possible for real-time tendency. If we have a sensor which sends a 1 byte data
each time and must control a device based on the sensor feedback, the RX
interrupt should be triggered for each data.

According to HW specification of serial UART devices, RX interrupt trigger
can be changed, but the trigger is hard-coded. For example, RX interrupt trigger
in 16550A can be set to 1, 4, 8, or 14 bytes for HW, but current driver sets
the trigger to only 8bytes.

This patch makes some devices change RX interrupt trigger from userland.

<How to use>
- Read current setting
 # cat /sys/dev/char/4\:64/rx_int_trig
 8

- Write user setting
 # echo 1 > /sys/dev/char/4\:64/rx_int_trig
 # cat /sys/dev/char/4\:64/rx_int_trig
 1

<Support uart devices>
- 16550A and Tegra (1, 4, 8, or 14 bytes)
- 16650V2 (8, 16, 24, or 28 bytes)
- 16654 (8, 16, 56, or 60 bytes)
- 16750 (1, 16, 32, or 56 bytes)
(Continue reading)

Loic Poulain | 16 Apr 18:48 2014
Picon

[PATCH] 8250_core: Fix unwanted TX chars write

On transmit-hold-register empty, serial8250_tx_chars
should be called only if we don't use DMA.
DMA has its own tx cycle.

Signed-off-by: Loic Poulain <loic.poulain <at> intel.com>
---
 drivers/tty/serial/8250/8250_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index 81f909c..0e1bf88 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
 <at>  <at>  -1520,7 +1520,7  <at>  <at>  int serial8250_handle_irq(struct uart_port *port, unsigned int iir)
 			status = serial8250_rx_chars(up, status);
 	}
 	serial8250_modem_status(up);
-	if (status & UART_LSR_THRE)
+	if (!up->dma && (status & UART_LSR_THRE))
 		serial8250_tx_chars(up);

 	spin_unlock_irqrestore(&port->lock, flags);
--

-- 
1.8.3.2

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
(Continue reading)

Loic Poulain | 16 Apr 18:43 2014
Picon

[PATCH] 8250_core: Fix unwanted TX chars write

On transmit-hold-register empty, serial8250_tx_chars
should be called only if we don't use DMA.
DMA has its own tx cycle.

Signed-off-by: Loic Poulain <loic.poulain <at> intel.com>
---
 drivers/tty/serial/8250/8250_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_core.c b/drivers/tty/serial/8250/8250_core.c
index 81f909c..0e1bf88 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
 <at>  <at>  -1520,7 +1520,7  <at>  <at>  int serial8250_handle_irq(struct uart_port *port, unsigned int iir)
 			status = serial8250_rx_chars(up, status);
 	}
 	serial8250_modem_status(up);
-	if (status & UART_LSR_THRE)
+	if (!up->dma && (status & UART_LSR_THRE))
 		serial8250_tx_chars(up);

 	spin_unlock_irqrestore(&port->lock, flags);
--

-- 
1.8.3.2

---------------------------------------------------------------------
Intel Corporation SAS (French simplified joint stock company)
Registered headquarters: "Les Montalets"- 2, rue de Paris, 
92196 Meudon Cedex, France
Registration Number:  302 456 199 R.C.S. NANTERRE
(Continue reading)


Gmane