ned-off-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 65 +++
1 file changed, 65 insertions(+)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 1e0983488a8d..1082ebf8a415 100644
--- a/drivers/iommu/dma-iommu.c
+++ b/drivers
ng.
Fixes: fade1ec055dc ("iommu/dma: Avoid PCI host bridge windows")
Signed-off-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 48d36ce59efb..1e0983488a8d 100644
ng to the hardware prior to handing it off
to Linux, as opposed to merely supplying a correct FDT or IORT table,
but I'm not sure it matters all that much, and the patch itself is fine:
Reviewed-by: Robin Murphy
Thanks,
Robin.
> Signed-off-by: Robert Richter
> ---
> drivers/iomm
Hi Eric,
On 13/03/17 13:07, Auger Eric wrote:
> Hi Robin,
>
> On 09/03/2017 20:50, Robin Murphy wrote:
>> Now that it's simple to discover the necessary reservations for a given
>> device/IOMMU combination, let's wire up the appropriate handling. Basic
>&g
On 13/03/17 13:08, Auger Eric wrote:
> Hi Robin,
>
> On 09/03/2017 20:50, Robin Murphy wrote:
>> Whilst it doesn't matter much to VFIO at the moment, when parsing
>> reserved regions on the host side we really needs to be able to tell
> s/needs/need
Oops!
>>
On 14/03/17 08:48, Oza Pawandeep wrote:
> It is possible that PCI device supports 64-bit DMA addressing,
> and thus it's driver sets device's dma_mask to DMA_BIT_MASK(64),
> however PCI host bridge may have limitations on the inbound
> transaction addressing. As an example, consider NVME SSD device
hould make it
simple to hook IPMMU-specific calls into the alloc and free paths, and
let the driver take care of the details internally.
Robin.
[1]:https://lists.linuxfoundation.org/pipermail/iommu/2017-January/020189.html
Robin Murphy (3):
iommu/dma: Convert to address-based allocation
iommu/
sake of internal consistency.
Signed-off-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 119 ++
1 file changed, 67 insertions(+), 52 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 48d36ce59efb..9a9dca1073e6 1
Now that allocation is suitably abstracted, our private alloc/free
helpers can drive the trivial MSI cookie allocator directly as well,
which lets us clean up its exposed guts from iommu_dma_map_msi_msg() and
simplify things quite a bit.
Signed-off-by: Robin Murphy
---
drivers/iommu/dma-iommu.c
Cortex-A53), but the real gain will be in sidestepping the rbtree
lock contention which larger ARM-based systems with lots of parallel I/O
are starting to feel the pain of.
Signed-off-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 39 ++-
1 file changed, 18
On 16/03/17 09:19, Oleksandr Tyshchenko wrote:
> Hi, all.
>
> Any comments?
Er, no, but in a good way ;)
Patches look fine to me, and I see Will's already queued them anyway.
Thanks for the respin, and apologies for losing it in my inbox!
Robin.
>
> On Mon, Feb 27, 2017 at 2:30 PM, Oleksandr
Williamson
CC: David Woodhouse
CC: k...@vger.kernel.org
Signed-off-by: Robin Murphy
---
Notes:
v2:
- Reword commit message
- Convert type to an enum [Eric]
- Rename vfio_iommu_has_resv_msi() for clarity [Eric]
drivers/iommu/amd_iommu.c | 2 +-
drivers/iommu/arm-smm
ng.
Fixes: fade1ec055dc ("iommu/dma: Avoid PCI host bridge windows")
Reviewed-by: Eric Auger
Signed-off-by: Robin Murphy
---
Notes:
v2:
- No change
drivers/iommu/dma-iommu.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drive
4.11 before anyone starts using the
sysfs region info in anger, but it's your call; #2 is really a standalone
fix (other than context conflicts) but is non-urgent; #3 and #4 can
happily wait for 4.12.
Robin.
Robin Murphy (4):
iommu: Disambiguate MSI region types
iommu/dma: Don't reserve
of quirks preventing the IOMMU from translating
certain addresses.
Reviewed-by: Eric Auger
Signed-off-by: Robin Murphy
---
Notes:
v2:
- Make the IOVA alignment logic safer [Eric]
- Don't duplicate direct region mapping [Eric]
- Don't wait for the subsequent patch to st
ting code into IOMMU drivers let's transform the existing
function into an iommu_get_resv_regions() helper that they can share.
Signed-off-by: Robin Murphy
---
Notes:
v2:
- New
drivers/iommu/arm-smmu-v3.c | 2 ++
drivers/iommu/arm-smmu.c| 2 ++
drivers
Hi Nate, Will,
On 16/03/17 16:24, Nate Watterson wrote:
> Hi Will,
>
> On 2017-03-10 15:49, Will Deacon wrote:
>> In preparation for allowing the default domain type to be overridden,
>> this patch adds support for IOMMU_DOMAIN_IDENTITY domains to the
>> ARM SMMUv3 driver.
>>
>> An identity domai
On 20/03/17 08:57, Oza Oza wrote:
> + linux-pci
>
> Regards,
> Oza.
>
> -Original Message-
> From: Oza Pawandeep [mailto:oza@broadcom.com]
> Sent: Friday, March 17, 2017 11:41 AM
> To: Joerg Roedel; Robin Murphy
> Cc: iommu@lists.linux-foundation.org
On 21/03/17 10:15, Mason wrote:
> [ Adding iommu ML ]
>
> On 17/03/2017 17:11, Mason wrote:
>
>> + * QUIRK #5
>> + * Only transfers within the BAR are forwarded to the host.
>> + * By default, the DMA framework expects that
>> + * PCI address 0x8000_ -> CPU address 0x8000_
>> + * which is
On 21/03/17 17:08, Will Deacon wrote:
> Hi Robin,
>
> On Thu, Mar 16, 2017 at 06:19:48PM +0000, Robin Murphy wrote:
>> On 16/03/17 16:24, Nate Watterson wrote:
>>> On 2017-03-10 15:49, Will Deacon wrote:
>>>> In preparation for allowing the default domain ty
On 21/03/17 17:21, Will Deacon wrote:
> On Tue, Mar 21, 2017 at 04:45:27PM +0100, Joerg Roedel wrote:
>> On Fri, Mar 10, 2017 at 08:49:36PM +, Will Deacon wrote:
>>> @@ -1014,8 +1027,8 @@ struct iommu_group *iommu_group_get_for_dev(struct
>>> device *dev)
>>> * IOMMU driver.
>>> */
>
On 22/03/17 06:27, Zhen Lei wrote:
> Keep these four variables type consistent with the paramters of function
> __alloc_and_insert_iova_range and the members of struct iova:
>
> 1. static int __alloc_and_insert_iova_range(struct iova_domain *iovad,
> unsigned long size, unsigned long
t in readability, though, I don't even care about
any codegen differences :)
Reviewed-by: Robin Murphy
> Signed-off-by: Zhen Lei
> ---
> drivers/iommu/iova.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/iommu/iova.c b/drivers/i
On 22/03/17 06:27, Zhen Lei wrote:
> Reserve the first granule size memory(start at start_pfn) as boundary
> iova, to make sure that iovad->cached32_node can not be NULL in future.
> Meanwhile, changed the assignment of iovad->cached32_node from rb_next to
> rb_prev of &free->node in function __cac
chance of catching normal operations completing before
committing to the fixed delay, but also backing off exponentially, since
if a sync really hasn't completed within one or two "reasonable time"
periods, it becomes increasingly unlikely that it ever will.
Signed-off-by: Robin Murph
On 24/03/17 09:27, Shameerali Kolothum Thodi wrote:
> Hi Sricharan,
>
>> -Original Message-
>> From: Sricharan R [mailto:sricha...@codeaurora.org]
>> Sent: Friday, March 24, 2017 7:10 AM
>> To: Wangzhou (B); robin.mur...@arm.com; will.dea...@arm.com;
>> j...@8bytes.org; lorenzo.pieral...@a
Hi Jean-Philippe,
On 27/02/17 19:54, Jean-Philippe Brucker wrote:
> Reintroduce smmu_group. This structure was removed during the generic DT
> bindings rework, but will be needed when implementing PCIe ATS, to lookup
> devices attached to a given domain.
>
> When unmapping from a domain, we need
Hi Rob,
On 27/03/17 15:34, Rob Herring wrote:
> On Sat, Mar 25, 2017 at 12:31 AM, Oza Pawandeep wrote:
>> it jumps to the parent node without examining the child node.
>> also with that, it throws "no dma-ranges found for node"
>> for pci dma-ranges.
>>
>> this patch fixes device node traversing
On 27/03/17 16:58, Shameerali Kolothum Thodi wrote:
>
>
>> -Original Message-
>> From: Shameerali Kolothum Thodi
>> Sent: Monday, March 27, 2017 3:53 PM
>> To: 'Robin Murphy'; Sricharan R; Wangzhou (B); will.dea...@arm.com;
>> j...@8bytes.org
es work, but is
vile, so I'm not seriously considering it (hence I've not bothered
making IOMMU configuration handle all circumstances). What it has served
to do, though, is give me a clear idea of how to properly sort out the
not-quite-right device/parent assumptions between of_dma_conf
On 28/03/17 16:00, Rob Herring wrote:
> On Fri, Mar 10, 2017 at 12:30:57AM +0530, Sricharan R wrote:
>> From: Laurent Pinchart
>>
>> Failures to look up an IOMMU when parsing the DT iommus property need to
>> be handled separately from the .of_xlate() failures to support deferred
>> probing.
>>
>>
to help
re-use") is very clear-cut: either the master_np argument is redundant
with dev->of_node, or dev->of_node is NULL and master_np is the relevant
parent bus. Let's ratify that behaviour, then teach the whole
of_dma_configure() pipeline to cope with both cases properly.
On 29/03/17 11:05, Andrzej Hajda wrote:
> In case of DMA_ATTR_FORCE_CONTIGUOUS allocations vm_area->pages
> is invalid. __iommu_mmap_attrs and __iommu_get_sgtable cannot use
> it. In first case temporary pages array is passed to iommu_dma_mmap,
> in 2nd case single entry sg table is created directl
On 29/03/17 16:12, Andrzej Hajda wrote:
> On 29.03.2017 14:55, Robin Murphy wrote:
>> On 29/03/17 11:05, Andrzej Hajda wrote:
>>> In case of DMA_ATTR_FORCE_CONTIGUOUS allocations vm_area->pages
>>> is invalid. __iommu_mmap_attrs and __iommu_get_sgtable cannot use
&
On 29/03/17 06:46, Oza Oza wrote:
> On Wed, Mar 29, 2017 at 10:23 AM, Oza Oza wrote:
>> On Wed, Mar 29, 2017 at 12:27 AM, Robin Murphy wrote:
>>> For PCI masters not represented in DT, we pass the OF node of their
>>> associated host bridge to of_dma_configure(),
On 30/03/17 09:30, Andrzej Hajda wrote:
> On 30.03.2017 09:40, Geert Uytterhoeven wrote:
>> Hi Andrzej,
>>
>> On Thu, Mar 30, 2017 at 8:51 AM, Andrzej Hajda wrote:
>>> On 29.03.2017 17:33, Robin Murphy wrote:
>>>> On 29/03/17 16:12, Andrzej Hajda wrot
On 30/03/17 12:16, Andrzej Hajda wrote:
[...]
> I guess Geert's proposition to create pages permanently is also not
> acceptable[2]. So how to fix crashes which appeared after patch adding
If I'm not mistaken, creating the pages permanently is what the
!DMA_ATTR_FORCE_CONTIGUOUS d
On 30/03/17 12:53, Geert Uytterhoeven wrote:
> Hi Robin,
>
> On Thu, Mar 30, 2017 at 1:46 PM, Robin Murphy wrote:
>> On 30/03/17 12:16, Andrzej Hajda wrote:
>> [...]
>>>>>>> I guess Geert's proposition to create pages permanently is also not
>
On 30/03/17 15:37, Will Deacon wrote:
> Hi Robin,
>
> This mostly looks great, but I have a couple of minor comments below.
>
> On Tue, Mar 07, 2017 at 06:09:07PM +0000, Robin Murphy wrote:
>> TLB synchronisation typically involves the SMMU blocking all incoming
>>
Hi Will,
Here's a quick v2 to address your comments and drop the needless meddling
(whaddaya know, it makes the whole lot look simpler!)
I'll put it on my list to take a look at SMMUv3 queue polling as suggested.
Robin.
Robin Murphy (4):
iommu/arm-smmu: Simplify ASID/VMID handli
arm_smmu_cfg; let's just
precalculate an ASID/VMID, plop it in there, and tidy up the users
accordingly. We'd also need something like this anyway if we ever get
near to thinking about SVM, so it's no bad thing.
Signed-off-by: Robin Murphy
---
v2: No change
drivers/iommu/
chance of catching normal operations completing before
committing to the fixed delay, but also backing off exponentially, since
if a sync really hasn't completed within one or two "reasonable time"
periods, it becomes increasingly unlikely that it ever will.
Signed-off-by: Robin Murp
round so that we just
maintain the CB_BASE address directly.
Signed-off-by: Robin Murphy
---
v2: No change
drivers/iommu/arm-smmu.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 34b745b
o the already unwieldy
monolithic TLB maintenance ops, break them up into smaller, neater,
functions which we can then mix and match as appropriate.
Signed-off-by: Robin Murphy
---
v2: Undo unnecessary refactoring of arm_smmu_tlb_inv_range_nosync()
(and forget about further attempts, since
. for MMU-500 configurations where the appended TBU
number gets in the way unnecessarily). Let's add a new property to allow
a single global mask value to better fit the latter situation.
Tested-by: Nipun Gupta
Signed-off-by: Robin Murphy
---
v2: Rewrite the documentation to actually make
On 31/03/17 13:40, Will Deacon wrote:
> Hi Robin, Joerg,
>
> On Wed, Mar 15, 2017 at 01:33:13PM +0000, Robin Murphy wrote:
>> Here's the first bit of lock contention removal to chew on - feedback
>> welcome! Note that for the current users of the io-pgtable framework,
Hi Joerg,
Here's the series rebased onto your current next branch just for the
sake of it, and with the tags added. No other changes.
Thanks,
Robin.
Robin Murphy (3):
iommu/dma: Convert to address-based allocation
iommu/dma: Clean up MSI IOVA allocation
iommu/dma: Plumb in the pe
Signed-off-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 58 ---
1 file changed, 25 insertions(+), 33 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
index 8e0b684da1ba..1b94beb43036 100644
--- a/drivers/iommu/dma-iommu.c
Cortex-A53), but the real gain will be in sidestepping the rbtree
lock contention which larger ARM-based systems with lots of parallel I/O
are starting to feel the pain of.
Reviewed-by: Nate Watterson
Tested-by: Nate Watterson
Signed-off-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 39
sake of internal consistency.
Reviewed-by: Nate Watterson
Tested-by: Nate Watterson
Signed-off-by: Robin Murphy
---
drivers/iommu/dma-iommu.c | 119 ++
1 file changed, 67 insertions(+), 52 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/
4 code, so it's good all round.
Signed-off-by: Robin Murphy
---
drivers/iommu/io-pgtable-arm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/io-pgtable-arm.c b/drivers/iommu/io-pgtable-arm.c
index f9bc6ebb8140..6e5df5e0a3bd 100644
--- a/drivers/iommu/io
gestions, which have indeed turned out to have holes in (no, I can't
see how we'd cleanly fix pci_device_group() either), I'll stand by my
earlier "(I have no actual objection to this patch, though, [...])":
Reviewed-by: Robin Murphy
> Signed-off-by: Jayachandran
On 03/04/17 14:15, Jayachandran C wrote:
> The Cavium ThunderX2 arm64 SoCs (called Broadcom Vulcan earlier), the PCI
> topology is slightly unusual. For a multi-node system, it looks like:
>
> [node level PCI bridges - one per node]
> [SoC PCI devices with MSI-X but no IOMMU]
> [PCI-PCIe "
but that
> situation will change when moving DMA configuration to device probe
> time.
Just for completeness:
Reviewed-by: Robin Murphy
> Tested-by: Marek Szyprowski
> Signed-off-by: Laurent Pinchart
> ---
> drivers/of/address.c | 20 ++--
> drivers/of/
nfigure() function is.
Reviewed-by: Robin Murphy
> Tested-by: Marek Szyprowski
> Signed-off-by: Laurent Pinchart
> ---
> drivers/of/device.c | 12
> drivers/of/platform.c | 5 -
> include/linux/of_device.h | 3 +++
> 3 files changed, 15 insertio
> SMMU drivers present but still not probed) or not (drivers not present).
>
> Add a simple function to IORT to detect if SMMU drivers for SMMU
> components managed by IORT are built-in in the kernel.
Ah, if only DT could be this neat and tidy :D
Reviewed-by: Robin Murphy
> Teste
done in the future.
Agreed; in the meantime, this fix is neat and robust enough.
Reviewed-by: Robin Murphy
> Signed-off-by: Sricharan R
> ---
> drivers/of/device.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/of/device.c b/drivers/of/dev
t case is currently handled by deferring the probe of the bus
> master device as well. A mechanism to either configure the bus master
> device without an IOMMU or to fail the bus master device probe depending
> on whether the IOMMU is optional or mandatory would be a good
> enhancement.
the bus
> master device as well. A mechanism to either configure the bus master
> device without an IOMMU or to fail the bus master device probe depending
> on whether the IOMMU is optional or mandatory would be a good
> enhancement.
I think we really have caught everything now...
Rev
the probe
> deferral mechanism, making the IORT linker section infrastructure
> unused, so that it can be removed.
>
> Remove the unused IORT linker section probing infrastructure
> from the kernel to complete the ACPI IORT IOMMU configure probe
> deferral mechanism impleme
> really_probe
>|
> dma_configure
>
> Similarly on the device/driver_unregister path __device_release_driver is
> called which inturn calls dma_deconfigure.
>
> This patch changes the dma ops configuration to probe time for
> both OF and ACPI based platform/am
git.kernel.org/pub/scm/linux/kernel/git/lpieralisi/linux.git
> iommu/probe-deferral
> [6] http://www.spinics.net/lists/linux-pci/msg57992.html
> [7] https://www.spinics.net/lists/arm-kernel/msg556209.html
> [8] http://patchwork.ozlabs.org/patch/743898/
>
> Laurent Pinchart (3)
On 04/04/17 12:50, Jayachandran C wrote:
> On Mon, Apr 03, 2017 at 04:07:53PM +0100, Robin Murphy wrote:
>> On 03/04/17 14:15, Jayachandran C wrote:
>>> The Cavium ThunderX2 arm64 SoCs (called Broadcom Vulcan earlier), the PCI
>>> topology is slightly unusual. For a
Hi Frank,
On 06/04/17 07:24, Frank Rowand wrote:
> On 04/04/17 03:18, Sricharan R wrote:
>> From: Laurent Pinchart
>>
>> Invalid dma-ranges values should be worked around when retrieving the
>> DMA range in of_dma_get_range(), not by all callers of the function.
>> This isn't much of a problem no
On 06/04/17 08:01, Frank Rowand wrote:
> On 04/04/17 03:18, Sricharan R wrote:
>> Size of the dma-range is calculated as coherent_dma_mask + 1
>> and passed to arch_setup_dma_ops further. It overflows when
>> the coherent_dma_mask is set for full 64 bits 0x,
>> resulting in size get
On 06/04/17 14:56, Rob Herring wrote:
> On Thu, Apr 6, 2017 at 5:24 AM, Robin Murphy wrote:
>> On 06/04/17 08:01, Frank Rowand wrote:
>>> On 04/04/17 03:18, Sricharan R wrote:
>>>> Size of the dma-range is calculated as coherent_dma_mask + 1
>>>> an
On 06/04/17 19:15, Manoj Iyer wrote:
> On Fri, 31 Mar 2017, Robin Murphy wrote:
>
>> With IOVA allocation suitably tidied up, we are finally free to opt in
>> to the per-CPU caching mechanism. The caching alone can provide a modest
>> improvement over walking the rb
On 06/04/17 20:34, Frank Rowand wrote:
> On 04/06/17 04:01, Sricharan R wrote:
>> Hi Frank,
>>
>> On 4/6/2017 12:31 PM, Frank Rowand wrote:
>>> On 04/04/17 03:18, Sricharan R wrote:
Size of the dma-range is calculated as coherent_dma_mask + 1
and passed to arch_setup_dma_ops further. It o
On 08/04/17 00:13, Frank Rowand wrote:
> On 04/07/17 07:46, Robin Murphy wrote:
>> On 06/04/17 20:34, Frank Rowand wrote:
>>> On 04/06/17 04:01, Sricharan R wrote:
>>>> Hi Frank,
>>>>
>>>> On 4/6/2017 12:31 PM, Frank Rowand wrote:
>>>
On 11/04/17 14:41, Bjorn Helgaas wrote:
> [+cc Joerg]
>
> On Tue, Apr 11, 2017 at 07:10:48AM +, Jayachandran C wrote:
>> On Mon, Apr 10, 2017 at 08:28:47PM -0500, Bjorn Helgaas wrote:
>>> Hi Jayachandran,
>>>
>>> On Mon, Apr 03, 2017 at 01:15:04PM +, Jayachandran C wrote:
The Cavium T
On 11/04/17 15:42, linucher...@gmail.com wrote:
> From: Linu Cherian
>
> Cavium 99xx SMMU implementation doesn't support page 1 register space
> and PAGE0_REGS_ONLY option will be enabled as an errata workaround.
Ugh :(
> This option when turned on, replaces all page 1 offsets used for
> EVTQ_P
On 11/04/17 15:42, linucher...@gmail.com wrote:
> From: Linu Cherian
>
> With implementations supporting only page 0 of register space,
> resource size can be 64k as well and hence perform size checks
> based on smmu option PAGE0_REGS_ONLY.
What harm comes of mapping page 1 if we don't access it
On 11/04/17 15:42, linucher...@gmail.com wrote:
> From: Geetha
>
> Cavium 99xx SMMU implementation doesn't not support unique irq lines for
> gerror, eventq and cmdq-sync. USE_SHARED_IRQS option enables to use single
> irq line for all three interrupts.
AFAICS, there's nothing actually wrong wit
On 11/04/17 15:42, linucher...@gmail.com wrote:
> From: Linu Cherian
>
> Add SMMuV3 model definitions.
>
> Signed-off-by: Linu Cherian
> ---
> include/acpi/actbl2.h | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/include/acpi/actbl2.h b/include/acpi/actbl2.h
> index 2b4af07..9db
On 11/04/17 17:21, Will Deacon wrote:
> On Tue, Apr 11, 2017 at 04:54:26PM +0100, Robin Murphy wrote:
>> On 11/04/17 15:42, linucher...@gmail.com wrote:
>>> From: Geetha
>>>
>>> Cavium 99xx SMMU implementation doesn't not support unique irq l
Hi Nate,
On 13/04/17 09:55, Nate Watterson wrote:
> Currently, the __iommu_dma_{map/free} functions call iova_{offset/align}
> making them unsuitable for use with iommu_domains having an IOMMU_DMA_MSI
> cookie since the cookie's iova_domain member, iovad, is uninitialized.
>
> Now that iommu_dma_
On 02/05/17 16:22, Michael S. Tsirkin wrote:
> On Tue, May 02, 2017 at 10:17:26AM +0200, Christoffer Dall wrote:
>> On Tue, May 2, 2017 at 10:13 AM, Auger Eric wrote:
>>> Hi Christoffer,
>>>
>>> On 02/05/2017 09:53, Christoffer Dall wrote:
On Tue, May 2, 2017 at 9:30 AM, Auger Eric wrote:
>>
Hi Geert,
On 02/05/17 19:35, Geert Uytterhoeven wrote:
> Hi Sricharan,
>
> On Fri, Feb 3, 2017 at 4:48 PM, Sricharan R wrote:
>> From: Laurent Pinchart
>>
>> Failures to look up an IOMMU when parsing the DT iommus property need to
>> be handled separately from the .of_xlate() failures to suppor
On 28/04/17 14:22, Ard Biesheuvel wrote:
> On 28 April 2017 at 14:17, Will Deacon wrote:
>> On Fri, Apr 28, 2017 at 02:14:49PM +0100, Ard Biesheuvel wrote:
>>> On 28 April 2017 at 14:11, Will Deacon wrote:
Hi Ard,
[+ devicetree@]
On Fri, Apr 14, 2017 at 01:43:15PM +0100,
On 27/04/17 12:13, sunil.kovv...@gmail.com wrote:
> From: Sunil Goutham
>
> Modified polling on CMDQ consumer similar to how polling is done for TLB SYNC
> completion in SMMUv2 driver. Code changes are done with reference to
>
> 8513c8930069 iommu/arm-smmu: Poll for TLB sync completion more effe
[apologies for the silence - I've been on holiday]
On 03/05/17 05:46, Oza Pawandeep wrote:
> current device framework and of framework integration assumes
> dma-ranges in a way where memory-mapped devices define their
> dma-ranges. (child-bus-address, parent-bus-address, length).
Well, yes, that
On 03/05/17 05:46, Oza Pawandeep wrote:
> this patch reserves the iova for PCI masters.
> ARM64 based SOCs may have scattered memory banks.
> such as iproc based SOC has
>
> <0x 0x8000 0x0 0x8000>, /* 2G @ 2G */
> <0x0008 0x8000 0x3 0x8000>, /* 14G @ 34G */
> <0x009
that sensible values will result anyway.
CLean up the code paths that are valid for an MSI cookie to ensure we
only do iova_domain-specific things when we're actually dealing with one.
Reported-by: Nate Watterson
Tested-by: Shanker Donthineni
Tested-by: Bharat Bhushan
Signed-off-by: Ro
On 04/05/17 19:41, Oza Oza wrote:
[...]
>>> 5) leaves scope of adding PCI flag handling for inbound memory
>>> by the new function.
>>
>> Which flags would ever actually matter? DMA windows aren't going to be
>> to config or I/O space, so the memory type can be assumed, and the
>> 32/64-bit distinc
On 04/05/17 19:52, Oza Oza wrote:
> On Thu, May 4, 2017 at 11:50 PM, Robin Murphy wrote:
>> On 03/05/17 05:46, Oza Pawandeep wrote:
>>> this patch reserves the iova for PCI masters.
>>> ARM64 based SOCs may have scattered memory banks.
>>> such as ipr
On 07/05/17 01:06, Jon Masters wrote:
> On 05/09/2016 06:00 AM, Robin Murphy wrote:
>> On 09/05/16 10:37, Robin Murphy wrote:
>>> Hi Niklas,
>>>
>>> On 08/05/16 11:59, Niklas Söderlund wrote:
>>>> Hi,
>>>>
>>>> While using
On 08/05/17 10:17, Linu Cherian wrote:
> On Sat May 06, 2017 at 01:03:28AM +0200, Robert Richter wrote:
>> On 05.05.17 17:38:05, Geetha sowjanya wrote:
>>> From: Linu Cherian
>>>
>>> Cavium ThunderX2 SMMU implementation doesn't support page 1 register space
>>> and PAGE0_REGS_ONLY option will be e
On 05/05/17 13:08, Geetha sowjanya wrote:
> From: Geetha Sowjanya
>
> Cavium ThunderX2 SMMU doesn't support MSI and also doesn't have unique irq
> lines for gerror, eventq and cmdq-sync.
>
> This patch addresses the issue by checking if any interrupt sources are
> using same irq number, then the
On 09/05/17 12:45, 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_
Hi Aaron,
On 11/05/17 14:36, Aaron Sierra wrote:
> I found it was impossible to allocate all of the address space
> defined by an IOVA domain. For example, a trivial domain with 2 pages
> would cover PFNs 0 (start) and 1 (limit), but attempting to allocate
> more than one total PFN would fail beca
IORT revision C has been published with a number of new SMMU
implementation identifiers; define them.
CC: Rafael J. Wysocki
CC: Robert Moore
CC: Lv Zheng
Signed-off-by: Robin Murphy
---
include/acpi/actbl2.h | 8
1 file changed, 8 insertions(+)
diff --git a/include/acpi/actbl2.h b
Revision C of IORT now allows us to identify ARM MMU-401 and the Cavium
ThunderX implementation; wire them up so that the appropriate quirks get
enabled when booting with ACPI.
Signed-off-by: Robin Murphy
---
drivers/iommu/arm-smmu.c | 8
1 file changed, 8 insertions(+)
diff --git a
extra states.
FWIW,
Acked-by: Robin Murphy
> Signed-off-by: Thomas Gleixner
> Cc: Joerg Roedel
> Cc: iommu@lists.linux-foundation.org
> ---
> drivers/iommu/of_iommu.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/iommu/of_iommu.c
> ++
Tested-by: Shanker Donthineni
Tested-by: Bharat Bhushan
Signed-off-by: Robin Murphy
---
Resending rebased to 4.12-rc1 with fixes tag.
drivers/iommu/dma-iommu.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.
On 11/05/17 19:27, Aaron Sierra wrote:
> - Original Message -
>> From: "Robin Murphy"
>> To: "Aaron Sierra" , "Joerg Roedel"
>> Cc: "iommu" , "Nate Watterson"
>>
>> Sent: Thursday, May 11, 2017 12:39:0
rbtree. Since we're working
with PFNs, representing one past the top of the address space is always
possible without fear of overflow, and elsewhere it just makes life a
little more straightforward.
Reported-by: Aaron Sierra
Signed-off-by: Robin Murphy
---
I've now run this through som
On 13/05/17 10:47, shameer wrote:
> This will provide a way to replace the existing skip_prefetch_cmd
> erratum using the new framework.
Yikes, between this and patch 1 we're already pushing 70 lines of new
code, and it still doesn't actually do anything yet. Implementing the
SMMUv3 equivalent of
On 13/05/17 10:47, shameer wrote:
> This replaces the existing broken_prefetch_cmd quirk using
> the new erratum framework.
>
> Signed-off-by: shameer
> ---
> arch/arm64/Kconfig | 10 +-
> drivers/iommu/arm-smmu-v3.c | 36 ++--
> 2 files changed,
On 13/05/17 10:47, shameer wrote:
> This moves the SW MSI reserve region allocation to probe fn.
Why?
> Signed-off-by: shameer
> ---
> drivers/iommu/arm-smmu-v3.c | 36 +++-
> 1 file changed, 27 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/iommu/arm-sm
On 13/05/17 10:47, 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
101 - 200 of 3517 matches
Mail list logo
