1. 06 4月, 2019 1 次提交
    • A
      dmaengine: imx-dma: fix warning comparison of distinct pointer types · afacaf85
      Anders Roxell 提交于
      [ Upstream commit 9227ab5643cb8350449502dd9e3168a873ab0e3b ]
      
      The warning got introduced by commit 930507c18304 ("arm64: add basic
      Kconfig symbols for i.MX8"). Since it got enabled for arm64. The warning
      haven't been seen before since size_t was 'unsigned int' when built on
      arm32.
      
      ../drivers/dma/imx-dma.c: In function ‘imxdma_sg_next’:
      ../include/linux/kernel.h:846:29: warning: comparison of distinct pointer types lacks a cast
         (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
                                   ^~
      ../include/linux/kernel.h:860:4: note: in expansion of macro ‘__typecheck’
         (__typecheck(x, y) && __no_side_effects(x, y))
          ^~~~~~~~~~~
      ../include/linux/kernel.h:870:24: note: in expansion of macro ‘__safe_cmp’
        __builtin_choose_expr(__safe_cmp(x, y), \
                              ^~~~~~~~~~
      ../include/linux/kernel.h:879:19: note: in expansion of macro ‘__careful_cmp’
       #define min(x, y) __careful_cmp(x, y, <)
                         ^~~~~~~~~~~~~
      ../drivers/dma/imx-dma.c:288:8: note: in expansion of macro ‘min’
        now = min(d->len, sg_dma_len(sg));
              ^~~
      
      Rework so that we use min_t and pass in the size_t that returns the
      minimum of two values, using the specified type.
      Signed-off-by: NAnders Roxell <anders.roxell@linaro.org>
      Acked-by: NOlof Johansson <olof@lixom.net>
      Reviewed-by: NFabio Estevam <festevam@gmail.com>
      Signed-off-by: NVinod Koul <vkoul@kernel.org>
      Signed-off-by: NSasha Levin <sashal@kernel.org>
      afacaf85
  2. 13 2月, 2019 1 次提交
    • L
      dmaengine: imx-dma: fix wrong callback invoke · 4a9e4bcd
      Leonid Iziumtsev 提交于
      commit 341198eda723c8c1cddbb006a89ad9e362502ea2 upstream.
      
      Once the "ld_queue" list is not empty, next descriptor will migrate
      into "ld_active" list. The "desc" variable will be overwritten
      during that transition. And later the dmaengine_desc_get_callback_invoke()
      will use it as an argument. As result we invoke wrong callback.
      
      That behaviour was in place since:
      commit fcaaba6c ("dmaengine: imx-dma: fix callback path in tasklet").
      But after commit 4cd13c21 ("softirq: Let ksoftirqd do its job")
      things got worse, since possible delay between tasklet_schedule()
      from DMA irq handler and actual tasklet function execution got bigger.
      And that gave more time for new DMA request to be submitted and
      to be put into "ld_queue" list.
      
      It has been noticed that DMA issue is causing problems for "mxc-mmc"
      driver. While stressing the system with heavy network traffic and
      writing/reading to/from sd card simultaneously the timeout may happen:
      
      10013000.sdhci: mxcmci_watchdog: read time out (status = 0x30004900)
      
      That often lead to file system corruption.
      Signed-off-by: NLeonid Iziumtsev <leonid.iziumtsev@gmail.com>
      Signed-off-by: NVinod Koul <vkoul@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4a9e4bcd
  3. 23 5月, 2018 1 次提交
  4. 21 1月, 2018 1 次提交
    • N
      ARM: 8745/1: get rid of __memzero() · ff5fdafc
      Nicolas Pitre 提交于
      The __memzero assembly code is almost identical to memset's except for
      two orr instructions. The runtime performance of __memset(p, n) and
      memset(p, 0, n) is accordingly almost identical.
      
      However, the memset() macro used to guard against a zero length and to
      call __memzero at compile time when the fill value is a constant zero
      interferes with compiler optimizations.
      
      Arnd found tha the test against a zero length brings up some new
      warnings with gcc v8:
      
        https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82103
      
      And successively rremoving the test against a zero length and the call
      to __memzero optimization produces the following kernel sizes for
      defconfig with gcc 6:
      
          text     data     bss       dec       hex  filename
      12248142  6278960  413588  18940690   1210312  vmlinux.orig
      12244474  6278960  413588  18937022   120f4be  vmlinux.no_zero_test
      12239160  6278960  413588  18931708   120dffc  vmlinux.no_memzero
      
      So it is probably not worth keeping __memzero around given that the
      compiler can do a better job at inlining trivial memset(p,0,n) on its
      own. And the memset code already handles a zero length just fine.
      Suggested-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NNicolas Pitre <nico@linaro.org>
      Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
      ff5fdafc
  5. 24 10月, 2017 1 次提交
  6. 02 6月, 2017 1 次提交
  7. 08 8月, 2016 1 次提交
  8. 16 7月, 2016 2 次提交
  9. 05 8月, 2015 1 次提交
  10. 07 7月, 2015 1 次提交
  11. 04 5月, 2015 1 次提交
  12. 22 12月, 2014 2 次提交
  13. 20 10月, 2014 1 次提交
  14. 04 8月, 2014 1 次提交
  15. 06 3月, 2014 2 次提交
  16. 31 10月, 2013 1 次提交
    • R
      dmaengine: imx-dma: fix format warnings · ac806a1c
      Russell King 提交于
      drivers/dma/imx-dma.c:575:3: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t'
      drivers/dma/imx-dma.c:575:3: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t'
      drivers/dma/imx-dma.c:589:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t'
      drivers/dma/imx-dma.c:599:4: warning: format '%x' expects argument of type 'unsigned int', but argument 9 has type 'dma_addr_t'
      drivers/dma/imx-dma.c:929:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t'
      drivers/dma/imx-dma.c:929:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t'
      drivers/dma/imx-dma.c:959:2: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t'
      drivers/dma/imx-dma.c:959:2: warning: format '%x' expects argument of type 'unsigned int', but argument 7 has type 'dma_addr_t'
      
      We can't use the %pa format for these because this relates to phys_addr_t,
      and dma_addr_t can be a different size.  So, fix these by converting them
      to %llx and casting the dma_addr_t to always be unsigned long long.
      
      While we're here, also use %zu for size_t.
      Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      ac806a1c
  17. 25 10月, 2013 1 次提交
  18. 04 10月, 2013 3 次提交
    • M
      dmaengine: imx-dma: fix callback path in tasklet · fcaaba6c
      Michael Grzeschik 提交于
      We need to free the ld_active list head before jumping into the callback
      routine. Otherwise the callback could run into issue_pending and change
      our ld_active list head we just going to free. This will run the channel
      list into an currupted and undefined state.
      Signed-off-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      fcaaba6c
    • M
      dmaengine: imx-dma: fix lockdep issue between irqhandler and tasklet · 5a276fa6
      Michael Grzeschik 提交于
      The tasklet and irqhandler are using spin_lock while other routines are
      using spin_lock_irqsave/restore. This leads to lockdep issues as
      described bellow. This patch is changing the code to use
      spinlock_irq_save/restore in both code pathes.
      
      As imxdma_xfer_desc always gets called with spin_lock_irqsave lock held,
      this patch also removes the spare call inside the routine to avoid
      double locking.
      
      [  403.358162] =================================
      [  403.362549] [ INFO: inconsistent lock state ]
      [  403.366945] 3.10.0-20130823+ #904 Not tainted
      [  403.371331] ---------------------------------
      [  403.375721] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
      [  403.381769] swapper/0 [HC0[0]:SC1[1]:HE1:SE0] takes:
      [  403.386762]  (&(&imxdma->lock)->rlock){?.-...}, at: [<c019d77c>] imxdma_tasklet+0x20/0x134
      [  403.395201] {IN-HARDIRQ-W} state was registered at:
      [  403.400108]   [<c004b264>] mark_lock+0x2a0/0x6b4
      [  403.404798]   [<c004d7c8>] __lock_acquire+0x650/0x1a64
      [  403.410004]   [<c004f15c>] lock_acquire+0x94/0xa8
      [  403.414773]   [<c02f74e4>] _raw_spin_lock+0x54/0x8c
      [  403.419720]   [<c019d094>] dma_irq_handler+0x78/0x254
      [  403.424845]   [<c0061124>] handle_irq_event_percpu+0x38/0x1b4
      [  403.430670]   [<c00612e4>] handle_irq_event+0x44/0x64
      [  403.435789]   [<c0063a70>] handle_level_irq+0xd8/0xf0
      [  403.440903]   [<c0060a20>] generic_handle_irq+0x28/0x38
      [  403.446194]   [<c0009cc4>] handle_IRQ+0x68/0x8c
      [  403.450789]   [<c0008714>] avic_handle_irq+0x3c/0x48
      [  403.455811]   [<c0008f84>] __irq_svc+0x44/0x74
      [  403.460314]   [<c0040b04>] cpu_startup_entry+0x88/0xf4
      [  403.465525]   [<c02f00d0>] rest_init+0xb8/0xe0
      [  403.470045]   [<c03e07dc>] start_kernel+0x28c/0x2d4
      [  403.474986]   [<a0008040>] 0xa0008040
      [  403.478709] irq event stamp: 50854
      [  403.482140] hardirqs last  enabled at (50854): [<c001c6b8>] tasklet_action+0x38/0xdc
      [  403.489954] hardirqs last disabled at (50853): [<c001c6a0>] tasklet_action+0x20/0xdc
      [  403.497761] softirqs last  enabled at (50850): [<c001bc64>] _local_bh_enable+0x14/0x18
      [  403.505741] softirqs last disabled at (50851): [<c001c268>] irq_exit+0x88/0xdc
      [  403.513026]
      [  403.513026] other info that might help us debug this:
      [  403.519593]  Possible unsafe locking scenario:
      [  403.519593]
      [  403.525548]        CPU0
      [  403.528020]        ----
      [  403.530491]   lock(&(&imxdma->lock)->rlock);
      [  403.534828]   <Interrupt>
      [  403.537474]     lock(&(&imxdma->lock)->rlock);
      [  403.541983]
      [  403.541983]  *** DEADLOCK ***
      [  403.541983]
      [  403.547951] no locks held by swapper/0.
      [  403.551813]
      [  403.551813] stack backtrace:
      [  403.556222] CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.0-20130823+ #904
      [  403.563039] Backtrace:
      [  403.565581] [<c000b98c>] (dump_backtrace+0x0/0x10c) from [<c000bb28>] (show_stack+0x18/0x1c)
      [  403.574054]  r6:00000000 r5:c05c51d8 r4:c040bd58 r3:00200000
      [  403.579872] [<c000bb10>] (show_stack+0x0/0x1c) from [<c02f398c>] (dump_stack+0x20/0x28)
      [  403.587955] [<c02f396c>] (dump_stack+0x0/0x28) from [<c02f29c8>] (print_usage_bug.part.28+0x224/0x28c)
      [  403.597340] [<c02f27a4>] (print_usage_bug.part.28+0x0/0x28c) from [<c004b404>] (mark_lock+0x440/0x6b4)
      [  403.606682]  r8:c004a41c r7:00000000 r6:c040bd58 r5:c040c040 r4:00000002
      [  403.613566] [<c004afc4>] (mark_lock+0x0/0x6b4) from [<c004d844>] (__lock_acquire+0x6cc/0x1a64)
      [  403.622244] [<c004d178>] (__lock_acquire+0x0/0x1a64) from [<c004f15c>] (lock_acquire+0x94/0xa8)
      [  403.631010] [<c004f0c8>] (lock_acquire+0x0/0xa8) from [<c02f74e4>] (_raw_spin_lock+0x54/0x8c)
      [  403.639614] [<c02f7490>] (_raw_spin_lock+0x0/0x8c) from [<c019d77c>] (imxdma_tasklet+0x20/0x134)
      [  403.648434]  r6:c3847010 r5:c040e890 r4:c38470d4
      [  403.653194] [<c019d75c>] (imxdma_tasklet+0x0/0x134) from [<c001c70c>] (tasklet_action+0x8c/0xdc)
      [  403.662013]  r8:c0599160 r7:00000000 r6:00000000 r5:c040e890 r4:c3847114 r3:c019d75c
      [  403.670042] [<c001c680>] (tasklet_action+0x0/0xdc) from [<c001bd4c>] (__do_softirq+0xe4/0x1f0)
      [  403.678687]  r7:00000101 r6:c0402000 r5:c059919c r4:00000001
      [  403.684498] [<c001bc68>] (__do_softirq+0x0/0x1f0) from [<c001c268>] (irq_exit+0x88/0xdc)
      [  403.692652] [<c001c1e0>] (irq_exit+0x0/0xdc) from [<c0009cc8>] (handle_IRQ+0x6c/0x8c)
      [  403.700514]  r4:00000030 r3:00000110
      [  403.704192] [<c0009c5c>] (handle_IRQ+0x0/0x8c) from [<c0008714>] (avic_handle_irq+0x3c/0x48)
      [  403.712664]  r5:c0403f28 r4:c0593ebc
      [  403.716343] [<c00086d8>] (avic_handle_irq+0x0/0x48) from [<c0008f84>] (__irq_svc+0x44/0x74)
      [  403.724733] Exception stack(0xc0403f28 to 0xc0403f70)
      [  403.729841] 3f20:                   00000001 00000004 00000000 20000013 c0402000 c04104a8
      [  403.738078] 3f40: 00000002 c0b69620 a0004000 41069264 a03fb5f4 c0403f7c c0403f40 c0403f70
      [  403.746301] 3f60: c004b92c c0009e74 20000013 ffffffff
      [  403.751383]  r6:ffffffff r5:20000013 r4:c0009e74 r3:c004b92c
      [  403.757210] [<c0009e30>] (arch_cpu_idle+0x0/0x4c) from [<c0040b04>] (cpu_startup_entry+0x88/0xf4)
      [  403.766161] [<c0040a7c>] (cpu_startup_entry+0x0/0xf4) from [<c02f00d0>] (rest_init+0xb8/0xe0)
      [  403.774753] [<c02f0018>] (rest_init+0x0/0xe0) from [<c03e07dc>] (start_kernel+0x28c/0x2d4)
      [  403.783051]  r6:c03fc484 r5:ffffffff r4:c040a0e0
      [  403.787797] [<c03e0550>] (start_kernel+0x0/0x2d4) from [<a0008040>] (0xa0008040)
      Signed-off-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      5a276fa6
    • M
      dmaengine: imx-dma: fix slow path issue in prep_dma_cyclic · edc530fe
      Michael Grzeschik 提交于
      When perparing cyclic_dma buffers by the sound layer, it will dump the
      following lockdep trace. The leading snd_pcm_action_single get called
      with read_lock_irq called. To fix this, we change the kcalloc call from
      GFP_KERNEL to GFP_ATOMIC.
      
      WARNING: at kernel/lockdep.c:2740 lockdep_trace_alloc+0xcc/0x114()
      DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags))
      Modules linked in:
      CPU: 0 PID: 832 Comm: aplay Not tainted 3.11.0-20130823+ #903
      Backtrace:
      [<c000b98c>] (dump_backtrace+0x0/0x10c) from [<c000bb28>] (show_stack+0x18/0x1c)
       r6:c004c090 r5:00000009 r4:c2e0bd18 r3:00404000
      [<c000bb10>] (show_stack+0x0/0x1c) from [<c02f397c>] (dump_stack+0x20/0x28)
      [<c02f395c>] (dump_stack+0x0/0x28) from [<c001531c>] (warn_slowpath_common+0x54/0x70)
      [<c00152c8>] (warn_slowpath_common+0x0/0x70) from [<c00153dc>] (warn_slowpath_fmt+0x38/0x40)
       r8:00004000 r7:a3b90000 r6:000080d0 r5:60000093 r4:c2e0a000 r3:00000009
      [<c00153a4>] (warn_slowpath_fmt+0x0/0x40) from [<c004c090>] (lockdep_trace_alloc+0xcc/0x114)
       r3:c03955d8 r2:c03907db
      [<c004bfc4>] (lockdep_trace_alloc+0x0/0x114) from [<c008f16c>] (__kmalloc+0x34/0x118)
       r6:000080d0 r5:c3800120 r4:000080d0 r3:c040a0f8
      [<c008f138>] (__kmalloc+0x0/0x118) from [<c019c95c>] (imxdma_prep_dma_cyclic+0x64/0x168)
       r7:a3b90000 r6:00000004 r5:c39d8420 r4:c3847150
      [<c019c8f8>] (imxdma_prep_dma_cyclic+0x0/0x168) from [<c024618c>] (snd_dmaengine_pcm_trigger+0xa8/0x160)
      [<c02460e4>] (snd_dmaengine_pcm_trigger+0x0/0x160) from [<c0241fa8>] (soc_pcm_trigger+0x90/0xb4)
       r8:c058c7b0 r7:c3b8140c r6:c39da560 r5:00000001 r4:c3b81000
      [<c0241f18>] (soc_pcm_trigger+0x0/0xb4) from [<c022ece4>] (snd_pcm_do_start+0x2c/0x38)
       r7:00000000 r6:00000003 r5:c058c7b0 r4:c3b81000
      [<c022ecb8>] (snd_pcm_do_start+0x0/0x38) from [<c022e958>] (snd_pcm_action_single+0x40/0x6c)
      [<c022e918>] (snd_pcm_action_single+0x0/0x6c) from [<c022ea64>] (snd_pcm_action_lock_irq+0x7c/0x9c)
       r7:00000003 r6:c3b810f0 r5:c3b810f0 r4:c3b81000
      [<c022e9e8>] (snd_pcm_action_lock_irq+0x0/0x9c) from [<c023009c>] (snd_pcm_common_ioctl1+0x7f8/0xfd0)
       r8:c3b7f888 r7:005407b8 r6:c2c991c0 r5:c3b81000 r4:c3b81000 r3:00004142
      [<c022f8a4>] (snd_pcm_common_ioctl1+0x0/0xfd0) from [<c023117c>] (snd_pcm_playback_ioctl1+0x464/0x488)
      [<c0230d18>] (snd_pcm_playback_ioctl1+0x0/0x488) from [<c02311d4>] (snd_pcm_playback_ioctl+0x34/0x40)
       r8:c3b7f888 r7:00004142 r6:00000004 r5:c2c991c0 r4:005407b8
      [<c02311a0>] (snd_pcm_playback_ioctl+0x0/0x40) from [<c00a14a4>] (vfs_ioctl+0x30/0x44)
      [<c00a1474>] (vfs_ioctl+0x0/0x44) from [<c00a1fe8>] (do_vfs_ioctl+0x55c/0x5c0)
      [<c00a1a8c>] (do_vfs_ioctl+0x0/0x5c0) from [<c00a208c>] (SyS_ioctl+0x40/0x68)
      [<c00a204c>] (SyS_ioctl+0x0/0x68) from [<c0009380>] (ret_fast_syscall+0x0/0x44)
       r8:c0009544 r7:00000036 r6:bedeaa58 r5:00000000 r4:000000c0
      Signed-off-by: NMichael Grzeschik <m.grzeschik@pengutronix.de>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      edc530fe
  19. 02 9月, 2013 1 次提交
  20. 05 7月, 2013 2 次提交
  21. 15 4月, 2013 2 次提交
  22. 26 1月, 2013 1 次提交
  23. 08 1月, 2013 1 次提交
  24. 24 10月, 2012 1 次提交
  25. 15 10月, 2012 3 次提交
  26. 22 9月, 2012 1 次提交
  27. 14 9月, 2012 1 次提交
  28. 01 9月, 2012 1 次提交
  29. 27 7月, 2012 1 次提交
    • F
      dma: imx-dma: Fix kernel crash due to missing clock conversion · a2367db2
      Fabio Estevam 提交于
      With the new i.MX clock infrastructure we need to request the dma clocks
      seperately: ahb and ipg clocks.
      
      This fixes the following kernel crash and make audio to be functional again:
      
      root@freescale /home$ aplay audio48k16S.wav
      Playing WAVE 'audio48k16S.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
      Unable to handle kernel NULL pointer dereference at virtual address 00000000
      pgd = c7b74000
      [00000000] *pgd=a7bb5831, *pte=00000000, *ppte=00000000
      Internal error: Oops: 17 [#1] PREEMPT ARM
      Modules linked in:
      CPU: 0    Not tainted  (3.5.0-rc5-next-20120702-00007-g3028b64 #1128)
      PC is at snd_dmaengine_pcm_get_chan+0x8/0x10
      LR is at snd_imx_pcm_hw_params+0x18/0xdc
      pc : [<c02d3cf8>]    lr : [<c02e95ec>]    psr: a0000013
      sp : c7b45e30  ip : ffffffff  fp : c7ae58e0
      r10: 00000000  r9 : c7ae981c  r8 : c7b88800
      r7 : c7ae5a60  r6 : c7ae5b20  r5 : c7ae9810  r4 : c7afa060
      r3 : 00000000  r2 : 00000001  r1 : c7b88800  r0 : c7afa060
      Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
      Control: 0005317f  Table: a7b74000  DAC: 00000015
      Process aplay (pid: 701, stack limit = 0xc7b44270)
      Stack: (0xc7b45e30 to 0xc7b46000)
      5e20:                                     00100000 00000029 c7b88800 c02db870
      5e40: c7ae5a60 c02d4594 00000010 01ae5a60 c7ae5a60 c7ae9810 c7ae9810 c7afa060
      5e60: c7ae5b20 c7ae5a60 c7b88800 c02e3ef0 c02e3e08 c7b1e400 c7afa060 c7b88800
      5e80: 00000000 c0014da8 c7b44000 00000000 bec566ac c02cd400 c7afa060 c7afa060
      5ea0: bec56800 c7b88800 c0014da8 c02cdd7c c04ee710 c04ee7b8 00000003 c005fc74
      5ec0: 00000000 7fffffff c7b45f00 c7afa060 c7b67420 c7ba3070 00000004 c0014da8
      5ee0: c7b44000 00000000 bec566ac c02ced88 c04e95f8 b6f5ab04 c7b45fb0 0145a468
      5f00: 0145a600 bec566bc bec56800 c7b67420 c7ba3070 c00d499c c7b45f18 c7b45f18
      5f20: 0000001a 00000004 00000001 c7b44000 c0527f40 00000009 00000008 00000000
      5f40: c7b44000 c002c9ec 00000001 c04f0ab0 c04ebec0 00000101 00000000 0000000a
      5f60: 60000093 c7b67420 bec56800 c25c4111 00000004 c0014da8 c7b44000 00000000
      5f80: bec566ac c00d4f38 b6ffb658 00000000 c0522d80 0145a468 b6fd5000 0145a418
      5fa0: 00000036 c0014c00 0145a468 b6fd5000 00000004 c25c4111 bec56800 00020001
      5fc0: 0145a468 b6fd5000 0145a418 00000036 0145a468 0145a600 bec566bc bec566ac
      5fe0: 0145a468 bec56388 b6f65ce4 b6dcebec 20000010 00000004 00000000 00000000
      [<c02d3cf8>] (snd_dmaengine_pcm_get_chan+0x8/0x10) from [<c02e95ec>] (snd_imx_pcm_hw_params+0x18/0xdc)
      [<c02e95ec>] (snd_imx_pcm_hw_params+0x18/0xdc) from [<c02e3ef0>] (soc_pcm_hw_params+0xe8/0x1f0)
      [<c02e3ef0>] (soc_pcm_hw_params+0xe8/0x1f0) from [<c02cd400>] (snd_pcm_hw_params+0x124/0x474)
      [<c02cd400>] (snd_pcm_hw_params+0x124/0x474) from [<c02cdd7c>] (snd_pcm_common_ioctl1+0x4b4/0xf74)
      [<c02cdd7c>] (snd_pcm_common_ioctl1+0x4b4/0xf74) from [<c02ced88>] (snd_pcm_playback_ioctl1+0x30/0x510)
      [<c02ced88>] (snd_pcm_playback_ioctl1+0x30/0x510) from [<c00d499c>] (do_vfs_ioctl+0x80/0x5e4)
      [<c00d499c>] (do_vfs_ioctl+0x80/0x5e4) from [<c00d4f38>] (sys_ioctl+0x38/0x60)
      [<c00d4f38>] (sys_ioctl+0x38/0x60) from [<c0014c00>] (ret_fast_syscall+0x0/0x2c)
      Code: e593000c e12fff1e e59030a0 e59330bc (e5930000)
      ---[ end trace fa518c8ba3a74e97 ]--
      Reported-by: NJavier Martin <javier.martin@vista-silicon.com>
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Acked-by: NSascha Hauer <s.hauer@pengutronix.de>
      Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>
      Cc: stable@vger.kernel.org
      a2367db2
  30. 11 5月, 2012 1 次提交
    • L
      dmaengine: Use dma_sg_len(sg) instead of sg->length · fdaf9c4b
      Lars-Peter Clausen 提交于
      sg->length may or may not contain the length of the dma region to transfer,
      depending on the architecture - dma_sg_len(sg) always will though. For the
      architectures which use the drivers modified by this patch it probably is the
      case that sg->length contains the dma transfer length. But to be consistent and
      future proof change them to use dma_sg_len.
      
      To quote Russel King:
      	sg->length is meaningless to something performing DMA.
      
      	In cases where sg_dma_len(sg) and sg->length are the same storage, then
      	there's no problem. But scatterlists _can_ (and one some architectures) do
      	split them - especially when you have an IOMMU which can allow you to
      	combine a scatterlist into fewer entries.
      
      	So, anything using sg->length for the size of a scatterlist's DMA transfer
      	_after_ a call to dma_map_sg() is almost certainly buggy.
      
      The patch has been generated using the following coccinelle patch:
      <smpl>
      @@
      struct scatterlist *sg;
      expression X;
      @@
      -sg[X].length
      +sg_dma_len(&sg[X])
      @@
      struct scatterlist *sg;
      @@
      -sg->length
      +sg_dma_len(sg)
      </smpl>
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NVinod Koul <vinod.koul@linux.intel.com>
      fdaf9c4b
  31. 20 4月, 2012 1 次提交