| Message ID | 20210420172619.3782831-1-thierry.reding@gmail.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | arm64: tegra: Prevent early SMMU faults | expand |
On Tue, Apr 20, 2021 at 07:26:09PM +0200, Thierry Reding wrote: > From: Thierry Reding <treding@nvidia.com> > > 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. Thanks, Thierry
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@nvidia.com> > > > > 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
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@nvidia.com> > > > > > > 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. 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
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@nvidia.com> >>>> >>>> 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
On 02/06/2021 09:33, Krzysztof Kozlowski wrote: > 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@nvidia.com> >>>>> >>> 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. OK, I think I have now the patchset you talked about - "memory: tegra: Driver unification" v2, right? Best regards, Krzysztof
On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote: > On 02/06/2021 09:33, Krzysztof Kozlowski wrote: > > 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@nvidia.com> > >>>>> > >>> 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. > > OK, I think I have now the patchset you talked about - "memory: tegra: > Driver unification" v2, right? Yes, that's the one. That series is fairly self-contained, but Dmitry's power management set has dependencies that pull in the regulator, clock and ARM SoC trees. I did a test merge of the driver unification series with a branch that has Dmitry's patches and all the dependencies and there are no conflicts so that, fortunately, doesn't further complicates things. Do you want me to send you a pull request with Dmitry's memory controller changes? You could then apply the unification series on top, which should allow this SMMU series to apply cleanly on top of that. I can also carry all these changes in the Tegra tree and send a PR in a few days once this has seen a bit more testing in linux-next, which also makes sure it's got a bit more testing in our internal test farm. Thierry
On 02/06/2021 10:52, Thierry Reding wrote: > On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote: >> On 02/06/2021 09:33, Krzysztof Kozlowski wrote: >>> 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@nvidia.com> >>>>>>> >>>>> 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. >> >> OK, I think I have now the patchset you talked about - "memory: tegra: >> Driver unification" v2, right? > > Yes, that's the one. That series is fairly self-contained, but Dmitry's > power management set has dependencies that pull in the regulator, clock > and ARM SoC trees. > > I did a test merge of the driver unification series with a branch that > has Dmitry's patches and all the dependencies and there are no conflicts > so that, fortunately, doesn't further complicates things. > > Do you want me to send you a pull request with Dmitry's memory > controller changes? You could then apply the unification series on top, > which should allow this SMMU series to apply cleanly on top of that. Makes sense and it looks quite bulletproof for future changes. Let's do like this. I will apply your patch 1/10 from this v2 on top of it and driver unification later. > I can also carry all these changes in the Tegra tree and send a PR in a > few days once this has seen a bit more testing in linux-next, which also > makes sure it's got a bit more testing in our internal test farm. > Best regards, Krzysztof
On Wed, Jun 02, 2021 at 12:44:58PM +0200, Krzysztof Kozlowski wrote: > On 02/06/2021 10:52, Thierry Reding wrote: > > On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote: > >> On 02/06/2021 09:33, Krzysztof Kozlowski wrote: > >>> 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@nvidia.com> > >>>>>>> > >>>>> 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. > >> > >> OK, I think I have now the patchset you talked about - "memory: tegra: > >> Driver unification" v2, right? > > > > Yes, that's the one. That series is fairly self-contained, but Dmitry's > > power management set has dependencies that pull in the regulator, clock > > and ARM SoC trees. > > > > I did a test merge of the driver unification series with a branch that > > has Dmitry's patches and all the dependencies and there are no conflicts > > so that, fortunately, doesn't further complicates things. > > > > Do you want me to send you a pull request with Dmitry's memory > > controller changes? You could then apply the unification series on top, > > which should allow this SMMU series to apply cleanly on top of that. > > Makes sense and it looks quite bulletproof for future changes. Let's do > like this. I will apply your patch 1/10 from this v2 on top of it and > driver unification later. Okey doke. Thierry -- please let me know which patches I can queue. Having the SMMU driver changes in the IOMMU tree really helps in case of conflicts with other SMMU changes. As I say, I can put stuff on a separate branch for you if it helps. Will
On Wed, Jun 02, 2021 at 12:44:58PM +0200, Krzysztof Kozlowski wrote: > On 02/06/2021 10:52, Thierry Reding wrote: > > On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote: > >> On 02/06/2021 09:33, Krzysztof Kozlowski wrote: > >>> 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@nvidia.com> > >>>>>>> > >>>>> 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. > >> > >> OK, I think I have now the patchset you talked about - "memory: tegra: > >> Driver unification" v2, right? > > > > Yes, that's the one. That series is fairly self-contained, but Dmitry's > > power management set has dependencies that pull in the regulator, clock > > and ARM SoC trees. > > > > I did a test merge of the driver unification series with a branch that > > has Dmitry's patches and all the dependencies and there are no conflicts > > so that, fortunately, doesn't further complicates things. > > > > Do you want me to send you a pull request with Dmitry's memory > > controller changes? You could then apply the unification series on top, > > which should allow this SMMU series to apply cleanly on top of that. > > Makes sense and it looks quite bulletproof for future changes. Let's do > like this. I will apply your patch 1/10 from this v2 on top of it and > driver unification later. The SMMU series here depends on the unification series, so the unification series needs to go first. It'd be a fair bit of work to reverse that because the ->probe_device() callback implemented by the first patch of this SMMU series is part of the tegra_mc_ops structure that's introduced in the unification series. Thierry
On 02/06/2021 16:53, Thierry Reding wrote: > On Wed, Jun 02, 2021 at 12:44:58PM +0200, Krzysztof Kozlowski wrote: >> On 02/06/2021 10:52, Thierry Reding wrote: >>> On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote: >>>> On 02/06/2021 09:33, Krzysztof Kozlowski wrote: >>>>> 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@nvidia.com> >>>>>>>>> >>>>>>> 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. >>>> >>>> OK, I think I have now the patchset you talked about - "memory: tegra: >>>> Driver unification" v2, right? >>> >>> Yes, that's the one. That series is fairly self-contained, but Dmitry's >>> power management set has dependencies that pull in the regulator, clock >>> and ARM SoC trees. >>> >>> I did a test merge of the driver unification series with a branch that >>> has Dmitry's patches and all the dependencies and there are no conflicts >>> so that, fortunately, doesn't further complicates things. >>> >>> Do you want me to send you a pull request with Dmitry's memory >>> controller changes? You could then apply the unification series on top, >>> which should allow this SMMU series to apply cleanly on top of that. >> >> Makes sense and it looks quite bulletproof for future changes. Let's do >> like this. I will apply your patch 1/10 from this v2 on top of it and >> driver unification later. > > The SMMU series here depends on the unification series, so the > unification series needs to go first. It'd be a fair bit of work to > reverse that because the ->probe_device() callback implemented by the > first patch of this SMMU series is part of the tegra_mc_ops structure > that's introduced in the unification series. Right, you already wrote it in the first email in this thread, I just reversed words in my head... Then as you wrote - take Dmitry's changes and share them via pull to me. I'll put on top the unification series, then #1 from this SMMU series and finally I'll provide a pull request for Will so his SMMU can go on. Best regards, Krzysztof
On 02/06/2021 16:58, Thierry Reding wrote: > On Wed, Jun 02, 2021 at 12:40:49PM +0100, Will Deacon wrote: >> On Wed, Jun 02, 2021 at 12:44:58PM +0200, Krzysztof Kozlowski wrote: >>> On 02/06/2021 10:52, Thierry Reding wrote: >>>> On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote: >>>>> On 02/06/2021 09:33, Krzysztof Kozlowski wrote: >>>>>> 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@nvidia.com> >>>>>>>>>> >>>>>>>> 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. >>>>> >>>>> OK, I think I have now the patchset you talked about - "memory: tegra: >>>>> Driver unification" v2, right? >>>> >>>> Yes, that's the one. That series is fairly self-contained, but Dmitry's >>>> power management set has dependencies that pull in the regulator, clock >>>> and ARM SoC trees. >>>> >>>> I did a test merge of the driver unification series with a branch that >>>> has Dmitry's patches and all the dependencies and there are no conflicts >>>> so that, fortunately, doesn't further complicates things. >>>> >>>> Do you want me to send you a pull request with Dmitry's memory >>>> controller changes? You could then apply the unification series on top, >>>> which should allow this SMMU series to apply cleanly on top of that. >>> >>> Makes sense and it looks quite bulletproof for future changes. Let's do >>> like this. I will apply your patch 1/10 from this v2 on top of it and >>> driver unification later. >> >> Okey doke. Thierry -- please let me know which patches I can queue. Having >> the SMMU driver changes in the IOMMU tree really helps in case of conflicts >> with other SMMU changes. As I say, I can put stuff on a separate branch for >> you if it helps. > > Given that the SMMU patches have a build-time dependency on the first > patch in the series, and the series depends on the unification series, I > think Krzysztof would have to pull the memory controller branch that I > have with Dmitry's work, apply the unification series on top and then > take patch 1 of this series on top of that. That's the state that you'd > have to pull into the SMMU tree to get the right dependencies. > > The SMMU pieces are the leaf of the dependency tree, so technically no > separate branch is needed, because I don't think anybody would have to > pull from it. However, a separate branch might make it easier to back > any of this work out if we have to. > > Krzysztof, I do plan on sending out a v3 of the unification series to > address the two cleanups that Dmitry and you have pointed out. After > that I can send out v3 of this series to fix the ordering issue that > Krishna had mentioned. After all of those are applied, would you be able > to provide a stable branch for Will's SMMU tree? Yes, I will provide a stable branch/tag. Best regards, Krzysztof
On Wed, Jun 02, 2021 at 12:40:49PM +0100, Will Deacon wrote: > On Wed, Jun 02, 2021 at 12:44:58PM +0200, Krzysztof Kozlowski wrote: > > On 02/06/2021 10:52, Thierry Reding wrote: > > > On Wed, Jun 02, 2021 at 09:35:13AM +0200, Krzysztof Kozlowski wrote: > > >> On 02/06/2021 09:33, Krzysztof Kozlowski wrote: > > >>> 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@nvidia.com> > > >>>>>>> > > >>>>> 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. > > >> > > >> OK, I think I have now the patchset you talked about - "memory: tegra: > > >> Driver unification" v2, right? > > > > > > Yes, that's the one. That series is fairly self-contained, but Dmitry's > > > power management set has dependencies that pull in the regulator, clock > > > and ARM SoC trees. > > > > > > I did a test merge of the driver unification series with a branch that > > > has Dmitry's patches and all the dependencies and there are no conflicts > > > so that, fortunately, doesn't further complicates things. > > > > > > Do you want me to send you a pull request with Dmitry's memory > > > controller changes? You could then apply the unification series on top, > > > which should allow this SMMU series to apply cleanly on top of that. > > > > Makes sense and it looks quite bulletproof for future changes. Let's do > > like this. I will apply your patch 1/10 from this v2 on top of it and > > driver unification later. > > Okey doke. Thierry -- please let me know which patches I can queue. Having > the SMMU driver changes in the IOMMU tree really helps in case of conflicts > with other SMMU changes. As I say, I can put stuff on a separate branch for > you if it helps. Given that the SMMU patches have a build-time dependency on the first patch in the series, and the series depends on the unification series, I think Krzysztof would have to pull the memory controller branch that I have with Dmitry's work, apply the unification series on top and then take patch 1 of this series on top of that. That's the state that you'd have to pull into the SMMU tree to get the right dependencies. The SMMU pieces are the leaf of the dependency tree, so technically no separate branch is needed, because I don't think anybody would have to pull from it. However, a separate branch might make it easier to back any of this work out if we have to. Krzysztof, I do plan on sending out a v3 of the unification series to address the two cleanups that Dmitry and you have pointed out. After that I can send out v3 of this series to fix the ordering issue that Krishna had mentioned. After all of those are applied, would you be able to provide a stable branch for Will's SMMU tree? Thierry
From: Thierry Reding <treding@nvidia.com> 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(-)