day 03 May 2017 15:54:59 Sricharan R wrote:
>>>>> On 5/3/2017 3:24 PM, Robin Murphy wrote:
>>>>>> On 02/05/17 19:35, Geert Uytterhoeven wrote:
>>>>>>> On Fri, Feb 3, 2017 at 4:48 PM, Sricharan R wrote:
>>>>>>>> From: Lau
On 16/05/17 15:10, Laurent Pinchart wrote:
> Hi Robin,
>
> On Tuesday 16 May 2017 15:04:55 Robin Murphy wrote:
>> On 16/05/17 08:17, Laurent Pinchart wrote:
>>> On Tuesday 16 May 2017 07:53:57 sricha...@codeaurora.org wrote:
>
> [snip]
>
>>>>
, NULL);
Should we clear dma_ops_setup here for symmetry? I guess in practice
it's down to the IOMMU driver so will never change after the first
probe, but it still feels like a bit of a nagging loose end.
With that (or firm reassurance that it's OK not to),
Reviewed-by: Rob
x27;t agree with the two-drivers-in-one approach.
Robin.
->8-
From: Robin Murphy
Subject: [PATCH] iommu/ipmmu-vmsa: Convert to iommu_fwspec
The parent IPMMU pointer and set of uTLB IDs are, as intended, a perfect
fit for the generic iommu_fwspec. Get rid of the architecture-specific
archdat
On 17/05/17 13:36, Joerg Roedel wrote:
> On Mon, May 15, 2017 at 04:01:30PM +0100, Robin Murphy wrote:
>> When __iommu_dma_map() and iommu_dma_free_iova() are called from
>> iommu_dma_get_msi_page(), various iova_*() helpers are still invoked in
>> the process, whcih is unwis
On 22/05/17 09:55, vji...@codeaurora.org wrote:
> From: Vijayanand Jitta
>
> There are TLBSTATUS registers in SMMU global register space as well as
> context bank register space. Currently we're polling the global
> TLBSTATUS registers after TLB invalidation, even when using the TLB
> invalidati
socki
CC: Robert Moore
CC: Lv Zheng
Acked-by: Robert Richter
Tested-by: Robert Richter
Signed-off-by: Robin Murphy
---
v2: Update more comments, add Robert's tags.
I'm including this here as a kernel patch just for context - once I've
figured out how we actually submit patche
mitigating sychronisation problems with
the ACPICA headers, we'll carry a backup copy of the new definitions
locally for the short term to make life simpler.
CC: sta...@vger.kernel.org # 4.10
Acked-by: Robert Richter
Tested-by: Robert Richter
Signed-off-by: Robin Murphy
---
v2: Add local b
On 23/05/17 17:25, Russell King - ARM Linux wrote:
> On Thu, Oct 27, 2016 at 09:07:23AM +0530, Sricharan wrote:
>> Hi Robin,
>>
>>> -Original Message-
>>> From: Robin Murphy [mailto:robin.mur...@arm.com]
>>> Sent: Wednesday, October 26, 2
On 25/05/17 18:33, Rob Clark wrote:
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Rob Clark
> Reviewed-by: Rob Herring
> ---
> .../devicetree/bindings/iommu/qcom,iommu.txt | 121
> +
> 1 file changed, 121 insertions(+)
> create mode 100644 Documentation/devicetree
On 25/05/17 18:33, Rob Clark wrote:
> An iommu driver for Qualcomm "B" family devices which do not completely
> implement the ARM SMMU spec. These devices have context-bank register
> layout that is similar to ARM SMMU, but no global register space (or at
> least not one that is accessible).
I st
neric IOVA allocator")
Signed-off-by: Robin Murphy
---
Just something I spotted whilst comparing dma_map_page() callchains...
drivers/iommu/amd_iommu.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/iommu/amd_iommu.c b/drivers/iommu/amd_iommu.c
index 63cacf5d6cf2..489dc3028
On 30/05/17 17:49, Ray Jui wrote:
> Hi Will,
>
> On 5/30/17 8:14 AM, Will Deacon wrote:
>> On Mon, May 29, 2017 at 06:18:45PM -0700, Ray Jui wrote:
>>> I'm writing to check with you to see if the latest arm-smmu.c driver in
>>> v4.12-rc Linux for smmu-500 can support mapping that is only specific
On 30/05/17 10:48, Joerg Roedel wrote:
> On Fri, May 26, 2017 at 07:31:26PM +0100, Robin Murphy wrote:
>> Unlike the old allocator, alloc_iova_fast() will return 0 if it failed
>> to allocate a PFN. Since the callers of dma_ops_alloc_iova() would end
>> up treating th
On 30/05/17 10:12, Joerg Roedel wrote:
> On Mon, May 22, 2017 at 04:06:37PM +0100, Robin Murphy wrote:
>> IORT revision C has been published with a number of new SMMU
>> implementation identifiers. Since IORT doesn't have any way of falling
>> back to a more generic
, not just whichever one comes out last.
Happily, this also makes things tidy enough that we can reduce the
number of both total lines of code, and confusing levels of indirection,
by pulling the "iommus"/"iommu-map" parsing helpers back in-line again.
Signed-off-by: Robin Murphy
-
Hi Ray,
On 05/06/17 19:03, Ray Jui wrote:
> Hi Will/Robin,
>
> Just want to check with you on this again. Do you have a very rough
> timeline on when the excessive locking in the IOMMU driver may be fixed
> (so we can restore expected up to 95% performance)?
I've currently got some experimental
, not least to make it less obtuse.
Signed-off-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm-v7s.c | 85 --
1 file changed, 45 insertions(+), 40 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s.c
b/drivers/iommu/io-pgtable-arm-v7s.c
index a490db0
ed itself.
The branch I've previously shared has been updated too:
git://linux-arm.org/linux-rm iommu/pgtable
All feedback welcome, as I'd really like to land this for 4.13.
Robin.
Robin Murphy (8):
iommu/io-pgtable-arm-v7s: Check table PTEs more precisely
iommu/io-pgtable-arm
block/page entries, then repeat by
unmapping at the next level if necessary. With a little refactoring of
some helper functions, the code ends up not much bigger than before, but
considerably easier to follow and to adapt in future.
Signed-off-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm.c
Whilst we don't support the PXN bit at all, so should never encounter a
level 1 section or supersection PTE with it set, it would still be wise
to check both table type bits to resolve any theoretical ambiguity.
Signed-off-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm-v7s.c | 3 ++-
1
As for SMMUv2, take advantage of io-pgtable's newfound tolerance for
concurrency. Unfortunately in this case the command queue lock remains a
point of serialisation for the unmap path, but there may be a little
more we can do to ameliorate that in future.
Signed-off-by: Robin Murphy
---
dr
where we are stirivng
to minimise latency by removing the locking in the first place.
To that end, let's introduce an explicit notion of cache-coherency to
io-pgtable, such that we will be able to avoid penalising IOMMUs which
know enough to know when they are coherent.
Signed-off-by: Robin M
deterministic results.
We do however still have to keep a lock around to serialise the ATS1*
translation ops, as parallel iova_to_phys() calls could lead to
unpredictable hardware behaviour otherwise.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu.c | 45
isbehaving callers making nonsensical
overlapping requests might lead to crashes instead of just unpredictable
results, but correct code really does not deserve to pay a significant
performance cost for the sake of masking bugs in theoretical broken code.
Signed-off-by: Robin Murphy
---
drivers/iommu/
g
lock; we just pull said lock down into the bowels of the implementation
so it's well out of the way of the normal call paths.
Signed-off-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm-v7s.c | 78 --
1 file changed, 58 insertions(+), 20 deletions(-
On 07/06/17 10:47, Tomasz Figa wrote:
> Hi Yong,
>
> +Robin, Joerg, IOMMU ML
>
> Please see my comments inline.
>
> On Tue, Jun 6, 2017 at 5:39 AM, Yong Zhi wrote:
>> IPU3 mmu based DMA mapping driver
>>
>> Signed-off-by: Yong Zhi
>> ---
>> drivers/media/pci/intel/ipu3/Kconfig | 6 +
>
Hi Christoph,
On 08/06/17 14:25, Christoph Hellwig wrote:
> DMA_ERROR_CODE is not a public API and will go away soon. dma dma-iommu
> driver already implements a proper ->mapping_error method, so it's only
> using the value internally. Add a new local define using the value
> that arm64 which is
On 08/06/17 14:25, Christoph Hellwig wrote:
> The dma alloc interface returns an error by return NULL, and the
> mapping interfaces rely on the mapping_error method, which the dummy
> ops already implement correctly.
>
> Thus remove the DMA_ERROR_CODE define.
Reviewed-by: Robin Mu
On 08/06/17 18:13, Rafael J. Wysocki wrote:
> On Thu, Jun 8, 2017 at 6:32 PM, Lorenzo Pieralisi
> wrote:
>> On Tue, May 30, 2017 at 05:33:38PM +0530, Geetha sowjanya wrote:
>>> Cavium ThunderX2 SMMUv3 implementation has two Silicon Erratas.
>>> 1. Errata ID #74
>>>SMMU register alias Page 1 is
On 08/06/17 15:35, Tomasz Figa wrote:
> On Thu, Jun 8, 2017 at 10:22 PM, Robin Murphy wrote:
>> On 07/06/17 10:47, Tomasz Figa wrote:
>>> Hi Yong,
>>>
>>> +Robin, Joerg, IOMMU ML
>>>
>>> Please see my comments inline.
>>&g
On 30/05/17 13:03, Geetha sowjanya wrote:
> From: Linu Cherian
>
> Cavium ThunderX2 SMMU implementation doesn't support page 1 register space
> and PAGE0_REGS_ONLY option is enabled as an errata workaround.
> This option when turned on, replaces all page 1 offsets used for
> EVTQ_PROD/CONS, PRIQ_
On 09/06/17 07:20, Tomasz Figa wrote:
> On Fri, Jun 9, 2017 at 3:07 AM, Robin Murphy wrote:
>> On 08/06/17 15:35, Tomasz Figa wrote:
>>> On Thu, Jun 8, 2017 at 10:22 PM, Robin Murphy wrote:
>>>> On 07/06/17 10:47, Tomasz Figa wrote:
>>>>>
On 09/06/17 12:38, Jayachandran C wrote:
> On Fri, Jun 09, 2017 Robin Murphy wrote:
>>
>> On 30/05/17 13:03, Geetha sowjanya wrote:
>>> From: Linu Cherian
>>>
>>> Cavium ThunderX2 SMMU implementation doesn't support page 1 register space
>>
context. The rest is just proactively
blatting address arguments with "arbitrary definitely-invalid value",
which is more paranoia than anything else (and arguably unnecessary).
It's not the biggest deal, though, so either way:
Reviewed-by: Robin Murphy
> Signed-off-by: Christoph
of backports and mitigating sychronisation problems with
the ACPICA headers, we'll carry a backup copy of the new definitions
locally for the short term to make life simpler.
CC: sta...@vger.kernel.org # 4.10
Acked-by: Robert Richter
Tested-by: Robert Richter
Signed-off-by: Robin Murphy
--
if
it does actually work as intended, feel free to take it ;)
Thanks,
Robin.
> Suggested-by: Robin Murphy (Patch 2 and 4)
> Signed-off-by: Robin Murphy (Patch 3)
> Signed-off-by: Magnus Damm
> ---
>
> Developed on renesas-drivers-2017-06-13-v4.12-rc5 and rebased to
&
On 15/06/17 11:29, Magnus Damm wrote:
> From: Magnus Damm
>
> Extend the driver to make use of iommu_device_register()/unregister()
> functions together with iommu_device_set_ops() and iommu_set_fwnode().
>
> These used to be part of the earlier posted 64-bit ARM (r8a7795) series but
> it turns
On 19/06/17 10:14, Magnus Damm wrote:
> From: Magnus Damm
>
> Add root device handling to the IPMMU driver by allowing certain
> DT compat strings to enable has_cache_leaf_nodes that in turn will
> support both root devices with interrupts and leaf devices that
> face the actual IPMMU consumer de
On 19/06/17 16:45, shameer wrote:
> The HiSilicon erratum 161010801 describes the limitation of HiSilicon
> platforms Hip06/Hip07 to support the SMMU mappings for MSI transactions.
>
> On these platforms GICv3 ITS translator is presented with the deviceID
> by extending the MSI payload data to 64
On 08/06/17 05:44, Ganapatrao Kulkarni wrote:
> ARM IORT specification (rev. C) has added two new fields to define
> proximity domain for the SMMUv3 node in the IORT table.
>
> Proximity Domain Valid:
> Set to 1 if the value provided in the Proximity Domain field is
> valid. Set to 0 o
On 20/06/17 12:04, Zhen Lei wrote:
> This function is protected by spinlock, and the latter will do memory
> barrier implicitly. So that we can safely use writel_relaxed. In fact, the
> dmb operation will lengthen the time protected by lock, which indirectly
> increase the locking confliction in th
Hi Christoph,
On 20/06/17 13:41, Christoph Hellwig wrote:
> On Fri, Jun 16, 2017 at 08:10:15PM +0200, Christoph Hellwig wrote:
>> I plan to create a new dma-mapping tree to collect all this work.
>> Any volunteers for co-maintainers, especially from the iommu gang?
>
> Ok, I've created the new tr
x27;ve ever actually seen that happen is if
TLBSYNC is issued while a context fault is pending - on MMU-500 it seems
that the sync just doesn't proceed until the fault is cleared - but that
stemmed from interrupts not being wired up correctly (on FPGAs) such
that we never saw the fault reported i
On 20/06/17 15:07, Shameerali Kolothum Thodi wrote:
>
>
>> -Original Message-
>> From: Lorenzo Pieralisi [mailto:lorenzo.pieral...@arm.com]
>> Sent: Tuesday, June 20, 2017 11:29 AM
>> To: Shameerali Kolothum Thodi
>> Cc: marc.zyng...@arm.com; sudeep.ho...@arm.com; will.dea...@arm.com;
>>
On 20/06/17 16:51, Lorenzo Pieralisi wrote:
> On Tue, Jun 20, 2017 at 04:16:18PM +0100, Robin Murphy wrote:
>> On 20/06/17 15:07, Shameerali Kolothum Thodi wrote:
>>>
>>>
>>>> -Original Message-
>>>> From: Lorenzo Pieralisi [mailto:lor
Whilst we don't support the PXN bit at all, so should never encounter a
level 1 section or supersection PTE with it set, it would still be wise
to check both table type bits to resolve any theoretical ambiguity.
Signed-off-by: Robin Murphy
---
v2: No change
drivers/iommu/io-pgtable-arm-
The feedback has been promising, so v2 is just a final update to cover
a handful of memory ordering and cosmetic tweaks that came up when Will
and I went through this offline.
Thanks,
Robin.
Robin Murphy (8):
iommu/io-pgtable-arm-v7s: Check table PTEs more precisely
iommu/io-pgtable-arm
block/page entries, then repeat by
unmapping at the next level if necessary. With a little refactoring of
some helper functions, the code ends up not much bigger than before, but
considerably easier to follow and to adapt in future.
Signed-off-by: Robin Murphy
---
v2: Make the address increment in
, not least to make it less obtuse.
Signed-off-by: Robin Murphy
---
v2: One trivial cosmetic tweak to the loop increment
drivers/iommu/io-pgtable-arm-v7s.c | 85 --
1 file changed, 45 insertions(+), 40 deletions(-)
diff --git a/drivers/iommu/io-pgtable-arm-v7s
isbehaving callers making nonsensical
overlapping requests might lead to crashes instead of just unpredictable
results, but correct code really does not deserve to pay a significant
performance cost for the sake of masking bugs in theoretical broken code.
Signed-off-by: Robin Murphy
---
v2:
- Fix b
where we are stirivng
to minimise latency by removing the locking in the first place.
To that end, let's introduce an explicit notion of cache-coherency to
io-pgtable, such that we will be able to avoid penalising IOMMUs which
know enough to know when they are coherent.
Signed-off-by: Robin M
g
lock; we just pull said lock down into the bowels of the implementation
so it's well out of the way of the normal call paths.
Signed-off-by: Robin Murphy
---
v2:
- Fix barriers in install_table
- Use READ_ONCE() in iova_to_phys just in case
drivers/iommu/io-pgtable
deterministic results.
We do however still have to keep a lock around to serialise the ATS1*
translation ops, as parallel iova_to_phys() calls could lead to
unpredictable hardware behaviour otherwise.
Signed-off-by: Robin Murphy
---
v2: No change
drivers/iommu/arm-smmu.c | 45
As for SMMUv2, take advantage of io-pgtable's newfound tolerance for
concurrency. Unfortunately in this case the command queue lock remains a
point of serialisation for the unmap path, but there may be a little
more we can do to ameliorate that in future.
Signed-off-by: Robin Murphy
---
v
On 23/06/17 09:47, John Garry wrote:
> On 22/06/2017 16:53, Robin Murphy wrote:
>> The feedback has been promising, so v2 is just a final update to cover
>> a handful of memory ordering and cosmetic tweaks that came up when Will
>> and I went through this offline.
>>
&
On 23/06/17 09:56, Linu Cherian wrote:
> On Fri Jun 23, 2017 at 11:23:26AM +0530, Linu Cherian wrote:
>>
>> Robin,
>> Was trying to understand the new changes. Had few questions on
>> arm_lpae_install_table.
>>
>> On Thu Jun 22, 2017 at 04:53:54PM +0100, R
On 26/06/17 12:35, John Garry wrote:
> On 23/06/2017 10:58, Robin Murphy wrote:
>> On 23/06/17 09:47, John Garry wrote:
>>> On 22/06/2017 16:53, Robin Murphy wrote:
>>>> The feedback has been promising, so v2 is just a final update to cover
>>>> a hand
On 27/06/17 08:28, Tomasz Figa wrote:
> Current implementation of __iommu_dma_alloc_pages() keeps adding
> __GFP_HIGHMEM to GFP flags regardless of whether other zone flags are
> already included in the incoming flags. If __GFP_DMA or __GFP_DMA32 is
> set at the same time as __GFP_HIGHMEM, the allo
t;
> Fix it by adding __GFP_NOWARN only to high order allocation attempts,
> which are not critical.
Makes sense to me.
Reviewed-by: Robin Murphy
> Signed-off-by: Tomasz Figa
> ---
> drivers/iommu/dma-iommu.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
>
On 27/06/17 12:17, Tomasz Figa wrote:
> On Tue, Jun 27, 2017 at 8:01 PM, Robin Murphy wrote:
>> On 27/06/17 08:28, Tomasz Figa wrote:
>>> Current implementation of __iommu_dma_alloc_pages() keeps adding
>>> __GFP_HIGHMEM to GFP flags regardless of whether other zone fla
On 27/06/17 13:44, Tomasz Figa wrote:
> On Tue, Jun 27, 2017 at 9:26 PM, Robin Murphy wrote:
>> On 27/06/17 12:17, Tomasz Figa wrote:
>>> On Tue, Jun 27, 2017 at 8:01 PM, Robin Murphy wrote:
>>>> On 27/06/17 08:28, Tomasz Figa wrote:
>>>>> Curr
ks to sanitise our inputs so that buggy callers
don't invite potential memory corruption.
Signed-off-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm-v7s.c | 6 ++
drivers/iommu/io-pgtable-arm.c | 7 +++
2 files changed, 13 insertions(+)
diff --git a/drivers/iommu/io-pgtable-ar
On 05/07/17 08:12, Tomasz Figa wrote:
> There is nothing wrong in having a loadable module implementing DMA API,
> for example to be used for sub-devices registered by the module. However,
> most of the functions from dma-iommu do not have their symbols exported,
> making it impossible to use them
On 06/07/17 03:25, Tomasz Figa wrote:
> On Thu, Jul 6, 2017 at 1:22 AM, Robin Murphy wrote:
>> On 05/07/17 08:12, Tomasz Figa wrote:
>>> There is nothing wrong in having a loadable module implementing DMA API,
>>> for example to be used for sub-devices registered by th
user actually relying on this flag for correctness,
let's reimplement it locally to avoid the headache of trying to make the
high-level version concurrency-safe for other users.
CC: Yong Wu
CC: Matthias Brugger
Signed-off-by: Robin Murphy
---
drivers/iommu/mtk_iommu.c | 6 ++
dri
n for
the sake of slightly helping one case which will virtually never happen
in typical usage), let's just retire it.
This reverts commit 88492a4700360a086e55d8874ad786105a5e8b0f.
Signed-off-by: Robin Murphy
---
drivers/iommu/io-pgtable.h | 9 +
1 file changed, 1 insertion(+), 8
On 07/07/17 14:30, Mark Rutland wrote:
> On Fri, Jul 07, 2017 at 12:39:58PM +0530, Srinath Mannam wrote:
>> This patch adds info about optional DT properties
>> iommu-map-drop-mask and msi-map-drop-mask.
>>
>> A drop mask represents the bits which will be
>> removed/dropped by system from Requester
On 07/07/17 16:22, Scott Branden wrote:
> Hi Robin,
>
> On 17-07-07 07:55 AM, Robin Murphy wrote:
>> On 07/07/17 14:30, Mark Rutland wrote:
[...]
>>> Your mapping can be expressed today using a number of msi-map entries,
>>> which you can easily generate pro
On 10/07/17 20:23, Bjorn Helgaas via iommu wrote:
> [+cc Joerg, iommu]
>
> On Fri, Jun 30, 2017 at 12:24 AM, Alexey Kardashevskiy wrote:
>> From: Yongji Xie
>>
>> Some iommu drivers would be initialized after PCI device
>> enumeration. So PCI_BUS_FLAGS_MSI_REMAP would not be set
>> when probing
On 12/07/17 08:11, Federico Vaga wrote:
> Hello,
>
> kernel version 4.4.x
>
> I'm facing an issue with the INTEL IOMMU driver and DMA mapping. I have an
> Ethernet driver that uses `dma_alloc_coherent()` to allocate and map some
> memory for DMA transfers.
Assuming 02:00.0 is your actual endpo
On 12/07/17 18:20, Federico Vaga wrote:
> On Wednesday, July 12, 2017 2:15:34 PM CEST Federico Vaga wrote:
>> Thank you Robin
>>
>> (inline comments)
>>
>> On Wednesday, July 12, 2017 1:10:51 PM CEST Robin Murphy wrote:
>>> On 12/07/17 08:11, Federic
On 13/07/17 07:48, Stephen Boyd wrote:
> On 07/13, Vivek Gautam wrote:
>> Hi Stephen,
>>
>>
>> On 07/13/2017 04:24 AM, Stephen Boyd wrote:
>>> On 07/06, Vivek Gautam wrote:
@@ -1231,12 +1237,18 @@ static int arm_smmu_map(struct iommu_domain
*domain, unsigned long iova,
static size_
Echoing what we do for Stream Map Entries, maintain a software shadow
state for context bank configuration. With this in place, we are mere
moments away from blissfully easy suspend/resume support.
Signed-off-by: Robin Murphy
---
Since the runtime PM discussion has come back again, I figured it
With all our hardware state tracked in such a way that we can naturally
restore it as part of the necessary reset, resuming is trivial, and
there's nothing to do on suspend at all.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu.c | 12
1 file changed, 12 insertions(+)
ather
less invasive manner.
Robin.
[1] https://www.mail-archive.com/iommu@lists.linux-foundation.org/msg17753.html
Robin Murphy (1):
iommu/iova: Extend rbtree node caching
Zhen Lei (3):
iommu/iova: Optimise rbtree searching
iommu/iova: Optimise the padding calculation
iommu/iova: Make dma
one
further with a little tweak of the ordering (which makes the intent of
the code that much cleaner as a bonus).
Signed-off-by: Zhen Lei
[rm: rewrote commit message to clarify]
Signed-off-by: Robin Murphy
---
drivers/iommu/iova.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions
32-bit PFN, when
init_iova_domain() can happily do that itself from the page granularity.
CC: Thierry Reding
CC: Jonathan Hunter
CC: David Airlie
CC: Sudeep Dutt
CC: Ashutosh Dixit
Signed-off-by: Zhen Lei
[rm: use iova_pfn(), rewrote commit message]
Signed-off-by: Robin Murphy
---
drive
-off-by: Robin Murphy
---
drivers/iommu/iova.c | 59 +---
include/linux/iova.h | 3 ++-
2 files changed, 30 insertions(+), 32 deletions(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index d094d1ca8f23..f5809a2ee6c2 100644
--- a
around, we can just
combine the upper limit, size, and mask directly to check against the
lower limit.
For an arm64 build, this alone knocks 16% off the size of the entire
alloc_iova() function!
Signed-off-by: Zhen Lei
[rm: simplified more of the arithmetic, rewrote commit message]
Signed-
On 19/07/17 03:40, Sricharan R wrote:
> Hi Robin,
>
> On 7/18/2017 6:14 PM, Robin Murphy wrote:
>> Echoing what we do for Stream Map Entries, maintain a software shadow
>> state for context bank configuration. With this in place, we are mere
>> moments away from bli
On 19/07/17 09:37, Ard Biesheuvel wrote:
> On 18 July 2017 at 17:57, Robin Murphy wrote:
>> Hi all,
>>
>> In the wake of the ARM SMMU optimisation efforts, it seems that certain
>> workloads (e.g. storage I/O with large scatterlists) probably remain quite
>> heav
On 19/07/17 10:33, Anup Patel wrote:
> This patchset primarily adds Broadcom FlexRM reset module for
> VFIO platform driver. We also have minor improvments in IOMMU
> and VFIO driver to allow VFIO no-IOMMU mode access to FlexRM.
I'm struggling to understand the IOMMU changes here - what's the
Flex
On 19/07/17 10:33, Anup Patel wrote:
> Some of the IOMMUs (such as ARM SMMU) are capable of bypassing
> transactions for which no IOMMU domain is configured.
>
> This patch adds IOMMU_CAP_BYPASS which can be used by IOMMU
> drivers to advertise transation bypass capability of an IOMMU.
Whatever t
On 19/07/17 10:33, Anup Patel wrote:
> The ARM SMMUv1 and SMMUv2 support bypassing transactions for
> which domain is not configured. The patch adds corresponding
> IOMMU capability to advertise this fact.
>
> Signed-off-by: Anup Patel
> ---
> drivers/iommu/arm-smmu.c | 2 ++
> 1 file changed, 2
On 19/07/17 10:33, Anup Patel wrote:
> The ARM SMMUv3 support bypassing transactions for which domain
> is not configured. The patch adds corresponding IOMMU capability
> to advertise this fact.
>
> Signed-off-by: Anup Patel
> ---
> drivers/iommu/arm-smmu-v3.c | 2 ++
> 1 file changed, 2 inserti
On 19/07/17 12:17, Anup Patel wrote:
> On Wed, Jul 19, 2017 at 4:27 PM, Robin Murphy wrote:
>> On 19/07/17 10:33, Anup Patel wrote:
>>> This patchset primarily adds Broadcom FlexRM reset module for
>>> VFIO platform driver. We also have minor improvments in IOMMU
>&g
On 19/07/17 12:26, Anup Patel wrote:
> On Wed, Jul 19, 2017 at 4:53 PM, Will Deacon wrote:
>> On Wed, Jul 19, 2017 at 04:49:00PM +0530, Anup Patel wrote:
>>> On Wed, Jul 19, 2017 at 4:28 PM, Robin Murphy wrote:
>>>> On 19/07/17 10:33, Anup Patel wrote:
>>>
On 19/07/17 04:12, Yong Zhi wrote:
> From: Tomasz Figa
>
> This driver translates Intel IPU3 internal virtual
> address to physical address.
>
> Signed-off-by: Tomasz Figa
> Signed-off-by: Yong Zhi
> ---
> drivers/media/pci/intel/ipu3/Kconfig| 9 +
> drivers/media/pci/intel/ipu3/Makefil
On 19/07/17 04:12, Yong Zhi wrote:
> From: Tomasz Figa
>
> This patch adds support for the IPU3 DMA mapping API.
>
> Signed-off-by: Tomasz Figa
> Signed-off-by: Yong Zhi
> ---
> drivers/media/pci/intel/ipu3/Kconfig | 8 +
> drivers/media/pci/intel/ipu3/Makefile | 2 +-
> driver
On 20/07/17 10:10, Will Deacon wrote:
> On Thu, Jul 20, 2017 at 09:32:00AM +0530, Anup Patel wrote:
>> On Wed, Jul 19, 2017 at 5:23 PM, Will Deacon wrote:
>>> There are two things here:
>>>
>>> 1. iommu_present() is pretty useless, because it applies to a "bus" which
>>> doesn't actually te
On 19/07/17 11:48, Shameerali Kolothum Thodi wrote:
>
>
>> -Original Message-
>> From: Will Deacon [mailto:will.dea...@arm.com]
>> Sent: Friday, July 14, 2017 8:33 PM
>> To: Shameerali Kolothum Thodi
>> Cc: lorenzo.pieral...@arm.com; marc.zyng...@arm.com;
>> sudeep.ho...@arm.com; robin.mu
one
further with a little tweak of the ordering (which makes the intent of
the code that much cleaner as a bonus).
Signed-off-by: Zhen Lei
Tested-by: Ard Biesheuvel
Tested-by: Zhen Lei
[rm: rewrote commit message to clarify]
Signed-off-by: Robin Murphy
---
v2: No change
drivers/iommu/iova.c
arithmetic, rewrote commit message]
Signed-off-by: Robin Murphy
---
v2: No change
drivers/iommu/iova.c | 40 ++--
1 file changed, 14 insertions(+), 26 deletions(-)
diff --git a/drivers/iommu/iova.c b/drivers/iommu/iova.c
index 8f7552dc4e04..d094d1ca8f23 100644
ather
less invasive manner.
Robin.
Changes from v1:
- Fix overflow with 32-bit dma_addr_t
- Add tested-bys
[1] https://www.mail-archive.com/iommu@lists.linux-foundation.org/msg17753.html
Robin Murphy (1):
iommu/iova: Extend rbtree node caching
Zhen Lei (3):
iommu/iova: Optimise rbtree searchi
it message]
Signed-off-by: Robin Murphy
---
v2: Avoid iova_pfn() overflow with 32-bit dma_addr_t
drivers/gpu/drm/tegra/drm.c | 3 +--
drivers/gpu/host1x/dev.c | 3 +--
drivers/iommu/amd_iommu.c| 7 ++-
drivers/iommu/dma-iommu.c| 18 +-
drivers/i
-by: Ard Biesheuvel
Tested-by: Zhen Lei
Signed-off-by: Robin Murphy
---
v2: No change
drivers/iommu/iova.c | 59 +---
include/linux/iova.h | 3 ++-
2 files changed, 30 insertions(+), 32 deletions(-)
diff --git a/drivers/iommu/iova.c b/drivers
this and the probe-deferral changes in 4.12, we should
now be able to rely on the presence of a group unambiguously indicating
whether a given device is associated with an IOMMU or not.
Robin.
Robin Murphy (4):
iommu/msm: Add iommu_group support
iommu/tegra-smmu: Add iommu_group support
: Robin Murphy
---
drivers/iommu/msm_iommu.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/msm_iommu.c b/drivers/iommu/msm_iommu.c
index d0448353d501..04f4d51ffacb 100644
--- a/drivers/iommu/msm_iommu.c
+++ b/drivers/iommu/msm_iommu.c
@@ -393,6 +393,7
), using generic_device_group() should at least
maintain existing behaviour with respect to the API.
Signed-off-by: Robin Murphy
---
drivers/iommu/tegra-smmu.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/iommu/tegra-smmu.c b/drivers/iommu/tegra-smmu.c
index eeb19f560a05
201 - 300 of 3517 matches
Mail list logo
