All of lore.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: Thu, 14 Jan 2016 23:27:50 +0000	[thread overview]
Message-ID: <5633580.zmkmTa5lyY@avalon> (raw)
In-Reply-To: <1452478667-30966-2-git-send-email-niklas.soderlund+renesas@ragnatech.se>

Hi Niklas,

On Thursday 14 January 2016 22:37:18 Niklas Söderlund wrote:
> * Laurent Pinchart [2016-01-14 01:37:37 +0200]:
> > Hi Niklas,
> > 
> > Thank you for the patch, and welcome to the hairy details of the DMA
> > mapping API :-)
> 
> Thanks and thank you for your feedback.
> 
> > 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.
> 
> I agree it's not how I wanted to do it but I could not figure out a way
> that do not end up calling ops->map_page in dma-mapping-common.h. I did
> also get a note from 'kbuild test robot' that phys_to_page is not
> available on all platforms. So in my v2 of this series I currently use:
> 
>     page = pfn_to_page(addr >> PAGE_SHIFT);
> 
> But I guess it's just as safe as phys_to_page.

At least the kmemcheck_mark_initialized(page_address(page) + offset, size); 
and debug_dma_map_page() calls in dma_map_page() look dangerous to me, as 
page_address() can dereference the struct page pointer depending on the 
platform.

Even the page_to_pfn() and page_to_phys() calls in the ARM map_page 
implementation would need to be checked for correctness as they depend on the 
memory model used by the platform. The cache sync code paths also worry me, 
but we should skip them anyway.

I wonder if we should have a dma_map_pfn or dma_map_phys...

> > > +	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.
> 
> I have implemented and are using such a construct for my v2. I also
> found the following patch but I could not determine if the idea of of a
> dma_map_pag_attrs was accepted or rejected.
> 
> PATCH v1 1/2] dma-mapping-common: add dma_map_page_attrs API
> https://www.spinics.net/lists/linux-arch/msg32334.html

The approach looks fine to me (and the second patch could be interesting too, 
but might not be the best way to do that), the series should probably be 
resurrected.

> > > +
> > > +	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.
>
> You are correct, this check can be removed. It was needed in a earlier
> version. I will wait a few days and see if it becomes clearer if the
> mapping should happen in the dmaengine or in the client. And depending
> on that outcome I will send out an updated version.
> 
> > > +	/* 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-14 23:27 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
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 [this message]
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=5633580.zmkmTa5lyY@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.