On 2018/7/25 6:01, Robin Murphy wrote:
> On 2018-07-12 7:18 AM, Zhen Lei wrote:
>> 1. Save the related domain pointer in struct iommu_dma_cookie, make iovad
>> capable call domain->ops->flush_iotlb_all to flush TLB.
>> 2. Add a new iommu capability: IOMMU_CAP_NON_STRICT, which used to indica
On 2018/7/25 5:51, Robin Murphy wrote:
> On 2018-07-12 7:18 AM, Zhen Lei wrote:
>> v2 -> v3:
>> Add a bootup option "iommu_strict_mode" to make the manager can choose which
>> mode to be used. The first 5 patches have not changed.
>> +iommu_strict_mode=[arm-smmu-v3]
>> +0 - strict
> From: Tian, Kevin
> Sent: Thursday, July 26, 2018 11:04 AM
[...]
> >
> > The IOMMU operations we care about don't take a device handle, I think,
> > just a domain. And VFIO itself only deals with domains when doing
> > map/unmap. Maybe we could add this operation to the IOMMU
> subsystem:
> >
> >
> From: Jean-Philippe Brucker [mailto:jean-philippe.bruc...@arm.com]
> Sent: Thursday, July 26, 2018 3:20 AM
>
> On 25/07/18 07:19, Tian, Kevin wrote:
> >> From: Tian, Kevin
> >> Sent: Wednesday, July 25, 2018 10:16 AM
> >>
> > [...]
> >>>
> >>> There is another way: as we're planning to add a gen
Hi Geert,
Thank you for the patch.
On Wednesday, 25 July 2018 16:10:29 EEST Geert Uytterhoeven wrote:
> The Renesas IPMMU-VMSA driver supports not just R-Car H2 and M2 SoCs,
> but also other R-Car Gen2 and R-Car Gen3 SoCs.
>
> Drop a superfluous "Renesas" while at it.
>
> Signed-off-by: Geert U
On 25/07/18 07:19, Tian, Kevin wrote:
>> From: Tian, Kevin
>> Sent: Wednesday, July 25, 2018 10:16 AM
>>
> [...]
>>>
>>> There is another way: as we're planning to add a generic pasid_alloc()
>>> function to the IOMMU API, the mdev module itself could allocate a
>>> default PASID for each mdev by c
From: Thor Thayer
Add the clocks required for the Stratix10 SMMU. Define the
clock names in the SMMU name array and add DT compatible
matching element.
Signed-off-by: Thor Thayer
---
This patch is dependent on the patch series
"iommu/arm-smmu: Add runtime pm/sleep support"
(https://patchwork.oz
From: Thor Thayer
Add SMMU support for the Stratix10 SOCFPGA. This patch requires
clock enables for the master TBUs and therefore has a dependency
on patches currently being reviewed.
This patchset is dependent on the patch series
"iommu/arm-smmu: Add runtime pm/sleep support"
(https://patchwork
From: Thor Thayer
Add SMMU support to the Stratix10 Device Tree which
includes adding the SMMU node and adding IOMMU stream
ids to the SMMU peripherals. Update bindings.
Signed-off-by: Thor Thayer
---
This patch is dependent on the patch series
"iommu/arm-smmu: Add runtime pm/sleep support"
(ht
On Tue, Jul 24, 2018 at 8:51 PM, Robin Murphy wrote:
> On 19/07/18 11:15, Vivek Gautam wrote:
>>
>> From: Sricharan R
>>
>> The smmu needs to be functional only when the respective
>> master's using it are active. The device_link feature
>> helps to track such functional dependencies, so that the
On 2018-07-25 4:27 PM, Lorenzo Pieralisi wrote:
On Mon, Jul 23, 2018 at 11:16:11PM +0100, Robin Murphy wrote:
Now that we can track upstream DMA constraints properly with
bus_dma_mask instead of trying (and failing) to maintain it in
coherent_dma_mask, it doesn't make much sense for the firmware
On Mon, Jul 23, 2018 at 11:16:11PM +0100, Robin Murphy wrote:
> Now that we can track upstream DMA constraints properly with
> bus_dma_mask instead of trying (and failing) to maintain it in
> coherent_dma_mask, it doesn't make much sense for the firmware code to
> be touching the latter at all. It'
On 12/07/18 08:45, Ganapatrao Kulkarni wrote:
Hi Robin,
On Mon, Jun 4, 2018 at 9:36 AM, Ganapatrao Kulkarni wrote:
ping??
On Mon, May 21, 2018 at 6:45 AM, Ganapatrao Kulkarni wrote:
On Thu, Apr 26, 2018 at 3:15 PM, Ganapatrao Kulkarni wrote:
Hi Robin,
On Mon, Apr 23, 2018 at 11:11 PM, G
On 25 July 2018 at 13:31, Christoph Hellwig wrote:
> Hi Robin,
>
> this series looks fine to me. Do you want me to pull this into the
> dma-mapping tree? I'd like to see a few more ACKs from the ACPI/OF/
> IOMMU maintainers though.
>
This fixes the issue I reported with the on-SoC NIC of the So
Hi Geert,
On 25/07/18 14:34, Geert Uytterhoeven wrote:
The Renesas IPMMU-VMSA driver is compatible with the notion of a type-1
IOMMU in VFIO.
This patch allows guests to use the VFIO_IOMMU_TYPE1 API on hosts
equipped with a Renesas VMSA-compatible IPMMU.
Signed-off-by: Geert Uytterhoeven
---
The Renesas IPMMU-VMSA driver is compatible with the notion of a type-1
IOMMU in VFIO.
This patch allows guests to use the VFIO_IOMMU_TYPE1 API on hosts
equipped with a Renesas VMSA-compatible IPMMU.
Signed-off-by: Geert Uytterhoeven
---
Lightly tested with sata_rcar on Renesas R-Car H3 ES2.0.
On 16/07/18 19:56, Thor Thayer wrote:
[...]
@@ -332,6 +342,36 @@
altr,modrst-offset = <0x20>;
};
+ smmu: iommu@fa00 {
+ compatible = "arm,mmu-500", "arm,smmu-v2";
+ reg = <0xfa00 0x4>;
+ #global-interrupts = <9>;
+
On Mon, Jul 23, 2018 at 11:16:08PM +0100, Robin Murphy wrote:
> When an explicit DMA limit is described by firmware, we need to remember
> it regardless of how drivers might subsequently update their devices'
> masks. The new bus_dma_mask field does that.
>
> CC: Lorenzo Pieralisi
> CC: Hanjun Gu
When attaching a device to an IOMMU group with
CONFIG_DEBUG_ATOMIC_SLEEP=y:
BUG: sleeping function called from invalid context at mm/slab.h:421
in_atomic(): 1, irqs_disabled(): 128, pid: 61, name: kworker/1:1
...
Call trace:
...
arm_lpae_alloc_pgtable+0x114/0x184
arm
The Renesas IPMMU-VMSA driver supports not just R-Car H2 and M2 SoCs,
but also other R-Car Gen2 and R-Car Gen3 SoCs.
Drop a superfluous "Renesas" while at it.
Signed-off-by: Geert Uytterhoeven
---
drivers/iommu/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/driv
On 09/07/18 12:18, Nipun Gupta wrote:
The existing IOMMU bindings cannot be used to specify the relationship
between fsl-mc devices and IOMMUs. This patch adds a generic binding for
mapping fsl-mc devices to IOMMUs, using iommu-map property.
No more nits from me :)
Acked-by: Robin Murphy
Si
On 09/07/18 12:18, Nipun Gupta wrote:
This patch adds support of dma configuration for devices on fsl-mc
bus using 'dma_configure' callback for busses. Also, directly calling
arch_setup_dma_ops is removed from the fsl-mc bus.
Reviewed-by: Robin Murphy
Signed-off-by: Nipun Gupta
Reviewed-by:
On 09/07/18 12:18, Nipun Gupta wrote:
Implement bus specific support for the fsl-mc bus including
registering arm_smmu_ops and bus specific device add operations.
I guess this is about as neat as it can get;
Reviewed-by: Robin Murphy
Signed-off-by: Nipun Gupta
---
drivers/iommu/arm-smmu.
On Wed, Jul 25, 2018 at 01:12:56PM +0100, Robin Murphy wrote:
> On 25/07/18 12:31, Christoph Hellwig wrote:
> >Hi Robin,
> >
> >this series looks fine to me. Do you want me to pull this into the
> >dma-mapping tree? I'd like to see a few more ACKs from the ACPI/OF/
> >IOMMU maintainers though.
>
On 25/07/18 12:31, Christoph Hellwig wrote:
Hi Robin,
this series looks fine to me. Do you want me to pull this into the
dma-mapping tree? I'd like to see a few more ACKs from the ACPI/OF/
IOMMU maintainers though.
Thanks, I was indeed assuming that the dma-mapping tree would be the
best ro
On Wed, Jul 25, 2018 at 01:31:22PM +0200, Christoph Hellwig wrote:
> Hi Robin,
>
> this series looks fine to me. Do you want me to pull this into the
> dma-mapping tree? I'd like to see a few more ACKs from the ACPI/OF/
> IOMMU maintainers though.
For the IOMMU parts:
Acked-by: Joerg R
On Tue, Jul 24, 2018 at 03:09:41PM +0530, Vivek Gautam wrote:
> On 7/24/2018 2:06 PM, Will Deacon wrote:
> >On Thu, Jul 19, 2018 at 11:23:56PM +0530, Vivek Gautam wrote:
> >>diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
> >>index 7c69736a30f8..4cb53bf4f423 100644
> >>--- a/driver
Refactor all the common code into what previously was map_single, which
is now renamed to __swiotlb_map_page. This also improves the map_sg
error handling and diagnostics to match the map_page ones.
Signed-off-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 114
Signed-off-by: Christoph Hellwig
---
include/linux/swiotlb.h | 1 -
kernel/dma/swiotlb.c| 2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
index 965be92c33b5..7ef541ce8f34 100644
--- a/include/linux/swiotlb.h
+++ b/include/l
Signed-off-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 8ca0964ebf3a..5c3db7c89e0f 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -606,8 +606,1
Signed-off-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 06cfc4d00325..03016221fc64 100644
--- a/kernel/dma/swiotlb.c
+++ b/kernel/dma/swiotlb.c
@@ -812,9 +812,9
All properly written drivers now have error handling in the
dma_map_single / dma_map_page callers. As swiotlb_tbl_map_single already
prints a useful warning when running out of swiotlb pool swace we can
also remove swiotlb_full entirely as it serves no purpose now.
Signed-off-by: Christoph Hellwi
This comments describes an aspect of the map_sg interface that isn't
even exploited by swiotlb.
Signed-off-by: Christoph Hellwig
---
kernel/dma/swiotlb.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
index 4f8a6dbf0b60..9062b14bc7f4 100644
-
Hi Konrad,
below are a few swiotlb patches. Mostly just cleanups, but the removal
of the panic option is an actual change in (rarely used) functionality.
I'd be happy to pick them up through the dma-mapping tree if you are
fine with that.
___
iommu mai
Thanks, I'll pull this into the dma-mapping tree.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Hi Robin,
this series looks fine to me. Do you want me to pull this into the
dma-mapping tree? I'd like to see a few more ACKs from the ACPI/OF/
IOMMU maintainers though.
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfounda
On Mon, Jul 23, 2018 at 11:16:09PM +0100, Robin Murphy wrote:
> When an explicit DMA limit is described by firmware, we need to remember
> it regardless of how drivers might subsequently update their devices'
> masks. The new bus_dma_mask field does that.
Looks good,
Reviewed-by: Christoph Hellwi
On Mon, Jul 23, 2018 at 11:16:08PM +0100, Robin Murphy wrote:
> When an explicit DMA limit is described by firmware, we need to remember
> it regardless of how drivers might subsequently update their devices'
> masks. The new bus_dma_mask field does that.
Looks good,
Reviewed-by: Christoph Hellwi
On Mon, Jul 23, 2018 at 11:16:07PM +0100, Robin Murphy wrote:
> Whilst the notion of an upstream DMA restriction is most commonly seen
> in PCI host bridges saddled with a 32-bit native interface, a more
> general version of the same issue can exist on complex SoCs where a bus
> or point-to-point i
Switch to the generic noncoherent direct mapping implementation.
Signed-off-by: Christoph Hellwig
---
arch/sh/Kconfig | 3 +-
arch/sh/include/asm/Kbuild| 1 +
arch/sh/include/asm/dma-mapping.h | 26 ---
arch/sh/kernel/Makefile | 2 +-
arch/sh/kernel
Half of the file just contains platform device memory setup code which
is required for all builds, and half contains helpers for dma coherent
allocation, which is only needed if CONFIG_DMA_NONCOHERENT is enabled.
Signed-off-by: Christoph Hellwig
---
arch/sh/kernel/Makefile | 2 +-
arch/sh
This is a slight change in behavior as we avoid the detour through the
virtual mapping for the coherent allocator, but if this CPU really is
coherent that should be the right thing to do.
Signed-off-by: Christoph Hellwig
---
arch/sh/Kconfig | 1 +
arch/sh/include/asm/dma-mappin
And use it in the maple bus code to avoid a dma API dependency.
Signed-off-by: Christoph Hellwig
---
arch/sh/include/asm/cacheflush.h | 7 +++
arch/sh/mm/consistent.c | 6 +-
drivers/sh/maple/maple.c | 7 ---
3 files changed, 12 insertions(+), 8 deletions(-)
diff --
Remove the indirection through the dma_ops variable, and just return
nommu_dma_ops directly from get_arch_dma_ops.
Signed-off-by: Christoph Hellwig
---
arch/sh/include/asm/dma-mapping.h | 5 ++---
arch/sh/kernel/dma-nommu.c| 8 +---
arch/sh/mm/consistent.c | 3 ---
arch/
Hi all,
can you review these patches to switch sh to use the generic
dma-noncoherent code? All the requirements are in mainline already
and we've switched various architectures over to it already.
Changes since V2:
- drop a now obsolete export
Changes since V1:
- fixed two stupid compile erro
45 matches
Mail list logo
