1. 27 3月, 2015 1 次提交
  2. 24 3月, 2015 1 次提交
  3. 11 3月, 2015 1 次提交
  4. 07 3月, 2015 3 次提交
  5. 10 1月, 2015 1 次提交
  6. 13 12月, 2014 1 次提交
  7. 26 11月, 2014 1 次提交
  8. 07 11月, 2014 1 次提交
  9. 06 11月, 2014 1 次提交
  10. 20 10月, 2014 1 次提交
  11. 11 9月, 2014 1 次提交
  12. 09 9月, 2014 1 次提交
  13. 28 7月, 2014 2 次提交
    • C
      serial: 8250_dw: Add support for deferred probing · c8ed99d4
      Chen-Yu Tsai 提交于
      The 8250_dw driver fails to probe if the specified clock isn't
      registered at probe time. Even if a clock frequency is given,
      the required clock might be gated because it wasn't properly
      enabled.
      
      This happened to me when the device is registered through DT,
      and the clock was part of an MFD, the PRCM found on A31 and A23
      SoCs. Unlike core clocks that are registered with OF_CLK_DECLARE,
      which happen almost immediately after the kernel starts, the
      clocks are registered as sub-devices of the PRCM MFD platform
      device. Even though devices are registered in the order they are
      found in the DT, the drivers are registered in a different,
      arbitrary order. It is possible that the 8250_dw driver is
      registered, and thus associated with the device and probed, before
      the clock driver is registered and probed.
      
      8250_dw then reports unable to get the clock, and fails. Without
      a working console, the kernel panics.
      
      This patch adds support for deferred probe handling for the clock
      and reset controller. It also fixes the cleanup path if
      serial8250_register_8250_port fails.
      Signed-off-by: NChen-Yu Tsai <wens@csie.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c8ed99d4
    • C
      serial: 8250_dw: Add optional reset control support · 7fe090bf
      Chen-Yu Tsai 提交于
      The Allwinner A31 and A23 SoCs have a reset controller
      maintaining the UART in reset by default.
      
      This patch adds optional reset support to the driver.
      Signed-off-by: NChen-Yu Tsai <wens@csie.org>
      Acked-by: NMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7fe090bf
  14. 18 7月, 2014 1 次提交
  15. 11 7月, 2014 3 次提交
  16. 25 4月, 2014 1 次提交
  17. 14 2月, 2014 1 次提交
  18. 08 1月, 2014 1 次提交
  19. 18 12月, 2013 1 次提交
  20. 17 12月, 2013 1 次提交
  21. 09 12月, 2013 2 次提交
  22. 04 10月, 2013 1 次提交
    • T
      serial: 8250_dw: Improve unwritable LCR workaround · c49436b6
      Tim Kryger 提交于
      When configured with UART_16550_COMPATIBLE=NO or in versions prior to
      the introduction of this option, the Designware UART will ignore writes
      to the LCR if the UART is busy.  The current workaround saves a copy of
      the last written LCR and re-writes it in the ISR for a special interrupt
      that is raised when a write was ignored.
      
      Unfortunately, interrupts are typically disabled prior to performing a
      sequence of register writes that include the LCR so the point at which
      the retry occurs is too late.  An example is serial8250_do_set_termios()
      where an ignored LCR write results in the baud divisor not being set and
      instead a garbage character is sent out the transmitter.
      
      Furthermore, since serial_port_out() offers no way to indicate failure,
      a serious effort must be made to ensure that the LCR is actually updated
      before returning back to the caller.  This is difficult, however, as a
      UART that was busy during the first attempt is likely to still be busy
      when a subsequent attempt is made unless some extra action is taken.
      
      This updated workaround reads back the LCR after each write to confirm
      that the new value was accepted by the hardware.  Should the hardware
      ignore a write, the TX/RX FIFOs are cleared and the receive buffer read
      before attempting to rewrite the LCR out of the hope that doing so will
      force the UART into an idle state.  While this may seem unnecessarily
      aggressive, writes to the LCR are used to change the baud rate, parity,
      stop bit, or data length so the data that may be lost is likely not
      important.  Admittedly, this is far from ideal but it seems to be the
      best that can be done given the hardware limitations.
      
      Lastly, the revised workaround doesn't touch the LCR in the ISR, so it
      avoids the possibility of a "serial8250: too much work for irq" lock up.
      This problem is rare in real situations but can be reproduced easily by
      wiring up two UARTs and running the following commands.
      
        # stty -F /dev/ttyS1 echo
        # stty -F /dev/ttyS2 echo
        # cat /dev/ttyS1 &
        [1] 375
        # echo asdf > /dev/ttyS1
        asdf
      
        [   27.700000] serial8250: too much work for irq96
        [   27.700000] serial8250: too much work for irq96
        [   27.710000] serial8250: too much work for irq96
        [   27.710000] serial8250: too much work for irq96
        [   27.720000] serial8250: too much work for irq96
        [   27.720000] serial8250: too much work for irq96
        [   27.730000] serial8250: too much work for irq96
        [   27.730000] serial8250: too much work for irq96
        [   27.740000] serial8250: too much work for irq96
      Signed-off-by: NTim Kryger <tim.kryger@linaro.org>
      Reviewed-by: NMatt Porter <matt.porter@linaro.org>
      Reviewed-by: NMarkus Mayer <markus.mayer@linaro.org>
      Reviewed-by: NHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c49436b6
  23. 28 9月, 2013 1 次提交
  24. 27 9月, 2013 2 次提交
  25. 20 8月, 2013 1 次提交
    • T
      serial: 8250_dw: Report CTS asserted for auto flow · 33acbb82
      Tim Kryger 提交于
      When a serial port is configured for RTS/CTS flow control, serial core
      will disable the transmitter if it observes CTS is de-asserted. This is
      perfectly reasonable and appropriate when the UART lacks the ability to
      automatically perform CTS flow control.
      
      However, if the UART hardware can manage flow control automatically, it
      is important that software not get involved.  When the DesignWare UART
      enables 16C750 style auto-RTS/CTS it stops generating interrupts for
      changes in CTS state so software mostly stays out of the way.  However,
      it does report the true state of CTS in the MSR so software may notice
      it is de-asserted and respond by improperly disabling the transmitter.
      Once this happens the transmitter will be blocked forever.
      
      To avoid this situation, we simply lie to the 8250 and serial core by
      reporting that CTS is asserted whenever auto-RTS/CTS mode is enabled.
      Signed-off-by: NTim Kryger <tim.kryger@linaro.org>
      Reviewed-by: NMatt Porter <matt.porter@linaro.org>
      Reviewed-by: NMarkus Mayer <markus.mayer@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      33acbb82
  26. 01 7月, 2013 1 次提交
  27. 22 5月, 2013 1 次提交
  28. 21 5月, 2013 1 次提交
  29. 13 4月, 2013 1 次提交
  30. 12 4月, 2013 4 次提交