1. 27 3月, 2015 12 次提交
  2. 26 3月, 2015 6 次提交
  3. 07 3月, 2015 2 次提交
  4. 07 2月, 2015 1 次提交
  5. 03 2月, 2015 8 次提交
  6. 10 1月, 2015 2 次提交
    • V
      tty: 8250: Add 64byte UART support for FSL platforms · fddceb8b
      Vijay Rai 提交于
      Some of FSL SoCs like T1040 has new version of UART controller which
      can support 64byte FiFo.
      To enable 64 byte support, following needs to be done:
      -FCR[EN64] needs to be programmed to 1 to enable it.
      -Also, when FCR[EN64]==1, RTL bits to be used as below
      to define various Receive Trigger Levels:
              -FCR[RTL] = 00  1 byte
              -FCR[RTL] = 01  16 bytes
              -FCR[RTL] = 10  32 bytes
              -FCR[RTL] = 11  56 bytes
      -tx_loadsz is set to 63-bytes instead of 64-bytes to implement
       workaround of errata A-008006 which states that tx_loadsz should
       be configured less than Maximum supported fifo bytes
      Signed-off-by: NVijay Rai <vijay.rai@freescale.com>
      Signed-off-by: NPriyanka Jain <Priyanka.Jain@freescale.com>
      Signed-off-by: NPoonam Aggrwal <poonam.aggrwal@freescale.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fddceb8b
    • P
      serial: omap_8250: Fix RTS handling · 4bf4ea9d
      Peter Hurley 提交于
      The OMAP3 UART ignores MCR[1] (ie., UART_MCR_RTS) when in autoRTS
      mode (UPF_HARD_FLOW + CRTSCTS). This makes it impossible for either
      the serial core or userspace to manually flow control the sender.
      
      Disable autoRTS mode when RTS is lowered and restore the previous
      mode when RTS is raised.
      
      Note that the OMAP3 UART provides no mechanism for switching from
      autoRTS mode without corrupting incoming data; to access the
      necessary register, the line control settings must be set to 8-e-2
      and thus any data received during that time will be interpreted with
      those settings. This corruption has been observed in practice.
      
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NPeter Hurley <peter@hurleysoftware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4bf4ea9d
  7. 26 11月, 2014 1 次提交
    • R
      serial: 8250: don't attempt a trylock if in sysrq · 6fad18fa
      Rabin Vincent 提交于
      Attempting to use SysRq via the 8250 serial port with spin lock
      debugging on on a uniprocessor system results in the following splat:
      
       SysRq :
       BUG: spinlock trylock failure on UP on CPU#0, swapper/0
        lock: serial8250_ports+0x0/0x8c0, .magic: dead4ead, .owner: swapper/0, .owner_cpu: 0
       CPU: 0 PID: 0 Comm: swapper Not tainted 3.18.0-rc4+ #37
       Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.7.5-20140531_083030-gandalf 04/01/2014
        ffffffff8245ba00 ffffffff81628b28 ffffffff812c8d27 ffffffff81628b48
        ffffffff8106812e ffffffff8245ba00 ffffffff814e22ed ffffffff81628b68
        ffffffff810681a6 0000000000000000 0000000000000000 ffffffff81628b88
       Call Trace:
        <IRQ>  [<ffffffff812c8d27>] dump_stack+0x19/0x1b
        [<ffffffff8106812e>] spin_dump+0x7e/0xd0
        [<ffffffff810681a6>] spin_bug+0x26/0x30
        [<ffffffff8106843c>] do_raw_spin_trylock+0x4c/0x60
        [<ffffffff812cdb1d>] _raw_spin_trylock+0x1d/0x60
        [<ffffffff812336d8>] serial8250_console_write+0x68/0x190
        [<ffffffff811eb0b0>] ? sprintf+0x40/0x50
        [<ffffffff8106ab5e>] call_console_drivers.constprop.11+0x9e/0xf0
        [<ffffffff8106b276>] console_unlock+0x3e6/0x490
        [<ffffffff8106b595>] vprintk_emit+0x275/0x530
        [<ffffffff812c869a>] printk+0x4d/0x4f
        [<ffffffff8121e612>] __handle_sysrq+0x62/0x1b0
        [<ffffffff8121e5b5>] ? __handle_sysrq+0x5/0x1b0
        [<ffffffff8121ebc6>] handle_sysrq+0x26/0x30
        [<ffffffff81233157>] serial8250_rx_chars+0x1d7/0x250
        [<ffffffff812338bb>] serial8250_handle_irq+0x7b/0x90
        [<ffffffff812338f3>] serial8250_default_handle_irq+0x23/0x30
        [<ffffffff812318b3>] serial8250_interrupt+0x63/0xe0
        [<ffffffff8106d80e>] handle_irq_event_percpu+0x4e/0x200
        [<ffffffff8106da01>] handle_irq_event+0x41/0x70
        [<ffffffff810701ee>] ? handle_edge_irq+0x1e/0x110
        [<ffffffff8107026e>] handle_edge_irq+0x9e/0x110
        [<ffffffff810041c2>] handle_irq+0x22/0x40
        [<ffffffff812d096e>] do_IRQ+0x4e/0xf0
        [<ffffffff812cf4ed>] common_interrupt+0x6d/0x6d
        <EOI>  [<ffffffff8100acbf>] ? default_idle+0x1f/0xd0
        [<ffffffff8100acbd>] ? default_idle+0x1d/0xd0
        [<ffffffff8100b61f>] arch_cpu_idle+0xf/0x20
        [<ffffffff8105c1db>] cpu_startup_entry+0x25b/0x360
        [<ffffffff812c726e>] rest_init+0xbe/0xd0
        [<ffffffff816a4dcb>] start_kernel+0x339/0x346
        [<ffffffff816a4495>] x86_64_start_reservations+0x2a/0x2c
        [<ffffffff816a4589>] x86_64_start_kernel+0xf2/0xf6
       HELP : loglevel(0-9) reboot(b) crash(c) show-all-locks(d) te...
      
      Before ebade5e8 ("serial: 8250: Clean up the locking for -rt")
      this was handled by not even attempting to try the lock if port->sysrq,
      since it is known to be taken by the interrupt handler; see
      https://bugzilla.kernel.org/show_bug.cgi?id=6716#c1.  Restore that
      behavior.
      Signed-off-by: NRabin Vincent <rabin@rab.in>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6fad18fa
  8. 07 11月, 2014 7 次提交
  9. 06 11月, 2014 1 次提交