Hi Will,
On 12/09/14 17:34, Will Deacon wrote:
Hi all,
Here is version three of the RFC I've previously posted here:
RFCv1:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-August/283023.html
RFCv2:
Hi Will,
After some fun times wondering why on Earth of_iommu_init was trying to
instantiate a GIC, I think we may need one of these as part of this
patch, too ;)
Robin.
---8---
diff --git a/drivers/iommu/of_iommu.c b/drivers/iommu/of_iommu.c
index 8656b63..1927691 100644
---
Hi Will,
On 14/11/14 18:56, Will Deacon wrote:
This patch plumbs the existing ARM IOMMU DMA infrastructure (which isn't
actually called outside of a few drivers) into arch_setup_dma_ops, so
that we can use IOMMUs for DMA transfers in a more generic fashion.
Since this significantly complicates
Hi Will,
On 14/11/14 18:56, Will Deacon wrote:
of_dma_configure determines the size of the DMA range for a device by
either parsing the dma-ranges property or inspecting the coherent DMA
mask. This same information can be used to initialise the max segment
size and boundary_mask to a default
mapping
running on arm64, so with the proviso that patch 6 definitely causes
problems, and patches 7 and 8 ported to arm64 rather than used directly,
for the series:
Tested-by: Robin Murphy robin.mur...@arm.com
Hopefully it's now stable enough that I can finish cleaning up my
hacked-up SMMU
In order to share the IOVA allocator with other architectures, break
the unnecssary dependency on the Intel IOMMU driver and move the
remaining IOVA internals to iova.c
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
drivers/iommu/intel-iommu.c | 33
], that frankly looks nicer ;)
I've merely left them in as context here.
[1]:http://thread.gmane.org/gmane.linux.ports.arm.kernel/331299
[2]:http://article.gmane.org/gmane.linux.kernel.iommu/7436
Robin Murphy (4):
iommu: build iova.c for any IOMMU
iommu: consolidate IOVA allocator code
iommu
page granularity from an implicit
compile-time constant to a per-domain property so we can make use
of it in IOVA domain context at runtime. To keep the abstraction tidy,
extend the little API of inline iova_* helpers to parallel some of the
equivalent PAGE_* macros.
Signed-off-by: Robin Murphy
In preparation for sharing the IOVA allocator, build it for all
IOMMU API users.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
drivers/iommu/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 16edef7
description of alloc_iova since we're
touching it anyway.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
drivers/iommu/intel-iommu.c | 9 ++---
drivers/iommu/iova.c| 10 ++
include/linux/iova.h| 7 +++
3 files changed, 15 insertions(+), 11 deletions(-)
diff --git
be mapped and therefore exposed to the device, and
brings the default iommu_map_sg implementation in line with
iommu_map/unmap with respect to alignment.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
Hi Joerg,
I noticed this whilst wiring up DMA mapping to this new API - on arm64
we anticipate
Hi,
On 26/11/14 07:17, leizhen wrote:
[...]
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index a3dbba8..9e50625 100644
--- a/drivers/iommu/iova.c
+++ b/drivers/iommu/iova.c
@@ -55,12 +55,16 @@ void free_iova_mem(struct iova *iova)
}
void
-init_iova_domain(struct iova_domain
, but it didn't blow up
or regress anything.
Regards,
Robin.
---8---
From 1f3d2612682c239e53f2c20e2ac5d19ef3f5387c Mon Sep 17 00:00:00 2001
Message-Id:
1f3d2612682c239e53f2c20e2ac5d19ef3f5387c.1417695078.git.robin.mur...@arm.com
From: Robin Murphy robin.mur...@arm.com
Date: Thu, 4 Dec 2014 11:53:13
:
b2e8c91ac49bef4008661e4628cd6b7249d84af5.1417698001.git.robin.mur...@arm.com
From: Robin Murphy robin.mur...@arm.com
Date: Thu, 4 Dec 2014 11:53:13 +
Subject: [PATCH v2] iommu: store DT-probed IOMMU data privately
Since the data pointer in the DT node is public and may be overwritten
by conflicting code
for this fix - I'm just keen to get the
merge-blocker out of the way.
Regards,
Robin.
---8---
From 9eba5081aaf4fa8ed5158675a6e622be11a64ae2 Mon Sep 17 00:00:00 2001
Message-Id:
9eba5081aaf4fa8ed5158675a6e622be11a64ae2.1417719305.git.robin.mur...@arm.com
From: Robin Murphy robin.mur...@arm.com
Date
Hi Will,
On 05/12/14 12:10, Will Deacon wrote:
[...]
Do you expect drivers to modify that *priv pointer after the ops
structure is registered? I'd be very surprised if that was the use
case. It's fine for the driver to register a non-const version, but
once it is registered, the infrastructure
mapping ops.
Acked-by: Arnd Bergmann a...@arndb.de
Acked-by: Marek Szyprowski m.szyprow...@samsung.com
Tested-by: Robin Murphy robin.mur...@arm.com
Signed-off-by: Will Deacon will.dea...@arm.com
---
arch/arm/include/asm/dma-mapping.h | 4 +++-
drivers/of/platform.c | 21
Hi Will,
On 17/12/14 12:09, Will Deacon wrote:
On Tue, Dec 16, 2014 at 12:08:15PM +, Arnd Bergmann wrote:
On Monday 15 December 2014 18:09:33 Will Deacon wrote:
Using a single domain is a bit of a waste of resources in my case, so an
evolution would be to create four domains and assign
Hi Laura,
Thanks for looking
On 23/01/15 17:42, Laura Abbott wrote:
On 1/12/2015 12:48 PM, Robin Murphy wrote:
Taking inspiration from the existing arch/arm code, break out some
generic functions to interface the DMA-API to the IOMMU-API. This will
do the bulk of the heavy lifting for IOMMU
On 23/01/15 16:47, Catalin Marinas wrote:
On Mon, Jan 12, 2015 at 08:48:52PM +, Robin Murphy wrote:
Catalin Marinas (1):
arm64: Combine coherent and non-coherent swiotlb dma_ops
Robin Murphy (4):
arm64: implement generic IOMMU configuration
iommu: implement common IOMMU ops
Hi Will,
Thanks for taking a look
On 23/01/15 15:26, Will Deacon wrote:
On Mon, Jan 12, 2015 at 08:48:56PM +, Robin Murphy wrote:
Taking some inspiration from the arch/arm code, implement the
arch-specific side of the DMA mapping ops using the new IOMMU-DMA layer.
Signed-off-by: Robin
Taking some inspiration from the arch/arm code, implement the
arch-specific side of the DMA mapping ops using the new IOMMU-DMA layer.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
arch/arm64/include/asm/device.h | 3 +
arch/arm64/include/asm/dma-mapping.h | 17 ++
arch/arm64/mm
in the common code are addressed we can complete the
refactoring by porting arch/arm over for a merge-worthy series.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
drivers/iommu/Kconfig | 7 +
drivers/iommu/Makefile| 1 +
drivers/iommu/dma-iommu.c | 552
://thread.gmane.org/gmane.linux.ports.tegra/20907
[3]:http://thread.gmane.org/gmane.linux.kernel.iommu/8492
Robin Murphy (3):
iommu: implement common IOMMU ops for DMA mapping
arm64: add IOMMU dma_ops
arm64: hook up IOMMU dma_ops
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm
With iommu_dma_ops in place, hook them up to the configuration code, so
IOMMU-fronted devices will get them automatically.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/dma-mapping.h | 11 ++-
arch/arm64/mm/dma
Hi Laura,
As a heads up, I'm still vainly hoping to move the ARM SMMU driver
entirely over to the generic framework - there's an iommu/dev branch on
top of the iommu/dma branch I pushed earlier[1] which you might want to
take a peek at to check if we're likely to end up pulling in different
On 13/01/15 08:02, Yingjoe Chen wrote:
On Mon, 2015-01-12 at 20:48 +, Robin Murphy wrote:
Hi all,
Whilst it's a long way off perfect, this has reached the point of being
functional and stable enough to be useful, so here it is. The core
consists of the meat of the arch/arm implementation
On 16/01/15 07:21, Yong Wu wrote:
[...]
Now that the server seems to be properly accessible again, I've made a
branch with both series available here:
git://linux-arm.org/linux-rm iommu/dma
Note that in the current state it also depends on having the ARM SMMU
driver selected in the config,
Hi Will,
Thanks for the comments,
On 09/02/15 04:05, Will Deacon wrote:
Hi Robin,
On Fri, Feb 06, 2015 at 02:55:13PM +, Robin Murphy wrote:
Taking inspiration from the existing arch/arm code, break out some
generic functions to interface the DMA-API to the IOMMU-API. This will
do
Hi Murali,
On 23/01/15 22:32, Murali Karicheri wrote:
Fix the dma-range size when the DT attribute is missing. i.e set size to
dev-coherent_dma_mask + 1 instead of dev-coherent_dma_mask. To detect
overflow when mask is set to max of u64, add a check, log error and return.
Some platform use
Hi Murali,
On 23/01/15 22:32, Murali Karicheri wrote:
Limit the dma_mask to minimum of dma_mask and dma_base + size - 1.
Also arm_iommu_create_mapping() has size parameter of size_t and
arm_setup_iommu_dma_ops() can take a value higher than that. So
limit the size to SIZE_MAX.
Signed-off-by:
Hi Murali,
[sorry, missed replying to yesterday's version]
On 27/01/15 21:00, Murali Karicheri wrote:
Fix the dma-range size when the DT attribute is missing. i.e set size to
dev-coherent_dma_mask + 1 instead of dev-coherent_dma_mask. Also add
code to check invalid values of size configured
On 28/01/15 11:05, Catalin Marinas wrote:
On Tue, Jan 27, 2015 at 06:55:15PM +, Murali Karicheri wrote:
On 01/27/2015 06:27 AM, Robin Murphy wrote:
On 23/01/15 22:32, Murali Karicheri wrote:
Fix the dma-range size when the DT attribute is missing. i.e set size to
dev-coherent_dma_mask + 1
On 28/01/15 14:30, Will Deacon wrote:
On Tue, Jan 27, 2015 at 12:08:56AM +, Joerg Roedel wrote:
From: Joerg Roedel jroe...@suse.de
The default domain will be used (if supported by the iommu
driver) when the devices in the iommu group are not attached
to any other domain.
Signed-off-by:
Hi Joerg,
On 27/01/15 00:21, Joerg Roedel wrote:
Hi Robin,
thanks for the patch, I think it is good start to move forward. See my
comments below.
On Mon, Jan 12, 2015 at 08:48:55PM +, Robin Murphy wrote:
Taking inspiration from the existing arch/arm code, break out some
generic functions
Hi Joseph,
Thanks for giving it a spin,
On 26/01/15 03:25, Joseph Lo wrote:
On 01/13/2015 04:48 AM, Robin Murphy wrote:
Taking some inspiration from the arch/arm code, implement the
arch-specific side of the DMA mapping ops using the new IOMMU-DMA layer.
Signed-off-by: Robin Murphy robin.mur
On 09/01/15 19:45, Arnd Bergmann wrote:
On Friday 09 January 2015 16:56:03 Robin Murphy wrote:
This one's a bit tricky to find a home for - I think technically it's
probably an IOMMU patch, but then the long-underlying problem doesn't
seem to have blown up anything until arm64, and my
Hi Joerg,
On 12/01/15 15:52, Joerg Roedel wrote:
[...]
Thanks for doing this, I like this patch-set.
I would also appreciate if someone from Intel could have a look at it,
David?
Besides, can you please re-post this patch-set rebased to latest
upstream with the better versions of patch 1 and
With iommu_dma_ops in place, hook them up to the configuration code, so
IOMMU-fronted devices will get them automatically.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/dma-mapping.h | 10 +-
arch/arm64/mm/dma
this in common code as the first step towards
consolidating the numerous versions spread around between architecture
code and IOMMU drivers.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
include/linux/dma-iommu.h | 78
lib/Kconfig | 8 +
lib/Makefile | 1
From: Catalin Marinas catalin.mari...@arm.com
Since dev_archdata now has a dma_coherent state, combine the two
coherent and non-coherent operations and remove their declaration,
together with set_dma_ops, from the arch dma-mapping.h file.
Signed-off-by: Catalin Marinas catalin.mari...@arm.com
Add the necessary call to of_iommu_init.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
arch/arm64/kernel/setup.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index b809911..8304141 100644
--- a/arch/arm64/kernel/setup.c
+++ b
/gmane.linux.kernel.iommu/8208
Catalin Marinas (1):
arm64: Combine coherent and non-coherent swiotlb dma_ops
Robin Murphy (4):
arm64: implement generic IOMMU configuration
iommu: implement common IOMMU ops for DMA mapping
arm64: add IOMMU dma_ops
arm64: hook up IOMMU dma_ops
arch/arm64/Kconfig
Taking some inspiration from the arch/arm code, implement the
arch-specific side of the DMA mapping ops using the new IOMMU-DMA layer.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
arch/arm64/include/asm/device.h | 3 +
arch/arm64/include/asm/dma-mapping.h | 12 ++
arch/arm64/mm
a bit by replacing the bare constants with slightly more meaningful
macros and removing the superfluous else statements.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
Hi, various maintainers from Git logs ;)
This one's a bit tricky to find a home for - I think technically it's
probably
On 13/01/15 08:02, Yingjoe Chen wrote:
On Mon, 2015-01-12 at 20:48 +, Robin Murphy wrote:
Hi all,
Whilst it's a long way off perfect, this has reached the point of being
functional and stable enough to be useful, so here it is. The core
consists of the meat of the arch/arm implementation
On 13/01/15 11:08, Stefano Stabellini wrote:
On Mon, 12 Jan 2015, Robin Murphy wrote:
Hi all,
Whilst it's a long way off perfect, this has reached the point of being
functional and stable enough to be useful, so here it is. The core
consists of the meat of the arch/arm implementation modified
In preparation for sharing the IOVA allocator, split it out under its
own Kconfig symbol.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
drivers/iommu/Kconfig | 4
drivers/iommu/Makefile | 3 ++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/Kconfig b
Kconfig symbol rather than a hack
Patch 4: sanity check for powers of two also, and clarify the comment
[1]:http://thread.gmane.org/gmane.linux.kernel.iommu/7480
[2]:http://thread.gmane.org/gmane.linux.kernel.iommu/7436
Robin Murphy (4):
iommu: allow building iova.c independently
iommu
description of alloc_iova since we're
touching it anyway.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
drivers/iommu/intel-iommu.c | 9 ++---
drivers/iommu/iova.c| 10 ++
include/linux/iova.h| 7 +++
3 files changed, 15 insertions(+), 11 deletions(-)
diff --git
page granularity from an implicit
compile-time constant to a per-domain property so we can make use
of it in IOVA domain context at runtime. To keep the abstraction tidy,
extend the little API of inline iova_* helpers to parallel some of the
equivalent PAGE_* macros.
Signed-off-by: Robin Murphy
In order to share the IOVA allocator with other architectures, break
the unnecssary dependency on the Intel IOMMU driver and move the
remaining IOVA internals to iova.c
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
drivers/iommu/intel-iommu.c | 33
On 09/03/15 20:09, Robin Murphy wrote:
[...]
I think ideally you'd call dma_map_page when you first create the page
table, dma_sync_single_for_device on any update, and dma_unmap_page when you
tear it down, and you'd also use the appropriate DMA addresses everywhere
instead of physical addresses
Hi Marek,
On 05/03/15 14:31, Marek Szyprowski wrote:
Hello,
On 2015-01-12 21:48, Robin Murphy wrote:
Hi all,
Whilst it's a long way off perfect, this has reached the point of being
functional and stable enough to be useful, so here it is. The core
consists of the meat of the arch/arm
On 05/03/15 17:28, Mitchel Humpherys wrote:
On Thu, Mar 05 2015 at 02:38:45 AM, Robin Murphy robin.mur...@arm.com wrote:
Hi Mitch,
On 05/03/15 00:18, Mitchel Humpherys wrote:
We're currently mapping a page in arm_smmu_flush_pgtable without ever
unmapping it. Fix this by calling
outside the default 32-bit mask.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
drivers/iommu/arm-smmu.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index fc13dd5..dc0ae62 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu
Hi Laura,
On 05/03/15 00:19, Laura Abbott wrote:
[...]
Consider that the IOMMU's page table walker is a DMA master in its own
right, and that is the device you're mapping the page tables for.
Therefore your IOMMU driver needs to have access to the struct device
of the IOMMU itself to use for
Hi Mitch,
On 05/03/15 00:18, Mitchel Humpherys wrote:
We're currently mapping a page in arm_smmu_flush_pgtable without ever
unmapping it. Fix this by calling dma_unmap_page on the returned dma
address. Since the only reason we're calling dma_map_page is to make
sure it actually gets flushed
Hi Marek,
On 28/04/15 10:08, Marek Szyprowski wrote:
Patch 22b3c181c6c324a46f71aae806d8ddbe61d25761 (arm: dma-mapping: limit
IOMMU mapping size) added a check for IO address space size. However
this patch broke IOMMU initialization for typical platforms initialized
from device tree, which get
On 28/04/15 15:52, Robin Murphy wrote:
Hi Marek,
On 28/04/15 10:08, Marek Szyprowski wrote:
Patch 22b3c181c6c324a46f71aae806d8ddbe61d25761 (arm: dma-mapping: limit
IOMMU mapping size) added a check for IO address space size. However
this patch broke IOMMU initialization for typical platforms
Hi Marek,
On 04/05/15 09:15, Marek Szyprowski wrote:
Some devices (like frame buffers) are enabled by bootloader and configured
to perform DMA operations automatically (like displaying boot logo or splash
screen). Such devices operate and perform DMA operation usually until the
proper driver
Oops, seems I'm rather behind on things - I started this review on the
RFC, but I'll finish it here...
On 15/05/15 10:43, Yong Wu wrote:
This patch is for ARM Short Descriptor Format.It has 2-levels
pagetable and the allocator supports 4K/64K/1M/16M.
From the look of the code, this doesn't
Hi Laurent,
On 15/05/15 00:00, Laurent Pinchart wrote:
The arm_iommu_create_mapping() function takes the IOMMU mapping size as
a size_t, limiting the size to 4GB - 1 on 32 bit platforms while most
bus masters would support the full 32 bits range. Fix this by passing
the size as a 64 bits
Hi Laurent,
On 15/05/15 00:00, Laurent Pinchart wrote:
Configuring DMA ops at probe time will allow deferring device probe when
the IOMMU isn't available yet.
This is great, as I think it also subtly solves the ordering problem the
current domain allocation has with platform devices. WRT to
On 16/05/15 08:08, Daniel Kurtz wrote:
On Fri, May 15, 2015 at 5:43 PM, Yong Wu yong...@mediatek.com wrote:
This patch adds support for m4u(Multimedia Memory Management Unit),
Currently it only support the m4u with 2 levels of page table on mt8173.
It is based on Robin Murphy's arm64:
On 18/06/15 16:00, Yong Wu wrote:
Hi Robin,
while our drm test, we meet a problem while dma-mmap.
On Thu, 2015-06-11 at 16:54 +0100, Robin Murphy wrote:
Taking inspiration from the existing arch/arm code, break out some
generic functions to interface the DMA-API to the IOMMU-API
With iommu_dma_ops in place, hook them up to the configuration code, so
IOMMU-fronted devices will get them automatically.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/dma-mapping.h | 11 ++-
arch/arm64/mm/dma
[2]:git://linux-arm.org/linux-rm iommu/dma
Robin Murphy (4):
iommu/iova: Avoid over-allocating when size-aligned
iommu: Implement common IOMMU ops for DMA mapping
arm64: Add IOMMU dma_ops
arm64: Hook up IOMMU dma_ops
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm
padding makes no sense.
CC: David Woodhouse dw...@infradead.org
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
drivers/iommu/intel-iommu.c | 2 ++
drivers/iommu/iova.c| 23 ++-
2 files changed, 8 insertions(+), 17 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c
Taking inspiration from the existing arch/arm code, break out some
generic functions to interface the DMA-API to the IOMMU-API. This will
do the bulk of the heavy lifting for IOMMU-backed dma-mapping.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
drivers/iommu/Kconfig | 7 +
drivers
Hi Joerg,
On 28/05/15 17:41, Joerg Roedel wrote:
From: Joerg Roedel jroe...@suse.de
The default domain will be used (if supported by the iommu
driver) when the devices in the iommu group are not attached
to any other domain.
Signed-off-by: Joerg Roedel jroe...@suse.de
---
Hi Joerg,
On 28/05/15 17:41, Joerg Roedel wrote:
From: Joerg Roedel jroe...@suse.de
The default domain will be used (if supported by the iommu
driver) when the devices in the iommu group are not attached
to any other domain.
Signed-off-by: Joerg Roedel jroe...@suse.de
---
On 28/05/15 17:41, Joerg Roedel wrote:
From: Joerg Roedel jroe...@suse.de
Make use of the default domain and re-attach a device to it
when it is detached from another domain. Also enforce that a
device has to be in the default domain before it can be
attached to a different domain.
On 28/05/15 17:41, Joerg Roedel wrote:
From: Joerg Roedel jroe...@suse.de
Add two new functions to the IOMMU-API to allow the IOMMU
drivers to export the requirements for direct mapped regions
per device.
This is useful for exporting the information in Intel VT-d's
RMRR entries or AMD-Vi's
with the pgsize_bitmap to cheat the system, I'm sure we don't want
to add any more of that. How about something like the below diff as a
first step?
Robin.
---8---
From: Robin Murphy robin.mur...@arm.com
Date: Fri, 29 May 2015 12:05:58 +0100
Subject: [PATCH] iommu: Allow drivers to support
padding makes no sense.
CC: David Woodhouse dw...@infradead.org
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
drivers/iommu/intel-iommu.c | 2 ++
drivers/iommu/iova.c| 23 ++-
2 files changed, 8 insertions(+), 17 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c
Taking inspiration from the existing arch/arm code, break out some
generic functions to interface the DMA-API to the IOMMU-API. This will
do the bulk of the heavy lifting for IOMMU-backed dma-mapping.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
drivers/iommu/Kconfig | 7 +
drivers
the kind of problematic system topologies in the current
IOMMU API anyway.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
arch/arm64/include/asm/device.h | 3 +
arch/arm64/include/asm/dma-mapping.h | 14 ++
arch/arm64/mm/dma-mapping.c | 342
for
platform devices, which should hopefully tie in with default domains
to make the add_device callback mostly redundant.
[1]:http://thread.gmane.org/gmane.linux.kernel.iommu/8773
[2]:http://thread.gmane.org/gmane.linux.kernel.iommu/9552
Robin Murphy (4):
iommu/iova: Avoid over-allocating when
With iommu_dma_ops in place, hook them up to the configuration code, so
IOMMU-fronted devices will get them automatically.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/dma-mapping.h | 11 ++-
arch/arm64/mm/dma
-dma-contig.c#L70
On Wed, 2015-05-27 at 15:09 +0100, Robin Murphy wrote:
Taking inspiration from the existing arch/arm code, break out some
generic functions to interface the DMA-API to the IOMMU-API. This will
do the bulk of the heavy lifting for IOMMU-backed dma-mapping.
Signed-off-by: Robin
On 03/07/15 10:27, Yong Wu wrote:
[...]
+/**
+ * iommu_dma_alloc - Allocate and map a buffer contiguous in IOVA space
+ * @dev: Device to allocate memory for. Must be a real device
+ * attached to an iommu_dma_domain
+ * @size: Size of buffer in bytes
+ * @gfp: Allocation flags
+ * @prot:
On 26/06/15 09:33, Zhen Lei wrote:
Now, we only support a master with only one stream id. It will cover most
hardware platforms and coding so easy.
Please refer Documentation\devicetree\bindings\iommu\iommu.txt on how to
bind device tree.
Signed-off-by: Zhen Lei thunder.leiz...@huawei.com
---
With the correct DMA API calls now integrated into the io-pgtable code,
let that handle the flushing of non-coherent page table updates.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
drivers/iommu/arm-smmu-v3.c | 18 +++---
1 file changed, 3 insertions(+), 15 deletions
With the correct DMA API calls now integrated into the io-pgtable code,
let that handle the flushing of non-coherent page table updates.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
drivers/iommu/arm-smmu.c | 22 ++
1 file changed, 6 insertions(+), 16 deletions
With the io-pgtable code now enforcing its own appropriate sync points,
the vestigial flush_pgtable callback becomes entirely redundant, so
remove it altogether.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
drivers/iommu/arm-smmu-v3.c | 10 --
1 file changed, 10 deletions
of the operation, and obviate
the need to call flush_pgtable on every individual update for
synchronisation.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
drivers/iommu/io-pgtable-arm.c | 43 +++---
drivers/iommu/io-pgtable.h | 3 ++-
2 files changed, 26
With the io-pgtable code now enforcing its own appropriate sync points,
the vestigial flush_pgtable callback becomes entirely redundant, so
remove it altogether.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
drivers/iommu/arm-smmu.c | 13 -
1 file changed, 13 deletions
to the dma-coherent property in the device tree
for the final say.
As an added bonus, since systems exist where an external CTTW signal
has been tied off incorrectly at integration, allowing DT to override
it offers a neat workaround for coherency issues with such SMMUs.
Signed-off-by: Robin Murphy
With the users fully converted to DMA API operations, it's dead, Jim.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
drivers/iommu/io-pgtable-arm.c | 6 --
drivers/iommu/io-pgtable.h | 2 --
2 files changed, 8 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers
With the correct DMA API calls now integrated into the io-pgtable code,
let that handle the flushing of non-coherent page table updates.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
drivers/iommu/ipmmu-vmsa.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions
pressure on
ZONE_DMA, and treat any DMA translation as a warning sign.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
Changes since v1[1]:
- Make device pointer mandatory and use DMA API unconditionally
- Remove flush_pgtable callback entirely
- Style, consistency and typo fixes
[1]:http
Hi Laurent,
[ +RMK, as his patch is indirectly involved here ]
On 04/08/15 14:16, Laurent Pinchart wrote:
Hi Will and Robin,
Thank you for the patch.
On Monday 03 August 2015 14:25:47 Will Deacon wrote:
From: Robin Murphy robin.mur...@arm.com
Currently, users of the LPAE page table code
With iommu_dma_ops in place, hook them up to the configuration code, so
IOMMU-fronted devices will get them automatically.
Acked-by: Catalin Marinas catalin.mari...@arm.com
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm
Taking inspiration from the existing arch/arm code, break out some
generic functions to interface the DMA-API to the IOMMU-API. This will
do the bulk of the heavy lifting for IOMMU-backed dma-mapping.
Signed-off-by: Robin Murphy robin.mur...@arm.com
---
drivers/iommu/Kconfig | 7 +
drivers
merged first as a stable base to work with (and un-block arm64
in the meantime). Have we decided yet whether this should go via the
IOMMU tree or the arm64 tree?
Thanks,
Robin.
[1]:http://thread.gmane.org/gmane.linux.kernel.iommu/10181
Robin Murphy (3):
iommu: Implement common IOMMU ops for DMA
On 28/07/15 11:18, Will Deacon wrote:
On Mon, Jul 27, 2015 at 07:18:10PM +0100, Robin Murphy wrote:
With the correct DMA API calls now integrated into the io-pgtable code,
let that handle the flushing of non-coherent page table updates.
Signed-off-by: Robin Murphy robin.mur...@arm.com
Hi Will,
On 28/07/15 10:43, Will Deacon wrote:
Hi Robin,
Cheers for doing this. Just a few comments (mainly in relation to being
consistent with SMMUv3).
Thanks!
On Mon, Jul 27, 2015 at 07:18:09PM +0100, Robin Murphy wrote:
Currently we detect the whether the SMMU has coherent page table
On 28/07/15 11:17, Will Deacon wrote:
[...]
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index 4e46021..b93a60e 100644
--- a/drivers/iommu/io-pgtable-arm.c
+++ b/drivers/iommu/io-pgtable-arm.c
@@ -200,12 +200,76 @@ typedef u64 arm_lpae_iopte;
static bool
On 30/07/15 19:45, Will Deacon wrote:
Hello,
On Thu, Jul 30, 2015 at 06:55:06PM +0100, tchalama...@caviumnetworks.com wrote:
From: Tirumalesh Chalamarla tchalama...@caviumnetworks.com
The SMMU architecture defines two different behaviors when 64-bit
registers are written with 32-bit writes.
1 - 100 of 3413 matches
Mail list logo
