linux-toradex.git/drivers/dma, branch v5.16-rc3 Linux kernel for Apalis and Colibri modules Merge tag 'dmaengine-5.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine 2021-11-10T19:47:55+00:00 Linus Torvalds torvalds@linux-foundation.org 2021-11-10T19:47:55+00:00 e68a7d35bb17247f8129e17126352a07433f2908 Pull dmaengine updates from Vinod Koul: "A bunch of driver updates, no new driver or controller support this time though: - Another pile of idxd updates - pm routines cleanup for at_xdmac driver - Correct handling of callback_result for few drivers - zynqmp_dma driver updates and descriptor management refinement - Hardware handshaking support for dw-axi-dmac - Support for remotely powered controllers in Qcom bam dma - tegra driver updates" * tag 'dmaengine-5.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine: (69 commits) dmaengine: ti: k3-udma: Set r/tchan or rflow to NULL if request fail dmaengine: ti: k3-udma: Set bchan to NULL if a channel request fail dmaengine: stm32-dma: avoid 64-bit division in stm32_dma_get_max_width dmaengine: fsl-edma: support edma memcpy dmaengine: idxd: fix resource leak on dmaengine driver disable dmaengine: idxd: cleanup completion record allocation dmaengine: zynqmp_dma: Correctly handle descriptor callbacks dmaengine: xilinx_dma: Correctly handle cyclic descriptor callbacks dmaengine: altera-msgdma: Correctly handle descriptor callbacks dmaengine: at_xdmac: fix compilation warning dmaengine: dw-axi-dmac: Simplify assignment in dma_chan_pause() dmaengine: qcom: bam_dma: Add "powered remotely" mode dt-bindings: dmaengine: bam_dma: Add "powered remotely" mode dmaengine: sa11x0: Mark PM functions as __maybe_unused dmaengine: switch from 'pci_' to 'dma_' API dmaengine: ioat: switch from 'pci_' to 'dma_' API dmaengine: hsu: switch from 'pci_' to 'dma_' API dmaengine: hisi_dma: switch from 'pci_' to 'dma_' API dmaengine: dw: switch from 'pci_' to 'dma_' API dmaengine: dw-edma-pcie: switch from 'pci_' to 'dma_' API ... 
Pull dmaengine updates from Vinod Koul:
 "A bunch of driver updates, no new driver or controller support this
  time though:

   - Another pile of idxd updates

   - pm routines cleanup for at_xdmac driver

   - Correct handling of callback_result for few drivers

   - zynqmp_dma driver updates and descriptor management refinement

   - Hardware handshaking support for dw-axi-dmac

   - Support for remotely powered controllers in Qcom bam dma

   - tegra driver updates"

* tag 'dmaengine-5.16-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/vkoul/dmaengine: (69 commits)
  dmaengine: ti: k3-udma: Set r/tchan or rflow to NULL if request fail
  dmaengine: ti: k3-udma: Set bchan to NULL if a channel request fail
  dmaengine: stm32-dma: avoid 64-bit division in stm32_dma_get_max_width
  dmaengine: fsl-edma: support edma memcpy
  dmaengine: idxd: fix resource leak on dmaengine driver disable
  dmaengine: idxd: cleanup completion record allocation
  dmaengine: zynqmp_dma: Correctly handle descriptor callbacks
  dmaengine: xilinx_dma: Correctly handle cyclic descriptor callbacks
  dmaengine: altera-msgdma: Correctly handle descriptor callbacks
  dmaengine: at_xdmac: fix compilation warning
  dmaengine: dw-axi-dmac: Simplify assignment in dma_chan_pause()
  dmaengine: qcom: bam_dma: Add "powered remotely" mode
  dt-bindings: dmaengine: bam_dma: Add "powered remotely" mode
  dmaengine: sa11x0: Mark PM functions as __maybe_unused
  dmaengine: switch from 'pci_' to 'dma_' API
  dmaengine: ioat: switch from 'pci_' to 'dma_' API
  dmaengine: hsu: switch from 'pci_' to 'dma_' API
  dmaengine: hisi_dma: switch from 'pci_' to 'dma_' API
  dmaengine: dw: switch from 'pci_' to 'dma_' API
  dmaengine: dw-edma-pcie: switch from 'pci_' to 'dma_' API
  ...
dmaengine: ti: k3-udma: Set r/tchan or rflow to NULL if request fail 2021-11-09T05:54:06+00:00 Kishon Vijay Abraham I kishon@ti.com 2021-10-31T03:24:11+00:00 eb91224e47ec33a0a32c9be0ec0fcb3433e555fd udma_get_*() checks if rchan/tchan/rflow is already allocated by checking if it has a NON NULL value. For the error cases, rchan/tchan/rflow will have error value and udma_get_*() considers this as already allocated (PASS) since the error values are NON NULL. This results in NULL pointer dereference error while de-referencing rchan/tchan/rflow. Reset the value of rchan/tchan/rflow to NULL if a channel request fails. CC: stable@vger.kernel.org Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Link: https://lore.kernel.org/r/20211031032411.27235-3-kishon@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org> 
udma_get_*() checks if rchan/tchan/rflow is already allocated by checking
if it has a NON NULL value. For the error cases, rchan/tchan/rflow will
have error value and udma_get_*() considers this as already allocated
(PASS) since the error values are NON NULL. This results in NULL pointer
dereference error while de-referencing rchan/tchan/rflow.

Reset the value of rchan/tchan/rflow to NULL if a channel request fails.

CC: stable@vger.kernel.org
Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Link: https://lore.kernel.org/r/20211031032411.27235-3-kishon@ti.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
dmaengine: ti: k3-udma: Set bchan to NULL if a channel request fail 2021-11-09T05:54:06+00:00 Kishon Vijay Abraham I kishon@ti.com 2021-10-31T03:24:10+00:00 5c6c6d60e4b489308ae4da8424c869f7cc53cd12 bcdma_get_*() checks if bchan is already allocated by checking if it has a NON NULL value. For the error cases, bchan will have error value and bcdma_get_*() considers this as already allocated (PASS) since the error values are NON NULL. This results in NULL pointer dereference error while de-referencing bchan. Reset the value of bchan to NULL if a channel request fails. CC: stable@vger.kernel.org Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com> Link: https://lore.kernel.org/r/20211031032411.27235-2-kishon@ti.com Signed-off-by: Vinod Koul <vkoul@kernel.org> 
bcdma_get_*() checks if bchan is already allocated by checking if it
has a NON NULL value. For the error cases, bchan will have error value
and bcdma_get_*() considers this as already allocated (PASS) since the
error values are NON NULL. This results in NULL pointer dereference
error while de-referencing bchan.

Reset the value of bchan to NULL if a channel request fails.

CC: stable@vger.kernel.org
Acked-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Link: https://lore.kernel.org/r/20211031032411.27235-2-kishon@ti.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
dmaengine: stm32-dma: avoid 64-bit division in stm32_dma_get_max_width 2021-11-09T05:50:35+00:00 Arnd Bergmann arnd@arndb.de 2021-11-03T15:33:12+00:00 2498363310e9b5e5de0e104709adc35c9f3ff7d9 Using the % operator on a 64-bit variable is expensive and can cause a link failure: arm-linux-gnueabi-ld: drivers/dma/stm32-dma.o: in function `stm32_dma_get_max_width': stm32-dma.c:(.text+0x170): undefined reference to `__aeabi_uldivmod' arm-linux-gnueabi-ld: drivers/dma/stm32-dma.o: in function `stm32_dma_set_xfer_param': stm32-dma.c:(.text+0x1cd4): undefined reference to `__aeabi_uldivmod' As we know that we just want to check the alignment in stm32_dma_get_max_width(), there is no need for a full division, and using a simple mask is a faster replacement. Same in stm32_dma_set_xfer_param(), change this to only allow burst transfers if the address is a multiple of the length. stm32_dma_get_best_burst just after will take buf_len into account to fix burst in case of misalignment. Fixes: b20fd5fa310c ("dmaengine: stm32-dma: fix stm32_dma_get_max_width") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com> Link: https://lore.kernel.org/r/20211103153312.41483-1-amelie.delaunay@foss.st.com Signed-off-by: Vinod Koul <vkoul@kernel.org> 
Using the % operator on a 64-bit variable is expensive and can
cause a link failure:

arm-linux-gnueabi-ld: drivers/dma/stm32-dma.o: in function `stm32_dma_get_max_width':
stm32-dma.c:(.text+0x170): undefined reference to `__aeabi_uldivmod'
arm-linux-gnueabi-ld: drivers/dma/stm32-dma.o: in function `stm32_dma_set_xfer_param':
stm32-dma.c:(.text+0x1cd4): undefined reference to `__aeabi_uldivmod'

As we know that we just want to check the alignment in
stm32_dma_get_max_width(), there is no need for a full division, and
using a simple mask is a faster replacement.

Same in stm32_dma_set_xfer_param(), change this to only allow burst
transfers if the address is a multiple of the length.
stm32_dma_get_best_burst just after will take buf_len into account to fix
burst in case of misalignment.

Fixes: b20fd5fa310c ("dmaengine: stm32-dma: fix stm32_dma_get_max_width")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Amelie Delaunay <amelie.delaunay@foss.st.com>
Link: https://lore.kernel.org/r/20211103153312.41483-1-amelie.delaunay@foss.st.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
dmaengine: fsl-edma: support edma memcpy 2021-10-28T17:26:24+00:00 Joy Zou joy.zou@nxp.com 2021-10-26T09:00:25+00:00 e0674853943287669a82d1ffe09a700944615978 Add memcpy in edma. The edma has the capability to transfer data by software trigger so that it could be used for memory copy. Enable MEMCPY for edma driver and it could be test directly by dmatest. Signed-off-by: Joy Zou <joy.zou@nxp.com> Link: https://lore.kernel.org/r/20211026090025.2777292-1-joy.zou@nxp.com Signed-off-by: Vinod Koul <vkoul@kernel.org> 
Add memcpy in edma. The edma has the capability to transfer data by
software trigger so that it could be used for memory copy. Enable
MEMCPY for edma driver and it could be test directly by dmatest.

Signed-off-by: Joy Zou <joy.zou@nxp.com>
Link: https://lore.kernel.org/r/20211026090025.2777292-1-joy.zou@nxp.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
dmaengine: idxd: fix resource leak on dmaengine driver disable 2021-10-28T17:24:45+00:00 Dave Jiang dave.jiang@intel.com 2021-10-25T15:01:04+00:00 a3e340c1574b6679f5b333221284d0959095da52 The wq resources needs to be released before the kernel type is reset by __drv_disable_wq(). With dma channels unregistered and wq quiesced, all the wq resources for dmaengine can be freed. There is no need to wait until wq is disabled. With the wq->type being reset to "unknown", the driver is skipping the freeing of the resources. Fixes: 0cda4f6986a3 ("dmaengine: idxd: create dmaengine driver for wq 'device'") Reported-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Tested-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/163517405099.3484556.12521975053711345244.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org> 
The wq resources needs to be released before the kernel type is reset by
__drv_disable_wq(). With dma channels unregistered and wq quiesced, all the
wq resources for dmaengine can be freed. There is no need to wait until wq
is disabled. With the wq->type being reset to "unknown", the driver is
skipping the freeing of the resources.

Fixes: 0cda4f6986a3 ("dmaengine: idxd: create dmaengine driver for wq 'device'")
Reported-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Tested-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/163517405099.3484556.12521975053711345244.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
dmaengine: idxd: cleanup completion record allocation 2021-10-28T17:24:44+00:00 Dave Jiang dave.jiang@intel.com 2021-10-25T14:59:49+00:00 2efe58cfaad4ad94eab888d287c174de5209a0c2 According to core-api/dma-api-howto.rst, the address from dma_alloc_coherent is gauranteed to align to the smallest PAGE_SIZE order. That supercedes the 64B/32B alignment requirement of the completion record. Remove alignment adjustment code. Tested-by: Jacob Pan <jacob.jun.pan@linux.intel.com> Signed-off-by: Dave Jiang <dave.jiang@intel.com> Link: https://lore.kernel.org/r/163517396063.3484297.7494385225280705372.stgit@djiang5-desk3.ch.intel.com Signed-off-by: Vinod Koul <vkoul@kernel.org> 
According to core-api/dma-api-howto.rst, the address from
dma_alloc_coherent is gauranteed to align to the smallest PAGE_SIZE order.
That supercedes the 64B/32B alignment requirement of the completion record.
Remove alignment adjustment code.

Tested-by: Jacob Pan <jacob.jun.pan@linux.intel.com>
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/163517396063.3484297.7494385225280705372.stgit@djiang5-desk3.ch.intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
dmaengine: zynqmp_dma: Correctly handle descriptor callbacks 2021-10-28T17:23:54+00:00 Lars-Peter Clausen lars@metafoo.de 2021-10-25T07:54:28+00:00 1825ecc908d4e77735a993a72406e04e9dfbe5eb DMA clients can provide one of two types of callbacks. For this reason dmaengine drivers should not directly invoke `callback`, but always use `dmaengine_desc_callback_invoke()`. This makes sure that both types of callbacks are handled correctly. The zynqmp_dma driver currently doesn't do this and only handles the `callback` type callback. If the client used the `callback_result` type callback it will not be called. Fix this by switching to `dmaengine_desc_callback_valid()` and `dmaengine_desc_callback_invoke()`. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20211025075428.2094-3-lars@metafoo.de Signed-off-by: Vinod Koul <vkoul@kernel.org> 
DMA clients can provide one of two types of callbacks. For this reason
dmaengine drivers should not directly invoke `callback`, but always use
`dmaengine_desc_callback_invoke()`. This makes sure that both types of
callbacks are handled correctly.

The zynqmp_dma driver currently doesn't do this and only handles the
`callback` type callback. If the client used the `callback_result` type
callback it will not be called.

Fix this by switching to `dmaengine_desc_callback_valid()` and
`dmaengine_desc_callback_invoke()`.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211025075428.2094-3-lars@metafoo.de
Signed-off-by: Vinod Koul <vkoul@kernel.org>
dmaengine: xilinx_dma: Correctly handle cyclic descriptor callbacks 2021-10-28T17:23:54+00:00 Lars-Peter Clausen lars@metafoo.de 2021-10-25T07:54:27+00:00 a63ddc38571ef32eb396eb81f50dca1c8d9b2432 DMA clients can provide one of two types of callbacks. For this reason dmaengine drivers should not directly invoke `callback`, but always use `dmaengine_desc_callback_invoke()`. This makes sure that both types of callbacks are handled correctly. The xilinx_dma driver currently doesn't do this for cyclic descriptors and only handles the `callback` type callback. If the client used the `callback_result` type callback it will not be called. Fix this by switching to `dmaengine_desc_callback_valid()` and `dmaengine_desc_callback_invoke()`. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20211025075428.2094-2-lars@metafoo.de Signed-off-by: Vinod Koul <vkoul@kernel.org> 
DMA clients can provide one of two types of callbacks. For this reason
dmaengine drivers should not directly invoke `callback`, but always use
`dmaengine_desc_callback_invoke()`. This makes sure that both types of
callbacks are handled correctly.

The xilinx_dma driver currently doesn't do this for cyclic descriptors and
only handles the `callback` type callback. If the client used the
`callback_result` type callback it will not be called.

Fix this by switching to `dmaengine_desc_callback_valid()` and
`dmaengine_desc_callback_invoke()`.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211025075428.2094-2-lars@metafoo.de
Signed-off-by: Vinod Koul <vkoul@kernel.org>
dmaengine: altera-msgdma: Correctly handle descriptor callbacks 2021-10-28T17:23:54+00:00 Lars-Peter Clausen lars@metafoo.de 2021-10-25T07:54:26+00:00 a34da7ef9a8c2b89ddb84689562f3d2b48a4e588 DMA clients can provide one of two types of callbacks. For this reason dmaengine drivers should not directly invoke `callback`, but always use dmaengine_desc_callback_invoke(). This makes sure that both types of callbacks are handled correctly. The altera-msgdma driver currently doesn't do this and only handles the `callback` type callback. If the client used the `callback_result` type callback it will not be called. Fix this by switching to `dmaengine_desc_callback_valid()` and `dmaengine_desc_callback_invoke()`. Signed-off-by: Lars-Peter Clausen <lars@metafoo.de> Link: https://lore.kernel.org/r/20211025075428.2094-1-lars@metafoo.de Signed-off-by: Vinod Koul <vkoul@kernel.org> 
DMA clients can provide one of two types of callbacks. For this reason
dmaengine drivers should not directly invoke `callback`, but always use
dmaengine_desc_callback_invoke(). This makes sure that both types of
callbacks are handled correctly.

The altera-msgdma driver currently doesn't do this and only handles the
`callback` type callback. If the client used the `callback_result` type
callback it will not be called.

Fix this by switching to `dmaengine_desc_callback_valid()` and
`dmaengine_desc_callback_invoke()`.

Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Link: https://lore.kernel.org/r/20211025075428.2094-1-lars@metafoo.de
Signed-off-by: Vinod Koul <vkoul@kernel.org>