Message ID | 20210607084910.21024-1-krzysztof.kozlowski@canonical.com (mailing list archive) |
---|---|
State | Mainlined |
Headers | show |
Series | [GIT,PULL] memory: Tegra memory controller for v5.14 | expand |
Hi Krzysztof, Thierry, On Mon, Jun 07, 2021 at 10:49:10AM +0200, Krzysztof Kozlowski wrote: > Hi Thierry and Will, > > This is the pull for you to base further SMMU aptches (prevent early SMMU > faults). This is a tonne of code for me to pull into the SMMU tree given that I only want one patch! Thierry, if I just stick: https://lore.kernel.org/r/20210603164632.1000458-4-thierry.reding@gmail.com on its own branch, can you stitch together whatever you need? Will
On Tue, Jun 08, 2021 at 01:01:29PM +0100, Will Deacon wrote: > Hi Krzysztof, Thierry, > > On Mon, Jun 07, 2021 at 10:49:10AM +0200, Krzysztof Kozlowski wrote: > > Hi Thierry and Will, > > > > This is the pull for you to base further SMMU aptches (prevent early SMMU > > faults). > > This is a tonne of code for me to pull into the SMMU tree given that I only > want one patch! > > Thierry, if I just stick: > > https://lore.kernel.org/r/20210603164632.1000458-4-thierry.reding@gmail.com > > on its own branch, can you stitch together whatever you need? I'm not sure I understand what you're proposing. For reference, here's the set of patches that I sent out: 1. memory: tegra: Implement SID override programming 2. dt-bindings: arm-smmu: Add Tegra186 compatible string 3. iommu/arm-smmu: Implement ->probe_finalize() 4. iommu/arm-smmu: tegra: Detect number of instances at runtime 5. iommu/arm-smmu: tegra: Implement SID override programming 6. iommu/arm-smmu: Use Tegra implementation on Tegra186 7. arm64: tegra: Use correct compatible string for Tegra186 SMMU 8. arm64: tegra: Hook up memory controller to SMMU on Tegra186 9. arm64: tegra: Enable SMMU support on Tegra194 Krzysztof already picked up patch 1 and I was assuming that you'd pick up 2-6 because they are to the ARM SMMU driver. However, if you're primarily interested in just patch 3, which is more "core" ARM SMMU than the rest, which are Tegra-specific, then I suppose what we could do is for you to give an Acked-by on the rest (2, 4-6) and then Krzysztof or I can pick them up and take them via ARM SoC, based on the stable branch from your tree that only has patch 3. Patch 6 touches arm-smmu-impl.c, though it's a two-line change that touches only the Tegra-specific matching bit in arm_smmu_impl_init(), so the likelihood of that conflicting with anything else is fairly small. Is that what you were proposing? Thierry
On Tue, Jun 08, 2021 at 04:38:48PM +0200, Thierry Reding wrote: > On Tue, Jun 08, 2021 at 01:01:29PM +0100, Will Deacon wrote: > > On Mon, Jun 07, 2021 at 10:49:10AM +0200, Krzysztof Kozlowski wrote: > > > This is the pull for you to base further SMMU aptches (prevent early SMMU > > > faults). > > > > This is a tonne of code for me to pull into the SMMU tree given that I only > > want one patch! > > > > Thierry, if I just stick: > > > > https://lore.kernel.org/r/20210603164632.1000458-4-thierry.reding@gmail.com > > > > on its own branch, can you stitch together whatever you need? > > I'm not sure I understand what you're proposing. For reference, here's > the set of patches that I sent out: > > 1. memory: tegra: Implement SID override programming > 2. dt-bindings: arm-smmu: Add Tegra186 compatible string > 3. iommu/arm-smmu: Implement ->probe_finalize() > 4. iommu/arm-smmu: tegra: Detect number of instances at runtime > 5. iommu/arm-smmu: tegra: Implement SID override programming > 6. iommu/arm-smmu: Use Tegra implementation on Tegra186 > 7. arm64: tegra: Use correct compatible string for Tegra186 SMMU > 8. arm64: tegra: Hook up memory controller to SMMU on Tegra186 > 9. arm64: tegra: Enable SMMU support on Tegra194 > > Krzysztof already picked up patch 1 and I was assuming that you'd pick > up 2-6 because they are to the ARM SMMU driver. However, if you're > primarily interested in just patch 3, which is more "core" ARM SMMU than > the rest, which are Tegra-specific, then I suppose what we could do is > for you to give an Acked-by on the rest (2, 4-6) and then Krzysztof or I > can pick them up and take them via ARM SoC, based on the stable branch > from your tree that only has patch 3. I think you previously said that patch 5 depends on patch 1, so I can't take 2-6 without also pulling in the memory controller queue. > Patch 6 touches arm-smmu-impl.c, though it's a two-line change that > touches only the Tegra-specific matching bit in arm_smmu_impl_init(), so > the likelihood of that conflicting with anything else is fairly small. > > Is that what you were proposing? I can queue as much or as little of 2-6 as you like, but I would like to avoid pulling in the memory controller queue into the arm smmu tree. But yes, whichever of those I take, I can put them on a separate branch so that you're not blocked for the later patches. You have a better handle on the dependencies, so please tell me what works for you. I just want to make sure that at least patch 3 lands in my tree, so we don't get late conflicts with other driver changes. Will
On 07/06/2021 10:49, Krzysztof Kozlowski wrote: > Hi Olof and Arnd, > > Tegra memory controller driver changes with necessary dependency from Thierry > (which you will also get from him): > 1. Dmitry's power domain work on Tegra MC drivers, > 2. Necessary clock and regulator dependencies for Dmitry's work. > Hi Olof and Arnd, Just FYI, the stable tag from Thierry which I pulled here (and you will get from him as well) might cause COMPILE_TEST failures on specific configurations. Regular defconfigs and allyes/allmod should not be affected. I am giving heads up in case this lands in Linus later... There will be two fixes for this, sent already by Thierry: https://lore.kernel.org/lkml/20210609112806.3565057-1-thierry.reding@gmail.com/ 1. reset controller stubs: going via reset tree, 2. reserved memory section: probably going via my tree later. Best regards, Krzysztof
On Tue, Jun 08, 2021 at 05:48:51PM +0100, Will Deacon wrote: > On Tue, Jun 08, 2021 at 04:38:48PM +0200, Thierry Reding wrote: > > On Tue, Jun 08, 2021 at 01:01:29PM +0100, Will Deacon wrote: > > > On Mon, Jun 07, 2021 at 10:49:10AM +0200, Krzysztof Kozlowski wrote: > > > > This is the pull for you to base further SMMU aptches (prevent early SMMU > > > > faults). > > > > > > This is a tonne of code for me to pull into the SMMU tree given that I only > > > want one patch! > > > > > > Thierry, if I just stick: > > > > > > https://lore.kernel.org/r/20210603164632.1000458-4-thierry.reding@gmail.com > > > > > > on its own branch, can you stitch together whatever you need? > > > > I'm not sure I understand what you're proposing. For reference, here's > > the set of patches that I sent out: > > > > 1. memory: tegra: Implement SID override programming > > 2. dt-bindings: arm-smmu: Add Tegra186 compatible string > > 3. iommu/arm-smmu: Implement ->probe_finalize() > > 4. iommu/arm-smmu: tegra: Detect number of instances at runtime > > 5. iommu/arm-smmu: tegra: Implement SID override programming > > 6. iommu/arm-smmu: Use Tegra implementation on Tegra186 > > 7. arm64: tegra: Use correct compatible string for Tegra186 SMMU > > 8. arm64: tegra: Hook up memory controller to SMMU on Tegra186 > > 9. arm64: tegra: Enable SMMU support on Tegra194 > > > > Krzysztof already picked up patch 1 and I was assuming that you'd pick > > up 2-6 because they are to the ARM SMMU driver. However, if you're > > primarily interested in just patch 3, which is more "core" ARM SMMU than > > the rest, which are Tegra-specific, then I suppose what we could do is > > for you to give an Acked-by on the rest (2, 4-6) and then Krzysztof or I > > can pick them up and take them via ARM SoC, based on the stable branch > > from your tree that only has patch 3. > > I think you previously said that patch 5 depends on patch 1, so I can't > take 2-6 without also pulling in the memory controller queue. > > > Patch 6 touches arm-smmu-impl.c, though it's a two-line change that > > touches only the Tegra-specific matching bit in arm_smmu_impl_init(), so > > the likelihood of that conflicting with anything else is fairly small. > > > > Is that what you were proposing? > > I can queue as much or as little of 2-6 as you like, but I would like to > avoid pulling in the memory controller queue into the arm smmu tree. But > yes, whichever of those I take, I can put them on a separate branch so > that you're not blocked for the later patches. > > You have a better handle on the dependencies, so please tell me what works > for you. I just want to make sure that at least patch 3 lands in my tree, > so we don't get late conflicts with other driver changes. Yes, if you could pick up patch 3 and send out a link with the stable branch, I think Krzysztof or I could pull in that branch and pick up the remaining patches. It'd be good if you could also ack the remaining SMMU patches so that ARM SoC knows that they've been sanctioned. Krzysztof: would you be okay with picking up patches 2 and 4-6 on top of your memory branch for v5.14? Thierry
On 10/06/2021 11:19, Thierry Reding wrote: > On Tue, Jun 08, 2021 at 05:48:51PM +0100, Will Deacon wrote: >> On Tue, Jun 08, 2021 at 04:38:48PM +0200, Thierry Reding wrote: >>> On Tue, Jun 08, 2021 at 01:01:29PM +0100, Will Deacon wrote: >>>> On Mon, Jun 07, 2021 at 10:49:10AM +0200, Krzysztof Kozlowski wrote: >>>>> This is the pull for you to base further SMMU aptches (prevent early SMMU >>>>> faults). >>>> >>>> This is a tonne of code for me to pull into the SMMU tree given that I only >>>> want one patch! >>>> >>>> Thierry, if I just stick: >>>> >>>> https://lore.kernel.org/r/20210603164632.1000458-4-thierry.reding@gmail.com >>>> >>>> on its own branch, can you stitch together whatever you need? >>> >>> I'm not sure I understand what you're proposing. For reference, here's >>> the set of patches that I sent out: >>> >>> 1. memory: tegra: Implement SID override programming >>> 2. dt-bindings: arm-smmu: Add Tegra186 compatible string >>> 3. iommu/arm-smmu: Implement ->probe_finalize() >>> 4. iommu/arm-smmu: tegra: Detect number of instances at runtime >>> 5. iommu/arm-smmu: tegra: Implement SID override programming >>> 6. iommu/arm-smmu: Use Tegra implementation on Tegra186 >>> 7. arm64: tegra: Use correct compatible string for Tegra186 SMMU >>> 8. arm64: tegra: Hook up memory controller to SMMU on Tegra186 >>> 9. arm64: tegra: Enable SMMU support on Tegra194 >>> >>> Krzysztof already picked up patch 1 and I was assuming that you'd pick >>> up 2-6 because they are to the ARM SMMU driver. However, if you're >>> primarily interested in just patch 3, which is more "core" ARM SMMU than >>> the rest, which are Tegra-specific, then I suppose what we could do is >>> for you to give an Acked-by on the rest (2, 4-6) and then Krzysztof or I >>> can pick them up and take them via ARM SoC, based on the stable branch >>> from your tree that only has patch 3. >> >> I think you previously said that patch 5 depends on patch 1, so I can't >> take 2-6 without also pulling in the memory controller queue. >> >>> Patch 6 touches arm-smmu-impl.c, though it's a two-line change that >>> touches only the Tegra-specific matching bit in arm_smmu_impl_init(), so >>> the likelihood of that conflicting with anything else is fairly small. >>> >>> Is that what you were proposing? >> >> I can queue as much or as little of 2-6 as you like, but I would like to >> avoid pulling in the memory controller queue into the arm smmu tree. But >> yes, whichever of those I take, I can put them on a separate branch so >> that you're not blocked for the later patches. >> >> You have a better handle on the dependencies, so please tell me what works >> for you. I just want to make sure that at least patch 3 lands in my tree, >> so we don't get late conflicts with other driver changes. > > Yes, if you could pick up patch 3 and send out a link with the stable > branch, I think Krzysztof or I could pull in that branch and pick up the > remaining patches. It'd be good if you could also ack the remaining SMMU > patches so that ARM SoC knows that they've been sanctioned. > > Krzysztof: would you be okay with picking up patches 2 and 4-6 on top of > your memory branch for v5.14? You mean the iommu patches? Yes, I can take them and later explain to Arnd/Olof why they come through me. Best regards, Krzysztof
On Thu, Jun 10, 2021 at 04:23:56PM +0200, Krzysztof Kozlowski wrote: > On 10/06/2021 11:19, Thierry Reding wrote: > > On Tue, Jun 08, 2021 at 05:48:51PM +0100, Will Deacon wrote: > >> On Tue, Jun 08, 2021 at 04:38:48PM +0200, Thierry Reding wrote: > >>> On Tue, Jun 08, 2021 at 01:01:29PM +0100, Will Deacon wrote: > >>>> On Mon, Jun 07, 2021 at 10:49:10AM +0200, Krzysztof Kozlowski wrote: > >>>>> This is the pull for you to base further SMMU aptches (prevent early SMMU > >>>>> faults). > >>>> > >>>> This is a tonne of code for me to pull into the SMMU tree given that I only > >>>> want one patch! > >>>> > >>>> Thierry, if I just stick: > >>>> > >>>> https://lore.kernel.org/r/20210603164632.1000458-4-thierry.reding@gmail.com > >>>> > >>>> on its own branch, can you stitch together whatever you need? > >>> > >>> I'm not sure I understand what you're proposing. For reference, here's > >>> the set of patches that I sent out: > >>> > >>> 1. memory: tegra: Implement SID override programming > >>> 2. dt-bindings: arm-smmu: Add Tegra186 compatible string > >>> 3. iommu/arm-smmu: Implement ->probe_finalize() > >>> 4. iommu/arm-smmu: tegra: Detect number of instances at runtime > >>> 5. iommu/arm-smmu: tegra: Implement SID override programming > >>> 6. iommu/arm-smmu: Use Tegra implementation on Tegra186 > >>> 7. arm64: tegra: Use correct compatible string for Tegra186 SMMU > >>> 8. arm64: tegra: Hook up memory controller to SMMU on Tegra186 > >>> 9. arm64: tegra: Enable SMMU support on Tegra194 > >>> > >>> Krzysztof already picked up patch 1 and I was assuming that you'd pick > >>> up 2-6 because they are to the ARM SMMU driver. However, if you're > >>> primarily interested in just patch 3, which is more "core" ARM SMMU than > >>> the rest, which are Tegra-specific, then I suppose what we could do is > >>> for you to give an Acked-by on the rest (2, 4-6) and then Krzysztof or I > >>> can pick them up and take them via ARM SoC, based on the stable branch > >>> from your tree that only has patch 3. > >> > >> I think you previously said that patch 5 depends on patch 1, so I can't > >> take 2-6 without also pulling in the memory controller queue. > >> > >>> Patch 6 touches arm-smmu-impl.c, though it's a two-line change that > >>> touches only the Tegra-specific matching bit in arm_smmu_impl_init(), so > >>> the likelihood of that conflicting with anything else is fairly small. > >>> > >>> Is that what you were proposing? > >> > >> I can queue as much or as little of 2-6 as you like, but I would like to > >> avoid pulling in the memory controller queue into the arm smmu tree. But > >> yes, whichever of those I take, I can put them on a separate branch so > >> that you're not blocked for the later patches. > >> > >> You have a better handle on the dependencies, so please tell me what works > >> for you. I just want to make sure that at least patch 3 lands in my tree, > >> so we don't get late conflicts with other driver changes. > > > > Yes, if you could pick up patch 3 and send out a link with the stable > > branch, I think Krzysztof or I could pull in that branch and pick up the > > remaining patches. It'd be good if you could also ack the remaining SMMU > > patches so that ARM SoC knows that they've been sanctioned. > > > > Krzysztof: would you be okay with picking up patches 2 and 4-6 on top of > > your memory branch for v5.14? > > You mean the iommu patches? Yes, I can take them and later explain to > Arnd/Olof why they come through me. Okay, great. Will, can you provide that stable branch? Or would you prefer if I prepared it and sent you a pull request? We're kind of running out of time, since for ARM SoC the cut-off point for new material is usually -rc6 and that's coming up pretty fast. Thierry
On Thu, Jun 10, 2021 at 05:05:27PM +0200, Thierry Reding wrote: > On Thu, Jun 10, 2021 at 04:23:56PM +0200, Krzysztof Kozlowski wrote: > > On 10/06/2021 11:19, Thierry Reding wrote: > > > On Tue, Jun 08, 2021 at 05:48:51PM +0100, Will Deacon wrote: > > >> I can queue as much or as little of 2-6 as you like, but I would like to > > >> avoid pulling in the memory controller queue into the arm smmu tree. But > > >> yes, whichever of those I take, I can put them on a separate branch so > > >> that you're not blocked for the later patches. > > >> > > >> You have a better handle on the dependencies, so please tell me what works > > >> for you. I just want to make sure that at least patch 3 lands in my tree, > > >> so we don't get late conflicts with other driver changes. > > > > > > Yes, if you could pick up patch 3 and send out a link with the stable > > > branch, I think Krzysztof or I could pull in that branch and pick up the > > > remaining patches. It'd be good if you could also ack the remaining SMMU > > > patches so that ARM SoC knows that they've been sanctioned. > > > > > > Krzysztof: would you be okay with picking up patches 2 and 4-6 on top of > > > your memory branch for v5.14? > > > > You mean the iommu patches? Yes, I can take them and later explain to > > Arnd/Olof why they come through me. > > Okay, great. > > Will, can you provide that stable branch? Or would you prefer if I > prepared it and sent you a pull request? We're kind of running out of > time, since for ARM SoC the cut-off point for new material is usually > -rc6 and that's coming up pretty fast. https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=for-thierry/arm-smmu Will
On 10/06/2021 19:29, Will Deacon wrote: > On Thu, Jun 10, 2021 at 05:05:27PM +0200, Thierry Reding wrote: >> On Thu, Jun 10, 2021 at 04:23:56PM +0200, Krzysztof Kozlowski wrote: >>> On 10/06/2021 11:19, Thierry Reding wrote: >>>> On Tue, Jun 08, 2021 at 05:48:51PM +0100, Will Deacon wrote: >>>>> I can queue as much or as little of 2-6 as you like, but I would like to >>>>> avoid pulling in the memory controller queue into the arm smmu tree. But >>>>> yes, whichever of those I take, I can put them on a separate branch so >>>>> that you're not blocked for the later patches. >>>>> >>>>> You have a better handle on the dependencies, so please tell me what works >>>>> for you. I just want to make sure that at least patch 3 lands in my tree, >>>>> so we don't get late conflicts with other driver changes. >>>> >>>> Yes, if you could pick up patch 3 and send out a link with the stable >>>> branch, I think Krzysztof or I could pull in that branch and pick up the >>>> remaining patches. It'd be good if you could also ack the remaining SMMU >>>> patches so that ARM SoC knows that they've been sanctioned. >>>> >>>> Krzysztof: would you be okay with picking up patches 2 and 4-6 on top of >>>> your memory branch for v5.14? >>> >>> You mean the iommu patches? Yes, I can take them and later explain to >>> Arnd/Olof why they come through me. >> >> Okay, great. >> >> Will, can you provide that stable branch? Or would you prefer if I >> prepared it and sent you a pull request? We're kind of running out of >> time, since for ARM SoC the cut-off point for new material is usually >> -rc6 and that's coming up pretty fast. > > https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/log/?h=for-thierry/arm-smmu Merged, thanks. I'll take ARM/SMMU patches from Thierry's patchset: 2, 4-6. Best regards, Krzysztof