linux-toradex.git/drivers/tty/serial, branch v3.2-rt10

sysrq: Allow immediate Magic SysRq output for PREEMPT_RT_FULL

2012-01-16T19:00:36+00:00

Add a CONFIG option to allow the output from Magic SysRq to be output
immediately, even if this causes large latencies.

If PREEMPT_RT_FULL, printk() will not try to acquire the console lock
when interrupts or preemption are disabled.  If the console lock is
not acquired the printk() output will be buffered, but will not be
output immediately. Some drivers call into the Magic SysRq code
with interrupts or preemption disabled, so the output of Magic SysRq
will be buffered instead of printing immediately if this option is
not selected.

Even with this option selected, Magic SysRq output will be delayed
if the attempt to acquire the console lock fails.

Signed-off-by: Frank Rowand 
Link: http://lkml.kernel.org/r/4E7CEF60.5020508@am.sony.com
Signed-off-by: Thomas Gleixner

kgdb/serial: Short term workaround

2012-01-16T19:00:35+00:00

On 07/27/2011 04:37 PM, Thomas Gleixner wrote:
>  - KGDB (not yet disabled) is reportedly unusable on -rt right now due
>    to missing hacks in the console locking which I dropped on purpose.
>

To work around this in the short term you can use this patch, in
addition to the clocksource watchdog patch that Thomas brewed up.

Comments are welcome of course.  Ultimately the right solution is to
change separation between the console and the HW to have a polled mode
+ work queue so as not to introduce any kind of latency.

Thanks,
Jason.

rt: Improve the serial console PASS_LIMIT

2012-01-16T19:00:31+00:00

Beyond the warning:

 drivers/tty/serial/8250.c:1613:6: warning: unused variable ‘pass_counter’ [-Wunused-variable]

the solution of just looping infinitely was ugly - up it to 1 million to
give it a chance to continue in some really ugly situation.

Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner

drivers-tty-fix-omap-lock-crap.patch

2012-01-16T19:00:31+00:00

Signed-off-by: Thomas Gleixner

serial: 8250: Call flush_to_ldisc when the irq is threaded

2012-01-16T19:00:30+00:00

Signed-off-by: Ingo Molnar

serial: 8250: Clean up the locking for -rt

2012-01-16T19:00:30+00:00

Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner

Merge branch 'tty-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty

2011-11-22T04:36:46+00:00

* 'tty-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
  TTY: ldisc, wait for ldisc infinitely in hangup
  TTY: ldisc, move wait idle to caller
  TTY: ldisc, allow waiting for ldisc arbitrarily long
  Revert "tty/serial: Prevent drop of DCD on suspend for Tegra UARTs"
  RS485: fix inconsistencies in the meaning of some variables
  pch_uart: Fix DMA resource leak issue
  serial,mfd: Fix CMSPAR setup
  tty/serial: Prevent drop of DCD on suspend for Tegra UARTs
  pch_uart: Change company name OKI SEMICONDUCTOR to LAPIS Semiconductor
  pch_uart: Support new device LAPIS Semiconductor ML7831 IOH
  pch_uart: Fix hw-flow control issue
  tty: hvc_dcc: Fix duplicate character inputs
  jsm: Change maintainership

Revert "tty/serial: Prevent drop of DCD on suspend for Tegra UARTs"

2011-11-16T00:01:09+00:00

This reverts commit 9636b755da7b498094bdf15b4ce9f6fd16995e4e.

It wasn't supposed to be applied, thanks to Doug for letting me know.

Cc: Doug Anderson 
Signed-off-by: Greg Kroah-Hartman

RS485: fix inconsistencies in the meaning of some variables

2011-11-15T20:13:44+00:00

The crisv10.c and the atmel_serial.c serial drivers intepret the fields of the
serial_rs485 structure in a different way.

In particular, crisv10.c uses SER_RS485_RTS_AFTER_SEND and
SER_RS485_RTS_ON_SEND for the voltage of the RTS pin; atmel_serial.c,
instead, uses these values to know if a delay must be set before and
after sending.  This patch makes the usage of these variables consistent
across all drivers and fixes the Documentation as well.

From now on, SER_RS485_RTS_AFTER_SEND and SER_RS485_RTS_ON_SEND will be
used to set the voltage of the RTS pin (as in the crisv10.c driver); the
delay will be understood by looking only at the value of
delay_rts_before_send and delay_rts_after_send.

Signed-off-by: Claudio Scordino 
Signed-off-by: Darron Black 
Acked-by: Jesper Nilsson 
Acked-by: Nicolas Ferre 
Acked-by: Alan Cox 
Signed-off-by: Greg Kroah-Hartman

pch_uart: Fix DMA resource leak issue

2011-11-15T20:13:43+00:00

Changing UART mode PIO->DMA->PIO->DMA like below, pch_uart driver can't get
DMA channel resource.

setserial /dev/ttyPCH0 ^low_latency
setserial /dev/ttyPCH0 low_latency

CAUSE:
Changing mode using setserial command, ".startup" function which gets DMA
channel is called before ".verify_port" function which sets
dma-flag(use_dma/use_dma_flag) as 1.

PIO->DMA
  .startup: Since dma-flag is 0, DMA channel is not requested.
  .verify_port: dma-flag is set as 1.
  .shutdown: N/A

DMA->PIO
  .startup: Since dma-flag is 1, DMA channel is requested.
  .verify_port: dma-flag is set as 0.
  .shutdown: Since dma-flag is 0, DMA channel is not released.

This means DMA channel resource leak occurs.
Next time, this driver can't get DMA channel resource forever.

MODIFICATION:
  Currently, when release DMA channel resource, this driver checks dma-flag.
  However, this specification occurs the above issue.
  This driver must check whether dma_request_channel is executed or not.
  The values are saved in private data variable "chan_tx/chan_tx".
  These variables mean if the value is NULL, DMA channel is not requested,
  if not NULL, DMA channel is requested.

This patch fixes the issue.

Signed-off-by: Tomoya MORINAGA 
Acked-by: Alan Cox 
Cc: stable 
Signed-off-by: Greg Kroah-Hartman