public inbox for linux-sh@vger.kernel.org
 help / color / mirror / Atom feed
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH 1/2] dmaengine: rcar-dmac: add iommu support for slave transfers
Date: Wed, 13 Jan 2016 23:37:37 +0000	[thread overview]
Message-ID: <1980027.UZjJqBrmjy@avalon> (raw)
In-Reply-To: <1452478667-30966-2-git-send-email-niklas.soderlund+renesas@ragnatech.se>

Hi Niklas,

Thank you for the patch, and welcome to the hairy details of the DMA mapping 
API :-)

On Monday 11 January 2016 03:17:46 Niklas Söderlund wrote:
> Enable slave transfers to devices behind IPMMU:s by mapping the slave
> addresses using the dma-mapping API.
> 
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> ---
>  drivers/dma/sh/rcar-dmac.c | 64 ++++++++++++++++++++++++++++++++++++++++---
>  1 file changed, 60 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> index 7820d07..da94809 100644
> --- a/drivers/dma/sh/rcar-dmac.c
> +++ b/drivers/dma/sh/rcar-dmac.c
> @@ -13,6 +13,7 @@
>  #include <linux/dma-mapping.h>
>  #include <linux/dmaengine.h>
>  #include <linux/interrupt.h>
> +#include <linux/iommu.h>
>  #include <linux/list.h>
>  #include <linux/module.h>
>  #include <linux/mutex.h>
> @@ -1101,6 +1102,24 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan,
> dma_addr_t buf_addr, return desc;
>  }
> 
> +static dma_addr_t __rcar_dmac_dma_map(struct dma_chan *chan, phys_addr_t
> addr,
> +		size_t size, enum dma_data_direction dir)
> +{
> +	struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
> +	struct page *page = phys_to_page(addr);

I wonder if that's really safe given that the physical address, not being part 
of RAM, is (unless I'm mistaken) not backed by a struct page.

> +	size_t offset = addr - page_to_phys(page);
> +	dma_addr_t map = dma_map_page(chan->device->dev, page, offset, size,
> +			dir);

You might want to use an _attrs() version of the call to pass the 
DMA_ATTR_NO_KERNEL_MAPPING and DMA_ATTR_SKIP_CPU_SYNC flags. Unfortunately 
there's no dma_map_page_attrs(), maybe it should be added.

> +
> +	if (dma_mapping_error(chan->device->dev, map)) {
> +		dev_err(chan->device->dev, "chan%u: failed to map %zx@%pap",
> +				rchan->index, size, &addr);
> +		return 0;
> +	}
> +
> +	return map;
> +}
> +
>  static int rcar_dmac_device_config(struct dma_chan *chan,
>  				   struct dma_slave_config *cfg)
>  {
> @@ -1110,10 +1129,47 @@ static int rcar_dmac_device_config(struct dma_chan
> *chan, * We could lock this, but you shouldn't be configuring the
>  	 * channel, while using it...
>  	 */
> -	rchan->src_slave_addr = cfg->src_addr;
> -	rchan->dst_slave_addr = cfg->dst_addr;
> -	rchan->src_xfer_size = cfg->src_addr_width;
> -	rchan->dst_xfer_size = cfg->dst_addr_width;
> +
> +	/* If we don't have a iommu domain no idea to trying to use it */
> +	if (!iommu_get_domain_for_dev(chan->device->dev)) {
> +		rchan->src_slave_addr = cfg->src_addr;
> +		rchan->dst_slave_addr = cfg->dst_addr;
> +		rchan->src_xfer_size = cfg->src_addr_width;
> +		rchan->dst_xfer_size = cfg->dst_addr_width;
> +		return 0;
> +	}

Driver are not supposed to deal with the IOMMU API directly. Would it be an 
issue dropping this check ? The dma_map_page() call should work fine without 
an IOMMU and return a DMA address identical to the physical address. Unless 
the memory is not DMA-ble, in which case bounce buffers would be used, and 
possible a few other corner cases. I'm not sure if we need to care about them.

> +	/* unmap old */
> +	if (rchan->src_slave_addr) {
> +		dma_unmap_page(chan->device->dev, rchan->src_slave_addr,
> +				rchan->src_xfer_size, DMA_FROM_DEVICE);
> +		rchan->src_slave_addr = 0;
> +		rchan->src_xfer_size = 0;
> +	}
> +
> +	if (rchan->dst_slave_addr) {
> +		dma_unmap_page(chan->device->dev, rchan->dst_slave_addr,
> +				rchan->dst_xfer_size, DMA_TO_DEVICE);
> +		rchan->dst_slave_addr = 0;
> +		rchan->dst_xfer_size = 0;
> +	}
> +
> +	/* map new */
> +	if (cfg->src_addr) {
> +		rchan->src_slave_addr = __rcar_dmac_dma_map(chan, cfg->src_addr,
> +				cfg->src_addr_width, DMA_FROM_DEVICE);
> +		if (!rchan->src_slave_addr)
> +			return -EIO;
> +		rchan->src_xfer_size = cfg->src_addr_width;
> +	}
> +
> +	if (cfg->dst_addr) {
> +		rchan->dst_slave_addr = __rcar_dmac_dma_map(chan, cfg->dst_addr,
> +				cfg->dst_addr_width, DMA_TO_DEVICE);
> +		if (!rchan->dst_slave_addr)
> +			return -EIO;
> +		rchan->dst_xfer_size = cfg->dst_addr_width;
> +	}
> 
>  	return 0;
>  }

-- 
Regards,

Laurent Pinchart


  parent reply	other threads:[~2016-01-13 23:37 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-11  2:17 [PATCH 1/2] dmaengine: rcar-dmac: add iommu support for slave transfers Niklas Söderlund
2016-01-11  2:37 ` kbuild test robot
2016-01-11  7:55 ` Geert Uytterhoeven
2016-01-11 18:59 ` Niklas Söderlund
2016-01-13 13:48 ` Vinod Koul
2016-01-13 13:55 ` Niklas Söderlund
2016-01-13 23:13 ` Laurent Pinchart
2016-01-13 23:15 ` Laurent Pinchart
2016-01-13 23:37 ` Laurent Pinchart [this message]
2016-01-14  3:48 ` Vinod Koul
2016-01-14 13:59 ` Laurent Pinchart
2016-01-14 21:37 ` Niklas Söderlund
2016-01-14 23:27 ` Laurent Pinchart
2016-01-18 13:48 ` Vinod Koul
2016-01-24 22:38 ` Laurent Pinchart
2016-02-03 12:04 ` Laurent Pinchart
2016-02-08  3:47 ` Vinod Koul
2016-02-10 23:51 ` Laurent Pinchart
2016-02-10 23:59 ` Laurent Pinchart
2016-02-15 17:41 ` Vinod Koul

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=1980027.UZjJqBrmjy@avalon \
    --to=laurent.pinchart@ideasonboard.com \
    --cc=linux-sh@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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