- 05 Jan, 2022 1 commit
-
-
Vinod Koul authored
We have a conflict in idxd driver between 'fixes' and 'next' and there are patches dependent on this so, merge the 'fixes' branch into next
-
- 03 Jan, 2022 6 commits
-
-
Kunihiko Hayashi authored
The variables src_addr and dst_addr handle DMA addresses, so these should be declared as dma_addr_t. Fixes: 667b9251 ("dmaengine: uniphier-xdmac: Add UniPhier external DMA controller driver") Signed-off-by:
Kunihiko Hayashi <hayashi.kunihiko@socionext.com> Link: https://lore.kernel.org/r/1639456963-10232-1-git-send-email-hayashi.kunihiko@socionext.comSigned-off-by:
Vinod Koul <vkoul@kernel.org>
-
Vinod Koul authored
Commit 188c310bdd5d ("dmaengine: xilinx_dpdma: stop using slave_id field") add the header file with incorrect format for SPDX tag, fix that WARNING: Improper SPDX comment style for 'include/linux/dma/xilinx_dpdma.h', please use '/*' instead #1: FILE: include/linux/dma/xilinx_dpdma.h:1: +// SPDX-License-Identifier: GPL-2.0 WARNING: Missing or malformed SPDX-License-Identifier tag in line 1 #1: FILE: include/linux/dma/xilinx_dpdma.h:1: +// SPDX-License-Identifier: GPL-2.0 Fixes: 188c310bdd5d ("dmaengine: xilinx_dpdma: stop using slave_id field") Signed-off-by: -
Rob Herring authored
Convert the Arm PL330 DMA controller binding to DT schema. The '#dma-channels' and '#dma-requests' properties are unused as they are discoverable and are non-standard (the standard props don't have '#'). So drop them from the binding. Cc: Vinod Koul <vkoul@kernel.org> Cc: dmaengine@vger.kernel.org Signed-off-by:
Rob Herring <robh@kernel.org> Link: https://lore.kernel.org/r/20211217170644.3145332-1-robh@kernel.orgSigned-off-by:
-
Amelie Delaunay authored
This patch fixes STM32_MDMA_CTBR_TSEL_MASK, which is [5:0], not [7:0]. Fixes: a4ffb13c ("dmaengine: Add STM32 MDMA driver") Signed-off-by:
Amelie Delaunay <amelie.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20211220165827.1238097-1-amelie.delaunay@foss.st.comSigned-off-by:
-
Yoshihiro Shimoda authored
Add support for R-Car S4-8. We can reuse R-Car V3U code so that renames variable names as "gen4". Note that some registers of R-Car V3U do not exist on R-Car S4-8, but none of them are used by the driver for now. Signed-off-by:
Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com> Reviewed-by:
Ulrich Hecht <uli+renesas@fpond.eu> Reviewed-by:
Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20211222114507.1252947-3-yoshihiro.shimoda.uh@renesas.comSigned-off-by:
-
Yoshihiro Shimoda authored
Document the compatible value for the Direct Memory Access Controller blocks in the Renesas R-Car S4-8 (R8A779F0) SoC. The most visible difference with DMAC blocks on other R-Car SoCs (except R8A779A0) is the move of the per-channel registers to a separate register block. Signed-off-by:
-
- 17 Dec, 2021 30 commits
-
-
Vinod Koul authored
Merge the tag dmaengine_topic_slave_id_removal_5.17 into next. This brings in the slave_id removal topic changes
-
Christophe JAILLET authored
'shdma_slave_used' is a bitmap. So use 'bitmap_zalloc()' to simplify code, improve the semantic and avoid some open-coded arithmetic in allocator arguments. Also change the corresponding 'kfree()' into 'bitmap_free()' to keep consistency. Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/3efaf2784424ae3d7411dc47f8b6b03e7bb8c059.1637702701.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
Geert Uytterhoeven authored
Use the FIELD_{GET,PREP}() helpers, instead of defining custom macros implementing the same operations. Signed-off-by: -
Colin Ian King authored
The pointer hwdesc is being initialized with a value that is never read, it is being updated later in a for-loop. The assignment is redundant and can be removed. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Reviewed-by:
-
Dave Jiang authored
Add a sysfs knob to allow tuning of retries for the kernel ENQCMDS descriptor submission. While on host, it is not as likely that ENQCMDS return busy during normal operations due to the driver controlling the number of descriptors allocated for submission. However, when the driver is operating as a guest driver, the chance of retry goes up significantly due to sharing a wq with multiple VMs. A default value is provided with the system admin being able to tune the value on a per WQ basis. Suggested-by:
Sanjay Kumar <sanjay.k.kumar@intel.com> Signed-off-by:
Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/163820629464.2702134.7577370098568297574.stgit@djiang5-desk3.ch.intel.comSigned-off-by:
-
Dave Jiang authored
Add default values for wq size, max_xfer_size and max_batch_size. These values should provide a general guidance for the wq configuration when the user does not specify any specific values. Signed-off-by:
-
Geert Uytterhoeven authored
"make dtbs_check": Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml arch/riscv/boot/dts/canaan/sipeed_maix_bit.dt.yaml: dma-controller@50000000: 'resets' does not match any of the regexes: 'pinctrl-[0-9]+' From schema: Documentation/devicetree/bindings/dma/snps,dw-axi-dmac.yaml The Synopsys DesignWare AXI DMA Controller on the Canaan K210 SoC exposes its reset signal. Signed-off-by:Geert Uytterhoeven <geert@linux-m68k.org> Acked-by:
Damien Le Moal <damien.lemoal@opensource.wdc.com> Link: https://lore.kernel.org/r/20211125152008.162571-1-geert@linux-m68k.orgSigned-off-by:
-
Paul Cercueil authored
For some devices with only half-duplex capabilities, it doesn't make much sense to use one DMA channel per direction, as both channels will never be active at the same time. Add support for bidirectional I/O on DMA channels. The client drivers can then request a "tx-rx" DMA channel which will be used for both directions. Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Link: https://lore.kernel.org/r/20211206174259.68133-7-paul@crapouillou.netSigned-off-by:
-
Paul Cercueil authored
Replace the uint32_t type used all over dma-jz4780.c with the equivalent Linux type: u32. Signed-off-by:
-
Paul Cercueil authored
The JZ4760 and JZ4760B SoCs have two regular DMA controllers with 6 channels each. They also have an extra DMA controller named MDMA with only 2 channels, that only supports memcpy operations, and one named BDMA with only 3 channels, that is mostly used for transfers between memories and the BCH controller. Signed-off-by:
-
Paul Cercueil authored
The JZ4760 SoC has a hardware problem with chan0 not enabling properly if it's enabled before chan1, after a reset (works fine afterwards). This is worked around in the probe function by just enabling then disabling chan1. Signed-off-by:
-
Paul Cercueil authored
Extend the binding to support specifying a different request type for each direction. Signed-off-by:
-
Paul Cercueil authored
The JZ4760 and JZ4760B SoCs have two additional DMA controllers: the MDMA, which only supports memcpy operations, and the BDMA which is mostly used for transfer between memories and the BCH controller. The JZ4770 also features the same BDMA as in the JZ4760B, but does not seem to have a MDMA. Signed-off-by:
-
Rob Herring authored
The TI k3-bcdma and k3-pktdma both use 'ti,sci' and 'ti,sci-dev-id' properties defined in ti,k3-sci-common.yaml. When 'unevaluatedProperties' support is enabled, the follow warning is generated: Documentation/devicetree/bindings/dma/ti/k3-bcdma.example.dt.yaml: dma-controller@485c0100: Unevaluated properties are not allowed ('ti,sci', 'ti,sci-dev-id' were unexpected) Documentation/devicetree/bindings/dma/ti/k3-pktdma.example.dt.yaml: dma-controller@485c0000: Unevaluated properties are not allowed ('ti,sci', 'ti,sci-dev-id' were unexpected) Add a reference to ti,k3-sci-common.yaml to fix this. Cc: Peter Ujfalusi <peter.ujfalusi@gmail.com> Cc: Vinod Koul <vkoul@kernel.org> Cc: dmaengine@vger.kernel.org Signed-off-by:Thierry Reding <treding@nvidia.com> Link: https://lore.kernel.org/r/20211206174226.2298135-1-robh@kernel.orgSigned-off-by:
-
Rob Herring authored
With 'unevaluatedProperties' support implemented, the example has warnings on primecell properties and 'resets': Documentation/devicetree/bindings/dma/arm-pl08x.example.dt.yaml: dma-controller@67000000: Unevaluated properties are not allowed ('arm,primecell-periphid', 'resets' were unexpected) Add the missing reference to primecell.yaml and definition for 'resets'. Cc: Vinod Koul <vkoul@kernel.org> Cc: dmaengine@vger.kernel.org Signed-off-by: -
Aswath Govindraju authored
Add support for J721S2 SOC. Signed-off-by:
Aswath Govindraju <a-govindraju@ti.com> Acked-by:
Peter Ujfalusi <peter.ujfalusi@gmail.com> Link: https://lore.kernel.org/r/20211119132315.15901-3-a-govindraju@ti.comSigned-off-by:
-
Aswath Govindraju authored
Add SYSFW defined rchan_oes_offset number for J721S2 SoC in soc data. Signed-off-by:
-
Gustavo A. R. Silva authored
Make use of the struct_size() helper instead of an open-coded version, in order to avoid any potential type mistakes or integer overflows that, in the worst scenario, could lead to heap overflows. Link: https://github.com/KSPP/linux/issues/160Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20211208001013.GA62330@embeddedorSigned-off-by:
-
Lars-Peter Clausen authored
Handle errors when trying to map the IRQ for the DMA channels. The main motivation here is to be able to handle probe deferral. E.g. when using DT overlays it is possible that the DMA controller is probed before interrupt controller, depending on the order in the DT. In order to support this switch from irq_of_parse_and_map() to of_irq_get(), which internally does the same, but it will return EPROBE_DEFER when the interrupt controller is not yet available. As a result other errors, such as an invalid IRQ specification, or missing IRQ are also properly handled. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Reviewed-by:
Radhey Shyam Pandey <radhey.shyam.pandey@xilinx.com> Link: https://lore.kernel.org/r/20211208114212.234130-1-lars@metafoo.deSigned-off-by:
-
Arnd Bergmann authored
All references to the slave_id field have been removed, so remove the field as well to prevent new references from creeping in again. Originally this allowed slave DMA drivers to configure which device is accessed with the dmaengine_slave_config() call, but this was inconsistent, as the same information is also passed while requesting a channel, and never changes in practice. In modern kernels, the device is always selected when requesting the channel, so the .slave_id field is no longer useful. Reviewed-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Mark Brown <broonie@kernel.org> Link: https://lore.kernel.org/r/20211122222203.4103644-12-arnd@kernel.orgSigned-off-by:
-
Arnd Bergmann authored
The display driver wants to pass a custom flag to the DMA engine driver, which it started doing by using the slave_id field that was traditionally used for a different purpose. As there is no longer a correct use for the slave_id field, it should really be removed, and the remaining users changed over to something different. The new mechanism for passing nonstandard settings is using the .peripheral_config field, so use that to pass a newly defined structure here, making it clear that this will not work in portable drivers. Reviewed-by:
-
Arnd Bergmann authored
The slave_id was previously used to pick one DMA slave instead of another, but this is now done through the DMA descriptors in device tree. For the qcom_adm driver, the configuration is documented in the DT binding to contain a tuple of device identifier and a "crci" field, but the implementation ends up using only a single cell for identifying the slave, with the crci getting passed in nonstandard properties of the device, and passed through the dma driver using the old slave_id field. Part of the problem apparently is that the nand driver ends up using only a single DMA request ID, but requires distinct values for "crci" depending on the type of transfer. Change both the dmaengine driver and the two slave drivers to allow the documented binding to work in addition to the ad-hoc passing of crci values. In order to no longer abuse the slave_id field, pass the data using the "peripheral_config" mechanism instead. Signed-off-by:
-
Arnd Bergmann authored
It appears that the code that reads the slave_id from the channel config was copied incorrectly from other drivers. Nothing ever sets this field on platforms that use this driver, so remove the reference. Reviewed-by:
Baolin Wang <baolin.wang7@gmail.com> Signed-off-by:
-
Arnd Bergmann authored
The last driver referencing the slave_id on Marvell PXA and MMP platforms was the SPI driver, but this stopped doing so a long time ago, so the TODO from the earlier patch can no be removed. Fixes: b729bf34 ("spi/pxa2xx: Don't use slave_id of dma_slave_config") Fixes: 13b3006b ("dma: mmp_pdma: add filter function") Signed-off-by:
-
Arnd Bergmann authored
The slave device is picked through either devicetree or a filter function, and any remaining out-of-tree drivers would have warned about this usage since 2015. Stop interpreting the field finally so it can be removed from the interface. Reviewed-by:
-
Arnd Bergmann authored
The field is not interpreted by the DMA engine driver, as all the data is passed from devicetree instead. Remove the assignment so the field can eventually be deleted. Reviewed-by:
Nicolas Saenz Julienne <nsaenz@kernel.org> Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Acked-by:
-
Arnd Bergmann authored
Setting slave_id makes no sense with DT based probing, and should eventually get removed entirely. Address this driver by no longer setting the field here. I could not find which DMA driver is used on PIC32, if it's in the tree at all, but none of the obvious ones even care about slave_id any more. Acked-by:
-
Arnd Bergmann authored
This field is no longer set from any driver now, so remove the last references as well. Signed-off-by:
-
Arnd Bergmann authored
Nothing sets the slave_id field any more, so stop accessing it to allow the removal of this field. Signed-off-by:
-
Arnd Bergmann authored
The DMA resource is never set up anywhere, and passing this as slave_id has not been the proper procedure in a long time. As a preparation for removing all slave_id references from the ALSA code, remove this one. According to Dmitry Osipenko, this driver has never been used and the mechanism for configuring DMA would not work as it is implemented, so this part will get rewritten when the driver gets put into use again in the future. Signed-off-by:
Dmitry Osipenko <digetx@gmail.com> Acked-by:
-
- 13 Dec, 2021 3 commits
-
-
Alyssa Ross authored
modprobe can't handle spaces in aliases. Fixes: 6b4cd727 ("dmaengine: st_fdma: Add STMicroelectronics FDMA engine driver support") Signed-off-by:
Alyssa Ross <hi@alyssa.is> Link: https://lore.kernel.org/r/20211125154441.2626214-1-hi@alyssa.isSigned-off-by:
-
Dave Jiang authored
Ming reported that with the abort path of the descriptor submission, there can be a window where a completed descriptor can be missed to be completed by the irq completion thread: CPU A CPU B Submit (successful) Submit (fail) irq_process_work_list() // empty llist_abort_desc() // remove all descs from pending list irq_process_pending_llist() // empty exit idxd_wq_thread() with no processing Add opportunistic descriptor completion in the abort path in order to remove the missed completion. Fixes: 6b4b87f2 ("dmaengine: idxd: fix submission race window") Reported-by:
Ming Li <ming4.li@intel.com> Signed-off-by:
-
Vignesh Raghavendra authored
Smatch reports below warnings [1] wrt dereferencing rm_res when it can potentially be ERR_PTR(). This is possible when entire range is allocated to Linux Fix this case by making sure, there is no deference of rm_res when its ERR_PTR(). [1]: drivers/dma/ti/k3-udma.c:4524 udma_setup_resources() error: 'rm_res' dereferencing possible ERR_PTR() drivers/dma/ti/k3-udma.c:4537 udma_setup_resources() error: 'rm_res' dereferencing possible ERR_PTR() drivers/dma/ti/k3-udma.c:4681 bcdma_setup_resources() error: 'rm_res' dereferencing possible ERR_PTR() drivers/dma/ti/k3-udma.c:4696 bcdma_setup_resources() error: 'rm_res' dereferencing possible ERR_PTR() drivers/dma/ti/k3-udma.c:4711 bcdma_setup_resources() error: 'rm_res' dereferencing possible ERR_PTR() drivers/dma/ti/k3-udma.c:4848 pktdma_setup_resources() error: 'rm_res' dereferencing possible ERR_PTR() drivers/dma/ti/k3-udma.c:4861 pktdma_setup_resources() error: 'rm_res' dereferencing possible ERR_PTR() Reported-by:
Nishanth Menon <nm@ti.com> Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com> Acked-by:
-
