1. 09 8月, 2014 1 次提交
  2. 07 8月, 2014 1 次提交
  3. 04 8月, 2014 1 次提交
  4. 30 7月, 2014 1 次提交
  5. 25 7月, 2014 1 次提交
  6. 17 7月, 2014 1 次提交
  7. 13 7月, 2014 1 次提交
  8. 02 6月, 2014 1 次提交
  9. 22 5月, 2014 1 次提交
  10. 30 4月, 2014 1 次提交
  11. 16 4月, 2014 1 次提交
    • J
      platform: Fix timberdale dependencies · 2dda47d1
      Jean Delvare 提交于
      VIDEO_TIMBERDALE selects TIMB_DMA which itself depends on
      MFD_TIMBERDALE, so VIDEO_TIMBERDALE should either select or depend on
      MFD_TIMBERDALE as well. I chose to make it depend on it because I
      think it makes more sense and it is consistent with what other options
      are doing.
      
      Adding a "|| HAS_IOMEM" to the TIMB_DMA dependencies silenced the
      kconfig warning about unmet direct dependencies but it was wrong:
      without MFD_TIMBERDALE, TIMB_DMA is useless as the driver has no
      device to bind to.
      Signed-off-by: NJean Delvare <jdelvare@suse.de>
      Cc: Vinod Koul <vinod.koul@intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Mauro Carvalho Chehab <m.chehab@samsung.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      2dda47d1
  12. 05 4月, 2014 1 次提交
  13. 18 2月, 2014 1 次提交
  14. 12 2月, 2014 1 次提交
  15. 03 2月, 2014 1 次提交
  16. 20 1月, 2014 1 次提交
  17. 08 1月, 2014 1 次提交
  18. 19 12月, 2013 1 次提交
    • D
      net_dma: mark broken · 77873803
      Dan Williams 提交于
      net_dma can cause data to be copied to a stale mapping if a
      copy-on-write fault occurs during dma.  The application sees missing
      data.
      
      The following trace is triggered by modifying the kernel to WARN if it
      ever triggers copy-on-write on a page that is undergoing dma:
      
       WARNING: CPU: 24 PID: 2529 at lib/dma-debug.c:485 debug_dma_assert_idle+0xd2/0x120()
       ioatdma 0000:00:04.0: DMA-API: cpu touching an active dma mapped page [pfn=0x16bcd9]
       Modules linked in: iTCO_wdt iTCO_vendor_support ioatdma lpc_ich pcspkr dca
       CPU: 24 PID: 2529 Comm: linbug Tainted: G        W    3.13.0-rc1+ #353
        00000000000001e5 ffff88016f45f688 ffffffff81751041 ffff88017ab0ef70
        ffff88016f45f6d8 ffff88016f45f6c8 ffffffff8104ed9c ffffffff810f3646
        ffff8801768f4840 0000000000000282 ffff88016f6cca10 00007fa2bb699349
       Call Trace:
        [<ffffffff81751041>] dump_stack+0x46/0x58
        [<ffffffff8104ed9c>] warn_slowpath_common+0x8c/0xc0
        [<ffffffff810f3646>] ? ftrace_pid_func+0x26/0x30
        [<ffffffff8104ee86>] warn_slowpath_fmt+0x46/0x50
        [<ffffffff8139c062>] debug_dma_assert_idle+0xd2/0x120
        [<ffffffff81154a40>] do_wp_page+0xd0/0x790
        [<ffffffff811582ac>] handle_mm_fault+0x51c/0xde0
        [<ffffffff813830b9>] ? copy_user_enhanced_fast_string+0x9/0x20
        [<ffffffff8175fc2c>] __do_page_fault+0x19c/0x530
        [<ffffffff8175c196>] ? _raw_spin_lock_bh+0x16/0x40
        [<ffffffff810f3539>] ? trace_clock_local+0x9/0x10
        [<ffffffff810fa1f4>] ? rb_reserve_next_event+0x64/0x310
        [<ffffffffa0014c00>] ? ioat2_dma_prep_memcpy_lock+0x60/0x130 [ioatdma]
        [<ffffffff8175ffce>] do_page_fault+0xe/0x10
        [<ffffffff8175c862>] page_fault+0x22/0x30
        [<ffffffff81643991>] ? __kfree_skb+0x51/0xd0
        [<ffffffff813830b9>] ? copy_user_enhanced_fast_string+0x9/0x20
        [<ffffffff81388ea2>] ? memcpy_toiovec+0x52/0xa0
        [<ffffffff8164770f>] skb_copy_datagram_iovec+0x5f/0x2a0
        [<ffffffff8169d0f4>] tcp_rcv_established+0x674/0x7f0
        [<ffffffff816a68c5>] tcp_v4_do_rcv+0x2e5/0x4a0
        [..]
       ---[ end trace e30e3b01191b7617 ]---
       Mapped at:
        [<ffffffff8139c169>] debug_dma_map_page+0xb9/0x160
        [<ffffffff8142bf47>] dma_async_memcpy_pg_to_pg+0x127/0x210
        [<ffffffff8142cce9>] dma_memcpy_pg_to_iovec+0x119/0x1f0
        [<ffffffff81669d3c>] dma_skb_copy_datagram_iovec+0x11c/0x2b0
        [<ffffffff8169d1ca>] tcp_rcv_established+0x74a/0x7f0:
      
      ...the problem is that the receive path falls back to cpu-copy in
      several locations and this trace is just one of the areas.  A few
      options were considered to fix this:
      
      1/ sync all dma whenever a cpu copy branch is taken
      
      2/ modify the page fault handler to hold off while dma is in-flight
      
      Option 1 adds yet more cpu overhead to an "offload" that struggles to compete
      with cpu-copy.  Option 2 adds checks for behavior that is already documented as
      broken when using get_user_pages().  At a minimum a debug mode is warranted to
      catch and flag these violations of the dma-api vs get_user_pages().
      
      Thanks to David for his reproducer.
      
      Cc: <stable@vger.kernel.org>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Vinod Koul <vinod.koul@intel.com>
      Cc: Alexander Duyck <alexander.h.duyck@intel.com>
      Reported-by: NDavid Whipple <whipple@securedatainnovations.ch>
      Acked-by: NDavid S. Miller <davem@davemloft.net>
      Signed-off-by: NDan Williams <dan.j.williams@intel.com>
      77873803
  19. 13 12月, 2013 1 次提交
  20. 12 12月, 2013 1 次提交
  21. 13 11月, 2013 1 次提交
  22. 14 10月, 2013 1 次提交
  23. 11 10月, 2013 1 次提交
  24. 08 10月, 2013 1 次提交
    • H
      dmaengine: add driver for Samsung s3c24xx SoCs · ddeccb8d
      Heiko Stuebner 提交于
      This adds a new driver to support the s3c24xx dma using the dmaengine
      and makes the old one in mach-s3c24xx obsolete in the long run.
      
      Conceptually the s3c24xx-dma feels like a distant relative of the pl08x
      with numerous virtual channels being mapped to a lot less physical ones.
      The driver therefore borrows a lot from the amba-pl08x driver in this
      regard. Functionality-wise the driver gains a memcpy ability in addition
      to the slave_sg one.
      
      The driver supports both the method for requesting the peripheral used
      by SoCs before the S3C2443 and the different method for S3C2443 and later.
      
      On earlier SoCs the hardware channels usable for specific peripherals is
      constrainted while on later SoCs all channels can be used for any peripheral.
      
      Tested on a s3c2416-based board, memcpy using the dmatest module and
      slave_sg partially using the spi-s3c64xx driver.
      Signed-off-by: NHeiko Stuebner <heiko@sntech.de>
      Acked-by: NLinus Walleij <linus.walleij@linaro.org>
      Acked-by: NVinod Koul <vinod.koul@intel.com>
      Signed-off-by: NKukjin Kim <kgene.kim@samsung.com>
      ddeccb8d
  25. 17 9月, 2013 1 次提交
    • J
      dma/Kconfig: Make TI_EDMA select TI_PRIV_EDMA · c2b9e974
      Josh Boyer 提交于
      The TI_EDMA driver unconditionally calls functions provided by the
      TI_PRIV_EDMA code, but it doesn't force that to be built-in.  If that isn't
      otherwise enabled somewhere, you can get build errors like:
      
      linux-3.12.0-0.rc0.git1.1.fc21.armv7hl/drivers/dma/edma.c:593: undefined reference to `edma_free_slot'
      drivers/built-in.o: In function `edma_terminate_all':
      linux-3.12.0-0.rc0.git1.1.fc21.armv7hl/drivers/dma/edma.c:169: undefined reference to `edma_stop'
      drivers/built-in.o: In function `edma_execute':
      linux-3.12.0-0.rc0.git1.1.fc21.armv7hl/drivers/dma/edma.c:122: undefined reference to `edma_write_slot'
      linux-3.12.0-0.rc0.git1.1.fc21.armv7hl/drivers/dma/edma.c:149: undefined reference to `edma_link'
      linux-3.12.0-0.rc0.git1.1.fc21.armv7hl/drivers/dma/edma.c:152: undefined reference to `edma_start'
      
      Make TI_EDMA select TI_PRIV_EDMA to avoid this.
      Signed-off-by: NJosh Boyer <jwboyer@fedoraproject.org>
      Acked-by: NMatt Porter <matt.porter@linaro.org>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      c2b9e974
  26. 28 8月, 2013 1 次提交
  27. 25 8月, 2013 1 次提交
  28. 09 8月, 2013 1 次提交
    • S
      usb: musb dma: add cppi41 dma driver · 9b3452d1
      Sebastian Andrzej Siewior 提交于
      This driver is currently used by musb' cppi41 couter part. I may merge
      both dma engine user of musb at some point but not just yet.
      
      The driver seems to work in RX/TX mode in host mode, tested on mass
      storage. I increaed the size of the TX / RX transfers and waited for the
      core code to cancel a transfers and it seems to recover.
      
      v2..3:
      - use mall transfers on RX side and check data toggle.
      - use rndis mode on tx side so we haveon interrupt for 4096 transfers.
      - remove custom "transferred" hack and use dmaengine_tx_status() to
        compute the total amount of data that has been transferred.
      - cancel transfers and reclaim descriptors
      
      v1..v2:
      - RX path added
      - dma mode 0 & 1 is working
      - device tree nodes re-created.
      
      Cc: Vinod Koul <vinod.koul@intel.com>
      Cc: Dan Williams <djbw@fb.com>
      Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: NFelipe Balbi <balbi@ti.com>
      9b3452d1
  29. 05 7月, 2013 2 次提交
  30. 24 6月, 2013 1 次提交
  31. 30 4月, 2013 1 次提交
  32. 16 4月, 2013 1 次提交
    • A
      dma: acpi-dma: introduce ACPI DMA helpers · 1b2e98bc
      Andy Shevchenko 提交于
      There is a new generic API to get a DMA channel for a slave device (commit
      9a6cecc8 "dmaengine: add helper function to request a slave DMA channel"). In
      similar fashion to the DT case (commit aa3da644 "of: Add generic device tree
      DMA helpers") we introduce helpers to the DMAC drivers which are enumerated by
      ACPI.
      
      The proposed extension provides the following API calls:
      	acpi_dma_controller_register(), devm_acpi_dma_controller_register()
      	acpi_dma_controller_free(), devm_acpi_dma_controller_free()
      	acpi_dma_simple_xlate()
      	acpi_dma_request_slave_chan_by_index()
      	acpi_dma_request_slave_chan_by_name()
      
      The first two should be used, for example, at probe() and remove() of the
      corresponding DMAC driver. At the register stage the DMAC driver supplies a
      custom xlate() function to translate a struct dma_spec into struct dma_chan.
      
      Accordingly to the ACPI Fixed DMA resource specification the only two pieces of
      information the slave device has are the channel id and the request line (slave
      id). Those two are represented by struct dma_spec. The
      acpi_dma_request_slave_chan_by_index() provides access to the specifix FixedDMA
      resource by its index. Whereas dma_request_slave_channel() takes a string
      parameter to identify the DMA resources required by the slave device. To make a
      slave device driver work with both DeviceTree and ACPI enumeration a simple
      convention is established: "tx" corresponds to the index 0 and "rx" to the
      index 1. In case of robust configuration the slave device driver unfortunately
      needs to call acpi_dma_request_slave_chan_by_index() directly.
      
      Additionally the patch provides "managed" version of the register/free pair
      i.e. devm_acpi_dma_controller_register() and devm_acpi_dma_controller_free().
      Usually, the driver uses only devm_acpi_dma_controller_register().
      Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Reviewed-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: NVinod Koul <vinod.koul@intel.com>
      1b2e98bc
  33. 15 4月, 2013 1 次提交
  34. 21 3月, 2013 1 次提交
  35. 14 2月, 2013 1 次提交
  36. 08 1月, 2013 2 次提交
  37. 07 1月, 2013 1 次提交
  38. 03 1月, 2013 1 次提交