archive mirror
 help / color / mirror / Atom feed
From: Frank Li <>
Subject: [PATCH v10 6/9] dmaengine: dw-edma: Fix eDMA Rd/Wr-channels and DMA-direction semantics
Date: Mon,  2 May 2022 19:57:58 -0500	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

From: Serge Semin <>

In accordance with [1, 2] the DW eDMA controller has been created to be
part of the DW PCIe Root Port and DW PCIe End-point controllers and to
offload the transferring of large blocks of data between application and
remote PCIe domains leaving the system CPU free for other tasks. In the
first case (eDMA being part of DW PCIe Root Port) the eDMA controller is
always accessible via the CPU DBI interface and never over the PCIe wire.
The later case is more complex. Depending on the DW PCIe End-Point IP-core
synthesize parameters it's possible to have the eDMA registers accessible
not only from the application CPU side, but also via mapping the eDMA CSRs
over a dedicated end-point BAR. So based on the specifics denoted above
the eDMA driver is supposed to support two types of the DMA controller
1) eDMA embedded into the DW PCIe Root Port/End-point and accessible over
the local CPU from the application side.
2) eDMA embedded into the DW PCIe End-point and accessible via the PCIe
wire with MWr/MRd TLPs generated by the CPU PCIe host controller.
Since the CPU memory resides different sides in these cases the semantics
of the MEM_TO_DEV and DEV_TO_MEM operations is flipped with respect to the
Tx and Rx DMA channels. So MEM_TO_DEV/DEV_TO_MEM corresponds to the Tx/Rx
channels in setup 1) and to the Rx/Tx channels in case of setup 2).

The DW eDMA driver has supported the case 2) since the initial
commit e63d79d1ffcd ("dmaengine: Add Synopsys eDMA IP core driver") in the
framework of the drivers/dma/dw-edma/dw-edma-pcie.c driver. The case 1)
support was added a bit later in commit bd96f1b2f43a ("dmaengine: dw-edma:
support local dma device transfer semantics"). Afterwards the driver was
supposed to cover the both possible eDMA setups, but the later commit
turned to be not fully correct. The problem was that the commit together
with the new functionality support also changed the channel direction
semantics in a way so the eDMA Read-channel (corresponding to the
DMA_DEV_TO_MEM direction for the case 1.) now uses the sgl/cyclic base
addresses as the Source addresses of the DMA-transfers and
dma_slave_config.dst_addr as the Destination address of the DMA-transfers.
Similarly the eDMA Write-channel (corresponding to the DMA_MEM_TO_DEV
direction for case 1.) now utilizes dma_slave_config.src_addr as a source
address of the DMA-transfers and sgl/cyclic base address as the
Destination address of the DMA-transfers. This contradicts to the logic of
the DMA-interface, which implies that DEV side is supposed to belong to
the PCIe device memory and MEM - to the CPU/Application memory. Indeed it
seems irrational to have the SG-list defined in the PCIe bus space, while
expecting a contiguous buffer allocated in the CPU memory. Moreover the
passed SG-list and cyclic DMA buffers are supposed to be mapped in a way
so to be seen by the DW eDMA Application (CPU) interface. So in order to
have the correct DW eDMA interface we need to invert the eDMA
Rd/Wr-channels and DMA-slave directions semantics by selecting the src/dst
addresses based on the DMA transfer direction instead of using the channel
direction capability.

[1] DesignWare Cores PCI Express Controller Databook - DWC PCIe Root Port,
v.5.40a, March 2019, p.1092
[2] DesignWare Cores PCI Express Controller Databook - DWC PCIe Endpoint,
v.5.40a, March 2019, p.1189

Fixes: bd96f1b2f43a ("dmaengine: dw-edma: support local dma device transfer semantics")
Co-developed-by: Manivannan Sadhasivam <>
Signed-off-by: Manivannan Sadhasivam <>
Signed-off-by: Serge Semin <>
Signed-off-by: Frank Li <>
 drivers/dma/dw-edma/dw-edma-core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
index 3ce0d7600da64..fa95d1d17db21 100644
--- a/drivers/dma/dw-edma/dw-edma-core.c
+++ b/drivers/dma/dw-edma/dw-edma-core.c
@@ -443,7 +443,7 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer)
 		chunk-> += burst->sz;
 		desc->alloc_sz += burst->sz;
-		if (chan->dir == EDMA_DIR_WRITE) {
+		if (dir == DMA_DEV_TO_MEM) {
 			burst->sar = src_addr;
 			if (xfer->type == EDMA_XFER_CYCLIC) {
 				burst->dar = xfer->xfer.cyclic.paddr;

  parent reply	other threads:[~2022-05-03  1:05 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-03  0:57 [PATCH v10 0/9] Enable designware PCI EP EDMA locally Frank Li
2022-05-03  0:57 ` [PATCH v10 1/9] dmaengine: dw-edma: Remove unused field irq in struct dw_edma_chip Frank Li
2022-05-03  0:57 ` [PATCH v10 2/9] dmaengine: dw-edma: Detach the private data and chip info structures Frank Li
2022-05-03  0:57 ` [PATCH v10 3/9] dmaengine: dw-edma: Change rg_region to reg_base in struct dw_edma_chip Frank Li
2022-05-03  0:57 ` [PATCH v10 4/9] dmaengine: dw-edma: Rename wr(rd)_ch_cnt to ll_wr(rd)_cnt " Frank Li
2022-05-03  0:57 ` [PATCH v10 5/9] dmaengine: dw-edma: Drop dma_slave_config.direction field usage Frank Li
2022-05-03  0:57 ` Frank Li [this message]
2022-05-03  0:57 ` [PATCH v10 7/9] dmaengine: dw-edma: Add support for chip specific flags Frank Li
2022-05-03  0:58 ` [PATCH v10 8/9] dmaengine: dw-edma: Add DW_EDMA_CHIP_32BIT_DBI " Frank Li
2022-05-04 18:43   ` Zhi Li
2022-05-03  0:58 ` [PATCH v10 9/9] PCI: endpoint: Enable DMA controller tests for endpoints with DMA capabilities Frank Li
2022-05-04 19:34   ` Zhi Li
2022-05-11  9:28   ` Lorenzo Pieralisi
2022-05-11 16:18     ` Zhi Li
2022-05-11 17:30       ` Lorenzo Pieralisi
2022-05-11 19:12         ` Zhi Li
2022-05-13  0:48           ` Zhi Li
2022-05-12 13:51   ` Kishon Vijay Abraham I
2022-05-12 15:36     ` Zhi Li
2022-05-03 23:18 ` [PATCH v10 0/9] Enable designware PCI EP EDMA locally Serge Semin
2022-05-10 17:47   ` Lorenzo Pieralisi
2022-05-10 18:02     ` Zhi Li
2022-05-12  0:04     ` Serge Semin
2022-05-12 14:14 ` Manivannan Sadhasivam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).