1. 14 7月, 2011 4 次提交
    • P
      dmaengine: remove ste_dma40 from issue_pending TODO · 78fdaec3
      Per Forlin 提交于
      ste_dma40 now implements issue_pending according to documentation.
      Submit adds descriptos to a pending queue with are flushed down to the DMAC
      at issue_pending.
      Signed-off-by: NPer Forlin <per.forlin@linaro.org>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      78fdaec3
    • P
      dmaengine/ste_dma40: add a separate queue for pending requests · a8f3067b
      Per Forlin 提交于
      tx_submit will add descriptors to the pending queue. Issue pending
      will then move the pending descriptors to the transfer queue.
      Signed-off-by: NPer Forlin <per.forlin@linaro.org>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      a8f3067b
    • A
      pch_dma: Fix channel locking · 70f18915
      Alexander Stein 提交于
      Fix for the following INFO message
      
      =================================
      [ INFO: inconsistent lock state ]
      2.6.39+ #89
      ---------------------------------
      inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
      rs232/822 [HC1[1]:SC0[0]:HE0:SE1] takes:
       (&(&pd_chan->lock)->rlock){?.....}, at: [<c123b9a1>] pdc_desc_get+0x16/0xab
      {HARDIRQ-ON-W} state was registered at:
        [<c104fe28>] mark_irqflags+0xbd/0x11a
        [<c1050386>] __lock_acquire+0x501/0x6bb
        [<c1050945>] lock_acquire+0x63/0x7b
        [<c131c51d>] _raw_spin_lock_bh+0x43/0x51
        [<c123bee4>] pd_alloc_chan_resources+0x92/0x11e
        [<c123ad62>] dma_chan_get+0x9b/0x107
        [<c123b2d1>] __dma_request_channel+0x61/0xdc
        [<c11ba24b>] pch_request_dma+0x61/0x19e
        [<c11bb3b8>] pch_uart_startup+0x16a/0x1a2
        [<c11b8446>] uart_startup+0x87/0x147
        [<c11b9183>] uart_open+0x117/0x13e
        [<c11a5c7d>] tty_open+0x23c/0x34c
        [<c1097705>] chrdev_open+0x140/0x15f
        [<c10930a6>] __dentry_open.clone.14+0x14a/0x22b
        [<c1093dfb>] nameidata_to_filp+0x36/0x40
        [<c109f28b>] do_last+0x513/0x635
        [<c109f4af>] path_openat+0x9c/0x2aa
        [<c109f6e4>] do_filp_open+0x27/0x69
        [<c1093f02>] do_sys_open+0xfd/0x184
        [<c1093fad>] sys_open+0x24/0x2a
        [<c131d58c>] sysenter_do_call+0x12/0x32
      irq event stamp: 2522
      hardirqs last  enabled at (2521): [<c131ca3b>] _raw_spin_unlock_irqrestore+0x36/0x52
      hardirqs last disabled at (2522): [<c131db27>] common_interrupt+0x27/0x34
      softirqs last  enabled at (2354): [<c102fa11>] __do_softirq+0x10a/0x11a
      softirqs last disabled at (2299): [<c10041a4>] do_softirq+0x57/0xa4
      
      other info that might help us debug this:
      2 locks held by rs232/822:
       #0:  (&tty->atomic_write_lock){+.+.+.}, at: [<c11a4b7a>] tty_write_lock+0x14/0x3c
       #1:  (&port_lock_key){-.....}, at: [<c11bad72>] pch_uart_interrupt+0x17/0x1e9
      
      stack backtrace:
      Pid: 822, comm: rs232 Not tainted 2.6.39+ #89
      Call Trace:
       [<c1319f90>] ? printk+0x19/0x1b
       [<c104f893>] print_usage_bug+0x184/0x18f
       [<c104e5b1>] ? print_irq_inversion_bug+0x10e/0x10e
       [<c104f943>] mark_lock_irq+0xa5/0x1f6
       [<c104fc9c>] mark_lock+0x208/0x2d7
       [<c104fdc0>] mark_irqflags+0x55/0x11a
       [<c1050386>] __lock_acquire+0x501/0x6bb
       [<c10042ee>] ? dump_trace+0x92/0xb6
       [<c1050945>] lock_acquire+0x63/0x7b
       [<c123b9a1>] ? pdc_desc_get+0x16/0xab
       [<c131c2d0>] _raw_spin_lock+0x3e/0x4c
       [<c123b9a1>] ? pdc_desc_get+0x16/0xab
       [<c123b9a1>] pdc_desc_get+0x16/0xab
       [<c10504d8>] ? __lock_acquire+0x653/0x6bb
       [<c123bb2c>] pd_prep_slave_sg+0x7c/0x1cb
       [<c1006c3f>] ? nommu_map_sg+0x6e/0x81
       [<c11bace6>] dma_handle_tx+0x2cf/0x344
       [<c11bad72>] ? pch_uart_interrupt+0x17/0x1e9
       [<c11baebb>] pch_uart_interrupt+0x160/0x1e9
       [<c10642fb>] handle_irq_event_percpu+0x25/0x127
       [<c1064429>] handle_irq_event+0x2c/0x43
       [<c1065e0d>] ? handle_fasteoi_irq+0x84/0x84
       [<c1065eb9>] handle_edge_irq+0xac/0xce
       <IRQ>  [<c1003ecb>] ? do_IRQ+0x38/0x9d
       [<c131db2e>] ? common_interrupt+0x2e/0x34
       [<c105007b>] ? __lock_acquire+0x1f6/0x6bb
       [<c131ca3d>] ? _raw_spin_unlock_irqrestore+0x38/0x52
       [<c11b798b>] ? uart_start+0x2d/0x32
       [<c11b7998>] ? uart_flush_chars+0x8/0xa
       [<c11a7962>] ? n_tty_write+0x12c/0x1c6
       [<c1027a73>] ? try_to_wake_up+0x251/0x251
       [<c11a4d0b>] ? tty_write+0x169/0x1dc
       [<c11a7836>] ? n_tty_ioctl+0xb7/0xb7
       [<c1094841>] ? vfs_write+0x91/0x10d
       [<c11a4ba2>] ? tty_write_lock+0x3c/0x3c
       [<c1094a69>] ? sys_write+0x3e/0x63
       [<c131d58c>] ? sysenter_do_call+0x12/0x32
      Signed-off-by: NAlexander Stein <alexander.stein@systec-electronic.com>
      Tested-by: NTomoya MORINAGA <tomoya-linux@dsn.okisemi.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      70f18915
    • H
      dma: mv_xor: use resource_size() · 4de1ba15
      H Hartley Sweeten 提交于
      Signed-off-by: NH Hartley Sweeten <hsweeten@visionengravers.com>
      Cc: Dan Williams <dan.j.williams@intel.com> (supporter:ASYNCHRONOUS TRAN...)
      Cc: Vinod Koul <vinod.koul@intel.com> (supporter:DMA GENERIC OFFLO...)
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      4de1ba15
  2. 24 6月, 2011 1 次提交
  3. 16 6月, 2011 1 次提交
  4. 10 6月, 2011 1 次提交
  5. 09 6月, 2011 7 次提交
  6. 06 6月, 2011 12 次提交
  7. 05 6月, 2011 4 次提交
  8. 04 6月, 2011 10 次提交