Message-ID: <20220324172554.GR2854@thinkpad>
Date:   Thu, 24 Mar 2022 22:55:54 +0530
From:   Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>
To:     Serge Semin <Sergey.Semin@...kalelectronics.ru>
Cc:     Gustavo Pimentel <gustavo.pimentel@...opsys.com>,
        Vinod Koul <vkoul@...nel.org>,
        Jingoo Han <jingoohan1@...il.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Frank Li <Frank.Li@....com>,
        Serge Semin <fancer.lancer@...il.com>,
        Alexey Malahov <Alexey.Malahov@...kalelectronics.ru>,
        Pavel Parkhomenko <Pavel.Parkhomenko@...kalelectronics.ru>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Rob Herring <robh@...nel.org>,
        Krzysztof Wilczyński <kw@...ux.com>,
        linux-pci@...r.kernel.org, dmaengine@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 09/25] dmaengine: dw-edma: Add CPU to PCIe bus address
 translation

On Thu, Mar 24, 2022 at 04:48:20AM +0300, Serge Semin wrote:
> Starting from commit 9575632052ba ("dmaengine: make slave address
> physical") the source and destination addresses of the DMA-slave device
> have been converted to being defined in CPU address space. It's DMA-device
> driver responsibility to properly convert them to the reachable DMA bus
> spaces. In case of the DW eDMA device, the source or destination
> peripheral (slave) devices reside PCIe bus space. Thus we need to perform
> the PCIe Host/EP windows-based (i.e. ranges DT-property) addresses
> translation otherwise the eDMA transactions won't work as expected (or can
> be even harmful) in case if the CPU and PCIe address spaces don't match.
> 
> Note 1. Even though the DMA interleaved template has both source and
> destination addresses declared of dma_addr_t type only CPU memory range is
> supposed to be mapped in a way so to be seen by the DMA device since it's
> a subject of the DMA getting towards the system side. The device part must
> not be mapped since slave device resides in the PCIe bus space, which
> isn't affected by IOMMUs or iATU translations. DW PCIe eDMA generates
> corresponding MWr/MRd TLPs on its own.
> 
> Note 2. This functionality is mainly required for the remote eDMA setup
> since the CPU address must be manually translated into the PCIe bus space
> before being written to LLI.{SAR,DAR}. If eDMA is embedded into the
> locally accessible DW PCIe RP/EP software-based translation isn't required
> since it will be done by hardware by means of the Outbound iATU as long as
> the DMA_BYPASS flag is cleared. If the later flag is set or there is no
> Outbound iATU entry found to which the SAR or DAR falls in (for Read and
> Write channel respectfully), there won't be any translation performed but
> DMA will proceed with the corresponding source/destination address as is.
> 
> Signed-off-by: Serge Semin <Sergey.Semin@...kalelectronics.ru>

Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@...aro.org>

Thanks,
Mani

> ---
>  drivers/dma/dw-edma/dw-edma-core.c | 18 +++++++++++++++++-
>  include/linux/dma/edma.h           | 15 +++++++++++++++
>  2 files changed, 32 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/dma/dw-edma/dw-edma-core.c b/drivers/dma/dw-edma/dw-edma-core.c
> index 97743fe44ebf..418b201fef67 100644
> --- a/drivers/dma/dw-edma/dw-edma-core.c
> +++ b/drivers/dma/dw-edma/dw-edma-core.c
> @@ -40,6 +40,17 @@ struct dw_edma_desc *vd2dw_edma_desc(struct virt_dma_desc *vd)
>  	return container_of(vd, struct dw_edma_desc, vd);
>  }
>  
> +static inline
> +u64 dw_edma_get_pci_address(struct dw_edma_chan *chan, phys_addr_t cpu_addr)
> +{
> +	struct dw_edma_chip *chip = chan->dw->chip;
> +
> +	if (chip->ops->pci_address)
> +		return chip->ops->pci_address(chip->dev, cpu_addr);
> +
> +	return cpu_addr;
> +}
> +
>  static struct dw_edma_burst *dw_edma_alloc_burst(struct dw_edma_chunk *chunk)
>  {
>  	struct dw_edma_burst *burst;
> @@ -328,11 +339,11 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer)
>  {
>  	struct dw_edma_chan *chan = dchan2dw_edma_chan(xfer->dchan);
>  	enum dma_transfer_direction dir = xfer->direction;
> -	phys_addr_t src_addr, dst_addr;
>  	struct scatterlist *sg = NULL;
>  	struct dw_edma_chunk *chunk;
>  	struct dw_edma_burst *burst;
>  	struct dw_edma_desc *desc;
> +	u64 src_addr, dst_addr;
>  	size_t fsz = 0;
>  	u32 cnt = 0;
>  	int i;
> @@ -407,6 +418,11 @@ dw_edma_device_transfer(struct dw_edma_transfer *xfer)
>  		dst_addr = chan->config.dst_addr;
>  	}
>  
> +	if (dir == DMA_DEV_TO_MEM)
> +		src_addr = dw_edma_get_pci_address(chan, (phys_addr_t)src_addr);
> +	else
> +		dst_addr = dw_edma_get_pci_address(chan, (phys_addr_t)dst_addr);
> +
>  	if (xfer->type == EDMA_XFER_CYCLIC) {
>  		cnt = xfer->xfer.cyclic.cnt;
>  	} else if (xfer->type == EDMA_XFER_SCATTER_GATHER) {
> diff --git a/include/linux/dma/edma.h b/include/linux/dma/edma.h
> index 5abac9640a4e..5cc87cfdd685 100644
> --- a/include/linux/dma/edma.h
> +++ b/include/linux/dma/edma.h
> @@ -23,8 +23,23 @@ struct dw_edma_region {
>  	size_t		sz;
>  };
>  
> +/**
> + * struct dw_edma_core_ops - platform-specific eDMA methods
> + * @irq_vector:		Get IRQ number of the passed eDMA channel. Note the
> + *                      method accepts the channel id in the end-to-end
> + *                      numbering with the eDMA write channels being placed
> + *                      first in the row.
> + * @pci_address:	Get PCIe bus address corresponding to the passed CPU
> + *			address. Note there is no need in specifying this
> + *			function if the address translation is performed by
> + *			the DW PCIe RP/EP controller with the DW eDMA device in
> + *			subject and DMA_BYPASS isn't set for all the outbound
> + *			iATU windows. That will be done by the controller
> + *			automatically.
> + */
>  struct dw_edma_core_ops {
>  	int (*irq_vector)(struct device *dev, unsigned int nr);
> +	u64 (*pci_address)(struct device *dev, phys_addr_t cpu_addr);
>  };
>  
>  enum dw_edma_map_format {
> -- 
> 2.35.1
> 

Powered by blists - more mailing lists