Skip to content
  1. Apr 11, 2013
  3. Apr 05, 2013
  5. Apr 03, 2013
  7. Mar 29, 2013
    • Chanho Min's avatar
      ARM: PL011: Add support for Rx DMA buffer polling. · cb06ff10
      Chanho Min authored 
      

In DMA support, The received data is not pushed to tty until the DMA buffer
is filled. But some megabyte rate chips such as BT expect fast response and
data should be pushed immediately. In order to fix this issue, We suggest
the use of the timer for polling DMA buffer.
In our test, no data loss occurred at high-baudrate as compared with interrupt-
driven (We tested with 3Mbps).
We changes:

- We add timer for polling. If we set poll_timer to 10, every 10ms,
 timer handler checks the residue in the dma buffer and transfer data
 to the tty. Also, last_residue is updated for the next polling.

- poll_timeout is used to prevent the timer's system cost.
  If poll_timeout is set to 3000 and no data is received in 3 seconds,
  we inactivate poll timer and driver falls back to interrupt-driven.
  When data is received again in FIFO and UART irq is occurred, we switch
  back to DMA mode and start polling.

- We use consistent DMA mappings to avoid from the frequent cache operation
  of the timer function for default.

- pl011_dma_rx_chars is modified. the pending size is recalculated because
  data can be taken by polling.

- the polling time is adjusted if dma rx poll is enabled but no rate is
  specified. Ideal polling interval to push 1 character at every interval
  is the reciprocal of 'baud rate / 10 line bits per character / 1000 ms
  per sec'. But It is very aggressive to system. Experimentally,
 '10000000 / baud' is suitable to receive dozens of characters. the poll rate
 can be specified statically by dma_rx_poll_rate of the platform data as well.

Changes compared to v1:
 - Use of consistent DMA mappings.
 - Added dma_rx_poll_rate in platform data to specify the polling interval.
 - Added dma_rx_poll_timeout in platform data to specify the polling timeout.

Changes compared to v2:
 - Use of consistent DMA mappings for default.
 - Added dma_rx_poll_enable in platform data to adjust the polling time
   according to the baud rate.
 - remove unnecessary lock from the polling function.

Signed-off-by: default avatarChanho Min <chanho.min@lge.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cb06ff10
  9. Mar 28, 2013
  11. Mar 25, 2013
  13. Mar 19, 2013
    • Zhang Yanfei's avatar
      driver: tty: serial: remove cast for kzalloc return value · b9a129f4
      Zhang Yanfei authored 
      

remove cast for kzalloc return value.

Signed-off-by: default avatarZhang Yanfei <zhangyanfei@cn.fujitsu.com>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b9a129f4
    • Jiri Slaby's avatar
      TTY: serial, stop accessing potential NULLs · 7bbe08d6
      Jiri Slaby authored 
      

The following commits:
* 6732c8bb (TTY: switch
  tty_schedule_flip)
* 2e124b4a (TTY: switch
  tty_flip_buffer_push)
* 05c7cd39 (TTY: switch
  tty_insert_flip_string)
* 92a19f9c (TTY: switch
  tty_insert_flip_char)
* 227434f8 (TTY: switch
  tty_buffer_request_room to tty_port)

introduced a potential NULL dereference to some drivers. In
particular, when the device is used as a console, incoming bytes can
kill the box. This is caused by removed checks for TTY against NULL.

It happened because it was unclear to me why the checks were there. I
assumed them superfluous because the interrupts were unbound or
otherwise stopped. But this is not the case for consoles for these
drivers, as was pointed out by David Miller.

Now, this patch re-introduces the checks (at this point we check
port->state, not the tty proper, as we do not care about tty pointers
anymore). For both of the drivers, we place the check below the
handling of break signal so that sysrq can actually work. (One needs
to issue a break and then sysrq key within the following 5 seconds.)

We do not change sc26xx, sunhv, and sunsu here because they behave the
same as before.  People having that hardware should fix the driver
eventually, however. They always could unconditionally dereference tty
in receive_chars, port->state in uart_handle_dcd_change, and
up->port.state->port.tty.

There is perhaps more to fix in all those drivers, but they are at
least in a state they were before.

Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: sparclinux@vger.kernel.org
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7bbe08d6
  15. Mar 18, 2013