Good effort to isolate bus config from smmu drivers.
Reviewed-By: Krishna Reddy
I have an orthogonal question here.
Can the following code handle the case, where different buses have different
type of SMMU instances(like one bus has SMMUv2 and another bus has SMMUv3)?
If it need to handle
t; .probe_finalize = nvidia_smmu_probe_finalize,
> + .init_context = nvidia_smmu_init_context,
> };
>
> static const struct arm_smmu_impl nvidia_smmu_single_impl = {
> .probe_finalize = nvidia_smmu_probe_finalize,
> + .init_context = nvidia_smmu_init_context,
> };
>
Reviewed-by: Krishna Reddy
-KR
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
Hi Eric,
> This is based on Jean-Philippe's
> [PATCH v14 00/10] iommu: I/O page faults for SMMUv3
> https://www.spinics.net/lists/arm-kernel/msg886518.html
> (including the patches that were not pulled for 5.13)
>
Jean's patches have been merged to v5.14.
Do you anticipate IOMMU/VFIO part patches
> +
> +err_pm_disable:
> + pm_runtime_disable(dev);
> return ret;
> }
Should it be pm_runtime_force_suspend()? qcom_iommu_device_remove() doesn't
use pm_runtime_disable(dev).
875 static int qcom_iommu_device_remove(struct platform_device *pdev)
876 {
...
881
> Instead of flush_ops in init_context hook, perhaps a io_pgtable quirk since
> this is
> related to tlb, probably a bad name but IO_PGTABLE_QUIRK_TLB_INV which will
> be set in init_context impl hook and the prev condition in
> io_pgtable_tlb_flush_walk()
> becomes something like below. Seems
> if (smmu->impl->probe_finalize)
The above is the issue. It should be updated as below similar to other
instances impl callbacks.
if (smmu->impl && smmu->impl->probe_finalize)
-KR
___
iommu mailing list
iommu@lists.linux-foundation.org
> Right but we won't know until we profile the specific usecases or try them in
> generic workload to see if they affect the performance. Sure, over
> invalidation is
> a concern where multiple buffers can be mapped to same context and the cache
> is not usable at the time for lookup and such but
> > + mutex_lock(>mutex);
> > iommu_alloc_default_domain(group, dev);
> > + mutex_unlock(>mutex);
>
> It feels wrong to serialise this for everybody just to cater for systems with
> aliasing SIDs between devices.
Serialization is limited to devices in the same group. Unless devices
Hi Sai,
> >> > No, the unmap latency is not just in some test case written, the
> >> > issue is very real and we have workloads where camera is reporting
> >> > frame drops because of this unmap latency in the order of 100s of
> milliseconds.
> Not exactly, this issue is not specific to camera.
> > No, the unmap latency is not just in some test case written, the issue
> > is very real and we have workloads where camera is reporting frame
> > drops because of this unmap latency in the order of 100s of milliseconds.
> > And hardware team recommends using ASID based invalidations for
> >
Hi Dmitry,
> Thank you for the answer. Could you please give more information about:
> 1) Are you on software or hardware team, or both?
I am in the software team and has contributed to initial Tegra SMMU driver in
the downstream along with earlier team member Hiroshi Doyu.
> 2) Is SMMU a
> Is it always safe to enable SMMU ASID in a middle of a DMA request made by a
> memory client?
>From MC point of view, It is safe to enable and has been this way from many
>years in downstream code for display engine.
It doesn't impact the transactions that have already bypassed SMMU before
>> Did that patch cause any issue, or is it just not needed on your system?
>> It fixes an hypothetical problem with the way ATS is implemented.
>> Maybe I actually observed it on an old software model, I don't
>> remember. Either way it's unlikely to go upstream but I'd like to know
>> if I
>+static const struct arm_smmu_impl nvidia_smmu_single_impl = {
>+ .probe_finalize = nvidia_smmu_probe_finalize,
>+};
nvidia_smmu_probe_finalize is used before it is defined. It is defined in patch
5.
-KR
___
iommu mailing list
Tested-by: Krishna Reddy
Validated v13 patches in context of nested translations validation for NVMe
PCIe device assigned to Guest VM.
V12 patches(v13 is yet to be tested) has been tested for SVA functionality on
Native OS and is functional.
-KR
Tested-by: Krishna Reddy
Validated nested translations with NVMe PCI device assigned to Guest VM.
Tested with both v12 and v13 of Jean-Philippe's patches as base.
> This is based on Jean-Philippe's
> [PATCH v12 00/10] iommu: I/O page faults for SMMUv3
> https://lore.kernel.org/linux-a
Tested-by: Krishna Reddy
Validated Nested SMMUv3 translations for NVMe PCIe device from Guest VM and is
functional.
This patch series resolved the mismatch(seen with v11 patches) for
VFIO_IOMMU_SET_PASID_TABLE and VFIO_IOMMU_CACHE_INVALIDATE Ioctls between linux
and QEMU patch series
> Hi Krishna,
> On 3/15/21 7:04 PM, Krishna Reddy wrote:
> > Tested-by: Krishna Reddy
> >
> >> 1) pass the guest stage 1 configuration
> >
> > Validated Nested SMMUv3 translations for NVMe PCIe device from Guest VM
> along with patch series "v11 SM
Tested-by: Krishna Reddy
> 1) pass the guest stage 1 configuration
> 3) invalidate stage 1 related caches
Validated Nested SMMUv3 translations for NVMe PCIe device from Guest VM along
with patch series "v13 SMMUv3 Nested Stage Setup (IOMMU part)" and QEMU patch
series "vS
Tested-by: Krishna Reddy
> 1) pass the guest stage 1 configuration
Validated Nested SMMUv3 translations for NVMe PCIe device from Guest VM along
with patch series "v11 SMMUv3 Nested Stage Setup (VFIO part)" and QEMU patch
series "vSMMUv3/pSMMUv3 2 stage VFIO integration&q
> I agree that we should let a device driver enable SVA if it supports some
> form of IOPF.
Right, The PCIe device has capability to handle IO page faults on its own when
ATS translation request response indicates that no valid mapping exist.
SMMU doesn't involve/handle page faults for ATS
Hi Jean,
> +bool arm_smmu_master_sva_supported(struct arm_smmu_master *master) {
> + if (!(master->smmu->features & ARM_SMMU_FEAT_SVA))
> + return false;
+
> + /* SSID and IOPF support are mandatory for the moment */
> + return master->ssid_bits &&
>> The Tegra Next Generation SOC uses arm-smmu-v3, but it doesn't have support
>> for BTM.
>> Do you have plan to get your earlier patch to handle invalidate
>> notifications into upstream sometime soon?
>> Can the dependency on BTM be relaxed with the patch?
>>
>> PATCH v9 13/13]
> > The Tegra Next Generation SOC uses arm-smmu-v3, but it doesn't have support
> > for BTM.
> > Do you have plan to get your earlier patch to handle invalidate
> > notifications into upstream sometime soon?
>Is that a limitation of the SMMU implementation, the interconnect or the
Hi Jean,
> > Why is BTM mandated for SVA? I couldn't find this requirement in
> > SMMU spec (Sorry if I missed it or this got discussed earlier). But
> > if performance is the
> only concern here,
> > is it better just to allow it with a warning rather than limiting
> > SMMUs without
> BTM?
>
>
Add binding for NVIDIA's Tegra194 SoC SMMU.
Reviewed-by: Jon Hunter
Reviewed-by: Rob Herring
Reviewed-by: Robin Murphy
Signed-off-by: Krishna Reddy
---
.../devicetree/bindings/iommu/arm,smmu.yaml | 25 ++-
1 file changed, 24 insertions(+), 1 deletion(-)
diff --git
.
Reviewed-by: Jon Hunter
Reviewed-by: Nicolin Chen
Reviewed-by: Pritesh Raithatha
Reviewed-by: Robin Murphy
Reviewed-by: Thierry Reding
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu-nvidia.c | 99 +
drivers/iommu/arm-smmu.c| 17 +-
drivers/iommu
/2019/9/2/980
v1 - https://lkml.org/lkml/2019/8/29/1588
Krishna Reddy (5):
iommu/arm-smmu: move TLB timeout and spin count macros
iommu/arm-smmu: ioremap smmu mmio region before implementation init
iommu/arm-smmu: add NVIDIA implementation for ARM MMU-500 usage
dt-bindings: arm-smmu: add
Reding
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index cdd15ead9bc4..de520115d3df 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
instance is supported by standard
arm-smmu.c driver itself.
Reviewed-by: Jon Hunter
Reviewed-by: Nicolin Chen
Reviewed-by: Pritesh Raithatha
Reviewed-by: Robin Murphy
Reviewed-by: Thierry Reding
Signed-off-by: Krishna Reddy
---
MAINTAINERS | 2 +
drivers/iommu/Makefile
Move TLB timeout and spin count macros to header file to
allow using the same from vendor specific implementations.
Reviewed-by: Jon Hunter
Reviewed-by: Nicolin Chen
Reviewed-by: Pritesh Raithatha
Reviewed-by: Robin Murphy
Reviewed-by: Thierry Reding
Signed-off-by: Krishna Reddy
>On Mon, Jul 13, 2020 at 02:50:20PM +0100, Will Deacon wrote:
>> On Tue, Jul 07, 2020 at 10:00:12PM -0700, Krishna Reddy wrote:
> >> Changes in v10:
>> > Perform SMMU base ioremap before calling implementation init.
>> > Check for Global faults across both
Thanks Rob. One question on setting "minItems: ". Please see below.
>> +allOf:
>> + - if:
>> + properties:
>> +compatible:
>> + contains:
>> +enum:
>> + - nvidia,tegra194-smmu
>> +then:
>> + properties:
>> +reg:
>> +
Add binding for NVIDIA's Tegra194 SoC SMMU.
Signed-off-by: Krishna Reddy
---
.../devicetree/bindings/iommu/arm,smmu.yaml| 18 ++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
b/Documentation/devicetree/bindings/iommu
Move TLB timeout and spin count macros to header file to
allow using the same from vendor specific implementations.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu.c | 3 ---
drivers/iommu/arm-smmu.h | 2 ++
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/iommu
ioremap smmu mmio region before calling into implementation init.
This is necessary to allow mapped address available during vendor
specific implementation init.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
/10/18/1601
v2 - https://lkml.org/lkml/2019/9/2/980
v1 - https://lkml.org/lkml/2019/8/29/1588
Krishna Reddy (5):
iommu/arm-smmu: move TLB timeout and spin count macros
iommu/arm-smmu: ioremap smmu mmio region before implementation init
iommu/arm-smmu: add NVIDIA implementation for ARM MMU-500
.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu-nvidia.c | 99 +
drivers/iommu/arm-smmu.c| 17 +-
drivers/iommu/arm-smmu.h| 3 +
3 files changed, 117 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/arm-smmu-nvidia.c b/drivers/iommu
instance is supported by standard
arm-smmu.c driver itself.
Signed-off-by: Krishna Reddy
---
MAINTAINERS | 2 +
drivers/iommu/Makefile | 2 +-
drivers/iommu/arm-smmu-impl.c | 3 +
drivers/iommu/arm-smmu-nvidia.c | 179
drivers
On 01/07/2020 20:00, Krishna Reddy wrote:
>>>>>> +items:
>>>>>> + - enum:
>>>>>> + - nvdia,tegra194-smmu
>>>>>> + - const: arm,mmu-500
>>>>
>>>>> Is the fall
>> With shared irq line, the context fault identification is not optimal
>> already. Reading all the context banks all the time can be additional mmio
>> read overhead. But, it may not hurt the real use cases as these happen only
>> when there are bugs.
>Right, I did ponder the idea of a
>Yeah, I realised later last night that this probably originated from forking
>the whole driver downstream. But even then you could have treated the other
>one as a separate nsmmu with a single instance ;)
True, But the initial nvidia implementation had limitation that it can only
handle one
+items:
+ - enum:
+ - nvdia,tegra194-smmu
+ - const: arm,mmu-500
> >
>>> Is the fallback compatible appropriate here? If software treats this as a
>>> standard MMU-500 it will only program the first instance (because the
>>> second isn't
>>> +for (inst = 0; inst < nvidia_smmu->num_inst; inst++) {
>>> +irq_ret = nvidia_smmu_global_fault_inst(irq, smmu, inst);
>>> +if (irq_ret == IRQ_HANDLED)
>>> +return irq_ret;
>>
>> Any chance there could be more than one SMMU faulting by the time
>> + - description: NVIDIA SoCs that use more than one "arm,mmu-500"
> Hmm, there must be a better way to word that to express that it only applies
> to the sets of SMMUs that must be programmed identically, and not any other
> independent MMU-500s that might also happen to be in the same
>> + * When Linux kernel supports multiple SMMU devices, the SMMU device
>> +used for
>> + * isochornous HW devices should be added as a separate ARM MMU-500
>> +device
>> + * in DT and be programmed independently for efficient TLB invalidates.
>I don't understand the "When" there - the driver
Move TLB timeout and spin count macros to header file to
allow using the same values from vendor specific implementations.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu.c | 3 ---
drivers/iommu/arm-smmu.h | 2 ++
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers
Add binding for NVIDIA's Tegra194 SoC SMMU topology that is based
on ARM MMU-500.
Signed-off-by: Krishna Reddy
---
.../devicetree/bindings/iommu/arm,smmu.yaml| 18 ++
1 file changed, 18 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
b
/lkml/2019/10/30/1054
v3 - https://lkml.org/lkml/2019/10/18/1601
v2 - https://lkml.org/lkml/2019/9/2/980
v1 - https://lkml.org/lkml/2019/8/29/1588
Krishna Reddy (4):
iommu/arm-smmu: move TLB timeout and spin count macros
iommu/arm-smmu: add NVIDIA implementation for ARM MMU-500 usage
dt
ARM MMU-500s.
This implementation supports programming two or three ARM MMU-500s
identically as per DT config.
Signed-off-by: Krishna Reddy
---
MAINTAINERS | 2 +
drivers/iommu/Makefile | 2 +-
drivers/iommu/arm-smmu-impl.c | 3 +
drivers/iommu/arm-smmu
Add global/context fault hooks to allow NVIDIA SMMU implementation
handle faults across multiple SMMUs.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu-nvidia.c | 98 +
drivers/iommu/arm-smmu.c| 17 +-
drivers/iommu/arm-smmu.h| 3 +
3
>> The driver intend to support up to 3 instances. It doesn't really mandate
>> that all three instances be present in same DT node.
>> Each mmio aperture in "reg" property is an instance here. reg =
>> , , ; The reg can have
>> all three or less and driver just configures based on reg and it
>OK, well I see what you are saying, but if we intended to support all 3 for
>Tegra194, then we should ensure all 3 are initialised correctly.
The driver intend to support up to 3 instances. It doesn't really mandate that
all three instances be present in same DT node.
Each mmio aperture in
>> NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave
>> IOVA accesses across them.
>> Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
>> string for Tegra194 SoC SMMU topology.
>There is no description here of the 3rd SMMU that you mention below.
>I think
>> +struct arm_smmu_device *nvidia_smmu_impl_init(struct arm_smmu_device
>> +*smmu) {
>> +unsigned int i;
>> +for (i = 1; i < MAX_SMMU_INSTANCES; i++) {
>> +struct resource *res;
>> +
>> +res = platform_get_resource(pdev, IORESOURCE_MEM, i);
>> +if
Add global/context fault hooks to allow NVIDIA SMMU implementation
handle faults across multiple SMMUs.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu-nvidia.c | 98 +
drivers/iommu/arm-smmu.c| 17 +-
drivers/iommu/arm-smmu.h| 3 +
3
Add binding for NVIDIA's Tegra194 SoC SMMU topology that is based
on ARM MMU-500.
Signed-off-by: Krishna Reddy
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
b
/5/21/1114
v4 - https://lkml.org/lkml/2019/10/30/1054
v3 - https://lkml.org/lkml/2019/10/18/1601
v2 - https://lkml.org/lkml/2019/9/2/980
v1 - https://lkml.org/lkml/2019/8/29/1588
Krishna Reddy (3):
iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage
dt-bindings: arm-smmu: Add
NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave
IOVA accesses across them.
Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
string for Tegra194 SoC SMMU topology.
Signed-off-by: Krishna Reddy
---
MAINTAINERS | 2 +
drivers/iommu
>> +static irqreturn_t nvidia_smmu_context_fault_bank(int irq,
>> + void __iomem *cb_base = nvidia_smmu_page(smmu, inst,
>> + smmu->numpage + idx);
[...]
>> + fsr = arm_smmu_cb_read(smmu, idx, ARM_SMMU_CB_FSR);
[...]
>> + writel_relaxed(fsr, cb_base + ARM_SMMU_CB_FSR);
>It reads FSR
>> + if (!nvidia_smmu->bases[0])
>> + nvidia_smmu->bases[0] = smmu->base;
>> +
>> + return nvidia_smmu->bases[inst] + (page << smmu->pgshift); }
>Not critical -- just a nit: why not put the bases[0] in init()?
smmu->base is not available during nvidia_smmu_impl_init() call.
Add binding for NVIDIA's Tegra194 SoC SMMU topology that is based
on ARM MMU-500.
Signed-off-by: Krishna Reddy
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
b
Add global/context fault hooks to allow NVIDIA SMMU implementation
handle faults across multiple SMMUs.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu-nvidia.c | 101 +++-
drivers/iommu/arm-smmu.c| 17 +-
drivers/iommu/arm-smmu.h| 3
- https://lkml.org/lkml/2019/10/30/1054
v3 - https://lkml.org/lkml/2019/10/18/1601
v2 - https://lkml.org/lkml/2019/9/2/980
v1 - https://lkml.org/lkml/2019/8/29/1588
Krishna Reddy (3):
iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage
dt-bindings: arm-smmu: Add binding
NVIDIA's Tegra194 SoC uses two ARM MMU-500s together to interleave
IOVA accesses across them.
Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
string for Tegra194 SoC SMMU topology.
Signed-off-by: Krishna Reddy
---
MAINTAINERS | 2 +
drivers/iommu
>Should NVIDIA_TEGRA194_SMMU be a separate value for smmu->model, perhaps? That
>way we avoid this somewhat odd check here.
NVIDIA haven't made any changes to arm,mmu-500. It is only used in different
topology. New model would be mis-leading here.
As suggested by Robin, It can just be moved to
>> + - nvdia,tegra194-smmu-500
>The -500 suffix here seems a bit redundant since there's no other type of SMMU
>in Tegra194, correct?
Yeah, there is only one type of SMMU supported in T194. It was added to be
synonymous with mmu-500. Can be removed.
-KR
Add global/context fault hooks to allow NVIDIA SMMU implementation
handle faults across multiple SMMUs.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu-nvidia.c | 100
drivers/iommu/arm-smmu.c| 11 +++-
drivers/iommu/arm-smmu.h| 3 +
3
>> drivers/iommu/arm-smmu-nvidia.c:151:33: sparse: sparse: cast removes
>> address space '' of expression
Reported-by: kbuild test robot
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu-nvidia.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/io
://lkml.org/lkml/2019/10/18/1601
v2 - https://lkml.org/lkml/2019/9/2/980
v1 - https://lkml.org/lkml/2019/8/29/1588
Krishna Reddy (4):
iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage
dt-bindings: arm-smmu: Add binding for Tegra194 SMMU
iommu/arm-smmu: Add global/context fault
NVIDIA's Tegra194 soc uses two ARM MMU-500s together to interleave
IOVA accesses across them.
Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
string for Tegra194 soc.
Signed-off-by: Krishna Reddy
---
MAINTAINERS | 2 +
drivers/iommu/Makefile
Add binding for NVIDIA's Tegra194 Soc SMMU that is based
on ARM MMU-500.
Signed-off-by: Krishna Reddy
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
b/Documentation
>For the record: I don't think we should apply these because we don't have a
>good way of testing them. We currently have three problems that prevent us
>from enabling SMMU on Tegra194:
Out of three issues pointed here, I see that only issue 2) is a real blocker
for enabling SMMU HW by default
NVIDIA's Tegra194 soc uses two ARM MMU-500s together to interleave
IOVA accesses across them.
Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
string for Tegra194 soc.
Signed-off-by: Krishna Reddy
---
MAINTAINERS | 2 +
drivers/iommu/Makefile
Add global/context fault hooks to allow NVIDIA SMMU implementation
handle faults across multiple SMMUs.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu-nvidia.c | 100
drivers/iommu/arm-smmu.c| 11 +++-
drivers/iommu/arm-smmu.h| 3 +
3
Enable SMMU translations for SDHCI and EQOS transactions on T194.
Signed-off-by: Krishna Reddy
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index
Changes in v5:
Rebased on top of git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git
next
v4 - https://lkml.org/lkml/2019/10/30/1054
v3 - https://lkml.org/lkml/2019/10/18/1601
v2 - https://lkml.org/lkml/2019/9/2/980
v1 - https://lkml.org/lkml/2019/8/29/1588
Krishna Reddy (5):
iommu
Add DT node for T194 SMMU to enable SMMU support.
Signed-off-by: Krishna Reddy
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 77
1 file changed, 77 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index
Add binding for NVIDIA's Tegra194 Soc SMMU that is based
on ARM MMU-500.
Signed-off-by: Krishna Reddy
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 5 +
1 file changed, 5 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.yaml
b/Documentation
Add global/context fault hooks to allow NVIDIA SMMU implementation
handle faults across multiple SMMUs.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu-nvidia.c | 100
drivers/iommu/arm-smmu.c| 11 -
drivers/iommu/arm-smmu.h
Add DT node for T194 SMMU to enable SMMU support.
Signed-off-by: Krishna Reddy
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 77
1 file changed, 77 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
Enable SMMU translations for SDHCI and EQOS transactions on T194.
Signed-off-by: Krishna Reddy
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 6f81e90
Add binding for NVIDIA's Tegra194 Soc SMMU that is based
on ARM MMU-500.
Signed-off-by: Krishna Reddy
---
Documentation/devicetree/bindings/iommu/arm,smmu.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
b/Documentation/devicetree
://lkml.org/lkml/2019/10/18/1601
v2 - https://lkml.org/lkml/2019/9/2/980
v1 - https://lkml.org/lkml/2019/8/29/1588
Krishna Reddy (6):
iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage
dt-bindings: arm-smmu: Add binding for Tegra194 SMMU
iommu/arm-smmu: Add global/context fault
NVIDIA's Tegra194 soc uses two ARM MMU-500s together to interleave
IOVA accesses across them.
Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
string for Tegra194 soc.
Signed-off-by: Krishna Reddy
---
MAINTAINERS | 2 +
drivers/iommu/Makefile
Add Memory controller DT node on T194 and enable it.
This patch is a prerequisite for SMMU enable on T194.
Signed-off-by: Krishna Reddy
---
arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 4
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 6 ++
2 files changed, 10 insertions(+)
diff
>>https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=for-joerg/arm-smmu/updates
Thanks Will! Let me rebase my patches on top of this branch and send it out.
-KR
___
iommu mailing list
iommu@lists.linux-foundation.org
Hi Robin,
>>Apologies for crossed wires, but I had a series getting rid of
>>arm_smmu_flush_ops which was also meant to end up making things a bit easier
>>for you:
I was looking to rebase on top of your changes first. Then I read Will's reply
that said your work is queued for 5.5.
Let me
Add binding for NVIDIA's Tegra194 Soc SMMU that is based
on ARM MMU-500.
Signed-off-by: Krishna Reddy
---
Documentation/devicetree/bindings/iommu/arm,smmu.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
b/Documentation/devicetree
Changes in v3:
Rebased on top of
https://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git/ next.
Resolved compile error seen with tegra194.dtsi changes after rebase.
v2 - https://lkml.org/lkml/2019/9/2/980
v1 - https://lkml.org/lkml/2019/8/29/1588
Krishna Reddy (7):
iommu/arm-smmu
NVIDIA's Tegra194 soc uses two ARM MMU-500s together to interleave
IOVA accesses across them.
Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
string for Tegra194 soc.
Signed-off-by: Krishna Reddy
---
MAINTAINERS | 2 +
drivers/iommu/Makefile
Add Memory controller DT node on T194 and enable it.
This patch is a prerequisite for SMMU enable on T194.
Signed-off-by: Krishna Reddy
---
arch/arm64/boot/dts/nvidia/tegra194-p2888.dtsi | 4
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 6 ++
2 files changed, 10 insertions(+)
diff
Add global/context fault hooks to allow NVIDIA SMMU implementation
handle faults across multiple SMMUs.
Signed-off-by: Krishna Reddy
---
drivers/iommu/arm-smmu-nvidia.c | 100
drivers/iommu/arm-smmu.c| 11 -
drivers/iommu/arm-smmu.h
Enable SMMU translations for SDHCI and EQOS transactions on T194.
Signed-off-by: Krishna Reddy
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 6f81e90
Remove const keyword for arm_smmu_flush_ops in arm_smmu_domain
and replace direct references to arm_smmu_tlb_sync* functions with
arm_smmu_flush_ops->tlb_sync().
This is necessary for vendor specific implementations that
need to override arm_smmu_flush_ops in part or full.
Signed-off-by: Kris
Add DT node for T194 SMMU to enable SMMU support.
Signed-off-by: Krishna Reddy
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 77
1 file changed, 77 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
Enable SMMU translations for SDHCI and EQOS transactions on T194.
Signed-off-by: Krishna Reddy
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra194.dtsi
b/arch/arm64/boot/dts/nvidia/tegra194.dtsi
index 5ae3bbf
Add binding for NVIDIA's Tegra194 Soc SMMU that is based
on ARM MMU-500.
Signed-off-by: Krishna Reddy
---
Documentation/devicetree/bindings/iommu/arm,smmu.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
b/Documentation/devicetree
.
v1 - https://lkml.org/lkml/2019/8/29/1588
Krishna Reddy (7):
iommu/arm-smmu: prepare arm_smmu_flush_ops for override
iommu/arm-smmu: add NVIDIA implementation for dual ARM MMU-500 usage
dt-bindings: arm-smmu: Add binding for Tegra194 SMMU
iommu/arm-smmu: Add global/context fault implementation
NVIDIA's Tegra194 soc uses two ARM MMU-500s together to interleave
IOVA accesses across them.
Add NVIDIA implementation for dual ARM MMU-500s and add new compatible
string for Tegra194 soc.
Signed-off-by: Krishna Reddy
---
MAINTAINERS | 2 +
drivers/iommu/Makefile
1 - 100 of 151 matches
Mail list logo
