- 12 Mar, 2019 7 commits
-
-
Vinod Koul authored
-
Vinod Koul authored
-
Vinod Koul authored
-
Vinod Koul authored
-
Vinod Koul authored
-
Vinod Koul authored
-
Vinod Koul authored
-
- 25 Feb, 2019 12 commits
-
-
Angus Ainslie (Purism) authored
Without the copy being aligned sdma1 fails ~10% of the time Signed-off-by:
Angus Ainslie (Purism) <angus@akkea.ca> Signed-off-by:
Vinod Koul <vkoul@kernel.org>
-
Angus Ainslie (Purism) authored
On i.mx8mq, there are two sdma instances, and the common dma framework will get a channel dynamically from any available sdma instance whether it's the first sdma device or the second sdma device. Some IPs like SAI only work with sdma2 not sdma1. To make sure the sdma channel is from the correct sdma device, use the node pointer to match. Signed-off-by:
Lucas Stach <l.stach@pengutronix.de> Tested-by:
Daniel Baluta <daniel.baluta@nxp.com> Signed-off-by:
-
Angus Ainslie (Purism) authored
On i.mx8 mscale B0 chip, AHB/SDMA clock ratio 2:1 can't be supportted, since SDMA clock ratio has to be increased to 250Mhz, AHB can't reach to 500Mhz, so use 1:1 instead. Based on NXP commit MLK-16841-1 by Robin Gong <yibin.gong@nxp.com> Signed-off-by:
-
Alexandru Ardelean authored
This patch starts to take advantage of the `dmatest_data` struct by moving the common allocation & free-ing bits into functions. Signed-off-by:
Alexandru Ardelean <alexandru.ardelean@analog.com> Signed-off-by:
-
Alexandru Ardelean authored
This is just a cosmetic change, since this variable gets used quite a bit inside the dmatest_func() routine. Signed-off-by:
-
Alexandru Ardelean authored
This change wraps the data for the source & destination buffers into a `struct dmatest_data`. The rename patterns are: * src_cnt -> src->cnt * dst_cnt -> dst->cnt * src_off -> src->off * dst_off -> dst->off * thread->srcs -> src->aligned * thread->usrcs -> src->raw * thread->dsts -> dst->aligned * thread->udsts -> dst->raw The intent is to make a function that moves duplicate parts of the code into common alloc & free functions, which will unclutter the `dmatest_func()` function. Signed-off-by:
-
Dave Jiang authored
IOATDMA 3.4 supports PCIe LTR mechanism. The registers are non-standard PCIe LTR support. This needs to be setup in order to not suffer performance impact and provide proper power management. The channel is set to active when it is allocated, and to passive when it's freed. Signed-off-by:
Dave Jiang <dave.jiang@intel.com> Signed-off-by:
-
Dave Jiang authored
Adding support for new feature on ioatdma 3.4 hardware that provides descriptor pre-fetching in order to reduce small DMA latencies. Signed-off-by:
-
Dave Jiang authored
IOATDMA v3.4 does not support DCA. Disable Signed-off-by:
-
Dave Jiang authored
Add Snowridge Xeon-D ioatdma PCI device id. Also applies for Icelake SP Xeon. This introduces ioatdma v3.4 platform. Also bumping driver version to 5.0 since we are adding additional code for 3.4 support. Signed-off-by:
-
Baolin Wang authored
We will describe the slave id in DMA cell specifier instead of DMA channel id, thus we should save the slave id from DMA engine translation function, and remove the channel id validation. Meanwhile we do not need set default slave id in sprd_dma_alloc_chan_resources(), remove it. Signed-off-by:
Baolin Wang <baolin.wang@linaro.org> Signed-off-by:
-
Baolin Wang authored
For Spreadtrum DMA engine, all channels are equal, which means slave can request any channels with setting a unique slave id to trigger this channel. Thus we can remove the channel id from device tree to assign the channel dynamically, moreover we should add the slave id in device tree. Signed-off-by:
Rob Herring <robh@kernel.org> Signed-off-by:
-
- 19 Feb, 2019 1 commit
-
-
Robin Murphy authored
Using dma_dev->dev for mappings before it's assigned with the correct device is unlikely to work as expected, and with future dma-direct changes, passing a NULL device may end up crashing entirely. I don't know enough about this hardware or the mv_xor_prep_dma_interrupt() operation to implement the appropriate error-handling logic that would have revealed those dma_map_single() calls failing on arm64 for as long as the driver has been enabled there, but moving the assignment earlier will at least make the current code operate as intended. Fixes: 22843545 ("dma: mv_xor: Add support for DMA_INTERRUPT") Reported-by:
John David Anglin <dave.anglin@bell.net> Tested-by:
Robin Murphy <robin.murphy@arm.com> Acked-by:
Thomas Petazzoni <thomas.petazzoni@bootlin.com> Tested-by:
-
- 11 Feb, 2019 2 commits
-
-
Federico Vaga authored
It clarifies that the DMA description pointer returned by `dmaengine_prep_*` function should not be used after submission. Signed-off-by:
Federico Vaga <federico.vaga@cern.ch> Signed-off-by:
-
Randy Dunlap authored
Fix markup warning: insert a blank line before the hint. Documentation/driver-api/dmaengine/dmatest.rst:63: WARNING: Unexpected indentation. Signed-off-by:
Randy Dunlap <rdunlap@infradead.org> Acked-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
- 04 Feb, 2019 13 commits
-
-
Li Yu authored
Add dma-channel-mask as a property for k3dma, it defines available dma channels which a non-secure mode driver can use. One sample usage of this is in Hi3660 SoC. DMA channel 0 is reserved to lpm3, which is a coprocessor for power management. So as a result, any request in kernel (which runs on main processor and in non-secure mode) should start from at least channel 1. Cc: Dan Williams <dan.j.williams@intel.com> Cc: Vinod Koul <vkoul@kernel.org> Cc: Tanglei Han <hantanglei@huawei.com> Cc: Zhuangluan Su <suzhuangluan@hisilicon.com> Cc: Ryan Grachek <ryan@edited.us> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: Guodong Xu <guodong.xu@linaro.org> Cc: dmaengine@vger.kernel.org Signed-off-by:
Li Yu <liyu65@hisilicon.com> [jstultz: Reworked to use a channel mask] Signed-off-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
-
Li Yu authored
Axi_config controls whether DMA resources can be accessed in non-secure mode, such as linux kernel. The register should be set by the bootloader stage and depends on the device. Thus, this patch removes axi_config from k3dma driver. Cc: Dan Williams <dan.j.williams@intel.com> Cc: Vinod Koul <vkoul@kernel.org> Cc: Tanglei Han <hantanglei@huawei.com> Cc: Zhuangluan Su <suzhuangluan@hisilicon.com> Cc: Ryan Grachek <ryan@edited.us> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: dmaengine@vger.kernel.org Acked-by:
Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by:
Guodong Xu <guodong.xu@linaro.org> [jstultz: Minor tweaks to commit message] Signed-off-by:
-
Youlin Wang authored
On the hi3660 hardware there are two (at least) DMA controllers, the DMA-P (Peripheral DMA) and the DMA-A (Audio DMA). The two blocks are similar, but have some slight differences. This resulted in the vendor implementing two separate drivers, which after review, they have been able to condense and re-use the existing k3dma driver. Thus, this patch adds support for the new "hisi-pcm-asp-dma-1.0" compatible string in the binding. One difference with the DMA-A controller, is that it does not need to initialize a clock. So we skip this by adding and using soc data flags. After above this driver will support both k3 and hisi_asp dma hardware. Cc: Dan Williams <dan.j.williams@intel.com> Cc: Vinod Koul <vkoul@kernel.org> Cc: Zhuangluan Su <suzhuangluan@hisilicon.com> Cc: Ryan Grachek <ryan@edited.us> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: dmaengine@vger.kernel.org Acked-by:
Youlin Wang <wwx575822@notesmail.huawei.com> Signed-off-by:
Tanglei Han <hantanglei@huawei.com> [jstultz: Reworked to use of_match_data, commit msg improvements] Signed-off-by:
-
John Stultz authored
Some dma channels can be reserved for secure mode or other hardware on the SoC, so provide a binding for a bitmask listing the available channels for the kernel to use. This follows the pre-existing bcm,dma-channel-mask binding. Cc: Vinod Koul <vkoul@kernel.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Tanglei Han <hantanglei@huawei.com> Cc: Zhuangluan Su <suzhuangluan@hisilicon.com> Cc: Ryan Grachek <ryan@edited.us> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: dmaengine@vger.kernel.org Cc: devicetree@vger.kernel.org Reviewed-by:
-
Youlin Wang authored
Extend the k3dma driver binding to support hisi-asp hardware variants. Cc: Vinod Koul <vkoul@kernel.org> Cc: Rob Herring <robh+dt@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Zhuangluan Su <suzhuangluan@hisilicon.com> Cc: Tanglei Han <hantanglei@huawei.com> Cc: Ryan Grachek <ryan@edited.us> Cc: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Cc: dmaengine@vger.kernel.org Cc: devicetree@vger.kernel.org Reviewed-by:
-
Scott Wood authored
Otherwise 64-bit PPC builds fail with undefined references to these accessors. Cc: Peng Ma <peng.ma@nxp.com> Cc: Wen He <wen.he_1@nxp.com> Fixes: 68997fff94afa (" dmaengine: fsldma: Adding macro FSL_DMA_IN/OUT implement for ARM platform") Signed-off-by:Scott Wood <oss@buserror.net> Signed-off-by:
-
Lukas Wunner authored
Remove an outdated comment claiming the driver only supports cyclic transactions. The driver has been supporting other transaction types for more than two years. Signed-off-by:
Lukas Wunner <lukas@wunner.de> Cc: Frank Pavlic <f.pavlic@kunbus.de> Cc: Martin Sperl <kernel@martin.sperl.org> Cc: Florian Meier <florian.meier@koalo.de> Tested-by:
Stefan Wahren <stefan.wahren@i2se.com> Acked-by:
Florian Kauer <florian.kauer@koalo.de> Signed-off-by:
-
Lukas Wunner authored
The BCM2835 DMA driver deletes a channel from a list upon termination without having added it to a list first. Moreover that operation is protected by a spinlock which isn't taken anywhere else. These appear to be remnants of an older version of the driver which accidentally got mainlined. Remove the dead code. Signed-off-by:
-
Lukas Wunner authored
Per section 4.2.1.1 of the BCM2835 ARM Peripherals spec, control blocks "must start at a 256 bit aligned address": https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf This rule is currently satisfied only by accident because struct bcm2835_dma_cb has a size of 256 bit and the DMA pool API happens to allocate blocks consecutively. It seems safer to be explicit and tell the DMA pool allocator about the required alignment. Signed-off-by:
-
Lukas Wunner authored
bcm2835_dma_abort() returns an int but bcm2835_dma_terminate_all() (its sole caller) does not evaluate the return value. Change the return type to void. Signed-off-by:
-
Lukas Wunner authored
There are multiple issues with bcm2835_dma_abort() (which is called on termination of a transaction): * The algorithm to abort the transaction first pauses the channel by clearing the ACTIVE flag in the CS register, then waits for the PAUSED flag to clear. Page 49 of the spec documents the latter as follows: "Indicates if the DMA is currently paused and not transferring data. This will occur if the active bit has been cleared [...]" https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf So the function is entering an infinite loop because it is waiting for PAUSED to clear which is always set due to the function having cleared the ACTIVE flag. The only thing that's saving it from itself is the upper bound of 10000 loop iterations. The code comment says that the intention is to "wait for any current AXI transfer to complete", so the author probably wanted to check the WAITING_FOR_OUTSTANDING_WRITES flag instead. Amend the function accordingly. * The CS register is only read at the beginning of the function. It needs to be read again after pausing the channel and before checking for outstanding writes, otherwise writes which were issued between the register read at the beginning of the function and pausing the channel may not be waited for. * The function seeks to abort the transfer by writing 0 to the NEXTCONBK register and setting the ABORT and ACTIVE flags. Thereby, the 0 in NEXTCONBK is sought to be loaded into the CONBLK_AD register. However experimentation has shown this approach to not work: The CONBLK_AD register remains the same as before and the CS register contains 0x00000030 (PAUSED | DREQ_STOPS_DMA). In other words, the control block is not aborted but merely paused and it will be resumed once the next DMA transaction is started. That is absolutely not the desired behavior. A simpler approach is to set the channel's RESET flag instead. This reliably zeroes the NEXTCONBK as well as the CS register. It requires less code and only a single MMIO write. This is also what popular user space DMA drivers do, e.g.: https://github.com/metachris/RPIO/blob/master/source/c_pwm/pwm.c Note that the spec is contradictory whether the NEXTCONBK register is writeable at all. On the one hand, page 41 claims: "The value loaded into the NEXTCONBK register can be overwritten so that the linked list of Control Block data structures can be dynamically altered. However it is only safe to do this when the DMA is paused." On the other hand, page 40 specifies: "Only three registers in each channel's register set are directly writeable (CS, CONBLK_AD and DEBUG). The other registers (TI, SOURCE_AD, DEST_AD, TXFR_LEN, STRIDE & NEXTCONBK), are automatically loaded from a Control Block data structure held in external memory." Fixes: 96286b57 ("dmaengine: Add support for BCM2835") Signed-off-by:
-
Lukas Wunner authored
If IRQ handlers are threaded (either because CONFIG_PREEMPT_RT_BASE is enabled or "threadirqs" was passed on the command line) and if system load is sufficiently high that wakeup latency of IRQ threads degrades, SPI DMA transactions on the BCM2835 occasionally break like this: ks8851 spi0.0: SPI transfer timed out bcm2835-dma 3f007000.dma: DMA transfer could not be terminated ks8851 spi0.0 eth2: ks8851_rdfifo: spi_sync() failed The root cause is an assumption made by the DMA driver which is documented in a code comment in bcm2835_dma_terminate_all(): /* * Stop DMA activity: we assume the callback will not be called * after bcm_dma_abort() returns (even if it does, it will see * c->desc is NULL and exit.) */ That assumption falls apart if the IRQ handler bcm2835_dma_callback() is threaded: A client may terminate a descriptor and issue a new one before the IRQ handler had a chance to run. In fact the IRQ handler may miss an *arbitrary* number of descriptors. The result is the following race condition: 1. A descriptor finishes, its interrupt is deferred to the IRQ thread. 2. A client calls dma_terminate_async() which sets channel->desc = NULL. 3. The client issues a new descriptor. Because channel->desc is NULL, bcm2835_dma_issue_pending() immediately starts the descriptor. 4. Finally the IRQ thread runs and writes BCM2835_DMA_INT to the CS register to acknowledge the interrupt. This clears the ACTIVE flag, so the newly issued descriptor is paused in the middle of the transaction. Because channel->desc is not NULL, the IRQ thread finalizes the descriptor and tries to start the next one. I see two possible solutions: The first is to call synchronize_irq() in bcm2835_dma_issue_pending() to wait until the IRQ thread has finished before issuing a new descriptor. The downside of this approach is unnecessary latency if clients desire rapidly terminating and re-issuing descriptors and don't have any use for an IRQ callback. (The SPI TX DMA channel is a case in point.) A better alternative is to make the IRQ thread recognize that it has missed descriptors and avoid finalizing the newly issued descriptor. So first of all, set the ACTIVE flag when acknowledging the interrupt. This keeps a newly issued descriptor running. If the descriptor was finished, the channel remains idle despite the ACTIVE flag being set. However the ACTIVE flag can then no longer be used to check whether the channel is idle, so instead check whether the register containing the current control block address is zero and finalize the current descriptor only if so. That way, there is no impact on latency and throughput if the client doesn't care for the interrupt: Only minimal additional overhead is introduced for non-cyclic descriptors as one further MMIO read is necessary per interrupt to check for idleness of the channel. Cyclic descriptors are sped up slightly by removing one MMIO write per interrupt. Fixes: 96286b57 ("dmaengine: Add support for BCM2835") Signed-off-by:
-
Laurentiu Tudor authored
This mapping needs to be created in order for slave dma transfers to work on systems with SMMU. The implementation mostly mimics the one in pl330 dma driver, authored by Robin Murphy. Signed-off-by:
Laurentiu Tudor <laurentiu.tudor@nxp.com> Suggested-by:
Angelo Dureghello <angelo@sysam.it> Signed-off-by:
-
- 20 Jan, 2019 5 commits
-
-
Phuong Nguyen authored
This commit fixes the issue that USB-DMAC hangs silently after system resumes on R-Car Gen3 hence renesas_usbhs will not work correctly when using USB-DMAC for bulk transfer e.g. ethernet or serial gadgets. The issue can be reproduced by these steps: 1. modprobe g_serial 2. Suspend and resume system. 3. connect a usb cable to host side 4. Transfer data from Host to Target 5. cat /dev/ttyGS0 (Target side) 6. echo "test" > /dev/ttyACM0 (Host side) The 'cat' will not result anything. However, system still can work normally. Currently, USB-DMAC driver does not have system sleep callbacks hence this driver relies on the PM core to force runtime suspend/resume to suspend and reinitialize USB-DMAC during system resume. After the commit 17218e00 ("PM / genpd: Stop/start devices without pm_runtime_force_suspend/resume()"), PM core will not force runtime suspend/resume anymore so this issue happens. To solve this, make system suspend resume explicit by using pm_runtime_force_{suspend,resume}() as the system sleep callbacks. SET_NOIRQ_SYSTEM_SLEEP_PM_OPS() is used to make sure USB-DMAC suspended after and initialized before renesas_usbhs." Signed-off-by:
Phuong Nguyen <phuong.nguyen.xw@renesas.com> Signed-off-by:
Hiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com> Cc: <stable@vger.kernel.org> # v4.16+ [shimoda: revise the commit log and add Cc tag] Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Signed-off-by:
-
Andy Duan authored
Pass ->dev to dma_alloc_coherent() API. We need this because dma_alloc_coherent() makes use of dev parameter and receiving NULL will result in a crash. Signed-off-by:
Andy Duan <fugang.duan@nxp.com> Signed-off-by:
Robin Gong <yibin.gong@nxp.com> Signed-off-by:
-
Vinod Koul authored
The return value of function 'imxdma_sg_next' is not checked anywhere, so make it void return type. Signed-off-by: -
Vinod Koul authored
now is used to keep size and it is better to change the variable type to size_t Signed-off-by: -
Anders Roxell authored
The warning got introduced by commit 930507c1 ("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:
Anders Roxell <anders.roxell@linaro.org> Acked-by:
Olof Johansson <olof@lixom.net> Reviewed-by:
Fabio Estevam <festevam@gmail.com> Signed-off-by:
-
