Hi,
This series add iommu support to rcar-dmac. It's tested on koelsch with
CONFIG_IPMMU_VMSA and by enabling the ipmmu_ds node in r8a7791.dtsi. I
verified operation by interacting with /dev/mmcblk1 which is a device
behind the iommu.
The series depends on out of tree patch '[PATCH] dmaengine: use
phys_addr_t for slave configuration' which currently is under review.
* Changes since v2
- Drop patch to add dma_{map,unmap}_page_attrs.
- Add dma_{map,unmap}_resource to handle the mapping without involving a
'struct page'. Thanks Laurent and Robin for pointing this out.
- Use size instead of address to keep track of if a mapping exist or not
since addr == 0 is valid. Thanks Laurent.
- Pick up patch from Robin with Laurents ack (hope it's OK for me to
attach the ack?) to add IOMMU_MMIO.
- Fix bug in rcar_dmac_device_config where the error check where
inverted.
- Use DMA_BIDIRECTIONAL in rcar_dmac_device_config since we at that
point can't be sure what direction the mapping is going to be used.
* Changes since v1
- Add and use a dma_{map,unmap}_page_attrs to be able to map the page
using attributes DMA_ATTR_NO_KERNEL_MAPPING and
DMA_ATTR_SKIP_CPU_SYNC. Thanks Laurent.
- Drop check if dmac is part of a iommu group or not, let the DMA
mapping api handle it.
- Move slave configuration data around in rcar-dmac to avoid code
duplication.
- Fix build issue reported by 'kbuild test robot' regarding phys_to_page
not availability on some configurations.
- Add DT information for r8a7791.
* Changes since RFC
- Switch to use the dma-mapping api instead of using the iommu_map()
directly. Turns out the dma-mapper is much smarter then me...
- Dropped the patch to expose domain->ops->pgsize_bitmap from within the
iommu api.
- Dropped the patch showing how I tested the RFC.
Niklas S?derlund (7):
dma-mapping: add {map,unmap}_resource to dma_map_ops
dma-mapping: add dma_{map,unmap}_resource
arm: dma-mapping: add {map,unmap}_resource for iommu ops
dmaengine: rcar-dmac: group slave configuration
dmaengine: rcar-dmac: add iommu support for slave transfers
ARM: dts: r8a7790: add iommus to dmac0 and dmac1
ARM: dts: r8a7791: add iommus to dmac0 and dmac1
Robin Murphy (1):
iommu: Add MMIO mapping type
arch/arm/boot/dts/r8a7790.dtsi | 30 +++++++++++++++
arch/arm/boot/dts/r8a7791.dtsi | 30 +++++++++++++++
arch/arm/mm/dma-mapping.c | 63 +++++++++++++++++++++++++++++++
drivers/dma/sh/rcar-dmac.c | 86 +++++++++++++++++++++++++++++++++---------
drivers/iommu/io-pgtable-arm.c | 4 +-
include/linux/dma-mapping.h | 33 ++++++++++++++++
include/linux/iommu.h | 1 +
7 files changed, 229 insertions(+), 18 deletions(-)
--
2.7.1
Map/Unmap a device resource from a physical address. If no dma_map_ops
method is available the operation is a no-op.
Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
---
include/linux/dma-mapping.h | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
From: Robin Murphy <robin.murphy@arm.com>
On some platforms, MMIO regions might need slightly different treatment
compared to mapping regular memory; add the notion of MMIO mappings to
the IOMMU API's memory type flags, so that callers can let the IOMMU
drivers know to do the right thing.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
---
drivers/iommu/io-pgtable-arm.c | 4 +++-
include/linux/iommu.h | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
Group slave address and transfer size in own structs for source and
destination. This is in preparation for hooking up the dma-mapping API
to the slave addresses.
Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
---
drivers/dma/sh/rcar-dmac.c | 37 +++++++++++++++++++++----------------
1 file changed, 21 insertions(+), 16 deletions(-)
Add methods to map/unmap device resources addresses for dma_map_ops that
are IOMMU aware. This is needed to map a device MMIO register from a
physical address.
Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
---
arch/arm/mm/dma-mapping.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 63 insertions(+)
Add methods to handle mapping of device resources from a physical
address. This is needed for example to map be able to map MMIO FIFO
registers to a IOMMU.
Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
---
include/linux/dma-mapping.h | 6 ++++++
1 file changed, 6 insertions(+)
From: Robin Murphy <robin.murphy@arm.com> Date: 2016-02-10 10:25:17
Hi Niklas,
Thanks for doing this, it looks good. Just a couple of minor comments on
this and the next patch...
On 10/02/16 00:57, Niklas S?derlund wrote:
quoted hunk
Map/Unmap a device resource from a physical address. If no dma_map_ops
method is available the operation is a no-op.
Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
---
include/linux/dma-mapping.h | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
From: Simon Horman <horms@verge.net.au> Date: 2016-02-10 17:56:09
Hi Niklas,
I am deferring accepting this and the similar patch for the r8a7791 pending
acceptance of the driver changes earlier in this series. Please let me know
if you prefer a different course of action.
I notice that the devel branch of there renesas tree there are
dmac nodes for the r8a7793, r8a7794 and r8a7795. Is this change,
also suitable for those SoCs? If so, do you plan to update them?
If not I'll add it to my todo list.
Hi Niklas,
Thank you for the patch.
On Wednesday 10 February 2016 01:57:51 Niklas S?derlund wrote:
From: Robin Murphy <robin.murphy@arm.com>
On some platforms, MMIO regions might need slightly different treatment
compared to mapping regular memory; add the notion of MMIO mappings to
the IOMMU API's memory type flags, so that callers can let the IOMMU
drivers know to do the right thing.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Answering the question from the cover letter, yes, it's totally fine to pick
the ack, that's actually expected.
Hi Niklas,
Thank you for the patch.
On Wednesday 10 February 2016 01:57:52 Niklas S?derlund wrote:
Add methods to handle mapping of device resources from a physical
address. This is needed for example to map be able to map MMIO FIFO
registers to a IOMMU.
Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
Apart from the typo in the commit message that Sergei already pointed out,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Hi Niklas,
Thank you for the patch.
On Wednesday 10 February 2016 01:57:54 Niklas S?derlund wrote:
Add methods to map/unmap device resources addresses for dma_map_ops that
are IOMMU aware. This is needed to map a device MMIO register from a
physical address.
Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
Hi Niklas,
Thank you for the patch.
On Wednesday 10 February 2016 01:57:55 Niklas S?derlund wrote:
Group slave address and transfer size in own structs for source and
destination. This is in preparation for hooking up the dma-mapping API
to the slave addresses.
Signed-off-by: Niklas S?derlund <niklas.soderlund+renesas@ragnatech.se>
destination side - * @src_slave_addr: slave source memory address
- * @dst_slave_addr: slave destination memory address
+ * @src: slave memory address and size on the source side
+ * @dst: slave memory address and size on the destination side
* @mid_rid: hardware MID/RID for the DMA client using this channel
* @lock: protects the channel CHCR register and the desc members
* @desc.free: list of free descriptors
@@ -142,10 +149,8 @@ struct rcar_dmac_chan { void __iomem *iomem; unsigned int index;- unsigned int src_xfer_size;- unsigned int dst_xfer_size;- dma_addr_t src_slave_addr;- dma_addr_t dst_slave_addr;+ struct rcar_dmac_chan_slave src;+ struct rcar_dmac_chan_slave dst; int mid_rid; spinlock_t lock;
+ 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);
You could align cfg with chan on the previous line (twice).
With this fixed and the attributes removed as explained by Robin,
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+ return ret;
}
static int rcar_dmac_chan_terminate_all(struct dma_chan *chan)
Hi Niklas,
Thank you for the patch.
On Wednesday 10 February 2016 01:57:57 Niklas S?derlund wrote:
No commit message ? I'd at least mention that as a side effect of this patch
channel 0 and 15 are disabled, reducing the effective number of channels to 14
per DMAC.
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Same comment and ack for patch 8/8.
Note that we should still try to find a way to selectively enable the IOMMU in
a per-device fashion, as system integrators might want it to be disabled for
some devices. There's no urgency though.
Hi Simon,
* Simon Horman [off-list ref] [2016-02-10 18:55:59 +0100]:
Hi Niklas,
I am deferring accepting this and the similar patch for the r8a7791 pending
acceptance of the driver changes earlier in this series. Please let me know
if you prefer a different course of action.
That sounds good, thanks.
I notice that the devel branch of there renesas tree there are
dmac nodes for the r8a7793, r8a7794 and r8a7795. Is this change,
also suitable for those SoCs? If so, do you plan to update them?
If not I'll add it to my todo list.
I planed to update all effected SoCs once the dependencies for this
series where accepted. But if you want to keep track of this I'm happy.
From: Robin Murphy <robin.murphy@arm.com> Date: 2016-02-11 15:57:32
On 11/02/16 00:02, Laurent Pinchart wrote:
Hi Niklas,
Thank you for the patch.
On Wednesday 10 February 2016 01:57:51 Niklas S?derlund wrote:
quoted
From: Robin Murphy <robin.murphy@arm.com>
On some platforms, MMIO regions might need slightly different treatment
compared to mapping regular memory; add the notion of MMIO mappings to
the IOMMU API's memory type flags, so that callers can let the IOMMU
drivers know to do the right thing.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Answering the question from the cover letter, yes, it's totally fine to pick
the ack, that's actually expected.
Worse than that, you might also be asked to fix it up when the silly
author remembers that he did this on a stage-2-only ARM SMMU, and the
attributes for the stage 1 tables that the IPMMU uses are in a different
code path:
--->8---
Hi Robin,
Thanks for your update patch I will include it in my next version. But
I'm sorry I do not understand, is your modification an addition or a
substitution to your original patch?
* Robin Murphy [off-list ref] [2016-02-11 15:57:26 +0000]:
quoted hunk
On 11/02/16 00:02, Laurent Pinchart wrote:
quoted
Hi Niklas,
Thank you for the patch.
On Wednesday 10 February 2016 01:57:51 Niklas S?derlund wrote:
quoted
From: Robin Murphy <robin.murphy@arm.com>
On some platforms, MMIO regions might need slightly different treatment
compared to mapping regular memory; add the notion of MMIO mappings to
the IOMMU API's memory type flags, so that callers can let the IOMMU
drivers know to do the right thing.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Answering the question from the cover letter, yes, it's totally fine to pick
the ack, that's actually expected.
Worse than that, you might also be asked to fix it up when the silly author
remembers that he did this on a stage-2-only ARM SMMU, and the attributes
for the stage 1 tables that the IPMMU uses are in a different code path:
--->8---
From: Robin Murphy <robin.murphy@arm.com> Date: 2016-02-16 12:43:47
On 16/02/16 12:06, Niklas S?derlund wrote:
Hi Robin,
Thanks for your update patch I will include it in my next version. But
I'm sorry I do not understand, is your modification an addition or a
substitution to your original patch?
Apologies for being confusing - that was a diff on top of the existing
patch, to be folded in. My original patch was only handling IOMMU_MMIO
for stage 2 PTEs, so we also need the extra code to handle the different
way of setting the appropriate memory type in stage 1 PTEs.
Robin.
* Robin Murphy [off-list ref] [2016-02-11 15:57:26 +0000]:
quoted
On 11/02/16 00:02, Laurent Pinchart wrote:
quoted
Hi Niklas,
Thank you for the patch.
On Wednesday 10 February 2016 01:57:51 Niklas S?derlund wrote:
quoted
From: Robin Murphy <robin.murphy@arm.com>
On some platforms, MMIO regions might need slightly different treatment
compared to mapping regular memory; add the notion of MMIO mappings to
the IOMMU API's memory type flags, so that callers can let the IOMMU
drivers know to do the right thing.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Answering the question from the cover letter, yes, it's totally fine to pick
the ack, that's actually expected.
Worse than that, you might also be asked to fix it up when the silly author
remembers that he did this on a stage-2-only ARM SMMU, and the attributes
for the stage 1 tables that the IPMMU uses are in a different code path:
--->8---
* Robin Murphy [off-list ref] [2016-02-16 12:43:40 +0000]:
On 16/02/16 12:06, Niklas S?derlund wrote:
quoted
Hi Robin,
Thanks for your update patch I will include it in my next version. But
I'm sorry I do not understand, is your modification an addition or a
substitution to your original patch?
Apologies for being confusing - that was a diff on top of the existing
patch, to be folded in. My original patch was only handling IOMMU_MMIO for
stage 2 PTEs, so we also need the extra code to handle the different way of
setting the appropriate memory type in stage 1 PTEs.
That's what I though but wanted to be clear, thanks for clarifying. I
will fold the diff into your patch and keep your SoB line and send it
out with my series, hope that's a OK way for me to handle it.
Once more thanks for your patch and feedback.
Robin.
quoted
* Robin Murphy [off-list ref] [2016-02-11 15:57:26 +0000]:
quoted
On 11/02/16 00:02, Laurent Pinchart wrote:
quoted
Hi Niklas,
Thank you for the patch.
On Wednesday 10 February 2016 01:57:51 Niklas S?derlund wrote:
quoted
From: Robin Murphy <robin.murphy@arm.com>
On some platforms, MMIO regions might need slightly different treatment
compared to mapping regular memory; add the notion of MMIO mappings to
the IOMMU API's memory type flags, so that callers can let the IOMMU
drivers know to do the right thing.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Answering the question from the cover letter, yes, it's totally fine to pick
the ack, that's actually expected.
Worse than that, you might also be asked to fix it up when the silly author
remembers that he did this on a stage-2-only ARM SMMU, and the attributes
for the stage 1 tables that the IPMMU uses are in a different code path:
--->8---