On 01/06/2021 20:08, Thierry Reding wrote:

On Tue, Jun 01, 2021 at 01:26:46PM +0100, Will Deacon wrote:

quoted

On Fri, May 28, 2021 at 07:05:28PM +0200, Thierry Reding wrote:

quoted

On Tue, Apr 20, 2021 at 07:26:09PM +0200, Thierry Reding wrote:

quoted

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel