1. 17 10月, 2013 2 次提交
    • H
      serial: imx: check the DMA for imx_tx_empty · 1ce43e58
      Huang Shijie 提交于
      Assume the following situation:
      
        If the DMA is enabled, and the a TX DMA operation is working,
      But we have not issued the TX DMA operation (or we have issued the
      TX DMA operation with dma_async_issue_pending(), but the DMA has not
      started to move the data from the memory to the TXFIFO).
      
      At this time, we may get the wrong status of the transmitter when we
      call the imx_tx_empty. In such situation, only check the USR2_TXDC
      does not enough for us.
      
      This patch checks the DMA's situation, and return 0 when the TX DMA is
      working.
      Signed-off-by: NHuang Shijie <b32955@freescale.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ce43e58
    • H
      serial: imx: implement the flush_buffer hook · eb56b7ed
      Huang Shijie 提交于
      The current driver does not implement the flush_buffer hook for
      uart_ops. When we enable the DMA for the driver, and test it with Bluetooth,
      we may meet the following bug for TX:
      
          [1] User application may call the flush operation at any time.
              The uart_flush_buffer() calls the uart_circ_clear() to set
              the xmit->head and xmit->tail with 0.
      
          [2] The TX DMA callback can be called at any time too.
              The dma_tx_call() will update the xmit->tail.
      
          If [2] occurs just after the [1], we will get the wrong xmit->tail.
      
      This patch implements the flush_buffer hook to fix this issue.
      Signed-off-by: NHuang Shijie <b32955@freescale.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eb56b7ed
  2. 27 9月, 2013 2 次提交
  3. 31 8月, 2013 1 次提交
  4. 13 8月, 2013 1 次提交
  5. 01 8月, 2013 1 次提交
  6. 27 7月, 2013 5 次提交
  7. 25 7月, 2013 1 次提交
  8. 18 6月, 2013 1 次提交
    • F
      serial: imx: Fix serial clock unbalance · 80c48497
      Fabio Estevam 提交于
      Since commit 0c375501 (serial: imx: enable the clocks for console), the
      imx_startup() function calls clk_prepare_enable conditionally, so we
      need to call clk_disable_unprepare inside imx_shutdown() under the same
      condition to avoid unbalanced clock calls.
      
      This avoids the following warning:
      
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 70 at drivers/clk/clk.c:780 __clk_disable+0x68/0x84()
      Modules linked in:
      CPU: 0 PID: 70 Comm: mountall Not tainted 3.10.0-rc4-next-20130607+ #435
      Backtrace:
      [<800116a4>] (dump_backtrace+0x0/0x10c) from [<80011844>] (show_stack+0x18/0x1c)
       r6:8069f4e8 r5:0000030c r4:00000000 r3:00000000
      [<8001182c>] (show_stack+0x0/0x1c) from [<8053bce0>] (dump_stack+0x78/0x94)
      [<8053bc68>] (dump_stack+0x0/0x94) from [<80023df8>] (warn_slowpath_common+0x6c/0x8c)
       r4:00000000 r3:00000000
      [<80023d8c>] (warn_slowpath_common+0x0/0x8c) from [<80023e3c>] (warn_slowpath_null+0x24/0x2c)
       r8:bf2ed008 r7:bfaa9810 r6:000f0013 r5:bf824b80 r4:bf824b80
      [<80023e18>] (warn_slowpath_null+0x0/0x2c) from [<8041af84>] (__clk_disable+0x68/0x84)
      [<8041af1c>] (__clk_disable+0x0/0x84) from [<8041b098>] (clk_disable+0x20/0x2c)
       r4:600f0013 r3:00000001
      [<8041b078>] (clk_disable+0x0/0x2c) from [<802c93e8>] (imx_shutdown+0xbc/0xec)
       r5:bf824b80 r4:bfaa9810
      [<802c932c>] (imx_shutdown+0x0/0xec) from [<802c63a0>] (uart_port_shutdown+0x34/0x40)
       r5:bf86f860 r4:bfaa9810
      [<802c636c>] (uart_port_shutdown+0x0/0x40) from [<802c68c0>] (uart_shutdown+0x98/0xc4)
       r4:bf86f800 r3:00000000
      [<802c6828>] (uart_shutdown+0x0/0xc4) from [<802c7514>] (uart_close+0x5c/0x198)
       r7:bfaa9810 r6:bf274400 r5:bf86f86c r4:bf86f800
      [<802c74b8>] (uart_close+0x0/0x198) from [<802ac648>] (tty_release+0xf8/0x500)
      [<802ac550>] (tty_release+0x0/0x500) from [<800c5a30>] (__fput+0x9c/0x208)
      [<800c5994>] (__fput+0x0/0x208) from [<800c5bac>] (____fput+0x10/0x14)
      [<800c5b9c>] (____fput+0x0/0x14) from [<80040234>] (task_work_run+0xb4/0xec)
      [<80040180>] (task_work_run+0x0/0xec) from [<80029238>] (do_exit+0x2b0/0x920)
       r8:8000e144 r7:000000f8 r6:bf306300 r5:00000000 r4:bfac1180
      [<80028f88>] (do_exit+0x0/0x920) from [<80029a4c>] (do_group_exit+0x50/0xd4)
       r7:000000f8
      [<800299fc>] (do_group_exit+0x0/0xd4) from [<80029ae8>] (__wake_up_parent+0x0/0x28)
       r7:000000f8 r6:00000001 r5:0006f7ae r4:0006f79a
      [<80029ad0>] (SyS_exit_group+0x0/0x18) from [<8000dfc0>] (ret_fast_syscall+0x0/0x30)
      ---[ end trace 16d080eb7efea4e9 ]---
      Reported-by: NShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Tested-by: NShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      80c48497
  9. 09 6月, 2013 1 次提交
  10. 07 6月, 2013 2 次提交
  11. 04 6月, 2013 2 次提交
  12. 21 5月, 2013 1 次提交
  13. 19 2月, 2013 1 次提交
  14. 15 2月, 2013 1 次提交
    • T
      serial: imx: Fix recursive locking bug · 677fe555
      Thomas Gleixner 提交于
      commit 9ec1882d (tty: serial: imx: console write routing is unsafe
      on SMP) introduced a recursive locking bug in imx_console_write().
      
      The callchain is:
      
      imx_rxint()
        spin_lock_irqsave(&sport->port.lock,flags);
        ...
        uart_handle_sysrq_char();
          sysrq_function();
            printk();
              imx_console_write();
                spin_lock_irqsave(&sport->port.lock,flags); <--- DEAD
      
      The bad news is that the kernel debugging facilities can dectect the
      problem, but the printks never surface on the serial console for
      obvious reasons.
      
      There is a similar issue with oops_in_progress. If the kernel crashes
      we really don't want to be stuck on the lock and unable to tell what
      happened.
      
      In general most UP originated drivers miss these checks and nobody
      ever notices because CONFIG_PROVE_LOCKING seems to be still ignored by
      a large number of developers.
      
      The solution is to avoid locking in the sysrq case and trylock in the
      oops_in_progress case.
      
      This scheme is used in other drivers as well and it would be nice if
      we could move this to a common place, so the usual copy/paste/modify
      bugs can be avoided.
      
      Now there is another issue with this scheme:
      
      CPU0 	    	     	 CPU1
      printk()
      			 rxint()
      			   sysrq_detection() -> sets port->sysrq
      			 return from interrupt
        console_write()
           if (port->sysrq)
           	avoid locking
      
      port->sysrq is reset with the next receive character. So as long as
      the port->sysrq is not reset and this can take an endless amount of
      time if after the break no futher receive character follows, all
      console writes happen unlocked.
      
      While the current writer is protected against other console writers by
      the console sem, it's unprotected against open/close or other
      operations which fiddle with the port. That's what the above mentioned
      commit tried to solve.
      
      That's an issue in all drivers which use that scheme and unfortunately
      there is no easy workaround. The only solution is to have a separate
      indicator port->sysrq_cpu. uart_handle_sysrq_char() then sets it to
      smp_processor_id() before calling into handle_sysrq() and resets it to
      -1 after that. Then change the locking check to:
      
           if (port->sysrq_cpu == smp_processor_id())
           	 locked = 0;
           else if (oops_in_progress)
               locked = spin_trylock_irqsave(port->lock, flags);
           else
        	 spin_lock_irqsave(port->lock, flags);
      
      That would force all other cpus into the spin_lock path. Problem
      solved, but that's way beyond the scope of this fix and really wants
      to be implemented in a common function which calls the uart specific
      write function to avoid another gazillion of hard to debug
      copy/paste/modify bugs.
      Reported-and-tested-by: NTim Sander <tim@krieglstein.org>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: stable <stable@vger.kernel.org>  # 3.6+
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      677fe555
  15. 07 2月, 2013 1 次提交
  16. 06 2月, 2013 1 次提交
  17. 18 1月, 2013 1 次提交
  18. 16 1月, 2013 7 次提交
  19. 22 9月, 2012 2 次提交
  20. 14 9月, 2012 1 次提交
  21. 06 9月, 2012 3 次提交
  22. 03 8月, 2012 1 次提交
  23. 01 7月, 2012 1 次提交