From patchwork Thu Mar 24 01:48:13 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Serge Semin X-Patchwork-Id: 12793924 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 68D34C43219 for ; Mon, 28 Mar 2022 16:44:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243062AbiC1QqI (ORCPT ); Mon, 28 Mar 2022 12:46:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45142 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242683AbiC1QqC (ORCPT ); Mon, 28 Mar 2022 12:46:02 -0400 Received: from mail.baikalelectronics.ru (mail.baikalelectronics.com [87.245.175.226]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4DAA721801; Mon, 28 Mar 2022 09:44:13 -0700 (PDT) Received: from mail.baikalelectronics.ru (unknown [192.168.51.25]) by mail.baikalelectronics.ru (Postfix) with ESMTP id BD16D1E493C; Thu, 24 Mar 2022 04:48:39 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.baikalelectronics.ru BD16D1E493C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=baikalelectronics.ru; s=mail; t=1648086519; bh=phRjSo/+vSNUHm7b1Z6XFMjq89kQ6ugKnVFCikCw3QQ=; h=From:To:CC:Subject:Date:In-Reply-To:References:From; b=WAML5i00dGv6ed5aqgZNQzibC7nU9u0igzV/9ydKlxS2zEPL8LEk1YnTKr4vTrLDK 5jL3+s2kmlL8fcq/2HNXP0lMLt3MyrC71kLQ+gwczxtqHstvcFCflGW8a1GQaA0AEW xC8cYDgexTm5eKvClSM8I0zfyOCcfbom8akvTGxY= Received: from localhost (192.168.168.10) by mail (192.168.51.25) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 24 Mar 2022 04:48:39 +0300 From: Serge Semin To: Gustavo Pimentel , Vinod Koul , Jingoo Han , Bjorn Helgaas , Frank Li , Manivannan Sadhasivam , Alan Mikhak CC: Serge Semin , Serge Semin , Alexey Malahov , Pavel Parkhomenko , Lorenzo Pieralisi , Rob Herring , =?utf-8?q?Krzysztof_Wilczy=C5=84ski?= , , , Subject: [PATCH 02/25] dmaengine: dw-edma: Fix eDMA Rd/Wr-channels and DMA-direction semantics Date: Thu, 24 Mar 2022 04:48:13 +0300 Message-ID: <20220324014836.19149-3-Sergey.Semin@baikalelectronics.ru> In-Reply-To: <20220324014836.19149-1-Sergey.Semin@baikalelectronics.ru> References: <20220324014836.19149-1-Sergey.Semin@baikalelectronics.ru> MIME-Version: 1.0 X-ClientProxiedBy: MAIL.baikal.int (192.168.51.25) To mail (192.168.51.25) Precedence: bulk List-ID: X-Mailing-List: linux-pci@vger.kernel.org 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 setups: 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 --- In accordance with agreement with Frank and Manivannan this patch is supposed to be moved to the series: Link: https://lore.kernel.org/dmaengine/20220310192457.3090-1-Frank.Li@nxp.com/ in place of the patch: [PATCH v5 5/9] dmaengine: dw-edma: Fix programming the source & dest addresses for ep Link: https://lore.kernel.org/dmaengine/20220310192457.3090-6-Frank.Li@nxp.com/ --- 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 e9e32ed74aa9..519d4b3c9fa0 100644 --- a/drivers/dma/dw-edma/dw-edma-core.c +++ b/drivers/dma/dw-edma/dw-edma-core.c @@ -442,7 +442,7 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer) chunk->ll_region.sz += 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;