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. Will
