On 2020-05-07 1:06 pm, Sai Prakash Ranjan wrote:
[...]
We could have our own context fault handler in QCOM implementation,
but that would just be duplicating things from arm-smmu context fault
handler. So I did not think it makes much sense to have our own
fault handler in qcom impl just for enab
On 2020-05-07 7:22 pm, Ajay kumar wrote:
On 5/7/20, Robin Murphy wrote:
On 2020-05-06 9:01 pm, vji...@codeaurora.org wrote:
From: Vijayanand Jitta
When ever a new iova alloc request comes iova is always searched
from the cached node and the nodes which are previous to cached
node. So, even
On 2020-05-06 6:46 pm, Jean-Philippe Brucker wrote:
Some SMMUv3 implementation embed the Perf Monitor Group Registers (PMCG)
inside the first 64kB region of the SMMU. Since PMCG are managed by a
separate driver, this layout causes resource reservation conflicts
during boot.
To avoid this conflic
conflict, don't reserve the MMIO regions that are
implementation defined. Although devm_ioremap_resource() still works on
full pages under the hood, this way we benefit from resource conflict
checks.
Reviewed-by: Robin Murphy
Although in case there's any other cause to resend, a couple of
operating directly
Nit: "let's"
on the struct sg_table objects, which take care of the proper use of
the nents and orig_nents entries.
A few more documentation nitpicks below, but either way the
implementation itself (modulo Christoph's fixup) looks good;
Reviewed-by: Robin
care of the proper use of
the nents and orig_nents entries.
While touching this, lets clarify some ambiguities in the comments for
the existing for_each helpers.
Reviewed-by: Robin Murphy
Signed-off-by: Marek Szyprowski
---
For more information, see '[PATCH v4 00/38] DRM: fix struct sg_
the nents and orig_nents entries.
Modulo Joerg's comments,
Reviewed-by: Robin Murphy
Signed-off-by: Marek Szyprowski
---
For more information, see '[PATCH v4 00/38] DRM: fix struct sg_table nents
vs. orig_nents misuse' thread:
https://lore.kernel.org/dri-devel/2020051
On 2020-05-15 09:19, Song Bao Hua wrote:
[ snip... nice analysis, but ultimately it's still "doing stuff has more
overhead than not doing stuff" ]
I am thinking several possible ways on decreasing or removing the latency of DMA
map/unmap for every single DMA transfer. Meanwhile, "non-strict"
On 2020-05-15 10:45, Joerg Roedel wrote:
From: Joerg Roedel
The IOMMU core code has support for deferring the attachment of a domain
to a device. This is needed in kdump kernels where the new domain must
not be attached to a device before the device driver takes it over.
But this needs support
On 2020-05-15 17:14, Joerg Roedel wrote:
On Fri, May 15, 2020 at 04:42:23PM +0100, Robin Murphy wrote:
struct iommu_domain *iommu_get_dma_domain(struct device *dev)
{
- return dev->iommu_group->default_domain;
+ struct iommu_domain *domain = dev->iommu_group->de
On 2020-05-15 19:26, Joerg Roedel wrote:
On Fri, May 15, 2020 at 05:28:53PM +0100, Robin Murphy wrote:
On 2020-05-15 17:14, Joerg Roedel wrote:
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index ba128d1cdaee..403fda04ea98 100644
--- a/drivers/iommu/dma-iommu.c
+++ b
On 2020-05-15 22:33, Song Bao Hua wrote:
Subject: Re: Constantly map and unmap of streaming DMA buffers with
IOMMU backend might cause serious performance problem
On Fri, May 15, 2020 at 01:10:21PM +0100, Robin Murphy wrote:
Meanwhile, for the safety of buffers, lower-layer drivers need to
On 2020-05-21 12:30, Prakash Gupta wrote:
Limit the iova size while freeing based on unmapped size. In absence of
this even with unmap failure, invalid iova is pushed to iova rcache and
subsequently can cause panic while rcache magazine is freed.
Can you elaborate on that panic?
Signed-off-by
On 2020-05-22 07:25, gup...@codeaurora.org wrote:
On 2020-05-22 01:46, Robin Murphy wrote:
On 2020-05-21 12:30, Prakash Gupta wrote:
Limit the iova size while freeing based on unmapped size. In absence of
this even with unmap failure, invalid iova is pushed to iova rcache and
subsequently can
On 2020-05-22 00:10, Rob Herring wrote:
On Thu, May 21, 2020 at 7:00 AM Lorenzo Pieralisi
wrote:
From: Laurentiu Tudor
The existing bindings cannot be used to specify the relationship
between fsl-mc devices and GIC ITSes.
Add a generic binding for mapping fsl-mc devices to GIC ITSes, using
On 2020-05-22 15:08, Rob Herring wrote:
On Fri, May 22, 2020 at 3:57 AM Diana Craciun OSS
wrote:
On 5/22/2020 12:42 PM, Robin Murphy wrote:
On 2020-05-22 00:10, Rob Herring wrote:
On Thu, May 21, 2020 at 7:00 AM Lorenzo Pieralisi
wrote:
From: Laurentiu Tudor
The existing bindings
On 2020-05-27 17:03, Srinath Mannam wrote:
This patch gives the provision to change default value of MSI IOVA base
to platform's suitable IOVA using module parameter. The present
hardcoded MSI IOVA base may not be the accessible IOVA ranges of platform.
That in itself doesn't seem entirely unre
On 2020-05-30 10:15, Barry Song wrote:
As tests show the latency of dma_unmap can increase dramatically while
calling them cross NUMA nodes, especially cross CPU packages, eg.
300ns vs 800ns while waiting for the completion of CMD_SYNC in an
empty command queue. The large latency causing by remot
On 2020-05-26 08:19, gup...@codeaurora.org wrote:
On 2020-05-22 14:54, Robin Murphy wrote:
On 2020-05-22 07:25, gup...@codeaurora.org wrote:
On 2020-05-22 01:46, Robin Murphy wrote:
On 2020-05-21 12:30, Prakash Gupta wrote:
I agree, we shouldn't be freeing the partial iova. Instead
the offending driver more
difficult. Let's simply WARN and otherwise ignore bogus PFNs.
Reported-by: Prakash Gupta
Signed-off-by: Robin Murphy
---
drivers/iommu/iova.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 0
On 2020-06-02 07:32, Bjorn Andersson wrote:
On Wed 27 May 04:03 PDT 2020, Will Deacon wrote:
Hi John, Bjorn,
On Tue, May 26, 2020 at 01:34:45PM -0700, John Stultz wrote:
On Thu, May 14, 2020 at 12:34 PM wrote:
On Thu 27 Feb 18:57 PST 2020, Bjorn Andersson wrote:
Rob, Will, we're reaching
On 2020-06-08 10:13, Sai Prakash Ranjan wrote:
Hi Will,
On 2020-06-08 13:48, Will Deacon wrote:
On Sun, Jun 07, 2020 at 04:39:18PM +0530, Sai Prakash Ranjan wrote:
Remove SMMU shutdown callback since it seems to cause more
problems than benefits. With this callback, we need to make
sure that a
On 2020-06-08 09:52, Geert Uytterhoeven wrote:
On systems with at least 32 MiB, but less than 32 GiB of RAM, the DMA
memory pools are much larger than intended (e.g. 2 MiB instead of 128
KiB on a 256 MiB system).
Fix this by correcting the calculation of the number of GiBs of RAM in
the system.
On 2020-06-08 13:25, Geert Uytterhoeven wrote:
Hi Robin,
On Mon, Jun 8, 2020 at 2:04 PM Robin Murphy wrote:
On 2020-06-08 09:52, Geert Uytterhoeven wrote:
On systems with at least 32 MiB, but less than 32 GiB of RAM, the DMA
memory pools are much larger than intended (e.g. 2 MiB instead of
On 2020-06-10 10:27, gup...@codeaurora.org wrote:
On 2020-06-02 18:38, Robin Murphy wrote:
Unlike the other instances which represent a complete loss of
consistency within the rcache mechanism itself, or a fundamental
and obvious misconfiguration by an IOMMU driver, the BUG_ON() in
Hi Jim,
Thanks for taking this on!
On 2020-06-16 21:55, Jim Quinlan wrote:
The new field in struct device 'dma_pfn_offset_map' is used to facilitate
the use of single or multiple pfn offsets between cpu addrs and dma addrs.
It subsumes the role of dev->dma_pfn_offset -- a uniform offset.
This
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:
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/283752.h
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
--- a/drivers/iom
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 val
U DMA 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
Hopefully it's now stable enough that I can finish cleaning up my
hacked-up SMMU driver (oh, th
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
---
drivers/iommu/intel-iommu.c | 33 ++---
drivers/iommu/iova.c
ries for that[2], 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 al
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
---
drivers/iommu/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/Makefile b/drivers/iommu/Makefile
index 16edef7..9f7910b 100644
--- a
description of alloc_iova since we're
touching it anyway.
Signed-off-by: Robin Murphy
---
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 a/drivers/iommu/
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
---
Hi Joerg,
I noticed this whilst wiring up DMA mapping to this new API - on arm64
we anticipate running 4k IOMMU pages
Hi,
On 26/11/14 06:58, leizhen wrote:
On 2014/11/26 1:27, Robin Murphy wrote:
In preparation for sharing the IOVA allocator, build it for all
IOMMU API users.
Signed-off-by: Robin Murphy
---
drivers/iommu/Makefile | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a
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 *iov
master (EHCI) being probed, 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 Mur
sage-Id:
From: Robin Murphy
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, move the DT-probed IOMMU ops to a private list
where they will be safe
Hi Thierry,
On 04/12/14 14:49, Thierry Reding wrote:
On Thu, Dec 04, 2014 at 01:43:32PM +, Robin Murphy wrote:
Hi Grant, thanks for the advice - silly micro-optimisations removed, and
I'll make a note to do so from my in-development code, too ;)
I didn't much like the casting
t quickly got
too invasive and out of scope 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.
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 c
: Arnd Bergmann
Acked-by: Marek Szyprowski
Tested-by: Robin Murphy
Signed-off-by: Will Deacon
---
arch/arm/include/asm/dma-mapping.h | 4 +++-
drivers/of/platform.c | 21 ++---
include/linux/dma-mapping.h| 8 +++-
3 files changed, 24 insertions(+), 9
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 dev
ess, clean up
a bit by replacing the bare constants with slightly more meaningful
macros and removing the superfluous "else" statements.
Signed-off-by: Robin Murphy
---
Hi, various maintainers from Git logs ;)
This one's a bit tricky to find a home for - I think technically it&#
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 unti
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
In preparation for sharing the IOVA allocator, split it out under its
own Kconfig symbol.
Signed-off-by: Robin Murphy
---
drivers/iommu/Kconfig | 4
drivers/iommu/Makefile | 3 ++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
1: Use a proper 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 indepe
description of alloc_iova since we're
touching it anyway.
Signed-off-by: Robin Murphy
---
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 a/drivers/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 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
---
drivers/iommu/intel-iommu.c | 33 ++---
drivers/iommu/iova.c
k to become truly generic.
[1]:http://thread.gmane.org/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_
From: Catalin Marinas
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
---
arch/arm64/include/asm/dma-mapping.h | 11 +
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
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/dma-mapping.h | 10 +-
arch/arm64/mm/dma-mapping.c | 22
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
---
include/linux/dma-iommu.h | 78
lib/Kconfig | 8 +
lib/Makefile | 1 +
lib/dma-iommu.c
Add the necessary call to of_iommu_init.
Signed-off-by: Robin Murphy
---
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/arch/arm64/kernel
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
---
arch/arm64/include/asm/device.h | 3 +
arch/arm64/include/asm/dma-mapping.h | 12 ++
arch/arm64/mm/dma-mapping.c
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 mod
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 implement
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 implement
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 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
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 for
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
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: M
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 ma
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
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 14:30, Will Deacon wrote:
On Tue, Jan 27, 2015 at 12:08:56AM +, Joerg Roedel wrote:
From: Joerg Roedel
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
---
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_m
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
---
arch/arm64/include/asm/device.h | 3 +
arch/arm64/include/asm/dma-mapping.h | 17 ++
arch/arm64/mm/dma-mapping.c
nux.kernel.iommu/8213
[2]:http://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 |
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
---
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/dma-mapping.h | 11 ++-
arch/arm64/mm/dma-mapping.c
common code are addressed we can complete the
refactoring by porting arch/arm over for a merge-worthy series.
Signed-off-by: Robin Murphy
---
drivers/iommu/Kconfig | 7 +
drivers/iommu/Makefile| 1 +
drivers/iommu/dma-iommu.c | 552 ++
include
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
d
On 10/02/15 04:39, Yingjoe Chen wrote:
On Fri, 2015-02-06 at 14:55 +, Robin Murphy wrote
<...>
diff --git a/arch/arm64/include/asm/dma-mapping.h
b/arch/arm64/include/asm/dma-mapping.h
index 6932bb5..c1b271f 100644
--- a/arch/arm64/include/asm/dma-mapping.h
+++ b/arch/arm64/include/a
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 the
On 09/02/15 06:02, Will Deacon wrote:
On Fri, Feb 06, 2015 at 02:55:14PM +, 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.
Is anybody looking at porting arch/arm/ over to this?
If
On 14/02/15 08:03, Yong Wu wrote:
On Tue, 2015-02-10 at 12:07 +, Robin Murphy wrote:
On 10/02/15 04:39, Yingjoe Chen wrote:
On Fri, 2015-02-06 at 14:55 +, Robin Murphy wrote
<...>
diff --git a/arch/arm64/include/asm/dma-mapping.h
b/arch/arm64/include/asm/dma-mapping.h
index 6
On 03/03/15 03:38, Yong Wu wrote:
On Mon, 2015-02-16 at 20:04 +, Robin Murphy wrote:
2)int (*domain_init)(struct iommu_domain *domain);
About this function, it will alloc pagetable for the iommu
domain. And We expect the pagetable memory is uncacheable, so try to
call
On 03/03/15 11:05, leizhen wrote:
On 2015/2/6 22:55, Robin Murphy wrote:
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
---
arch/arm64/Kconfig | 1 +
arch/arm64
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 ou
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 th
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 arc
On 05/03/15 17:28, Mitchel Humpherys wrote:
On Thu, Mar 05 2015 at 02:38:45 AM, Robin Murphy 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 dma_unmap_page on the ret
outside the default 32-bit mask.
Signed-off-by: Robin Murphy
---
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/arm-smmu.c
@@ -1630,6
Hi Russell,
On 09/03/15 17:59, Russell King - ARM Linux wrote:
[...]
For a noncoherent device, dma_map_single() will end up calling
__dma_map_area() with the page offset and size of the original request, so
the updated part gets flushed by VA, and the rest of the page isn't touched
if it doesn'
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
On 18/03/15 11:22, Yong Wu wrote:
Hi Tomasz,
Thanks very much for your review. please help check below.
The others I will fix in the next version.
Hi Robin,
There are some place I would like you can have a look and give me
some suggestion.
On Wed, 2015-03-11 at 19:53 +0900, Tomasz Figa
Hi Joerg,
On 31/03/15 15:24, Joerg Roedel wrote:
Hi Will,
On Fri, Mar 27, 2015 at 05:19:46PM +, Will Deacon wrote:
Please can you pull the following IOMMU changes for 4.1? They move the
per-iommu_ops pgsize_bitmap field into the iommu_domain, which allows
IOMMUs such as the ARM SMMU to sup
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
On 15/08/2019 14:57, Will Deacon wrote:
Hi Robin,
On Thu, Aug 15, 2019 at 01:43:11PM +0100, Robin Murphy wrote:
On 14/08/2019 18:56, Will Deacon wrote:
Commit b6b65ca20bc9 ("iommu/io-pgtable-arm: Add support for non-strict
mode") added an unconditional call to io_pgtabl
The less said about "~12UL" the better. Oh dear.
We get away with it due to calling constraints that mean IOVAs are
implicitly at least page-aligned to begin with, but still; oh dear.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu.c | 2 +-
1 file changed, 1 insertion(+),
. The (new) patches #1 and #2 are up front as conceptual fixes,
although they're not actually critical - it turns out to be more of an
embarrassment than a real problem in practice.
For ease of reference, the overall diff against v1 is attached below.
Robin.
Robin Murphy (17):
iommu/arm-
FIELD_PREP remains a terrible name, but the overall simplification will
make further work on this stuff that much more manageable. This also
serves as an audit of the header, wherein we can impose a consistent
grouping and ordering of the offset and field definitions
Signed-off-by: Robin Murphy
601 - 700 of 3517 matches
Mail list logo
