From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752099AbcCGF7n (ORCPT ); Mon, 7 Mar 2016 00:59:43 -0500 Received: from mga01.intel.com ([192.55.52.88]:48000 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751798AbcCGF7l (ORCPT ); Mon, 7 Mar 2016 00:59:41 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.22,549,1449561600"; d="scan'208";a="61125056" Date: Mon, 7 Mar 2016 11:33:49 +0530 From: Vinod Koul To: Niklas =?iso-8859-1?Q?S=F6derlund?= Cc: linux-renesas-soc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, dmaengine@vger.kernel.org, iommu@lists.linux-foundation.org, robin.murphy@arm.com, laurent.pinchart@ideasonboard.com, geert+renesas@glider.be, linus.walleij@linaro.org, dan.j.williams@intel.com, arnd@arndb.de, linux-arch@vger.kernel.org Subject: Re: [PATCH v4 6/8] dmaengine: rcar-dmac: add iommu support for slave transfers Message-ID: <20160307060349.GE11154@localhost> References: <1455655184-14478-1-git-send-email-niklas.soderlund+renesas@ragnatech.se> <1455655184-14478-7-git-send-email-niklas.soderlund+renesas@ragnatech.se> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1455655184-14478-7-git-send-email-niklas.soderlund+renesas@ragnatech.se> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Feb 16, 2016 at 09:39:42PM +0100, Niklas Söderlund wrote: > Enable slave transfers to devices behind IPMMU:s by mapping the slave IPMMU:s ? > addresses using the dma-mapping API. > > Signed-off-by: Niklas Söderlund > Reviewed-by: Laurent Pinchart > --- > drivers/dma/sh/rcar-dmac.c | 52 +++++++++++++++++++++++++++++++++++++++++----- > 1 file changed, 47 insertions(+), 5 deletions(-) > > diff --git a/drivers/dma/sh/rcar-dmac.c b/drivers/dma/sh/rcar-dmac.c > index 743873c..6a24847 100644 > --- a/drivers/dma/sh/rcar-dmac.c > +++ b/drivers/dma/sh/rcar-dmac.c > @@ -1106,21 +1106,63 @@ rcar_dmac_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf_addr, > return desc; > } > > +static int rcar_dmac_set_slave_addr(struct dma_chan *chan, > + struct rcar_dmac_chan_slave *slave, > + phys_addr_t addr, size_t size) > +{ > + enum dma_data_direction dir; > + > + /* > + * We can't know the direction at this time, see documentation for > + * 'direction' in struct dma_slave_config. > + */ Okay so we are mapping on the device config, which doesn't seem intutive. Why is this not done during prepare calls? > + dir = DMA_BIDIRECTIONAL; > + > + if (slave->xfer_size) { > + dma_unmap_resource(chan->device->dev, slave->slave_addr, > + slave->xfer_size, dir, NULL); > + slave->slave_addr = 0; > + slave->xfer_size = 0; > + } > + > + if (size) { > + slave->slave_addr = dma_map_resource(chan->device->dev, addr, > + size, dir, NULL); > + > + if (dma_mapping_error(chan->device->dev, slave->slave_addr)) { > + struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan); > + > + dev_err(chan->device->dev, > + "chan%u: failed to map %zx@%pap", rchan->index, > + size, &addr); > + return -EIO; > + } > + > + slave->xfer_size = size; > + } > + > + return 0; > +} > + > static int rcar_dmac_device_config(struct dma_chan *chan, > struct dma_slave_config *cfg) > { > struct rcar_dmac_chan *rchan = to_rcar_dmac_chan(chan); > + int ret; > > /* > * 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; > > - return 0; > + ret = rcar_dmac_set_slave_addr(chan, &rchan->src, cfg->src_addr, > + cfg->src_addr_width); > + if (ret) > + return ret; > + > + ret = rcar_dmac_set_slave_addr(chan, &rchan->dst, cfg->dst_addr, > + cfg->dst_addr_width); > + return ret; > } > > static int rcar_dmac_chan_terminate_all(struct dma_chan *chan) > -- > 2.7.1 > -- ~Vinod