From: Thierry Reding <redacted>
Hi,
this is a set of patches that is the result of earlier discussions
regarding early identity mappings that are needed to avoid SMMU faults
during early boot.
The goal here is to avoid early identity mappings altogether and instead
postpone the need for the identity mappings to when devices are attached
to the SMMU. This works by making the SMMU driver coordinate with the
memory controller driver on when to start enforcing SMMU translations.
This makes Tegra behave in a more standard way and pushes the code to
deal with the Tegra-specific programming into the NVIDIA SMMU
implementation.
Compared to the original version of these patches, I've split the
preparatory work into a separate patch series because it became very
large and will be mostly uninteresting for this audience.
Patch 1 provides a mechanism to program SID overrides at runtime. Patch
2 updates the ARM SMMU device tree bindings to include the Tegra186
compatible string as suggested by Robin during review.
Patches 3 and 4 create the fundamentals in the SMMU driver to support
this and also make this functionality available on Tegra186. Patch 5
hooks the ARM SMMU up to the memory controller so that the memory client
stream ID overrides can be programmed at the right time.
Patch 6 extends this mechanism to Tegra186 and patches 7-9 enable all of
this through device tree updates. Patch 10 (that was included in earlier
version to show how SMMU will be enabled for display controllers) has
been dropped for now while waiting for the identity mappings support to
land.
The end result is that various peripherals will have SMMU enabled, while
the display controllers will keep using passthrough, as initially set up
by firmware. Once the device tree bindings have been accepted and the
SMMU driver has been updated to create identity mappings for the display
controllers, they can be hooked up to the SMMU and the code in this
series will automatically program the SID overrides to enable SMMU
translations at the right time.
Will, Krzysztof: as discussed, it'd be best if Krzysztof picked up patch
1 into the memory controller tree on top of v3 of the driver unification
series I sent out earlier today and then sent out a PR for Will to merge
and apply patches 2-6. I can then take patches 7-9 in via the Tegra tree
since there are no hard dependencies.
Changes in v3:
- move hunk from patch 4 to patch 5 to preserve bisectibility
Changes in v2:
- split off the preparatory work into a separate series (that needs to
be applied first)
- address review comments by Robin
Thierry
Thierry Reding (9):
memory: tegra: Implement SID override programming
dt-bindings: arm-smmu: Add Tegra186 compatible string
iommu/arm-smmu: Implement ->probe_finalize()
iommu/arm-smmu: tegra: Detect number of instances at runtime
iommu/arm-smmu: tegra: Implement SID override programming
iommu/arm-smmu: Use Tegra implementation on Tegra186
arm64: tegra: Use correct compatible string for Tegra186 SMMU
arm64: tegra: Hook up memory controller to SMMU on Tegra186
arm64: tegra: Enable SMMU support on Tegra194
.../devicetree/bindings/iommu/arm,smmu.yaml | 11 ++-
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 4 +-
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 86 ++++++++++++++++++
drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 3 +-
drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c | 90 +++++++++++++++----
drivers/iommu/arm/arm-smmu/arm-smmu.c | 13 +++
drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 +
drivers/memory/tegra/mc.c | 9 ++
drivers/memory/tegra/tegra186.c | 72 +++++++++++++++
include/soc/tegra/mc.h | 3 +
10 files changed, 269 insertions(+), 23 deletions(-)
--
2.31.1
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Thierry Reding <redacted>
Instead of programming all SID overrides during early boot, perform the
operation on-demand after the SMMU translations have been set up for a
device. This reuses data from device tree to match memory clients for a
device and programs the SID specified in device tree, which corresponds
to the SID used for the SMMU context banks for the device.
Signed-off-by: Thierry Reding <redacted>
---
drivers/memory/tegra/mc.c | 9 +++++
drivers/memory/tegra/tegra186.c | 72 +++++++++++++++++++++++++++++++++
include/soc/tegra/mc.h | 3 ++
3 files changed, 84 insertions(+)
From: Thierry Reding <redacted>
Parse the reg property in device tree and detect the number of instances
represented by a device tree node. This is subsequently needed in order
to support single-instance SMMUs with the Tegra implementation because
additional programming is needed to properly configure the SID override
registers in the memory controller.
Signed-off-by: Thierry Reding <redacted>
---
Changes in v3:
- move .probe_finalize initialization to later patch
Changes in v2:
- provide a separate implementation to simplify single instances
drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c | 57 ++++++++++++++------
1 file changed, 41 insertions(+), 16 deletions(-)
From: Thierry Reding <redacted>
Tegra186 requires the same SID override programming as Tegra194 in order
to seamlessly transition from the firmware framebuffer to the Linux
framebuffer, so the Tegra implementation needs to be used on Tegra186
devices as well.
Signed-off-by: Thierry Reding <redacted>
---
drivers/iommu/arm/arm-smmu/arm-smmu-impl.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
From: Thierry Reding <redacted>
The SMMU found on Tegra186 requires interoperation with the memory
controller in order to program stream ID overrides. The generic ARM SMMU
500 compatible is therefore inaccurate. Replace it with a more correct,
SoC-specific compatible string.
Signed-off-by: Thierry Reding <redacted>
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Thierry Reding <redacted>
The secure firmware keeps some SID override registers set as passthrough
in order to allow devices such as the display controller to operate with
no knowledge of SMMU translations until an operating system driver takes
over. This is needed in order to seamlessly transition from the firmware
framebuffer to the OS framebuffer.
Upon successfully attaching a device to the SMMU and in the process
creating identity mappings for memory regions that are being accessed,
the Tegra implementation will call into the memory controller driver to
program the override SIDs appropriately.
Signed-off-by: Thierry Reding <redacted>
---
Changes in v3:
- move .probe_finalize initialization to this patch
drivers/iommu/arm/arm-smmu/arm-smmu-nvidia.c | 33 ++++++++++++++++++--
1 file changed, 30 insertions(+), 3 deletions(-)
From: Thierry Reding <redacted>
The ARM SMMU instantiations found on Tegra186 and later need inter-
operation with the memory controller in order to correctly program
stream ID overrides.
Furthermore, on Tegra194 multiple instances of the SMMU can gang up
to achieve higher throughput. In order to do this, they have to be
programmed identically so that the memory controller can interleave
memory accesses between them.
Add the Tegra186 compatible string to make sure the interoperation
with the memory controller can be enabled on that SoC generation.
Signed-off-by: Thierry Reding <redacted>
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
@@ -54,8 +54,14 @@ properties:-const:arm,mmu-500-description:NVIDIA SoCs that program two ARM MMU-500s identicallyitems:+-description:NVIDIA SoCs that require memory controller interaction+and may program multiple ARM MMU-500s identically with the memory+controller interleaving translations between multiple instances+for improved performance.+items:-enum:--nvidia,tegra194-smmu+-const:nvidia,tegra194-smmu+-const:nvidia,tegra186-smmu-const:nvidia,smmu-500-items:-const:arm,mmu-500
From: Thierry Reding <redacted>
Implement a ->probe_finalize() callback that can be used by vendor
implementations to perform extra programming necessary after devices
have been attached to the SMMU.
Signed-off-by: Thierry Reding <redacted>
---
Changes in v2:
- remove unnecessarily paranoid check
drivers/iommu/arm/arm-smmu/arm-smmu.c | 13 +++++++++++++
drivers/iommu/arm/arm-smmu/arm-smmu.h | 1 +
2 files changed, 14 insertions(+)
From: Thierry Reding <redacted>
On Tegra186 and later, the memory controller needs to be programmed in
coordination with any of the ARM SMMU instances to configure the stream
ID used for each memory client.
To support this, add a phandle reference to the memory controller to the
SMMU device tree node.
Signed-off-by: Thierry Reding <redacted>
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 2 ++
1 file changed, 2 insertions(+)
From: Thierry Reding <redacted>
Add the device tree node for the dual-SMMU found on Tegra194 and hook up
peripherals such as host1x, BPMP, HDA, SDMMC, EQOS and VIC.
Signed-off-by: Thierry Reding <redacted>
---
arch/arm64/boot/dts/nvidia/tegra194.dtsi | 86 ++++++++++++++++++++++++
1 file changed, 86 insertions(+)
From: Krzysztof Kozlowski <hidden> Date: 2021-06-03 19:53:23
On Thu, 3 Jun 2021 18:46:23 +0200, Thierry Reding wrote:
this is a set of patches that is the result of earlier discussions
regarding early identity mappings that are needed to avoid SMMU faults
during early boot.
The goal here is to avoid early identity mappings altogether and instead
postpone the need for the identity mappings to when devices are attached
to the SMMU. This works by making the SMMU driver coordinate with the
memory controller driver on when to start enforcing SMMU translations.
This makes Tegra behave in a more standard way and pushes the code to
deal with the Tegra-specific programming into the NVIDIA SMMU
implementation.
[...]
Applied, thanks!
[1/9] memory: tegra: Implement SID override programming
commit: 393d66fd2cacba3e6aa95d7bb38790bfb7b1cc3a
Best regards,
--
Krzysztof Kozlowski [off-list ref]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Krzysztof Kozlowski <hidden> Date: 2021-06-11 06:58:53
On Thu, 3 Jun 2021 18:46:23 +0200, Thierry Reding wrote:
this is a set of patches that is the result of earlier discussions
regarding early identity mappings that are needed to avoid SMMU faults
during early boot.
The goal here is to avoid early identity mappings altogether and instead
postpone the need for the identity mappings to when devices are attached
to the SMMU. This works by making the SMMU driver coordinate with the
memory controller driver on when to start enforcing SMMU translations.
This makes Tegra behave in a more standard way and pushes the code to
deal with the Tegra-specific programming into the NVIDIA SMMU
implementation.
[...]
Applied, thanks!
[1/9] memory: tegra: Implement SID override programming
(no commit info)
[2/9] dt-bindings: arm-smmu: Add Tegra186 compatible string
commit: 4287861dca9d77490ee50de42aa3ada92da86c9d
[3/9] - skipped
[4/9] iommu/arm-smmu: tegra: Detect number of instances at runtime
commit: 7ecbf253f8d64c08de28d16a66e3abbe873f6c9f
[5/9] iommu/arm-smmu: tegra: Implement SID override programming
commit: 8eb68595475ac5fcaaa3718a173283df48cb4ef1
[6/9] iommu/arm-smmu: Use Tegra implementation on Tegra186
commit: 2c1bc371268862a991a6498e1dddc8971b9076b8
Best regards,
--
Krzysztof Kozlowski [off-list ref]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Fri, Jun 11, 2021 at 08:48:00AM +0200, Krzysztof Kozlowski wrote:
On Thu, 3 Jun 2021 18:46:23 +0200, Thierry Reding wrote:
quoted
this is a set of patches that is the result of earlier discussions
regarding early identity mappings that are needed to avoid SMMU faults
during early boot.
The goal here is to avoid early identity mappings altogether and instead
postpone the need for the identity mappings to when devices are attached
to the SMMU. This works by making the SMMU driver coordinate with the
memory controller driver on when to start enforcing SMMU translations.
This makes Tegra behave in a more standard way and pushes the code to
deal with the Tegra-specific programming into the NVIDIA SMMU
implementation.
[...]
Applied, thanks!
[1/9] memory: tegra: Implement SID override programming
(no commit info)
[2/9] dt-bindings: arm-smmu: Add Tegra186 compatible string
commit: 4287861dca9d77490ee50de42aa3ada92da86c9d
[3/9] - skipped
[4/9] iommu/arm-smmu: tegra: Detect number of instances at runtime
commit: 7ecbf253f8d64c08de28d16a66e3abbe873f6c9f
[5/9] iommu/arm-smmu: tegra: Implement SID override programming
commit: 8eb68595475ac5fcaaa3718a173283df48cb4ef1
[6/9] iommu/arm-smmu: Use Tegra implementation on Tegra186
commit: 2c1bc371268862a991a6498e1dddc8971b9076b8
I've applied patches 7-9 to the Tegra tree.
Thanks Krzysztof and Will for your help in getting this over the finish
line!
Thierry
From: Marek Szyprowski <m.szyprowski@samsung.com> Date: 2021-06-15 21:45:55
Hi,
On 03.06.2021 18:46, Thierry Reding wrote:
From: Thierry Reding <redacted>
Implement a ->probe_finalize() callback that can be used by vendor
implementations to perform extra programming necessary after devices
have been attached to the SMMU.
Signed-off-by: Thierry Reding <redacted>
This patch landed recently in linux-next as commit 0d97174aeadf
("iommu/arm-smmu: Implement ->probe_finalize()"). It causes the
following issue on ARM Juno R1 board:
arm-smmu 2b500000.iommu: probing hardware configuration...
arm-smmu 2b500000.iommu: SMMUv1 with:
arm-smmu 2b500000.iommu: stage 2 translation
arm-smmu 2b500000.iommu: coherent table walk
arm-smmu 2b500000.iommu: stream matching with 32 register groups
arm-smmu 2b500000.iommu: 4 context banks (4 stage-2 only)
arm-smmu 2b500000.iommu: Supported page sizes: 0x60211000
arm-smmu 2b500000.iommu: Stage-2: 40-bit IPA -> 40-bit PA
arm-smmu 7fb00000.iommu: probing hardware configuration...
arm-smmu 7fb00000.iommu: SMMUv1 with:
arm-smmu 7fb00000.iommu: stage 2 translation
arm-smmu 7fb00000.iommu: coherent table walk
arm-smmu 7fb00000.iommu: stream matching with 16 register groups
arm-smmu 7fb00000.iommu: 4 context banks (4 stage-2 only)
arm-smmu 7fb00000.iommu: Supported page sizes: 0x60211000
arm-smmu 7fb00000.iommu: Stage-2: 40-bit IPA -> 40-bit PA
arm-smmu 7fb10000.iommu: probing hardware configuration...
arm-smmu 7fb10000.iommu: SMMUv1 with:
arm-smmu 7fb10000.iommu: stage 2 translation
arm-smmu 7fb10000.iommu: non-coherent table walk
arm-smmu 7fb10000.iommu: (IDR0.CTTW overridden by FW configuration)
arm-smmu 7fb10000.iommu: stream matching with 2 register groups
arm-smmu 7fb10000.iommu: 1 context banks (1 stage-2 only)
arm-smmu 7fb10000.iommu: Supported page sizes: 0x60211000
arm-smmu 7fb10000.iommu: Stage-2: 40-bit IPA -> 40-bit PA
arm-smmu 7fb20000.iommu: probing hardware configuration...
arm-smmu 7fb20000.iommu: SMMUv1 with:
arm-smmu 7fb20000.iommu: stage 2 translation
arm-smmu 7fb20000.iommu: non-coherent table walk
arm-smmu 7fb20000.iommu: (IDR0.CTTW overridden by FW configuration)
arm-smmu 7fb20000.iommu: stream matching with 2 register groups
arm-smmu 7fb20000.iommu: 1 context banks (1 stage-2 only)
arm-smmu 7fb20000.iommu: Supported page sizes: 0x60211000
arm-smmu 7fb20000.iommu: Stage-2: 40-bit IPA -> 40-bit PA
arm-smmu 7fb30000.iommu: probing hardware configuration...
arm-smmu 7fb30000.iommu: SMMUv1 with:
arm-smmu 7fb30000.iommu: stage 2 translation
arm-smmu 7fb30000.iommu: coherent table walk
arm-smmu 7fb30000.iommu: stream matching with 2 register groups
arm-smmu 7fb30000.iommu: 1 context banks (1 stage-2 only)
arm-smmu 7fb30000.iommu: Supported page sizes: 0x60211000
arm-smmu 7fb30000.iommu: Stage-2: 40-bit IPA -> 40-bit PA
tda998x 0-0070: found TDA19988
tda998x 0-0071: found TDA19988
brd: module loaded
loop: module loaded
megasas: 07.714.04.00-rc1
sata_sil24 0000:03:00.0: Adding to iommu group 0
Unable to handle kernel NULL pointer dereference at virtual address
0000000000000070
Mem abort info:
ESR = 0x96000004
EC = 0x25: DABT (current EL), IL = 32 bits
SET = 0, FnV = 0
EA = 0, S1PTW = 0
Data abort info:
ISV = 0, ISS = 0x00000004
CM = 0, WnR = 0
[0000000000000070] user address but active_mm is swapper
Internal error: Oops: 96000004 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.13.0-rc1+ #3466
Hardware name: ARM Juno development board (r1) (DT)
pstate: 20000005 (nzCv daif -PAN -UAO -TCO BTYPE=--)
pc : arm_smmu_probe_finalize+0x14/0x48
lr : iommu_probe_device+0x74/0x120
...
Call trace:
arm_smmu_probe_finalize+0x14/0x48
of_iommu_configure+0xe4/0x1b8
of_dma_configure_id+0xf8/0x2d8
pci_dma_configure+0x44/0x88
really_probe+0xc0/0x3c0
driver_probe_device+0x60/0xc0
device_driver_attach+0x6c/0x78
__driver_attach+0xc0/0x100
bus_for_each_dev+0x68/0xc8
driver_attach+0x20/0x28
bus_add_driver+0x168/0x1f8
driver_register+0x60/0x110
__pci_register_driver+0x5c/0x68
sil24_pci_driver_init+0x20/0x28
do_one_initcall+0x84/0x450
kernel_init_freeable+0x2dc/0x334
kernel_init+0x10/0x110
ret_from_fork+0x10/0x18
Code: b40001e1 f9405821 f9400023 f9401461 (f9403822)
---[ end trace 561eda4b855861d1 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
SMP: stopping secondary CPUs
Kernel Offset: disabled
CPU features: 0x00240022,25006086
Memory Limit: none
---[ end Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0000000b ]---
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Robin Murphy <robin.murphy@arm.com> Date: 2021-06-15 21:48:01
On 2021-06-15 19:01, Marek Szyprowski wrote:
Hi,
On 03.06.2021 18:46, Thierry Reding wrote:
quoted
From: Thierry Reding <redacted>
Implement a ->probe_finalize() callback that can be used by vendor
implementations to perform extra programming necessary after devices
have been attached to the SMMU.
Signed-off-by: Thierry Reding <redacted>
This patch landed recently in linux-next as commit 0d97174aeadf
("iommu/arm-smmu: Implement ->probe_finalize()"). It causes the
following issue on ARM Juno R1 board:
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
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Rob Herring <robh@kernel.org> Date: 2021-06-18 19:50:01
On Thu, Jun 3, 2021 at 10:49 AM Thierry Reding [off-list ref] wrote:
quoted hunk
From: Thierry Reding <redacted>
The ARM SMMU instantiations found on Tegra186 and later need inter-
operation with the memory controller in order to correctly program
stream ID overrides.
Furthermore, on Tegra194 multiple instances of the SMMU can gang up
to achieve higher throughput. In order to do this, they have to be
programmed identically so that the memory controller can interleave
memory accesses between them.
Add the Tegra186 compatible string to make sure the interoperation
with the memory controller can be enabled on that SoC generation.
Signed-off-by: Thierry Reding <redacted>
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
@@ -54,8 +54,14 @@ properties:-const:arm,mmu-500-description:NVIDIA SoCs that program two ARM MMU-500s identicallyitems:+-description:NVIDIA SoCs that require memory controller interaction
This is not valid jsonschema:
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:4:items: 'anyOf' conditional failed, one
must be fixed:
None is not of type 'object', 'boolean'
None is not of type 'array'
from schema $id: http://json-schema.org/draft-07/schema#
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:4:items: 'oneOf' conditional failed, one
must be fixed:
None is not of type 'object'
None is not of type 'array'
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:4:items: 'oneOf' conditional failed, one
must be fixed:
None is not of type 'object'
None is not of type 'array'
from schema $id: http://devicetree.org/meta-schemas/string-array.yaml#
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:5:items: 'oneOf' conditional failed, one
must be fixed:
[{'enum': [{'const': 'nvidia,tegra194-smmu'}, {'const':
'nvidia,tegra186-smmu'}]}, {'const': 'nvidia,smmu-500'}] is not of
type 'object'
{'const': 'nvidia,tegra194-smmu'} is not of type 'string'
{'const': 'nvidia,tegra186-smmu'} is not of type 'string'
from schema $id: http://devicetree.org/meta-schemas/string-array.yaml#
This was not reviewed nor tested since the DT list was not Cc'ed.
Rob
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
From: Krzysztof Kozlowski <hidden> Date: 2021-06-21 06:48:47
On 18/06/2021 21:47, Rob Herring wrote:
On Thu, Jun 3, 2021 at 10:49 AM Thierry Reding [off-list ref] wrote:
quoted
From: Thierry Reding <redacted>
The ARM SMMU instantiations found on Tegra186 and later need inter-
operation with the memory controller in order to correctly program
stream ID overrides.
Furthermore, on Tegra194 multiple instances of the SMMU can gang up
to achieve higher throughput. In order to do this, they have to be
programmed identically so that the memory controller can interleave
memory accesses between them.
Add the Tegra186 compatible string to make sure the interoperation
with the memory controller can be enabled on that SoC generation.
Signed-off-by: Thierry Reding <redacted>
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
@@ -54,8 +54,14 @@ properties:-const:arm,mmu-500-description:NVIDIA SoCs that program two ARM MMU-500s identicallyitems:+-description:NVIDIA SoCs that require memory controller interaction
This is not valid jsonschema:
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:4:items: 'anyOf' conditional failed, one
must be fixed:
None is not of type 'object', 'boolean'
None is not of type 'array'
from schema $id: http://json-schema.org/draft-07/schema#
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:4:items: 'oneOf' conditional failed, one
must be fixed:
None is not of type 'object'
None is not of type 'array'
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:4:items: 'oneOf' conditional failed, one
must be fixed:
None is not of type 'object'
None is not of type 'array'
from schema $id: http://devicetree.org/meta-schemas/string-array.yaml#
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:5:items: 'oneOf' conditional failed, one
must be fixed:
[{'enum': [{'const': 'nvidia,tegra194-smmu'}, {'const':
'nvidia,tegra186-smmu'}]}, {'const': 'nvidia,smmu-500'}] is not of
type 'object'
{'const': 'nvidia,tegra194-smmu'} is not of type 'string'
{'const': 'nvidia,tegra186-smmu'} is not of type 'string'
from schema $id: http://devicetree.org/meta-schemas/string-array.yaml#
This was not reviewed nor tested since the DT list was not Cc'ed.
Ugh, I see now weird empty item on a list... and not only DT list was
skipped - Thierry did not Cc you either.
My bad, I did not check that patch thoroughly before applying.
Thierry, please Cc folks mentioned by get_maintainer.pl. Either sent a
fix or a revert, if fix needs more time.
Additionally, why the patch changes reg to "minItems: 1" for
nvidia,tegra194-smmu?
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
On Mon, Jun 21, 2021 at 08:46:54AM +0200, Krzysztof Kozlowski wrote:
On 18/06/2021 21:47, Rob Herring wrote:
quoted
On Thu, Jun 3, 2021 at 10:49 AM Thierry Reding [off-list ref] wrote:
quoted
From: Thierry Reding <redacted>
The ARM SMMU instantiations found on Tegra186 and later need inter-
operation with the memory controller in order to correctly program
stream ID overrides.
Furthermore, on Tegra194 multiple instances of the SMMU can gang up
to achieve higher throughput. In order to do this, they have to be
programmed identically so that the memory controller can interleave
memory accesses between them.
Add the Tegra186 compatible string to make sure the interoperation
with the memory controller can be enabled on that SoC generation.
Signed-off-by: Thierry Reding <redacted>
---
Documentation/devicetree/bindings/iommu/arm,smmu.yaml | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
@@ -54,8 +54,14 @@ properties:-const:arm,mmu-500-description:NVIDIA SoCs that program two ARM MMU-500s identicallyitems:+-description:NVIDIA SoCs that require memory controller interaction
This is not valid jsonschema:
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:4:items: 'anyOf' conditional failed, one
must be fixed:
None is not of type 'object', 'boolean'
None is not of type 'array'
from schema $id: http://json-schema.org/draft-07/schema#
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:4:items: 'oneOf' conditional failed, one
must be fixed:
None is not of type 'object'
None is not of type 'array'
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:4:items: 'oneOf' conditional failed, one
must be fixed:
None is not of type 'object'
None is not of type 'array'
from schema $id: http://devicetree.org/meta-schemas/string-array.yaml#
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:5:items: 'oneOf' conditional failed, one
must be fixed:
[{'enum': [{'const': 'nvidia,tegra194-smmu'}, {'const':
'nvidia,tegra186-smmu'}]}, {'const': 'nvidia,smmu-500'}] is not of
type 'object'
{'const': 'nvidia,tegra194-smmu'} is not of type 'string'
{'const': 'nvidia,tegra186-smmu'} is not of type 'string'
from schema $id: http://devicetree.org/meta-schemas/string-array.yaml#
This was not reviewed nor tested since the DT list was not Cc'ed.
Ugh, I see now weird empty item on a list... and not only DT list was
skipped - Thierry did not Cc you either.
This seemed like a too trivial addition to waste Rob's time on, so I
didn't add him (or the DT list for that matter) on Cc. The ARM SMMU
maintainers had reviewed this, which seemed like it was enough for what
the DT bindings change was doing.
In any case, I clearly should've checked the DT binding check output
more carefully. It's rather messy for Tegra because there's quite a few
that we haven't converted yet. I'll have to resume my effort to convert
the remaining ones and fixup the device trees so that we can actually
run the DT binding and DTB validation checks more usefully.
My bad, I did not check that patch thoroughly before applying.
Thierry, please Cc folks mentioned by get_maintainer.pl. Either sent a
fix or a revert, if fix needs more time.
I've sent out a follow-up fix that removes the two bogus lines. It looks
like that was the result of a bad conflict resolution on my part.
Additionally, why the patch changes reg to "minItems: 1" for
nvidia,tegra194-smmu?
This is because originally the Tegra194 SMMU nodes were supposed to only
represent a "dual" instance. However, on Tegra194 there are three SMMU
instances in total, with the third instance (dedicated for isochronous
traffic) being completely separate and having only a single range of
registers.
That third instance was previously supposed to be covered by the normal
"arm,mmu-500" compatible string, but given that we really need that
interoperation between SMMU and memory controller for SID override
programming, we need the Tegra-specific compatible for the ISO instance
of the SMMU as well. And since that uses only one set of registers,
minItems had to become 1.
Thierry
@@ -54,8 +54,14 @@ properties:-const:arm,mmu-500-description:NVIDIA SoCs that program two ARM MMU-500s identicallyitems:+-description:NVIDIA SoCs that require memory controller interaction
This is not valid jsonschema:
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:4:items: 'anyOf' conditional failed, one
must be fixed:
None is not of type 'object', 'boolean'
None is not of type 'array'
from schema $id: http://json-schema.org/draft-07/schema#
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:4:items: 'oneOf' conditional failed, one
must be fixed:
None is not of type 'object'
None is not of type 'array'
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:4:items: 'oneOf' conditional failed, one
must be fixed:
None is not of type 'object'
None is not of type 'array'
from schema $id: http://devicetree.org/meta-schemas/string-array.yaml#
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:5:items: 'oneOf' conditional failed, one
must be fixed:
[{'enum': [{'const': 'nvidia,tegra194-smmu'}, {'const':
'nvidia,tegra186-smmu'}]}, {'const': 'nvidia,smmu-500'}] is not of
type 'object'
{'const': 'nvidia,tegra194-smmu'} is not of type 'string'
{'const': 'nvidia,tegra186-smmu'} is not of type 'string'
from schema $id: http://devicetree.org/meta-schemas/string-array.yaml#
This was not reviewed nor tested since the DT list was not Cc'ed.
Ugh, I see now weird empty item on a list... and not only DT list was
skipped - Thierry did not Cc you either.
This seemed like a too trivial addition to waste Rob's time on, so I
didn't add him (or the DT list for that matter) on Cc. The ARM SMMU
maintainers had reviewed this, which seemed like it was enough for what
the DT bindings change was doing.
Hmm, I didn't review it. I find the yaml stuff unreadable so I usually
wait for the DT folks to ack bindings changes before I queue them in the
SMMU tree.
Will
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
@@ -54,8 +54,14 @@ properties:-const:arm,mmu-500-description:NVIDIA SoCs that program two ARM MMU-500s identicallyitems:+-description:NVIDIA SoCs that require memory controller interaction
This is not valid jsonschema:
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:4:items: 'anyOf' conditional failed, one
must be fixed:
None is not of type 'object', 'boolean'
None is not of type 'array'
from schema $id: http://json-schema.org/draft-07/schema#
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:4:items: 'oneOf' conditional failed, one
must be fixed:
None is not of type 'object'
None is not of type 'array'
from schema $id: http://devicetree.org/meta-schemas/keywords.yaml#
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:4:items: 'oneOf' conditional failed, one
must be fixed:
None is not of type 'object'
None is not of type 'array'
from schema $id: http://devicetree.org/meta-schemas/string-array.yaml#
/builds/robherring/linux-dt/Documentation/devicetree/bindings/iommu/arm,smmu.yaml:
properties:compatible:oneOf:5:items: 'oneOf' conditional failed, one
must be fixed:
[{'enum': [{'const': 'nvidia,tegra194-smmu'}, {'const':
'nvidia,tegra186-smmu'}]}, {'const': 'nvidia,smmu-500'}] is not of
type 'object'
{'const': 'nvidia,tegra194-smmu'} is not of type 'string'
{'const': 'nvidia,tegra186-smmu'} is not of type 'string'
from schema $id: http://devicetree.org/meta-schemas/string-array.yaml#
This was not reviewed nor tested since the DT list was not Cc'ed.
Ugh, I see now weird empty item on a list... and not only DT list was
skipped - Thierry did not Cc you either.
This seemed like a too trivial addition to waste Rob's time on, so I
didn't add him (or the DT list for that matter) on Cc. The ARM SMMU
maintainers had reviewed this, which seemed like it was enough for what
the DT bindings change was doing.
Hmm, I didn't review it. I find the yaml stuff unreadable so I usually
wait for the DT folks to ack bindings changes before I queue them in the
SMMU tree.
Alright... in the future I'll make sure to always Cc DT folks, even for
trivial stuff like this.
Thierry