From: niklas.soderlund@ragnatech.se (Niklas Söderlund)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv9 6/6] dmaengine: rcar-dmac: add iommu support for slave transfers
Date: Mon, 9 Jan 2017 16:42:20 +0100 [thread overview]
Message-ID: <20170109154220.GH29854@bigcity.dyn.berto.se> (raw)
In-Reply-To: <26490346.qhNpbOL6eO@avalon>
Hi Laurent,
On 2017-01-02 01:08:04 +0200, Laurent Pinchart wrote:
> Hi Niklas,
>
> On Monday 05 Sep 2016 12:52:44 Laurent Pinchart wrote:
> > On Wednesday 10 Aug 2016 13:22:19 Niklas S?derlund wrote:
> > > Enable slave transfers to a device behind a IPMMU 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 | 82 ++++++++++++++++++++++++++++++++++++-----
> > > 1 file changed, 74 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c
> > > index cf983a9..22a5e40 100644
> > > --- a/drivers/dma/sh/rcar-dmac.c
> > > +++ b/drivers/dma/sh/rcar-dmac.c
>
> [snip]
>
> > > +static int rcar_dmac_map_slave_addr(struct dma_chan *chan,
> > > + enum dma_transfer_direction dir)
> > > +{
> > > + struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan);
> > > + struct rcar_dmac_chan_map *map = &rchan->map;
> > > + phys_addr_t dev_addr;
> > > + size_t dev_size;
> > > + enum dma_data_direction dev_dir;
> > > +
> > > + if (dir == DMA_DEV_TO_MEM) {
> > > + dev_addr = rchan->src.slave_addr;
> > > + dev_size = rchan->src.xfer_size;
> > > + dev_dir = DMA_TO_DEVICE;
> >
> > Shouldn't this be DMA_FROM_DEVICE, and DMA_TO_DEVICE below ?
>
> This comment can be ignored (thank you Robin for the explanation), but ...
>
> > > + } else {
> > > + dev_addr = rchan->dst.slave_addr;
> > > + dev_size = rchan->dst.xfer_size;
> > > + dev_dir = DMA_FROM_DEVICE;
> > > + }
> > > +
> > > + /* Reuse current map if possible. */
> > > + if (dev_addr == map->slave.slave_addr &&
> > > + dev_size == map->slave.xfer_size &&
> > > + dev_dir == map->dir)
> > > + return 0;
> > > +
> > > + /* Remove old mapping if present. */
> > > + if (map->slave.xfer_size)
> > > + dma_unmap_resource(chan->device->dev, map->addr,
> > > + map->slave.xfer_size, map->dir, 0);
> >
> > Unless I'm mistaken the resource will not be unmapped when freeing channel
> > resources, will it ?
>
> I believe this one still needs to be addressed.
I believe you are correct, I will look in to it and hopefully submit a
patch to address it. Thanks for brining it up.
>
> > > + map->slave.xfer_size = 0;
> > > +
> > > + /* Create new slave address map. */
> > > + map->addr = dma_map_resource(chan->device->dev, dev_addr, dev_size,
> > > + dev_dir, 0);
> > > +
> > > + if (dma_mapping_error(chan->device->dev, map->addr)) {
> > > + dev_err(chan->device->dev,
> > > + "chan%u: failed to map %zx@%pap", rchan->index,
> > > + dev_size, &dev_addr);
> > > + return -EIO;
> > > + }
> > > +
> > > + dev_dbg(chan->device->dev, "chan%u: map %zx@%pap to %pad dir: %s\n",
> > > + rchan->index, dev_size, &dev_addr, &map->addr,
> >
> > > + dev_dir == DMA_TO_DEVICE ? "DMA_TO_DEVICE" :
> > "DMA_FROM_DEVICE");
> >
> > > +
> > > + map->slave.slave_addr = dev_addr;
> > > + map->slave.xfer_size = dev_size;
> > > + map->dir = dev_dir;
> > > +
> > > + return 0;
> > > +}
>
> [snip]
>
> --
> Regards,
>
> Laurent Pinchart
>
--
Regards,
Niklas S?derlund
next prev parent reply other threads:[~2017-01-09 15:42 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-10 11:22 [PATCHv9 0/6] dmaengine: rcar-dmac: add iommu support for slave transfers Niklas Söderlund
2016-08-10 11:22 ` [PATCHv9 1/6] dma-mapping: add {map,unmap}_resource to dma_map_ops Niklas Söderlund
2016-08-10 11:22 ` [PATCHv9 2/6] dma-debug: add support for resource mappings Niklas Söderlund
2016-09-05 9:39 ` Laurent Pinchart
2016-08-10 11:22 ` [PATCHv9 3/6] dma-mapping: add dma_{map,unmap}_resource Niklas Söderlund
2016-09-05 9:46 ` Laurent Pinchart
2016-08-10 11:22 ` [PATCHv9 4/6] arm: dma-mapping: add {map, unmap}_resource for iommu ops Niklas Söderlund
2016-08-23 15:31 ` [PATCHv9 4/6] arm: dma-mapping: add {map,unmap}_resource " Niklas Söderlund
2016-09-05 9:54 ` [PATCHv9 4/6] arm: dma-mapping: add {map, unmap}_resource " Laurent Pinchart
2016-08-10 11:22 ` [PATCHv9 5/6] dmaengine: rcar-dmac: group slave configuration Niklas Söderlund
2016-08-10 11:22 ` [PATCHv9 6/6] dmaengine: rcar-dmac: add iommu support for slave transfers Niklas Söderlund
2016-09-05 9:52 ` Laurent Pinchart
2016-09-05 10:37 ` Robin Murphy
2017-01-01 23:08 ` Laurent Pinchart
2017-01-09 15:42 ` Niklas Söderlund [this message]
2016-08-10 17:37 ` [PATCHv9 0/6] " Vinod Koul
2016-09-15 16:26 ` Vinod Koul
2016-09-16 9:07 ` Arnd Bergmann
2016-09-16 9:48 ` Laurent Pinchart
2016-09-16 10:36 ` Robin Murphy
2016-09-16 12:05 ` Laurent Pinchart
2016-09-16 12:49 ` Robin Murphy
2016-09-16 13:01 ` Laurent Pinchart
2016-09-16 12:02 ` Arnd Bergmann
2016-09-16 12:09 ` Laurent Pinchart
2016-09-16 12:22 ` Arnd Bergmann
2016-09-16 12:58 ` Laurent Pinchart
2016-09-23 7:25 ` Niklas Söderlund
2016-09-26 16:47 ` 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=20170109154220.GH29854@bigcity.dyn.berto.se \
--to=niklas.soderlund@ragnatech.se \
--cc=linux-arm-kernel@lists.infradead.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;
as well as URLs for NNTP newsgroup(s).