iommu/msm: Add DT adaptation and generic bindings support

The MSM IOMMU is an implementation compatible with the ARM VMSA short descriptor page tables. It provides address translation for bus masters outside of the CPU, each connected to the IOMMU through a port called micro-TLB. Adding the DT bindings for the same.

Signed-off-by Sricharan R <[email protected]>

---
 .../devicetree/bindings/iommu/msm,iommu-v0.txt     | 64 ++++++++++++++++++++++
 1 file changed, 64 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt

While using the generic pagetable ops the tlb maintenance operation gets completed in the sync callback. So use writel_relaxed for all register access and add a mb() at appropriate places.

Signed-off-by Sricharan R <[email protected]>

---
 drivers/iommu/msm_iommu.c         |  24 +++++++--
 drivers/iommu/msm_iommu_hw-8xxx.h | 109 ++++++++++++++++++++------------------
 2 files changed, 79 insertions(+), 54 deletions(-)

drivers/iommu/msm_iommu.c +0 -0

index 0299a37..dfcaeef 100644

drivers/iommu/msm_iommu.c +3 -0

 static void __reset_context(void __iomem *base, int ctx)

@@ -257,6 +267,9 @@ static void __reset_context(void __iomem *base, int ctx)
 	SET_TLBFLPTER(base, ctx, 0);
 	SET_TLBSLPTER(base, ctx, 0);
 	SET_TLBLKCR(base, ctx, 0);
+
+	/* Ensure completion of relaxed writes from the above SET macros */
+	mb();
 }
 
 static void __program_context(void __iomem *base, int ctx,

drivers/iommu/msm_iommu_hw-8xxx.h +2 -1

index fc16010..fe2c5ca 100644
@@ -24,13 +24,19 @@
 #define GET_CTX_REG(reg, base, ctx) \
 				(readl((base) + (reg) + ((ctx) << CTX_SHIFT)))
 
-#define SET_GLOBAL_REG(reg, base, val)	writel((val), ((base) + (reg)))
+/*
+ * The writes to the global/context registers needs to be synced only after

Quoted 6 lines

 #define GET_CTX_REG(reg, base, ctx) \
                              (readl((base) + (reg) + ((ctx) << CTX_SHIFT)))

drivers/iommu/msm_iommu_hw-8xxx.h +2 -1

-#define SET_GLOBAL_REG(reg, base, val)       writel((val), ((base) + (reg)))
+/*
+ * The writes to the global/context registers needs to be synced only after

drivers/iommu/msm_iommu_hw-8xxx.h line 36

Quoted 10 lines

drivers/iommu/msm_iommu_hw-8xxx.h +7 -2

+ * all the configuration writes are done. So use relaxed accessors and
+ * a barrier at the end.
+ */
+#define SET_GLOBAL_REG_RELAXED(reg, base, val) \
+                            writel_relaxed((val), ((base) + (reg)))
 
-#define SET_CTX_REG(reg, base, ctx, val) \
-                     writel((val), ((base) + (reg) + ((ctx) << CTX_SHIFT)))
+#define SET_CTX_REG_RELAXED(reg, base, ctx, val) \
+             writel_relaxed((val), ((base) + (reg) + ((ctx) << CTX_SHIFT)))

Please add the relaxed accessors first in a separate patch, and then change over one user at a time before you remove the non-relaxed ones.

It's hard to believe that all users are actually performance critical, so start with the ones that gain the most performance. As commented above, some of the conversions seem particularly fishy and it's likely that a slow reset() function should not be fixed by making reset() faster but by calling it less often.

drivers/iommu/msm_iommu.c static void msm_iommu_reset(void __iomem *base, int ncb) · line 130

Quoted 8 lines

drivers/iommu/msm_iommu.c +3 -0

@@ -124,6 +124,9 @@ static void msm_iommu_reset(void __iomem *base, int ncb)
 		SET_TLBLKCR(base, ctx, 0);
 		SET_CONTEXTIDR(base, ctx, 0);
 	}
+
+	/* Ensure completion of relaxed writes from the above SET macros */
+	mb();
 }

Why do the above use the relaxed writes? Do you have any performance numbers showing that skipping the sync for the reset makes a measurable difference?

How did you prove that skipping the sync before the write is safe?

How about resetting the iommu less often instead?

drivers/iommu/msm_iommu.c static void __flush_iotlb(void *cookie) · line 152

Quoted 11 lines

drivers/iommu/msm_iommu.c +3 -0

 static void __flush_iotlb(void *cookie)

@@ -141,6 +144,9 @@ static void __flush_iotlb(void *cookie)
 		list_for_each_entry(master, &iommu->ctx_list, list)
 			SET_CTX_TLBIALL(iommu->base, master->num, 0);
 
+		/* To ensure completion of TLBIALL above */
+		mb();
+
 		__disable_clocks(iommu);
 	}
 fail:

__disable_clocks() takes spinlocks and accesses the hardware, which in turn will also involve multiple syncs, so this seems like a premature optimization.

Have you tried just leaving the clocks enabled? I'd suspect you could gain more performance that way.

drivers/iommu/msm_iommu.c fail: · line 192

Quoted 9 lines

drivers/iommu/msm_iommu.c +2 -1

@@ -181,7 +187,8 @@ fail:
 
 static void __flush_iotlb_sync(void *cookie)
 {
-	/* To avoid a null function pointer */
+	/* To ensure completion of the TLBIVA in __flush_iotlb_range */
+	mb();
 }

I don't understand the specific race from the comment.

What operation comes after this that relies on __flush_iotlb_range having completed, and how does an mb() guarantee this?

This seems to be a bug fix that is unrelated to the change to use writel_relaxed(), so better split it out into a separate patch, with a longer changeset description. Did you spot this race by running into incorrect data, or by inspection?

drivers/iommu/msm_iommu.c static void config_mids(struct msm_iommu_dev *iommu, · line 249

Quoted 10 lines

drivers/iommu/msm_iommu.c +3 -0

 static const struct iommu_gather_ops msm_iommu_gather_ops = {

@@ -235,6 +242,9 @@ static void config_mids(struct msm_iommu_dev *iommu,
 		/* Set security bit override to be Non-secure */
 		SET_NSCFG(iommu->base, mid, 3);
 	}
+
+	/* Ensure completion of relaxed writes from the above SET macros */
+	mb();
 }
 

This looks similar to the msm_iommu_reset() case. Maybe put those two into one patch, or find a way to run config_mids() less often so it doesn't show up in the profiles any more.

If you hit this often enough that it causes performance problems, it's more likely that there is a bug in your code than that changing to relaxed accessors is a good idea.

Quoted 12 lines

drivers/iommu/msm_iommu.c +3 -0

 static void __reset_context(void __iomem *base, int ctx)

@@ -257,6 +267,9 @@ static void __reset_context(void __iomem *base, int ctx)
 	SET_TLBFLPTER(base, ctx, 0);
 	SET_TLBSLPTER(base, ctx, 0);
 	SET_TLBLKCR(base, ctx, 0);
+
+	/* Ensure completion of relaxed writes from the above SET macros */
+	mb();
 }
 
 static void __program_context(void __iomem *base, int ctx,

drivers/iommu/msm_iommu.c static void __program_context(void __iomem *base, int ctx, · line 326

Quoted 9 lines

drivers/iommu/msm_iommu.c +3 -0

@@ -305,6 +318,9 @@ static void __program_context(void __iomem *base, int ctx,
 
 	/* Enable the MMU */
 	SET_M(base, ctx, 1);
+
+	/* Ensure completion of relaxed writes from the above SET macros */
+	mb();
 }
 
 static struct iommu_domain *msm_iommu_domain_alloc(unsigned type)

Maybe one more patch for these? I can see that __reset_context/__program_context would be run often enough to make a difference, though maybe not as much as the flushes.

Also, split this in two patches: one that adds a comment describing how you proved that you don't need barriers before the writes, and another one adding the barrier afterwards, with a description of the failure scenario.

Quoted 10 lines

drivers/iommu/msm_iommu.c +2 -1

@@ -500,7 +516,8 @@ static phys_addr_t msm_iommu_iova_to_phys(struct iommu_domain *domain,
 	/* Invalidate context TLB */
 	SET_CTX_TLBIALL(iommu->base, master->num, 0);
 	SET_V2PPR(iommu->base, master->num, va & V2Pxx_VA);
-
+	/* Ensure completion of relaxed writes from the above SET macros */
+	mb();
 	par = GET_PAR(iommu->base, master->num);
 

drivers/iommu/msm_iommu.c static phys_addr_t msm_iommu_iova_to_phys(struct iommu_domain *domain, · line 523

Quoted 1 line

drivers/iommu/msm_iommu.c +0 -0

 	/* We are dealing with a supersection */

In this case, I'd say it's better to rewrite the function to avoid the
read: iova_to_phys() should be fast, and not require hardware access. Getting rid of the hardware access by using an in-memory cache for this should gain more than just removing the barriers, as an MMIO read is always slow

drivers/iommu/msm_iommu.c static int msm_iommu_probe(struct platform_device *pdev) · line 736

Quoted 9 lines

drivers/iommu/msm_iommu.c +2 -1

@@ -714,7 +731,8 @@ static int msm_iommu_probe(struct platform_device *pdev)
 	par = GET_PAR(iommu->base, 0);
 	SET_V2PCFG(iommu->base, 0, 0);
 	SET_M(iommu->base, 0, 0);
-
+	/* Ensure completion of relaxed writes from the above SET macros */
+	mb();
 	if (!par) {

Probe() clearly isn't performance sensitive, so please back this out and use the non-relaxed accessors.

Quoted 17 lines

drivers/iommu/msm_iommu_hw-8xxx.h +7 -1

index fc16010..fe2c5ca 100644
@@ -24,13 +24,19 @@
 #define GET_CTX_REG(reg, base, ctx) \
 				(readl((base) + (reg) + ((ctx) << CTX_SHIFT)))
 
-#define SET_GLOBAL_REG(reg, base, val)	writel((val), ((base) + (reg)))
+/*
+ * The writes to the global/context registers needs to be synced only after
+ * all the configuration writes are done. So use relaxed accessors and
+ * a barrier at the end.
+ */
+#define SET_GLOBAL_REG_RELAXED(reg, base, val) \
+			       writel_relaxed((val), ((base) + (reg)))
 

drivers/iommu/msm_iommu_hw-8xxx.h line 36

Quoted 4 lines

drivers/iommu/msm_iommu_hw-8xxx.h +2 -2

-#define SET_CTX_REG(reg, base, ctx, val) \
-			writel((val), ((base) + (reg) + ((ctx) << CTX_SHIFT)))
+#define SET_CTX_REG_RELAXED(reg, base, ctx, val) \
+		writel_relaxed((val), ((base) + (reg) + ((ctx) << CTX_SHIFT)))

Please add the relaxed accessors first in a separate patch, and then change over one user at a time before you remove the non-relaxed ones.

It's hard to believe that all users are actually performance critical, so start with the ones that gain the most performance. As commented above, some of the conversions seem particularly fishy and it's likely that a slow reset() function should not be fixed by making reset() faster but by calling it less often.

Can you just remove those macros, and open-code the function calls?

This is an unnecessary obfuscation that now also hides the fact that you are using relaxed accessors.

Hi Arnd,

Quoted 15 lines

drivers/iommu/msm_iommu.c static void msm_iommu_reset(void __iomem *base, int ncb) · line 130

Quoted 8 lines

drivers/iommu/msm_iommu.c +3 -0

@@ -124,6 +124,9 @@ static void msm_iommu_reset(void __iomem *base, int ncb)
 		SET_TLBLKCR(base, ctx, 0);
 		SET_CONTEXTIDR(base, ctx, 0);
 	}
+
+	/* Ensure completion of relaxed writes from the above SET macros */
+	mb();
 }

Why do the above use the relaxed writes? Do you have any performance numbers showing that skipping the sync for the reset makes a measurable difference?

How did you prove that skipping the sync before the write is safe?

Quoted 2 lines

How about resetting the iommu less often instead?

I had measured the numbers only for the full usecase path, not for the reset path alone. I saw improvement of about 5% on full numbers. As you said, the reset path would be called only less often
and might not bring a measurable change. I did not see a difference in behavior when changing the sync to happen after the writes.

But my understanding was that
the sync after the writes was required to ensure write completion.

I should have made smaller patches to do this change.
The only patch relevant for this series is the one that changes the write in _iotlb_range function. Rest of the changes, should be added one by one in a separate series.

Quoted 11 lines

drivers/iommu/msm_iommu.c fail: · line 192

Quoted 8 lines

drivers/iommu/msm_iommu.c +2 -1

@@ -181,7 +187,8 @@ fail:
 
 static void __flush_iotlb_sync(void *cookie)
 {
-	/* To avoid a null function pointer */
+	/* To ensure completion of the TLBIVA in __flush_iotlb_range */
+	mb();
 }

I don't understand the specific race from the comment.

Quoted 3 lines

What operation comes after this that relies on __flush_iotlb_range having completed, and how does an mb() guarantee this?

The flush_iotlb_range operation invalidates the tlb for writes to pagetable and the finally calls the sync operation to ensure completion of the flush and this is required before returning back to the client of the iommu. In the case of this iommu, only a barrier is required to ensure completion of the invalidate operation.

Quoted 5 lines

This seems to be a bug fix that is unrelated to the change to use writel_relaxed(), so better split it out into a separate patch, with a longer changeset description. Did you spot this race by running into incorrect data, or by inspection?

No i did not see a data corruption issue without the mb(), but that it would have been hidden in someother way as well. Another difference was the sync was done before the write previously and now its moved after the write. As i understand sync after the write is correct. So i will change this patch with more description and move rest of that changes out.

Quoted 9 lines

Quoted 9 lines

drivers/iommu/msm_iommu.c +2 -1

@@ -500,7 +516,8 @@ static phys_addr_t msm_iommu_iova_to_phys(struct iommu_domain *domain,
 	/* Invalidate context TLB */
 	SET_CTX_TLBIALL(iommu->base, master->num, 0);
 	SET_V2PPR(iommu->base, master->num, va & V2Pxx_VA);
-
+	/* Ensure completion of relaxed writes from the above SET macros */
+	mb();
 	par = GET_PAR(iommu->base, master->num);
 

Quoted 7 lines

drivers/iommu/msm_iommu.c static phys_addr_t msm_iommu_iova_to_phys(struct iommu_domain *domain, · line 523

Quoted 1 line

drivers/iommu/msm_iommu.c +0 -0

 	/* We are dealing with a supersection */

In this case, I'd say it's better to rewrite the function to avoid the
read: iova_to_phys() should be fast, and not require hardware access. Getting rid of the hardware access by using an in-memory cache for this should gain more than just removing the barriers, as an MMIO read is always slow

Ok, you mean using the software walk through ? I will check on this to measure
the latency difference. If thats true, then the iopgtable ops itself provides a
function for iova_to_phys conversion, so that can be used.

Quoted 5 lines

I had measured the numbers only for the full usecase path, not for the reset path alone. I saw improvement of about 5% on full numbers. As you said, the reset path would be called only less often
and might not bring a measurable change. I did not see a difference in behavior when changing the sync to happen after the writes.

Ok, then better not change it.

Quoted 2 lines

But my understanding was that
the sync after the writes was required to ensure write completion.

Can you cite the relevant documentation on this? Is this specific to the Qualcomm CPU implementation or the IOMMU? I don't think the ARM architecture requires anything like this in general.

Quoted 16 lines

Quoted 12 lines

drivers/iommu/msm_iommu.c fail: · line 192

Quoted 9 lines

drivers/iommu/msm_iommu.c +2 -1

@@ -181,7 +187,8 @@ fail:
 
 static void __flush_iotlb_sync(void *cookie)
 {
-	/* To avoid a null function pointer */
+	/* To ensure completion of the TLBIVA in __flush_iotlb_range */
+	mb();
 }

I don't understand the specific race from the comment.

Quoted 3 lines

What operation comes after this that relies on __flush_iotlb_range having completed, and how does an mb() guarantee this?

Quoted 5 lines

The flush_iotlb_range operation invalidates the tlb for writes to pagetable and the finally calls the sync operation to ensure completion of the flush and this is required before returning back to the client of the iommu. In the case of this iommu, only a barrier is required to ensure completion of the invalidate operation.

This doesn't answer my question: What operation would a client do that requires the flush to be completed here? A barrier is always defined in terms of things that come before it in combination with things that come after it.

Any operation that could trigger a DMA from a device is required to have a barrier preceding it (usually wmb() one implied by writel()), so this is clearly not about a driver that installs a DMA mapping before starting a DMA, but I don't see what else it would be.

Quoted 6 lines

Quoted 5 lines

In this case, I'd say it's better to rewrite the function to avoid the
read: iova_to_phys() should be fast, and not require hardware access. Getting rid of the hardware access by using an in-memory cache for this should gain more than just removing the barriers, as an MMIO read is always slow

Quoted 3 lines

Ok, you mean using the software walk through ? I will check on this to measure
the latency difference. If thats true, then the iopgtable ops itself provides a
function for iova_to_phys conversion, so that can be used.

I hadn't realized that this is a lookup in the hardware, rather than reading a static register. It's probably a good idea to check this anyway.

Quoted 6 lines

Any operation that could trigger a DMA from a device is required to have a barrier preceding it (usually wmb() one implied by writel()), so this is clearly not about a driver that installs a DMA mapping before starting a DMA, but I don't see what else it would be.

Ok, so i was doing this from the idea that, other iommu drivers
where polling on a status bit in their sync call to ensure completion
of pending TLB invalidations. But in this case, there is no status bit.
So added a barrier to have no ordering issues before the client
triggers the dma operation. But as you say above that it is implicit that the device would have a barrier before starting the trigger, then the barrier here becomes redundant.

Quoted 7 lines

Ok, so i was doing this from the idea that, other iommu drivers
where polling on a status bit in their sync call to ensure completion
of pending TLB invalidations. But in this case, there is no status bit.
So added a barrier to have no ordering issues before the client
triggers the dma operation. But as you say above that it is implicit that the device would have a barrier before starting the trigger, then the barrier here becomes redundant.

Ok. There are two more things to note here:

* On other platforms, polling the register is likely required because an MMIO write is "posted", meaning that a sync after writel() will only ensure that it has left the CPU write queue, but it may still be on the bus fabric and whatever side-effects are triggered by the write are normally not guaranteed to be completed even after the 'sync'. You need to check the datasheet for your IOMMU to find out whether the 'dsb' instruction actually has any effect on the IOMMU. If not, then neither the barrier that you add here nor the barrier in the following writel() is sufficient.

* The one barrier that is normally required in an IOMMU is between updating the in-memory page tables and the following MMIO store that triggers the TLB flush for that entry. This barrier is implied by writel() but not writel_relaxed(). If you don't have a hardware page table walker in your IOMMU, you don't need to worry about this.

Hi Arnd,

Quoted 10 lines

Quoted 7 lines

Ok, so i was doing this from the idea that, other iommu drivers
where polling on a status bit in their sync call to ensure completion
of pending TLB invalidations. But in this case, there is no status bit.
So added a barrier to have no ordering issues before the client
triggers the dma operation. But as you say above that it is implicit that the device would have a barrier before starting the trigger, then the barrier here becomes redundant.

Ok. There are two more things to note here:

Quoted 10 lines

* On other platforms, polling the register is likely required because an MMIO write is "posted", meaning that a sync after writel() will only ensure that it has left the CPU write queue, but it may still be on the bus fabric and whatever side-effects are triggered by the write are normally not guaranteed to be completed even after the 'sync'. You need to check the datasheet for your IOMMU to find out whether the 'dsb' instruction actually has any effect on the IOMMU. If not, then neither the barrier that you add here nor the barrier in the following writel() is sufficient.

Thanks for the detailed explanation.
i will check this. So with this, i think that if the iommu does not
support polling for its status, then it should listen to 'dsb' otherwise there will no be no way of make it coherent ?

Quoted 7 lines

* The one barrier that is normally required in an IOMMU is between updating the in-memory page tables and the following MMIO store that triggers the TLB flush for that entry. This barrier is implied by writel() but not writel_relaxed(). If you don't have a hardware page table walker in your IOMMU, you don't need to worry about this.

To get my understanding correct here, is the barrier required here because
of speculative fetch ?

Quoted 10 lines

Quoted 10 lines

* On other platforms, polling the register is likely required because an MMIO write is "posted", meaning that a sync after writel() will only ensure that it has left the CPU write queue, but it may still be on the bus fabric and whatever side-effects are triggered by the write are normally not guaranteed to be completed even after the 'sync'. You need to check the datasheet for your IOMMU to find out whether the 'dsb' instruction actually has any effect on the IOMMU. If not, then neither the barrier that you add here nor the barrier in the following writel() is sufficient.

Quoted 4 lines

Thanks for the detailed explanation.
i will check this. So with this, i think that if the iommu does not
support polling for its status, then it should listen to 'dsb' otherwise there will no be no way of make it coherent ?

It's more likely that you have to do a readl() after the writel() to any address inside of the device in order to ensure the writel() has completed, but that is something that the hardware manual for the iommu should describe.

Quoted 9 lines

Quoted 7 lines

* The one barrier that is normally required in an IOMMU is between updating the in-memory page tables and the following MMIO store that triggers the TLB flush for that entry. This barrier is implied by writel() but not writel_relaxed(). If you don't have a hardware page table walker in your IOMMU, you don't need to worry about this.

To get my understanding correct here, is the barrier required here because
of speculative fetch ?

It doesn't have to be a speculative fetch, it could also be a normal fetch triggered by a DMA. The point is that the CPU is free to reorder the store to (io page table) memory relative to the store to the IOMMU flush register, and when you directly follow up with a store to the DMA master that triggers a transfer, this transfer can hit the IOMMU and cause the stale page table entry to be read.

I guess in practice the barrier that comes before the MMIO write to the DMA master would ensure ordering of the DMA after both the IOPTE update and the MMIO flush (unless there was the speculative fetch you mentioned), but this is where I'm no longer confident enough in my pwn understanding of th ordering rules to rely on that. Having the barrier between the IOPTE update and the flush certainly leaves no room for ambiguity.

The msm_iommu.c driver currently works based on platform data.
A single master device can be connected to more than one iommu and multiple contexts in each of the iommu. This association between master and iommus was represented from platform data using parent/child devices. The master drivers were responsible for attaching all of the iommus/context to a domain. Now the platform data support is removed and DT support is added. The master/iommus are added through generic iommu bindings.

This is essentially rework of the patch posted earlier by Rob Clark <[email protected]>. This series folds the changes in to the existing driver with the addition of generic bindings.

         http://www.spinics.net/lists/linux-arm-msm/msg10077.html

Tested this series on ifc6410 board.

[V5] Changed the compatible binding name as per comments, added comments
for usage of barriers in patch 6.

[V4] Addressed comments for making the iommu compatible binding more soc
specific and updated the documentation for the iommu clocks.

[V3] Addressed comments to correct the usage
of the #iommu-cells binding, improve the flush_iotlb_range function, added a new patch to use writel_relaxed for register access and split up the documentation patch.

[V2] Adapted the driver to use generic ARMV7S short descriptor pagetable ops
and addressed comments.

[V1]

    https://lists.linuxfoundation.org/pipermail/iommu/2015-August/014074.html

Sricharan R (7):
iommu/msm: Add DT adaptation
documentation: iommu: Add bindings for msm,iommu-v0 ip iommu/msm: Move the contents from msm_iommu_dev.c to msm_iommu.c iommu/msm: Add support for generic master bindings iommu/msm: use generic ARMV7S short descriptor pagetable ops iommu/msm: Use writel_relaxed and add a barrier iommu/msm: Remove driver BROKEN

  .../devicetree/bindings/iommu/msm,iommu-v0.txt     |  64 ++
  drivers/iommu/Kconfig                              |   2 +-
  drivers/iommu/Makefile                             |   2 +-
  drivers/iommu/msm_iommu.c                          | 885 +++++++++++----------
  drivers/iommu/msm_iommu.h                          |  73 +-
  drivers/iommu/msm_iommu_dev.c                      | 381 ---------
  drivers/iommu/msm_iommu_hw-8xxx.h                  | 109 +--
  7 files changed, 636 insertions(+), 880 deletions(-)

create mode 100644 Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt delete mode 100644 drivers/iommu/msm_iommu_dev.c

The msm_iommu.c driver currently works based on platform data.
A single master device can be connected to more than one iommu and multiple contexts in each of the iommu. This association between master and iommus was represented from platform data using parent/child devices. The master drivers were responsible for attaching all of the iommus/context to a domain. Now the platform data support is removed and DT support is added. The master/iommus are added through generic iommu bindings.

[V1]

    https://lists.linuxfoundation.org/pipermail/iommu/2015-August/014074.html

Sricharan R (7):
iommu/msm: Add DT adaptation
documentation: iommu: Add bindings for msm,iommu-v0 ip iommu/msm: Move the contents from msm_iommu_dev.c to msm_iommu.c iommu/msm: Add support for generic master bindings iommu/msm: use generic ARMV7S short descriptor pagetable ops iommu/msm: Use writel_relaxed and add a barrier iommu/msm: Remove driver BROKEN

  .../devicetree/bindings/iommu/msm,iommu-v0.txt     |  64 ++
  drivers/iommu/Kconfig                              |   2 +-
  drivers/iommu/Makefile                             |   2 +-
  drivers/iommu/msm_iommu.c                          | 885 +++++++++++----------
  drivers/iommu/msm_iommu.h                          |  73 +-
  drivers/iommu/msm_iommu_dev.c                      | 381 ---------
  drivers/iommu/msm_iommu_hw-8xxx.h                  | 109 +--
  7 files changed, 636 insertions(+), 880 deletions(-)

create mode 100644 Documentation/devicetree/bindings/iommu/msm,iommu-v0.txt delete mode 100644 drivers/iommu/msm_iommu_dev.c