tty: serial: 8250_omap: add custom DMA-TX callback
authorSebastian Andrzej Siewior <bigeasy@linutronix.de>
Mon, 29 Sep 2014 18:06:43 +0000 (20:06 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Thu, 6 Nov 2014 03:10:07 +0000 (19:10 -0800)
commit31a171328e870c9f65d01191e51a75cde5f78ffd
treeda97b9102b4803eb5218e3008791b1e9d8f5b3ae
parentf1a297bb044265efafd9b941d00d52cb66835695
tty: serial: 8250_omap: add custom DMA-TX callback

This patch provides mostly a copy of serial8250_tx_dma() +
__dma_tx_complete() with the following extensions:

- DMA bug
  At least on AM335x the following problem exists: Even if the TX FIFO is
  empty and a TX transfer is programmed (and started) the UART does not
  trigger the DMA transfer.
  After $TRESHOLD number of bytes have been written to the FIFO manually the
  UART reevaluates the whole situation and decides that now there is enough
  room in the FIFO and so the transfer begins.
  This problem has not been seen on DRA7 or beagle board xm (OMAP3). I am not
  sure if this is UART-IP core specific or DMA engine.

  The workaround is to use a threshold of one byte, program the DMA
  transfer minus one byte and then to put the first byte into the FIFO to
  kick start the transfer.

- support for runtime PM
  RPM is enabled on start_tx(). We can't disable RPM on DMA complete callback
  because there is still data in the FIFO which is being sent. We have to wait
  until the FIFO is empty before we disable it.
  For this to happen we fake a TX sent error and enable THRI. Once the
  FIFO is empty we receive an interrupt and since the TTY-buffer is still
  empty we "put RPM" via __stop_tx(). Should it been filed then in the
  start_tx() path we should program the DMA transfer and remove the error
  flag and the THRI bit.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Reviewed-by: Peter Hurley <peter@hurleysoftware.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
drivers/tty/serial/8250/8250_omap.c
include/uapi/linux/serial_reg.h