summaryrefslogtreecommitdiff
path: root/drivers/dma
AgeCommit message (Collapse)Author
2017-02-22Merge tag 'tty-4.11-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty Pull tty/serial driver updates from Greg KH: "Here is the big tty/serial driver patchset for 4.11-rc1. Not much here, but a lot of little fixes and individual serial driver updates all over the subsystem. Majority are for the sh-sci driver and platform (the arch-specific changes have acks from the maintainer). The start of the "serial bus" code is here as well, but nothing is converted to use it yet. That work is still ongoing, hopefully will start to show up across different subsystems for 4.12 (bluetooth is one major place that will be used.) All of these have been in linux-next for a while with no reported issues" * tag 'tty-4.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty: (109 commits) tty: pl011: Work around QDF2400 E44 stuck BUSY bit atmel_serial: Use the fractional divider when possible tty: Remove extra include in HVC console tty framework serial: exar: Enable MSI support serial: exar: Move register defines from uapi header to consumer site serial: pci: Remove unused pci_boards entries serial: exar: Move Commtech adapters to 8250_exar as well serial: exar: Fix feature control register constants serial: exar: Fix initialization of EXAR registers for ports > 0 serial: exar: Fix mapping of port I/O resources serial: sh-sci: fix hardware RX trigger level setting tty/serial: atmel: ensure state is restored after suspending serial: 8250_dw: Avoid "too much work" from bogus rx timeout interrupt serdev: ttyport: check whether tty_init_dev() fails serial: 8250_pci: make pciserial_detach_ports() static ARM: dts: STiH410-b2260: Enable HW flow-control ARM: dts: STiH407-family: Use new Pinctrl groups ARM: dts: STiH407-pinctrl: Add Pinctrl group for HW flow-control ARM: dts: STiH410-b2260: Identify the UART RTS line dt-bindings: serial: Update 'uart-has-rtscts' description ...
2017-02-22Merge tag 'usb-4.11-rc1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB/PHY updates from Greg KH: "Here is the big USB and PHY driver updates for 4.11-rc1. Nothing major, just the normal amount of churn in the usb gadget and dwc and xhci controllers, new device ids, new phy drivers, a new usb-serial driver, and a few other minor changes in different USB drivers. All have been in linux-next for a long time with no reported issues" * tag 'usb-4.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (265 commits) usb: cdc-wdm: remove logically dead code USB: serial: keyspan: drop header file USB: serial: io_edgeport: drop io-tables header file usb: musb: add code comment for clarification usb: misc: add USB251xB/xBi Hi-Speed Hub Controller Driver usb: misc: usbtest: remove redundant check on retval < 0 USB: serial: upd78f0730: sort device ids USB: serial: upd78f0730: add ID for EVAL-ADXL362Z ohci-hub: fix typo in dbg_port macro usb: musb: dsps: Manage CPPI 4.1 DMA interrupt in DSPS usb: musb: tusb6010: Clean up tusb_omap_dma structure usb: musb: cppi_dma: Clean up cppi41_dma_controller structure usb: musb: cppi_dma: Clean up cppi structure usb: musb: cppi41: Detect aborted transfers in cppi41_dma_callback() usb: musb: dma: Add a DMA completion platform callback drivers: usb: usbip: Add missing break statement to switch usb: mtu3: remove redundant dev_err call in get_ssusb_rscs() USB: serial: mos7840: fix another NULL-deref at open USB: serial: console: clean up sanity checks USB: serial: console: fix uninitialised spinlock ...
2017-02-21Merge tag 'dmaengine-4.11-rc1' of git://git.infradead.org/users/vkoul/slave-dmaLinus Torvalds
Pull dmaengine updates from Vinod Koul: "This time we fairly boring and bit small update. - Support for Intel iDMA 32-bit hardware - deprecate broken support for channel switching in async_tx - bunch of updates on stm32-dma - Cyclic support for zx dma and making in generic zx dma driver - Small updates to bunch of other drivers" * tag 'dmaengine-4.11-rc1' of git://git.infradead.org/users/vkoul/slave-dma: (29 commits) async_tx: deprecate broken support for channel switching dmaengine: rcar-dmac: Widen DMA mask to 40 bits dmaengine: sun6i: allow build on ARM64 platforms (sun50i) dmaengine: Provide a wrapper for memcpy operations dmaengine: zx: fix build warning dmaengine: dw: we do support Merrifield SoC in PCI mode dmaengine: dw: add support of iDMA 32-bit hardware dmaengine: dw: introduce register mappings for iDMA 32-bit dmaengine: dw: introduce block2bytes() and bytes2block() dmaengine: dw: extract dwc_chan_pause() for future use dmaengine: dw: replace convert_burst() with one liner dmaengine: dw: register IRQ and DMA pool with instance ID dmaengine: dw: Fix data corruption in large device to memory transfers dmaengine: ste_dma40: indicate granularity on channels dmaengine: ste_dma40: indicate directions on channels dmaengine: stm32-dma: Add error messages if xlate fails dmaengine: dw: pci: remove LPE Audio DMA ID dmaengine: stm32-dma: Add max_burst support dmaengine: stm32-dma: Add synchronization support dmaengine: stm32-dma: Fix residue computation issue in cyclic mode ...
2017-02-21Merge branch 'topic/zx' into for-linusVinod Koul
2017-02-21Merge branch 'topic/stm32-dma' into for-linusVinod Koul
2017-02-21Merge branch 'topic/ste' into for-linusVinod Koul
2017-02-21Merge branch 'topic/intel' into for-linusVinod Koul
2017-02-14dmaengine: rcar-dmac: Widen DMA mask to 40 bitsGeert Uytterhoeven
By default, the DMA mask covers only the low 32-bit address space, which causes SWIOTLB on arm64 to fall back to a bounce buffer for DMA transfers involving memory outside the 32-bit address space. The R-Car DMA controller hardware supports a 40-bit address space, hence widen the DMA mask to 40 bits to actually make use of this feature. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Vinod Koul <vinod.koul@intel.com>
2017-02-10Merge branches 'iommu/fixes', 'arm/exynos', 'arm/renesas', 'arm/smmu', ↵Joerg Roedel
'arm/mediatek', 'arm/core', 'x86/vt-d' and 'core' into next
2017-02-09usb: musb: dsps: Manage CPPI 4.1 DMA interrupt in DSPSAlexandre Bailon
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 Zheng
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 ↵Joerg Roedel
git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into arm/core
2017-01-25dmaengine: pl330: fix double lockIago Abal
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 Nie
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 Shevchenko
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 Shevchenko
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 Shevchenko
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 Shevchenko
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 Shevchenko
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 Shevchenko
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 Shevchenko
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 Nikula
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 Lindgren
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 Lindgren
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 Lindgren
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 Humpherys
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 Shevchenko
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 Walleij
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 Walleij
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öderlund
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 Ujfalusi
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 Madianga
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 ↵Krister Johansen
allocations. 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 Shevchenko
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 Madianga
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 Madianga
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 Madianga
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 Madianga
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 Madianga
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 Szyprowski
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 Ujfalusi
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 Guo
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 Guo
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 Guo
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 Lilja
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 JAILLET
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 Wilcox
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 Madianga
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 Madianga
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 Delvare
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>