1. 19 9月, 2017 1 次提交
  2. 29 8月, 2017 2 次提交
  3. 30 7月, 2017 1 次提交
  4. 17 7月, 2017 2 次提交
  5. 29 6月, 2017 3 次提交
  6. 25 5月, 2017 1 次提交
  7. 18 5月, 2017 1 次提交
  8. 12 4月, 2017 1 次提交
  9. 09 4月, 2017 1 次提交
  10. 31 1月, 2017 2 次提交
    • F
      serial: imx: Fix the CTS_B polarity in RS485 mode · bc2be239
      Fabio Estevam 提交于
      When userspace passes the SER_RS485_RTS_ON_SEND flag it means that the
      CTS_B pin should go to logic level high before the transmission begins.
      
      CTS_B goes to logic level high when both CTSC and CTS bits are cleared.
      
      When userspace passes the SER_RS485_RTS_AFTER_SEND flag it means that the
      CTS_B pin should go to logic level low after the transmission finishes.
      
      CTS_B goes to logic level low when CTSC bit is cleared and CTS bit is set.
      
      So fix the CTS_B polarity logic.
      Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bc2be239
    • F
      serial: imx: Fix the RTS GPIO polarity in RS485 mode · 1a613626
      Fabio Estevam 提交于
      On a board that needs to drive RTS GPIO high in order to enable the
      transmission of a RS485 transceiver the following description is
      passed in the devide tree:
      
      &uart4 {
              pinctrl-names = "default";
              pinctrl-0 = <&pinctrl_uart4>;
              rts-gpios = <&gpio6 2 GPIO_ACTIVE_HIGH>;
              status = "okay";
      };
      
      and userspace configures the uart port as follows:
      
      /* enable RS485 mode: */
      rs485conf.flags |= SER_RS485_ENABLED;
      
      /* set logical level for RTS pin equal to 1 when sending: */
      rs485conf.flags |= SER_RS485_RTS_ON_SEND;
      
      /* set logical level for RTS pin equal to 0 after sending: */
      rs485conf.flags &= ~(SER_RS485_RTS_AFTER_SEND);
      
      However the RTS GPIO polarity observed in the oscilloscope is inverted.
      
      When the SER_RS485_RTS_ON_SEND flag is set the imx_port_rts_active()
      function should be called and following the same logic when
      SER_RS485_RTS_AFTER_SEND flag is cleared the imx_port_rts_inactive()
      should be called.
      
      Do such logic change so that RS485 communication in half duplex can
      work successfully when the RTS GPIO pin is passed via device tree.
      Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1a613626
  11. 12 1月, 2017 1 次提交
  12. 27 9月, 2016 1 次提交
  13. 15 9月, 2016 1 次提交
  14. 14 9月, 2016 1 次提交
  15. 02 9月, 2016 2 次提交
  16. 31 8月, 2016 2 次提交
    • N
      serial: imx-serial - update RX error counters when DMA is used · 41d98b5d
      Nandor Han 提交于
      Update error counters when DMA is used for receiving data. Do
      this by using DMA transaction error event instead error interrupts
      to reduce interrupt load.
      Tested-by: NPeter Senna Tschudin <peter.senna@collabora.com>
      Acked-by: NPeter Senna Tschudin <peter.senna@collabora.com>
      Signed-off-by: NNandor Han <nandor.han@ge.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      41d98b5d
    • N
      serial: imx-serial - update UART IMX driver to use cyclic DMA · 9d297239
      Nandor Han 提交于
      The IMX UART has a 32 bytes HW buffer which can be filled up in
      2777us at 115200 baud or 80us at 4Mbaud (supported by IMX53).
      Taking this in consideration there is a good probability to lose
      data because of the DMA startup latency.
      Our tests (explained below) indicates a latency up to 4400us when
      creating interrupt load and ~70us without. When creating interrupt
      load I was able to see continuous overrun errors by checking serial
      driver statistics using the command:
      `cat /proc/tty/driver/IMX-uart`.
      
      Replace manual restart of DMA with cyclic DMA to eliminate data loss
      due to DMA engine startup latency (similar approch to atmel_serial.c
      driver). As result the DMA engine will start on the first serial data
      transfer and stops only when serial port is closed.
      
      Tests environment:
       Using the m53evk board I have used a GPIO for profiling the IMX
       serial driver.
        - The RX line and GPIO were connected to oscilloscope.
        - Run a small test program on the m53evk board that will only open
          and read data from ttymxc2 port.
        - Connect the ttymxc2 port to my laptop using a USB serial converter
          where another test program is running, able to send configurable
          packet lengths and intervals.
        - Serial ports configured at 115200 8N1.
        - Interrupts load created by disconnecting/connecting (3s interval)
          a USB hub, using a digital switch, with 4 USB devices (USB-Serial
          converter, USB SD card, etc) connected.
          (around 160 interrupts/second generated)
        - The GPIO was toggled HI in the `imx_int` when USR1_RRDY or USR1_AGTIM
          events are received and toggled back, once the DMA configuration
          is finalized, at the end of `imx_dma_rxint`.
      
      Measurements:
      The measurements were done from the end of the last byte (RX line) until
      the GPIO was toggled back LOW.
      
      Note: The GPIO toggling was done using `gpiod_set_value` method.
      
      Tests performed:
         1. Sending 9 bytes packets at 8ms interval. Having the 9 bytes packets
            will activate the RRDY threshold event and IMX serial interrupt
            called.
            Results:
              - DMA start latency (interrupt start latency +
                 DMA configuration) consistently 70us when system not loaded.
              - DMA start latency up to 4400us when system loaded.
         2. Sending 40 bytes packet at 8mS interval.
            Results with load:
              - Able to observe overruns by running:
                 `watch -n1 cat /proc/tty/driver/IMX-uart`
      Tested-by: NPeter Senna Tschudin <peter.senna@collabora.com>
      Acked-by: NPeter Senna Tschudin <peter.senna@collabora.com>
      Signed-off-by: NNandor Han <nandor.han@ge.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9d297239
  17. 01 5月, 2016 8 次提交
  18. 07 2月, 2016 1 次提交
    • M
      serial: imx: Fix suspend / resume. · 29add68d
      Martin Fuzzey 提交于
      When a non console i.MX UART is enabled in the device tree,
      system suspend fails due to an unprepared clock:
      
      [  638.794563] PM: Syncing filesystems ... done.
      [  638.878902] Freezing user space processes ... (elapsed 0.002 seconds) done.
      [  638.888454] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.
      [  638.996697] PM: suspend of devices complete after 97.200 msecs
      [  639.002611] PM: suspend devices took 0.100 seconds
      [  639.013020] PM: late suspend of devices complete after 2.288 msecs
      [  639.021486] ------------[ cut here ]------------
      [  639.026147] WARNING: CPU: 0 PID: 488 at drivers/clk/clk.c:732 clk_core_enable+0xc0/0x12c()
      [  639.034413] Modules linked in:
      [  639.037490] CPU: 0 PID: 488 Comm: system_server Tainted: G        W       4.4.0-rc5-pknbsp-svn2214-atag-v4.4-rc5-121-gebfd9cb #1304
      [  639.049312] Hardware name: Freescale i.MX53 (Device Tree Support)
      [  639.055444] [<c0016d54>] (unwind_backtrace) from [<c00140f8>] (show_stack+0x20/0x24)
      [  639.063199] [<c00140f8>] (show_stack) from [<c02c99a0>] (dump_stack+0x20/0x28)
      [  639.070442] [<c02c99a0>] (dump_stack) from [<c0024ca8>] (warn_slowpath_common+0x88/0xc0)
      [  639.078541] [<c0024ca8>] (warn_slowpath_common) from [<c0024d0c>] (warn_slowpath_null+0x2c/0x34)
      [  639.087332] [<c0024d0c>] (warn_slowpath_null) from [<c05171e8>] (clk_core_enable+0xc0/0x12c)
      [  639.095777] [<c05171e8>] (clk_core_enable) from [<c05172f8>] (clk_enable+0x2c/0x40)
      [  639.103441] [<c05172f8>] (clk_enable) from [<c0349880>] (imx_serial_port_suspend_noirq+0x20/0xe0)
      [  639.112336] [<c0349880>] (imx_serial_port_suspend_noirq) from [<c03a26a0>] (dpm_run_callback+0x68/0x16c)
      [  639.121825] [<c03a26a0>] (dpm_run_callback) from [<c03a2898>] (__device_suspend_noirq+0xf4/0x22c)
      [  639.130705] [<c03a2898>] (__device_suspend_noirq) from [<c03a4b0c>] (dpm_suspend_noirq+0x148/0x30c)
      [  639.139764] [<c03a4b0c>] (dpm_suspend_noirq) from [<c00511d4>] (suspend_devices_and_enter+0x2e8/0x6a4)
      [  639.149078] [<c00511d4>] (suspend_devices_and_enter) from [<c00518a0>] (pm_suspend+0x310/0x4b8)
      [  639.157782] [<c00518a0>] (pm_suspend) from [<c00500ec>] (state_store+0x7c/0xcc)
      [  639.165099] [<c00500ec>] (state_store) from [<c02cb6dc>] (kobj_attr_store+0x1c/0x28)
      [  639.172858] [<c02cb6dc>] (kobj_attr_store) from [<c01633d4>] (sysfs_kf_write+0x54/0x58)
      [  639.180871] [<c01633d4>] (sysfs_kf_write) from [<c01629b4>] (kernfs_fop_write+0x100/0x1c8)
      [  639.189152] [<c01629b4>] (kernfs_fop_write) from [<c00fb8b8>] (__vfs_write+0x3c/0xe8)
      [  639.196991] [<c00fb8b8>] (__vfs_write) from [<c00fc810>] (vfs_write+0xa4/0x160)
      [  639.204307] [<c00fc810>] (vfs_write) from [<c00fcac4>] (SyS_write+0x4c/0x98)
      [  639.211363] [<c00fcac4>] (SyS_write) from [<c0010760>] (ret_fast_syscall+0x0/0x3c)
      
      This does not happen for the common case of a single UART used as a console
      (since imx_console_setup() already does a prepare)
      Signed-off-by: NMartin Fuzzey <mfuzzey@parkeon.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      29add68d
  19. 14 12月, 2015 4 次提交
  20. 05 10月, 2015 4 次提交
    • F
      Revert "serial: imx: remove unbalanced clk_prepare" · 0c727a42
      Fabio Estevam 提交于
      This reverts commit 9e7b399d.
      
      Commit ("9e7b399d") causes the following warning and sometimes
      also hangs the system:
      
      ------------[ cut here ]------------
       WARNING: CPU: 0 PID: 0 at kernel/locking/mutex.c:868 mutex_trylock+0x20c/0x22c()
       DEBUG_LOCKS_WARN_ON(in_interrupt())
       Modules linked in:
      CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc7-next-20150818-00001-g14418a6 #4
      Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
      Backtrace:
      [<80012f08>] (dump_backtrace) from [<800130a4>] (show_stack+0x18/0x1c)
      r6:00000364 r5:00000000 r4:00000000 r3:00000000
      [<8001308c>] (show_stack) from [<807902b8>] (dump_stack+0x88/0xa4)
      [<80790230>] (dump_stack) from [<8002a604>] (warn_slowpath_common+0x80/0xbc)
      r5:807945c4 r4:80ab3b50
      [<8002a584>] (warn_slowpath_common) from [<8002a6e4>] (warn_slowpath_fmt+0x38/0x40)
      r8:00000000 r7:8131100c r6:8054c3cc r5:8131300c r4:80b0a570
      [<8002a6b0>] (warn_slowpath_fmt) from [<807945c4>] (mutex_trylock+0x20c/0x22c)
      r3:8095d0d8 r2:8095ab28
      [<807943b8>] (mutex_trylock) from [<8054c3cc>] (clk_prepare_lock+0x14/0xf4)
      r7:8131100c r6:be3f0c80 r5:00000037 r4:be3f0c80
      [<8054c3b8>] (clk_prepare_lock) from [<8054dbfc>] (clk_prepare+0x18/0x30)
      r5:00000037 r4:be3f0c80
      [<8054dbe4>] (clk_prepare) from [<8036a600>] (imx_console_write+0x30/0x244)
      r4:812d0bc8 r3:8132b9a4
      
      To reproduce the problem we only need to let the board idle for something
      like 30 seconds.
      
      Tested on a imx6q-sabresd.
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Reviewed-by: NEduardo Valentin <edubezval@gmail.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0c727a42
    • L
      serial: imx: also update RX stats in DMA path · abc7882a
      Lucas Stach 提交于
      The RX bytecount was only updated in the PIO path and thus
      the device erroneously reported a value of 0 if DMA is in
      use.
      Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
      Acked-by: NJiada Wang <jiada_wang@mentor.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      abc7882a
    • L
      serial: imx: re-enable DMA support without hardware flow control · 7e11577e
      Lucas Stach 提交于
      The commit enabling DMA support even if no flow control is present
      was reverted on the grounds that it uncovered a number of bugs in
      the code that lead to hanging tty devices and/or missing characters.
      
      After tracking down the issues it is clear that those were generic
      bugs and had nothing to do with flow control being present or not,
      only that allowing DMA without hardware flow control increased
      the exposure of that code a lot.
      
      Now that those bugs are fixed, it should be safe to re-enable DMA
      support.
      Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
      Acked-by: NJiada Wang <jiada_wang@mentor.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7e11577e
    • L
      serial: imx: don't use idle condition detect for DMA transfers · 905c0dec
      Lucas Stach 提交于
      The reference manual states that idle condition detect should not be used
      with DMA transfers, as the ROM SDMA scripts don't check those conditions.
      
      The RAM SDMA scripts worked around this, but the change broke compatibility
      with the ROM scripts.
      
      The previous commits fixed the DMA burst sizes, so that the aging timer is
      now working as described in the reference manual. With this fixed we can
      remove the hack of using the idle condition detect to stop the DMA transfer
      if there are no new characters incoming.
      
      This should work with both the ROM and RAM SDMA scripts.
      Signed-off-by: NLucas Stach <l.stach@pengutronix.de>
      Acked-by: NJiada Wang <jiada_wang@mentor.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      905c0dec