On 01/06/2021 20:08, Thierry Reding wrote: > On Tue, Jun 01, 2021 at 01:26:46PM +0100, Will Deacon wrote: >> On Fri, May 28, 2021 at 07:05:28PM +0200, Thierry Reding wrote: >>> On Tue, Apr 20, 2021 at 07:26:09PM +0200, Thierry Reding wrote: >>>> From: Thierry Reding <treding@xxxxxxxxxx> >>>> >>>> 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 is included here to show how >>>> SMMU will be enabled for display controllers. However, it cannot be >>>> applied yet because the code to create identity mappings for potentially >>>> live framebuffers hasn't been merged yet. >>>> >>>> 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. >>>> >>>> Note that the series creates a compile time dependency between the >>>> memory controller and IOMMU trees. If it helps I can provide a branch >>>> for each tree, modelling the dependency, once the series has been >>>> reviewed. >>>> >>>> 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 (10): >>>> 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 >>>> arm64: tegra: Enable SMMU support for display on Tegra194 >>>> >>>> .../devicetree/bindings/iommu/arm,smmu.yaml | 11 +- >>>> arch/arm64/boot/dts/nvidia/tegra186.dtsi | 4 +- >>>> arch/arm64/boot/dts/nvidia/tegra194.dtsi | 166 ++++++++++++++++++ >>>> 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, 349 insertions(+), 23 deletions(-) >>> >>> Will, Robin, >>> >>> do you have any more comments on the ARM SMMU bits of this series? If >>> not, can you guys provide an Acked-by so that Krzysztof can pick this >>> (modulo the DT patches) up into the memory-controller tree for v5.14? >>> >>> I'll send out a v3 with the bisectibilitiy fix that Krishna pointed >>> out. >> >> Probably best if I queue 3-6 on a separate branch once you send a v3, >> then Krzysztof can pull that in if he needs it. > > Patch 5 has a build-time dependency on patch 1, so they need to go in > together. The reason why I suggested Krzysztof pick these up is because > there is a restructuring series that this depends on, which will go into > Krzysztof's tree. So in order to pull in 3-6, you'd get a bunch of other > and mostly unrelated stuff as well. I missed that part... what other series are needed for this one? Except Dmitry's power management set I do not have anything in my sight for Tegras memory controllers. Anyway, I can take the memory bits and provide a stable tag with these. Recently there was quite a lot work around Tegra memory controllers, so this makes especially sense if new patches appear. > > Alternatively I can set this all up on stable branches and send out pull > requests for both you and Krzysztof to merge. Or if this is all too > complicated and you'd just prefer to ack the patches I could also take > this through ARM SoC via the Tegra tree. > > Thierry > Best regards, Krzysztof
