aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/dma (follow)
AgeCommit message (Collapse)AuthorFilesLines
2017-02-09usb: musb: dsps: Manage CPPI 4.1 DMA interrupt in DSPSAlexandre Bailon1-21/+7
Despite the CPPI 4.1 is a generic DMA, it is tied to USB. On the DSPS, CPPI 4.1 interrupt's registers are in USBSS (the MUSB glue). Currently, to enable / disable and clear interrupts, the CPPI 4.1 driver maps and accesses to USBSS's register, which making CPPI 4.1 driver not really generic. Move the interrupt management to DSPS driver. Signed-off-by: Alexandre Bailon <abailon@baylibre.com> Acked-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Bin Liu <b-liu@ti.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-02-05dmaengine: sun6i: allow build on ARM64 platforms (sun50i)Icenowy Zheng1-1/+1
As 64-bit Allwinner H5 SoC has the same DMA engine with H3, the DMA driver should be allowed to be built for ARM64, in order to make it work on H5. Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-30Merge branch 'iommu/iommu-priv' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into arm/coreJoerg Roedel1-2/+3
2017-01-25dmaengine: pl330: fix double lockIago Abal1-13/+6
The static bug finder EBA (http://www.iagoabal.eu/eba/) reported the following double-lock bug: Double lock: 1. spin_lock_irqsave(pch->lock, flags) at pl330_free_chan_resources:2236; 2. call to function `pl330_release_channel' immediately after; 3. call to function `dma_pl330_rqcb' in line 1753; 4. spin_lock_irqsave(pch->lock, flags) at dma_pl330_rqcb:1505. I have fixed it as suggested by Marek Szyprowski. First, I have replaced `pch->lock' with `pl330->lock' in functions `pl330_alloc_chan_resources' and `pl330_free_chan_resources'. This avoids the double-lock by acquiring a different lock than `dma_pl330_rqcb'. NOTE that, as a result, `pl330_free_chan_resources' executes `list_splice_tail_init' on `pch->work_list' under lock `pl330->lock', whereas in the rest of the code `pch->work_list' is protected by `pch->lock'. I don't know if this may cause race conditions. Similarly `pch->cyclic' is written by `pl330_alloc_chan_resources' under `pl330->lock' but read by `pl330_tx_submit' under `pch->lock'. Second, I have removed locking from `pl330_request_channel' and `pl330_release_channel' functions. Function `pl330_request_channel' is only called from `pl330_alloc_chan_resources', so the lock is already held. Function `pl330_release_channel' is called from `pl330_free_chan_resources', which already holds the lock, and from `pl330_del'. Function `pl330_del' is called in an error path of `pl330_probe' and at the end of `pl330_remove', but I assume that there cannot be concurrent accesses to the protected data at those points. Signed-off-by: Iago Abal <mail@iagoabal.eu> Reviewed-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-25dmaengine: zx: fix build warningJun Nie1-1/+1
Fix build warning that related to PAGE_SIZE. The maximum DMA length has nothing to do with PAGE_SIZE, just use a fix number for the definition. drivers/dma/zx_dma.c: In function 'zx_dma_prep_memcpy': drivers/dma/zx_dma.c:523:8: warning: division by zero [-Wdiv-by-zero] drivers/dma/zx_dma.c: In function 'zx_dma_prep_slave_sg': drivers/dma/zx_dma.c:567:11: warning: division by zero [-Wdiv-by-zero] Signed-off-by: Jun Nie <jun.nie@linaro.org> Tested-by: Shawn Guo <shawn.guo@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-25dmaengine: dw: we do support Merrifield SoC in PCI modeAndy Shevchenko1-0/+15
Intel Merrifield platform contains Intel integrated DMA (iDMA 32-bit) which has a slightly different register mapping, e.g. some bits in CTL_* and CFG_* channel registers, and has to use platform data since there is no autoconfiguration. The iDMA 32-bit specification is available in the publicly available documentation for Intel Braswell and BayTrail SoCs as LPE Audio DMA. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-25dmaengine: dw: add support of iDMA 32-bit hardwareAndy Shevchenko1-9/+92
iDMA 32-bit is Intel designed DMA controller that behaves like Synopsys Designware DMA. This patch adds a support of the new Intel hardware. Due to iDMA 32-bit has no autoconfiguration the platform code must provide a platform data to dw_dma_probe(). By default full FIFO (1024 bytes) is assigned to channel 0. Here we slice FIFO on equal parts between channels for iDMA 32-bit case. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-25dmaengine: dw: introduce register mappings for iDMA 32-bitAndy Shevchenko1-3/+49
The integrated DMA (iDMA 32-bit) is Intel designed DMA controller which mimics Synopsys Designware DMA. This patch appends the register mappings for the parts which are slightly different to the DesignWare hardware. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-25dmaengine: dw: introduce block2bytes() and bytes2block()Andy Shevchenko2-23/+35
The newly introduced helpers prepare driver to support new DMA controller hardware. While here, introduce DWC_CTLH_BLOCK_TS() macro as well. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-25dmaengine: dw: extract dwc_chan_pause() for future useAndy Shevchenko1-5/+9
iDMA 32-bit has a special handling of the FIFO during pause() / terminate_all(). Prepare code to implement that. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-25dmaengine: dw: replace convert_burst() with one linerAndy Shevchenko1-18/+11
Replace convert_burst() with one liner in place. The change simplifies further extension of the driver to cover new DMA controller hardware. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-25dmaengine: dw: register IRQ and DMA pool with instance IDAndy Shevchenko4-2/+8
It is really useful not only for debugging to have an IRQ line and DMA pool labeled with driver and its instance ID. Do this for DesignWare DMA driver. All current users of this IP would be enhanced later on. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-25dmaengine: dw: Fix data corruption in large device to memory transfersJarkko Nikula1-11/+9
When transferring more data than the maximum block size supported by the HW multiplied by source width the transfer is split into smaller chunks. Currently code calculates the memory width and thus aligment before splitting for both memory to device and device to memory transfers. For memory to device transfers this work fine since alignment is preserved through the splitting and split blocks are still memory width aligned. However in device to memory transfers aligment breaks when maximum block size multiplied by register width doesn't have the same alignment than the buffer. For instance when transferring from an 8-bit register 4100 bytes (32-bit aligned) on a DW DMA that has maximum block size of 4095 elements. An attempt to do such transfers caused data corruption. Fix this by calculating and setting the destination memory width after splitting by using the split block aligment and length. Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-25dmaengine: cppi41: Clean up pointless warningsTony Lindgren1-8/+5
With patches "dmaengine: cppi41: Fix runtime PM timeouts with USB mass storage", and "dmaengine: cppi41: Fix oops in cppi41_runtime_resume", the pm_runtime_get/put() in cppi41_irq() is no longer needed. We now guarantee that cppi41 is enabled when dma is in use. We can still get pointless error -115 when musb is configured as a usb peripheral. That's because we should now check for the state of is_suspended instead. Let's just remove the now useless code and replace it with a WARN(). Signed-off-by: Tony Lindgren <tony@atomide.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-25dmaengine: cppi41: Fix oops in cppi41_runtime_resumeTony Lindgren1-15/+25
Commit fdea2d09b997 ("dmaengine: cppi41: Add basic PM runtime support") together with recent MUSB changes allowed USB and DMA on BeagleBone to idle when no cable is connected. But looks like few corner case issues still remain. Looks like just by re-plugging USB cable about ten or so times on BeagleBone when configured in USB peripheral mode we can get warnings and eventually trigger an oops in cppi41 DMA: WARNING: CPU: 0 PID: 14 at drivers/dma/cppi41.c:1154 cppi41_runtime_suspend+ x28/0x38 [cppi41] ... WARNING: CPU: 0 PID: 14 at drivers/dma/cppi41.c:452 push_desc_queue+0x94/0x9c [cppi41] ... Unable to handle kernel NULL pointer dereference at virtual address 00000104 pgd = c0004000 [00000104] *pgd=00000000 Internal error: Oops: 805 [#1] SMP ARM ... [<bf0d92cc>] (cppi41_runtime_resume [cppi41]) from [<c0589838>] (__rpm_callback+0xc0/0x214) [<c0589838>] (__rpm_callback) from [<c05899ac>] (rpm_callback+0x20/0x80) [<c05899ac>] (rpm_callback) from [<c0589460>] (rpm_resume+0x504/0x78c) [<c0589460>] (rpm_resume) from [<c058a1a0>] (pm_runtime_work+0x60/0xa8) [<c058a1a0>] (pm_runtime_work) from [<c0156120>] (process_one_work+0x2b4/0x808) This is because of a race with runtime PM and cppi41_dma_issue_pending() as reported by Alexandre Bailon <abailon@baylibre.com> in earlier set of patches. Based on mailing list discussions we however came to the conclusion that a different fix from Alexandre's fix is needed in order to guarantee that DMA is really active when we try to use it. To fix the issue, we need to add a driver specific flag as we otherwise can have -EINPROGRESS state set by runtime PM and can't rely on pm_runtime_active() to tell us when we can use the DMA. And we need to make sure the DMA transfers get triggered in the queued order. So let's always queue the transfers, then flush the queue from both cppi41_dma_issue_pending() and cppi41_runtime_resume() as suggested by Grygorii Strashko <grygorii.strashko@ti.com> in an earlier example patch. For reference, this is also documented in Documentation/power/runtime_pm.txt in the example at the end of the file as pointed out by Grygorii Strashko <grygorii.strashko@ti.com>. Based on earlier patches from Alexandre Bailon <abailon@baylibre.com> and Grygorii Strashko <grygorii.strashko@ti.com> modified based on testing and what was discussed on the mailing lists. Fixes: fdea2d09b997 ("dmaengine: cppi41: Add basic PM runtime support") Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Bin Liu <b-liu@ti.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Patrick Titiano <ptitiano@baylibre.com> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Reported-by: Alexandre Bailon <abailon@baylibre.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Tested-by: Bin Liu <b-liu@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-25dmaengine: cppi41: Fix runtime PM timeouts with USB mass storageTony Lindgren1-0/+16
Commit fdea2d09b997 ("dmaengine: cppi41: Add basic PM runtime support") added runtime PM support for cppi41, but had corner case issues. Some of the issues were fixed with commit 098de42ad670 ("dmaengine: cppi41: Fix unpaired pm runtime when only a USB hub is connected"). That fix however caused a new regression where we can get error -115 messages with USB on BeagleBone when connecting a USB mass storage device to a hub. This is because when connecting a USB mass storage device to a hub, the initial DMA transfers can take over 200ms to complete and cppi41 autosuspend delay times out. To fix the issue, we want to implement refcounting for chan_busy array that contains the active dma transfers. Increasing the autosuspend delay won't help as that the delay could be potentially seconds, and it's best to let the USB subsystem to deal with the timeouts on errors. The earlier attempt for runtime PM was buggy as the pm_runtime_get/put() calls could get unpaired easily as they did not follow the state of the chan_busy array as described in commit 098de42ad670 ("dmaengine: cppi41: Fix unpaired pm runtime when only a USB hub is connected". Let's fix the issue by adding pm_runtime_get() to where a new transfer is added to the chan_busy array, and calls to pm_runtime_put() where chan_busy array entry is cleared. This prevents any autosuspend timeouts from happening while dma transfers are active. Fixes: 098de42ad670 ("dmaengine: cppi41: Fix unpaired pm runtime when only a USB hub is connected") Fixes: fdea2d09b997 ("dmaengine: cppi41: Add basic PM runtime support") Cc: Andy Shevchenko <andy.shevchenko@gmail.com> Cc: Bin Liu <b-liu@ti.com> Cc: Grygorii Strashko <grygorii.strashko@ti.com> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Patrick Titiano <ptitiano@baylibre.com> Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com> Signed-off-by: Tony Lindgren <tony@atomide.com> Tested-by: Bin Liu <b-liu@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-19dmaengine: pl330: Make sure microcode is privilegedMitchel Humpherys1-2/+3
The PL330 is hard-wired such that instruction fetches on both the manager and channel threads go out onto the bus with the "privileged" bit set. This can become troublesome once there is an IOMMU or other form of memory protection downstream, since those will typically be programmed by the DMA mapping subsystem in the expectation of normal unprivileged transactions (such as the PL330 channel threads' own data accesses as currently configured by this driver). To avoid the case of, say, an IOMMU blocking an unexpected privileged transaction with a permission fault, use the newly-introduced DMA_ATTR_PRIVILEGED attribute for the mapping of our microcode buffer. That way the DMA layer can do whatever it needs to do to make things continue to work as expected on more complex systems. Cc: Dan Williams <dan.j.williams@intel.com> Cc: Vinod Koul <vinod.koul@intel.com> Reviewed-by: Robin Murphy <robin.murphy@arm.com> Tested-by: Robin Murphy <robin.murphy@arm.com> Acked-by: Will Deacon <will.deacon@arm.com> Acked-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org> [rm: remove now-redundant local variable, clarify commit message] Signed-off-by: Robin Murphy <robin.murphy@arm.com> Signed-off-by: Will Deacon <will.deacon@arm.com>
2017-01-19serial: 8250_mid: handle interrupt correctly in DMA caseAndy Shevchenko1-2/+15
Starting from Tangier B0 and continuing on Anniedale the HSU DMA interrupt line is actually shared with UART. Handling them independently is racy and quite often comes with the following traceback. irq 54: nobody cared (try booting with the "irqpoll" option) CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-rc6-edison64-86244934+ #1 Hardware name: Intel Corporation Merrifield/BODEGA BAY, BIOS 542 2015.01.21:18.19.48 ffff88003f203eb0 ffffffff8130e718 ffff880032627000 ffff88003262709c ffff88003f203ed8 ffffffff810a3960 ffff880032627000 0000000000000000 ffff880032627000 ffff88003f203f10 ffffffff810a3cc7 ffff880032627000 Call Trace: <IRQ> [<ffffffff8130e718>] dump_stack+0x4d/0x65 [<ffffffff810a3960>] __report_bad_irq+0x30/0xc0 [<ffffffff810a3cc7>] note_interrupt+0x227/0x270 [<ffffffff810a1380>] handle_irq_event_percpu+0x40/0x50 [<ffffffff810a13b7>] handle_irq_event+0x27/0x50 [<ffffffff810a42d5>] handle_fasteoi_irq+0x85/0x150 [<ffffffff8101d7fe>] handle_irq+0x6e/0x120 [<ffffffff8105b8bc>] ? _local_bh_enable+0x1c/0x50 [<ffffffff8101d0d6>] do_IRQ+0x46/0xd0 [<ffffffff818cef3f>] common_interrupt+0x7f/0x7f <EOI> [<ffffffff818cdead>] ? mwait_idle+0x7d/0x140 [<ffffffff81024c9a>] arch_cpu_idle+0xa/0x10 [<ffffffff818ce150>] default_idle_call+0x20/0x30 [<ffffffff810908fd>] cpu_startup_entry+0x16d/0x1d0 [<ffffffff818c882d>] rest_init+0x6d/0x70 [<ffffffff81f93e8f>] start_kernel+0x3e2/0x3ef [<ffffffff81f9343d>] x86_64_start_reservations+0x38/0x3a [<ffffffff81f93529>] x86_64_start_kernel+0xea/0xed handlers: [<ffffffff81411670>] serial8250_interrupt Disabling IRQ #54 Fix this by handling interrupt only in one place. The issue is discussed here: https://github.com/andy-shev/linux/issues/5 Moreover this also fixes another bug when Rx DMA returns wrong residue and we can't rely on it. Reviewed-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-14dmaengine: ste_dma40: indicate granularity on channelsLinus Walleij1-0/+1
The ste_dma40 has burst level granularity on the residue registers, which is necessary for some clients to know, notably the UART. Before this patch we get this message: uart-pl011 80007000.uart: RX DMA disabled - no residue processing This patch fixes it. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-14dmaengine: ste_dma40: indicate directions on channelsLinus Walleij1-2/+4
Since the introduction of the .directions flags, ste_dma40 was never patched to indicate which transfer directions it can manage. This causes a problem when trying to use the dmaengine for generic ALSA SoC DMA: ux500-msp-i2s.1: Failed to get DMA channel capabilities, falling back to period counting: -6 This patch fixes this issue by indicating the supported transfer directions for slave and memcpy channels. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-13dmaengine: rcar-dmac: unmap slave resource when channel is freedNiklas Söderlund1-0/+8
The slave mapping should be removed together with other channel resources when the channel is freed. If it's not unmapped it will hang around forever after the channel is freed. Fixes: 9f878603dbdb7db3 ("dmaengine: rcar-dmac: add iommu support for slave transfers") Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-10dmaengine: omap-dma: Fix the port_window supportPeter Ujfalusi1-15/+16
We do not yet have users of port_window. The following errors were found when converting the tusb6010_omap.c musb driver: - The peripheral side must have SRC_/DST_PACKED disabled - when configuring the burst for the peripheral side the memory side configuration were overwritten: d->csdp = ... -> d->csdp |= ... - The EI and FI were configured for the wrong sides of the transfers. With these changes and the converted tus6010_omap.c I was able to verify that things are working as they expected to work. Fixes: 201ac4861c19 ("dmaengine: omap-dma: Support for slave devices with data port window") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-10dmaengine: stm32-dma: Add error messages if xlate failsM'boumba Cedric Madianga1-9/+15
This patch adds some error messages when a slave device fails to request a channel. Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com> Reviewed-by: Ludovic BARRE <ludovic.barre@st.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-10dmaengine: iota: ioat_alloc_chan_resources should not perform sleeping allocations.Krister Johansen1-2/+2
On a kernel with DEBUG_LOCKS, ioat_free_chan_resources triggers an in_interrupt() warning. With PROVE_LOCKING, it reports detecting a SOFTIRQ-safe to SOFTIRQ-unsafe lock ordering in the same code path. This is because dma_generic_alloc_coherent() checks if the GFP flags permit blocking. It allocates from different subsystems if blocking is permitted. The free path knows how to return the memory to the correct allocator. If GFP_KERNEL is specified then the alloc and free end up going through cma_alloc(), which uses mutexes. Given that ioat_free_chan_resources() can be called in interrupt context, ioat_alloc_chan_resources() must specify GFP_NOWAIT so that the allocations do not block and instead use an allocator that uses spinlocks. Signed-off-by: Krister Johansen <kjlx@templeofstupid.com> Acked-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-10dmaengine: dw: pci: remove LPE Audio DMA IDAndy Shevchenko1-2/+1
LPE Audio driver should take care of DMA IPs by itself. Keeping an ID like this in dw_dma_pci.c is anyway wrong since that block has two DMA controllers under one ID (like MFD device). That's also why I didn't include LPE Audio ID for Intel Merrifield previously. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-03dmaengine: stm32-dma: Add max_burst supportM'boumba Cedric Madianga1-0/+2
This patch sets the max_burst value supported by the STM32 DMA Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-03dmaengine: stm32-dma: Add synchronization supportM'boumba Cedric Madianga1-0/+8
Implement the new device_synchronize() callback to allow proper synchronization when stopping a channel. Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-03dmaengine: stm32-dma: Fix residue computation issue in cyclic modeM'boumba Cedric Madianga1-13/+26
This patch resolves the residue computation issue detected in cyclic mode. Now, in cyclic mode, we increment next_sg variable as soon as a period is transferred instead of after pushing a new sg request. Then, we take into account that after transferring a complete buffer, the next_sg variable is equal to 0. Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com> Reviewed-by: Ludovic BARRE <ludovic.barre@st.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-03dmaengine: stm32-dma: Rework starting transfer managementM'boumba Cedric Madianga1-11/+9
This patch reworks the way to manage transfer starting. Now, starting DMA is only allowed when the channel is not busy. Then, stm32_dma_start_transfer is declared as void. At least, after each transfer completion, we start the next transfer if a new descriptor as been queued in the issued list during an ongoing transfer. Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com> Reviewed-by: Ludovic BARRE <ludovic.barre@st.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-03dmaengine: stm32-dma: Fix typo in KconfigM'boumba Cedric Madianga1-1/+1
As STM32 DMA driver is only used as buit-in driver, it couldn't be used as module. Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com> Reviewed-by: Ludovic BARRE <ludovic.barre@st.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-03dmaengine: pl330: Fix runtime PM support for terminated transfersMarek Szyprowski1-0/+11
PL330 DMA engine driver is leaking a runtime reference after any terminated DMA transactions. This patch fixes this issue by tracking runtime PM state of the device and making additional call to pm_runtime_put() in terminate_all callback if needed. Fixes: ae43b3289186 ("ARM: 8202/1: dmaengine: pl330: Add runtime Power Management support v12") Signed-off-by: Marek Szyprowski <m.szyprowski@samsung.com> Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-03dmaengine: omap-dma: Fix dynamic lch_map allocationPeter Ujfalusi1-9/+21
The original patch did not done what it was supposed to be doing and even worst it broke legacy boot (OMAP1). The lch_map size should be the number of available logical channels in sDMA and the od->dma_requests should store the number of available DMA request lines usable in sDMA. In legacy mode we do not have a way to get the DMA request count, in that case we use OMAP_SDMA_REQUESTS (127), despite the fact that OMAP1510 have only 31 DMA request line. Fixes: 2d1a9a946fae ("dmaengine: omap-dma: Dynamically allocate memory for lch_map") Reported-by: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: stable@vger.kernel.org # v4.9 Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Tested-by: Aaro Koskinen <aaro.koskinen@iki.fi> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-02dmaengine: zx: fix residue calculationShawn Guo1-1/+2
The dma residue is defined as the free space to end of transfer buffer, which could be multiple segments chained together. So the residue calculation in zx_dma_tx_status() works for both slave_sg and cyclic case. But unfortunately, the 'index' is wrong. It should plus one, because the current segment is already occupied and shouldn't be counted into free space. This fixes the HDMI audio noise issue we see on ZX296718 with SPDIF interface. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Reviewed-by: Jun Nie <jun.nie@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-02dmaengine: zx: set DMA_CYCLIC cap_mask bitShawn Guo1-0/+1
The zx_dma driver supports cyclic transfer mode. Let's set DMA_CYCLIC cap_mask bit to make that clear, and avoid unnecessary failure when clients request channel via dma_request_chan_by_mask() with DMA_CYCLIC bit set in mask. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Reviewed-by: Jun Nie <jun.nie@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-02dmaengine: zx: rename zx296702_dma.c to zx_dma.cShawn Guo3-3/+3
ZTE ZX dma driver is not ZX296702 specific. It works for not only ZX296702 but also other ZTE ZX family platforms like ZX296718. Let's rename the file to reflect that. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Reviewed-by: Jun Nie <jun.nie@linaro.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-02dmaengine: ipu: Make sure the interrupt routine checks all interrupts.Magnus Lilja1-1/+1
Commit 3d8cc00073d6 ("dmaengine: ipu: Consolidate duplicated irq handlers") consolidated the two interrupts routines into one, but the remaining interrupt routine only checks the status of the error interrupts, not the normal interrupts. This patch fixes that problem (tested on i.MX31 PDK board). Fixes: 3d8cc00073d6 ("dmaengine: ipu: Consolidate duplicated irq handlers") Cc: Vinod Koul <vinod.koul@intel.com> Cc: <stable@vger.kernel.org> # 4.1.x Signed-off-by: Magnus Lilja <lilja.magnus@gmail.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-02dmaengine: ti-dma-crossbar: Add some 'of_node_put()' in error path.Christophe JAILLET1-0/+2
Add some missing 'of_node_put()' in early exit error path. Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-02dmaengine: Convert ID allocation to an IDAMatthew Wilcox1-10/+11
dmaengine currently uses an IDR to allocate DMA IDs, but it only needs to know whether IDs are in use or not; the ID to pointer functionality of the IDR is unused. That means it can use the more space-efficient IDA. Signed-off-by: Matthew Wilcox <mawilcox@microsoft.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-02dmaengine: stm32-dma: Fix null pointer dereference in stm32_dma_tx_statusM'boumba Cedric Madianga1-7/+3
chan->desc is always set to NULL when a DMA transfer is complete. As a DMA transfer could be complete during the call of stm32_dma_tx_status, we need to be sure that chan->desc is not NULL before using this variable to avoid a null pointer deference issue. Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com> Reviewed-by: Ludovic BARRE <ludovic.barre@st.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-02dmaengine: stm32-dma: Set correct args number for DMA request from DTM'boumba Cedric Madianga1-5/+2
This patch sets the right number of arguments to be used for DMA clients which request channels from DT. Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com> Reviewed-by: Ludovic BARRE <ludovic.barre@st.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-02dmaengine: dw: fix typo in KconfigJean Delvare1-1/+1
platfroms -> platforms Signed-off-by: Jean Delvare <jdelvare@suse.de> Fixes: fed42c198b45 ("dma: dw: add PCI part of the driver") Cc: Viresh Kumar <vireshk@kernel.org> Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-02dmaengine: ioatdma: workaround SKX ioatdma versionDave Jiang1-0/+2
The Skylake ioatdma is technically CBDMA 3.2+ and contains the same hardware bits with some additional 3.3 features, but it's not really 3.3 where the driver is concerned. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-01-02dmaengine: ioatdma: Add Skylake PCI Dev IDDave Jiang2-1/+10
Adding Skylake Xeon PCI device ids for ioatdma and related bits. Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2016-12-25ktime: Cleanup ktime_set() usageThomas Gleixner1-2/+2
ktime_set(S,N) was required for the timespec storage type and is still useful for situations where a Seconds and Nanoseconds part of a time value needs to be converted. For anything where the Seconds argument is 0, this is pointless and can be replaced with a simple assignment. Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Peter Zijlstra <peterz@infradead.org>
2016-12-14Merge tag 'dmaengine-4.10-rc1' of git://git.infradead.org/users/vkoul/slave-dmaLinus Torvalds34-284/+777
Pull dmaengine updates from Vinod Koul: "Fairly routine update this time around with all changes specific to drivers: - New driver for STMicroelectronics FDMA - Memory-to-memory transfers on dw dmac - Support for slave maps on pl08x devices - Bunch of driver fixes to use dma_pool_zalloc - Bunch of compile and warning fixes spread across drivers" [ The ST FDMA driver already came in earlier through the remoteproc tree ] * tag 'dmaengine-4.10-rc1' of git://git.infradead.org/users/vkoul/slave-dma: (68 commits) dmaengine: sirf-dma: remove unused ‘sdesc’ dmaengine: pl330: remove unused ‘regs’ dmaengine: s3c24xx: remove unused ‘cdata’ dmaengine: stm32-dma: remove unused ‘src_addr’ dmaengine: stm32-dma: remove unused ‘dst_addr’ dmaengine: stm32-dma: remove unused ‘sfcr’ dmaengine: pch_dma: remove unused ‘cookie’ dmaengine: mic_x100_dma: remove unused ‘data’ dmaengine: img-mdc: remove unused ‘prev_phys’ dmaengine: usb-dmac: remove unused ‘uchan’ dmaengine: ioat: remove unused ‘res’ dmaengine: ioat: remove unused ‘ioat_dma’ dmaengine: ioat: remove unused ‘is_raid_device’ dmaengine: pl330: do not generate unaligned access dmaengine: k3dma: move to dma_pool_zalloc dmaengine: at_hdmac: move to dma_pool_zalloc dmaengine: at_xdmac: don't restore unsaved status dmaengine: ioat: set error code on failures dmaengine: ioat: set error code on failures dmaengine: DW DMAC: add multi-block property to device tree ...
2016-12-14Merge branch 'topic/st_fdma' into for-linusVinod Koul4-0/+1153
2016-12-14Merge branch 'topic/s3c64xx' into for-linusVinod Koul1-0/+11
2016-12-14Merge branch 'topic/qcom' into for-linusVinod Koul5-103/+270
2016-12-14Merge branch 'topic/pxa' into for-linusVinod Koul1-28/+0
2016-12-14Merge branch 'topic/omap' into for-linusVinod Koul2-37/+153