| Message ID | 20230207-iommu-support-v2-0-60d5fa00e4e5@baylibre.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add IOMMU support to MT8365 SoC | expand |
On 05/04/2023 10:06, Alexandre Mergnat wrote: > Add MT8365 SMI common support. > > Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com> > --- Why the driver patch is after DTS? Driver code cannot be mixed with the DTS on branches/repos, so such ordering suggest your patchset is not bisectable. Best regards, Krzysztof
Ok, I will move the driver patch before the DTS patches in the next version. Regards, Alexandre Le mer. 5 avr. 2023 à 11:43, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> a écrit : > > On 05/04/2023 10:06, Alexandre Mergnat wrote: > > Add MT8365 SMI common support. > > > > Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com> > > --- > > Why the driver patch is after DTS? Driver code cannot be mixed with the > DTS on branches/repos, so such ordering suggest your patchset is not > bisectable. > > Best regards, > Krzysztof >
On 05/04/2023 10:06, Alexandre Mergnat wrote: > This commits are based on the Fabien Parent <fparent@baylibre.com> work. > > The purpose of this series is to add the following HWs / IPs support for > the MT8365 SoC: > - System Power Manager > - MultiMedia Memory Management Unit "M4U" (IOMMU) > - Smart Multimedia Interface "SMI" > - Local arbiter "LARB" > > This series depends to two others which add power support for MT8365 SoC > [1] [2]. So does it mean they cannot be merged? On first glance I do not see the dependency, so I wonder if we understand the dependencies the same. And subsystems. Best regards, Krzysztof
On 05/04/2023 11:53, Alexandre Mergnat wrote: > Ok, I will move the driver patch before the DTS patches in the next version. > Or do not send it together at all, which might solve your dependency problem. According to your cover letter I cannot take the memory controller bits, so I am waiting for dependencies to hit the mainline. Alternatively I will need pull request with stable tag. Best regards, Krzysztof
On 05/04/2023 13:45, Krzysztof Kozlowski wrote: > On 05/04/2023 11:53, Alexandre Mergnat wrote: >> Ok, I will move the driver patch before the DTS patches in the next version. >> > Or do not send it together at all, which might solve your dependency > problem. According to your cover letter I cannot take the memory > controller bits, so I am waiting for dependencies to hit the mainline. > Alternatively I will need pull request with stable tag. > Ok, I prefer send the driver patch in another serie. That will solve the dependency with the DTS a least. Regards, Alexandre
On 05/04/2023 13:43, Krzysztof Kozlowski wrote: > On 05/04/2023 10:06, Alexandre Mergnat wrote: >> This commits are based on the Fabien Parent <fparent@baylibre.com> work. >> >> The purpose of this series is to add the following HWs / IPs support for >> the MT8365 SoC: >> - System Power Manager >> - MultiMedia Memory Management Unit "M4U" (IOMMU) >> - Smart Multimedia Interface "SMI" >> - Local arbiter "LARB" >> >> This series depends to two others which add power support for MT8365 SoC >> [1] [2]. > So does it mean they cannot be merged? On first glance I do not see the > dependency, so I wonder if we understand the dependencies the same. And > subsystems. Exactly, we shouldn't merge it before the dependent series to don't break the build due to "#include <dt-bindings/power/mediatek,mt8365-power.h>" in the DTSI file. Additionally, LARB will not work properly (or at all) without the power support. Regards, Alexandre
On 05/04/2023 15:13, Alexandre Mergnat wrote: > > On 05/04/2023 13:43, Krzysztof Kozlowski wrote: >> On 05/04/2023 10:06, Alexandre Mergnat wrote: >>> This commits are based on the Fabien Parent <fparent@baylibre.com> work. >>> >>> The purpose of this series is to add the following HWs / IPs support for >>> the MT8365 SoC: >>> - System Power Manager >>> - MultiMedia Memory Management Unit "M4U" (IOMMU) >>> - Smart Multimedia Interface "SMI" >>> - Local arbiter "LARB" >>> >>> This series depends to two others which add power support for MT8365 SoC >>> [1] [2]. >> So does it mean they cannot be merged? On first glance I do not see the >> dependency, so I wonder if we understand the dependencies the same. And >> subsystems. > Exactly, we shouldn't merge it before the dependent series to don't ] > break the build due to > "#include <dt-bindings/power/mediatek,mt8365-power.h>" in the DTSI file. > Additionally, LARB will not work properly (or at all) without the power > support. And how driver is related to it? If it is, you might have some unusual coupling between power and memory controller driver. Best regards, Krzysztof
On 05/04/2023 15:06, Alexandre Mergnat wrote: > > On 05/04/2023 13:45, Krzysztof Kozlowski wrote: >> On 05/04/2023 11:53, Alexandre Mergnat wrote: >>> Ok, I will move the driver patch before the DTS patches in the next version. >>> >> Or do not send it together at all, which might solve your dependency >> problem. According to your cover letter I cannot take the memory >> controller bits, so I am waiting for dependencies to hit the mainline. >> Alternatively I will need pull request with stable tag. >> > Ok, I prefer send the driver patch in another serie. That will solve the > dependency with the DTS a least. What dependency? Why do you have dependencies between drivers and DTS? That's a no-go. Best regards, Krzysztof
On 05/04/2023 15:54, Krzysztof Kozlowski wrote: > On 05/04/2023 15:06, Alexandre Mergnat wrote: >> On 05/04/2023 13:45, Krzysztof Kozlowski wrote: >>> On 05/04/2023 11:53, Alexandre Mergnat wrote: >>>> Ok, I will move the driver patch before the DTS patches in the next version. >>>> >>> Or do not send it together at all, which might solve your dependency >>> problem. According to your cover letter I cannot take the memory >>> controller bits, so I am waiting for dependencies to hit the mainline. >>> Alternatively I will need pull request with stable tag. >>> >> Ok, I prefer send the driver patch in another serie. That will solve the >> dependency with the DTS a least. > What dependency? Why do you have dependencies between drivers and DTS? > That's a no-go. I probably do something wrong but, that start with this comment [1]: > I guess we should add a independent "mediatek,mt8365-smi-common". Then I have added the mt8365 compatible support in the driver instead of using the mt8186 which already supported and used in the v1. I change the binding and DTS to use "mediatek,mt8365-smi-common" only (no more "mediatek,mt8186-smi-common"). Maybe "dependency isn't the good word to use in that case. Except for the patch order in the serie (or send the driver in another one), everything is fine or there are others wrong things ? [1]: https://lore.kernel.org/all/488d226a8a66bc6f5b96063b2816b59dd065ad3f.camel@mediatek.com/ Regards, Alexandre
On 05/04/2023 16:34, Alexandre Mergnat wrote: > > On 05/04/2023 15:54, Krzysztof Kozlowski wrote: >> On 05/04/2023 15:06, Alexandre Mergnat wrote: >>> On 05/04/2023 13:45, Krzysztof Kozlowski wrote: >>>> On 05/04/2023 11:53, Alexandre Mergnat wrote: >>>>> Ok, I will move the driver patch before the DTS patches in the next version. >>>>> >>>> Or do not send it together at all, which might solve your dependency >>>> problem. According to your cover letter I cannot take the memory >>>> controller bits, so I am waiting for dependencies to hit the mainline. >>>> Alternatively I will need pull request with stable tag. >>>> >>> Ok, I prefer send the driver patch in another serie. That will solve the >>> dependency with the DTS a least. >> What dependency? Why do you have dependencies between drivers and DTS? >> That's a no-go. > I probably do something wrong but, that start with this comment [1]: > >> I guess we should add a independent "mediatek,mt8365-smi-common". > > Then I have added the mt8365 compatible support in the driver instead of using the mt8186 which already supported and used in the v1. > I change the binding and DTS to use "mediatek,mt8365-smi-common" only (no more "mediatek,mt8186-smi-common"). > Maybe "dependency isn't the good word to use in that case. I do not see patch changing existing compatible. Which one is it? I don't know what is your meaning of dependency then. For all of us, dependency means one patch must be applied after another patch. So is this the case here? If yes, then why? > Except for the patch order in the serie (or send the driver in another one), everything is fine or there are others wrong things ? If this is the question to me, then I am not the maintainer of your platform. I am taking only memory controller bits, which look fine and I would have already apply them if not the dependency trouble. Soon the window for applying will close, BTW. We are almost at RC6. Best regards, Krzysztof
Le jeu. 6 avr. 2023 à 09:50, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> a écrit : > > On 05/04/2023 16:34, Alexandre Mergnat wrote: > > > > On 05/04/2023 15:54, Krzysztof Kozlowski wrote: > >> On 05/04/2023 15:06, Alexandre Mergnat wrote: > >>> On 05/04/2023 13:45, Krzysztof Kozlowski wrote: > >>>> On 05/04/2023 11:53, Alexandre Mergnat wrote: > >>>>> Ok, I will move the driver patch before the DTS patches in the next version. > >>>>> > >>>> Or do not send it together at all, which might solve your dependency > >>>> problem. According to your cover letter I cannot take the memory > >>>> controller bits, so I am waiting for dependencies to hit the mainline. > >>>> Alternatively I will need pull request with stable tag. > >>>> > >>> Ok, I prefer send the driver patch in another serie. That will solve the > >>> dependency with the DTS a least. > >> What dependency? Why do you have dependencies between drivers and DTS? > >> That's a no-go. > > I probably do something wrong but, that start with this comment [1]: > > > >> I guess we should add a independent "mediatek,mt8365-smi-common". > > > > Then I have added the mt8365 compatible support in the driver instead of using the mt8186 which already supported and used in the v1. > > I change the binding and DTS to use "mediatek,mt8365-smi-common" only (no more "mediatek,mt8186-smi-common"). > > Maybe "dependency isn't the good word to use in that case. > > I do not see patch changing existing compatible. Which one is it? I was talking between the v1 and v2 of this serie > > I don't know what is your meaning of dependency then. For all of us, > dependency means one patch must be applied after another patch. So is > this the case here? If yes, then why? I don't think so. I think you start talking dependency in your 2nd reply about driver/DTS, but this is only related change. > > > Except for the patch order in the serie (or send the driver in another one), everything is fine or there are others wrong things ? > > If this is the question to me, then I am not the maintainer of your > platform. I am taking only memory controller bits, which look fine and I > would have already apply them if not the dependency trouble. Soon the > window for applying will close, BTW. We are almost at RC6. The dependency is between the power series and the DTS change in this series as explained in the cover letter thread (PATCH 00/10). IMHO, you can take the bindings without worry. I don't see possible regression. This series seems pretty simple, one part adds MT8365 SMI common support in the bindings, the mt8365-evk DTS and the mtk-smi driver, and there are no exotic stuffs. To conclude: I'm ok to send this driver patch in another series and put it as a dependency of the iommu series to answer your first comment: > >>>>>Driver code cannot be mixed with the DTS on branches/repos, so such ordering suggest your patchset is not bisectable. Regards, Alexandre
This commits are based on the Fabien Parent <fparent@baylibre.com> work. The purpose of this series is to add the following HWs / IPs support for the MT8365 SoC: - System Power Manager - MultiMedia Memory Management Unit "M4U" (IOMMU) - Smart Multimedia Interface "SMI" - Local arbiter "LARB" This series depends to two others which add power support for MT8365 SoC [1] [2]. Regards, Alex [1]: https://lore.kernel.org/all/20230203-evk-board-support-v2-0-6ec7cdb10ccf@baylibre.com/ [2]: https://lore.kernel.org/lkml/20230105170735.1637416-1-msp@baylibre.com/ Signed-off-by: Alexandre Mergnat <amergnat@baylibre.com> --- Changes in v2: - Split power domain patch (3) in 4 patches to explain in the commit messages the added subsystems. - Add an independent "mediatek,mt8365-smi-common" compatible to have its own LARB bus select. - Link to v1: https://lore.kernel.org/r/20230207-iommu-support-v1-0-4f0c81fd52c1@baylibre.com --- Alexandre Mergnat (10): dt-bindings: memory-controllers: mediatek,smi-common: add mt8365 dt-bindings: memory-controllers: mediatek,smi-larb: add mt8365 arm64: dts: mediatek: add mmsys support for mt8365 SoC arm64: dts: mediatek: add camsys support for mt8365 SoC arm64: dts: mediatek: add apu support for mt8365 SoC arm64: dts: mediatek: add power domain support for mt8365 SoC arm64: dts: mediatek: add smi support for mt8365 SoC arm64: dts: mediatek: add larb support for mt8365 SoC arm64: dts: mediatek: add iommu support for mt8365 SoC memory: mtk-smi: mt8365: Add SMI Support .../memory-controllers/mediatek,smi-common.yaml | 2 + .../memory-controllers/mediatek,smi-larb.yaml | 4 + arch/arm64/boot/dts/mediatek/mt8365.dtsi | 210 +++++++++++++++++++++ drivers/memory/mtk-smi.c | 7 + 4 files changed, 223 insertions(+) --- base-commit: 1db7fc94e6e116f43f7bf3adb33407f21bc29fd9 change-id: 20230207-iommu-support-5e620926e42e Best regards,