| Message ID | 20201104164923.21238-18-digetx@gmail.com |
|---|---|
| State | Accepted |
| Commit | 825c7f4aa2866b77c0238855e2f58d56d2f13eae |
| Headers | show |
| Series | Introduce memory interconnect for NVIDIA Tegra SoCs | expand |
On Thu, Nov 26, 2020 at 06:26:05PM +0100, Thierry Reding wrote: > On Wed, Nov 04, 2020 at 07:48:53PM +0300, Dmitry Osipenko wrote: > > Each memory client has unique hardware ID, add these IDs. > > > > Acked-by: Rob Herring <robh@kernel.org> > > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > > --- > > include/dt-bindings/memory/tegra20-mc.h | 53 +++++++++++++++++++++++++ > > 1 file changed, 53 insertions(+) > > Is there any chance you could drop these dt-bindings include patches > (17, 18 and 19) so that I can pick them up into the Tegra tree? The > device tree changes that I was going to pick up depend on this and > fail to build if applied as-is. > > I was looking at your linux-mem-ctrl tree and had initially thought I > could just pull in one of the branches to get these dependencies, but it > looks like the dt-bindings patches are on the for-v5.11/tegra-mc branch, > which the ARM SoC maintainers wouldn't like to see me pull in for a > dependency on device tree changes. Partially you answered here. :) Since you should not pull my branch into a DT branch, you also should not put these include/dt-bindings patches there. SoC guys will complain about this as well. These patches are also needed for the driver, so if you take them, I would need them back in a pull request. SoC folks could spot it as well and point that such merge should not happen. > If this is all fixed at this point, I'll just have to push back the > device tree changes to v5.12, or perhaps see if the ARM SoC maintainers > are willing to take a late pull request that's based on v5.11-rc1. Yeah, that's a known problem. I asked about this Arnd and Olof in the past and got reply with two solutions: 1. Apply current version of patch without defines, just hard-coded numbers. After merging to Linus, replace the numbers with defines. 2. Wait with DTS till dependencies reach Linus. Best regards, Krzysztof
On Thu, 26 Nov 2020 at 18:39, Krzysztof Kozlowski <krzk@kernel.org> wrote: > > On Thu, Nov 26, 2020 at 06:26:05PM +0100, Thierry Reding wrote: > > On Wed, Nov 04, 2020 at 07:48:53PM +0300, Dmitry Osipenko wrote: > > > Each memory client has unique hardware ID, add these IDs. > > > > > > Acked-by: Rob Herring <robh@kernel.org> > > > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > > > --- > > > include/dt-bindings/memory/tegra20-mc.h | 53 +++++++++++++++++++++++++ > > > 1 file changed, 53 insertions(+) > > > > Is there any chance you could drop these dt-bindings include patches > > (17, 18 and 19) so that I can pick them up into the Tegra tree? The > > device tree changes that I was going to pick up depend on this and > > fail to build if applied as-is. > > > > I was looking at your linux-mem-ctrl tree and had initially thought I > > could just pull in one of the branches to get these dependencies, but it > > looks like the dt-bindings patches are on the for-v5.11/tegra-mc branch, > > which the ARM SoC maintainers wouldn't like to see me pull in for a > > dependency on device tree changes. > > Partially you answered here. :) Since you should not pull my branch into > a DT branch, you also should not put these include/dt-bindings patches > there. SoC guys will complain about this as well. > > These patches are also needed for the driver, so if you take them, I > would need them back in a pull request. SoC folks could spot it as well > and point that such merge should not happen. It seems I was wrong - these patches are not needed for the driver code. Neither in applied parts nor in upcoming Dmitry's work. In such case I could rework my branches and send a new pull request. The patches would stay only in your tree. Best regards, Krzysztof
On Thu, Nov 26, 2020 at 06:45:51PM +0100, Krzysztof Kozlowski wrote: > On Thu, 26 Nov 2020 at 18:39, Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > On Thu, Nov 26, 2020 at 06:26:05PM +0100, Thierry Reding wrote: > > > On Wed, Nov 04, 2020 at 07:48:53PM +0300, Dmitry Osipenko wrote: > > > > Each memory client has unique hardware ID, add these IDs. > > > > > > > > Acked-by: Rob Herring <robh@kernel.org> > > > > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > > > > --- > > > > include/dt-bindings/memory/tegra20-mc.h | 53 +++++++++++++++++++++++++ > > > > 1 file changed, 53 insertions(+) > > > > > > Is there any chance you could drop these dt-bindings include patches > > > (17, 18 and 19) so that I can pick them up into the Tegra tree? The > > > device tree changes that I was going to pick up depend on this and > > > fail to build if applied as-is. > > > > > > I was looking at your linux-mem-ctrl tree and had initially thought I > > > could just pull in one of the branches to get these dependencies, but it > > > looks like the dt-bindings patches are on the for-v5.11/tegra-mc branch, > > > which the ARM SoC maintainers wouldn't like to see me pull in for a > > > dependency on device tree changes. > > > > Partially you answered here. :) Since you should not pull my branch into > > a DT branch, you also should not put these include/dt-bindings patches > > there. SoC guys will complain about this as well. > > > > These patches are also needed for the driver, so if you take them, I > > would need them back in a pull request. SoC folks could spot it as well > > and point that such merge should not happen. > > It seems I was wrong - these patches are not needed for the driver > code. Neither in applied parts nor in upcoming Dmitry's work. In such > case I could rework my branches and send a new pull request. The > patches would stay only in your tree. Acked-by: Krzysztof Kozlowski <krzk@kernel.org> Best regards, Krzysztof
On Thu, Nov 26, 2020 at 06:45:51PM +0100, Krzysztof Kozlowski wrote: > On Thu, 26 Nov 2020 at 18:39, Krzysztof Kozlowski <krzk@kernel.org> wrote: > > > > On Thu, Nov 26, 2020 at 06:26:05PM +0100, Thierry Reding wrote: > > > On Wed, Nov 04, 2020 at 07:48:53PM +0300, Dmitry Osipenko wrote: > > > > Each memory client has unique hardware ID, add these IDs. > > > > > > > > Acked-by: Rob Herring <robh@kernel.org> > > > > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > > > > --- > > > > include/dt-bindings/memory/tegra20-mc.h | 53 +++++++++++++++++++++++++ > > > > 1 file changed, 53 insertions(+) > > > > > > Is there any chance you could drop these dt-bindings include patches > > > (17, 18 and 19) so that I can pick them up into the Tegra tree? The > > > device tree changes that I was going to pick up depend on this and > > > fail to build if applied as-is. > > > > > > I was looking at your linux-mem-ctrl tree and had initially thought I > > > could just pull in one of the branches to get these dependencies, but it > > > looks like the dt-bindings patches are on the for-v5.11/tegra-mc branch, > > > which the ARM SoC maintainers wouldn't like to see me pull in for a > > > dependency on device tree changes. > > > > Partially you answered here. :) Since you should not pull my branch into > > a DT branch, you also should not put these include/dt-bindings patches > > there. SoC guys will complain about this as well. > > > > These patches are also needed for the driver, so if you take them, I > > would need them back in a pull request. SoC folks could spot it as well > > and point that such merge should not happen. > > It seems I was wrong - these patches are not needed for the driver > code. Neither in applied parts nor in upcoming Dmitry's work. In such > case I could rework my branches and send a new pull request. The > patches would stay only in your tree. Oh yeah, I forgot to mention that the driver doesn't actually need these. I'll take your Acked-bys and put these three patches into the Tegra tree, then. Thanks, Thierry
On Thu, Nov 26, 2020 at 06:39:22PM +0100, Krzysztof Kozlowski wrote: > On Thu, Nov 26, 2020 at 06:26:05PM +0100, Thierry Reding wrote: > > On Wed, Nov 04, 2020 at 07:48:53PM +0300, Dmitry Osipenko wrote: > > > Each memory client has unique hardware ID, add these IDs. > > > > > > Acked-by: Rob Herring <robh@kernel.org> > > > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > > > --- > > > include/dt-bindings/memory/tegra20-mc.h | 53 +++++++++++++++++++++++++ > > > 1 file changed, 53 insertions(+) > > > > Is there any chance you could drop these dt-bindings include patches > > (17, 18 and 19) so that I can pick them up into the Tegra tree? The > > device tree changes that I was going to pick up depend on this and > > fail to build if applied as-is. > > > > I was looking at your linux-mem-ctrl tree and had initially thought I > > could just pull in one of the branches to get these dependencies, but it > > looks like the dt-bindings patches are on the for-v5.11/tegra-mc branch, > > which the ARM SoC maintainers wouldn't like to see me pull in for a > > dependency on device tree changes. > > Partially you answered here. :) Since you should not pull my branch into > a DT branch, you also should not put these include/dt-bindings patches > there. SoC guys will complain about this as well. > > These patches are also needed for the driver, so if you take them, I > would need them back in a pull request. SoC folks could spot it as well > and point that such merge should not happen. > > > If this is all fixed at this point, I'll just have to push back the > > device tree changes to v5.12, or perhaps see if the ARM SoC maintainers > > are willing to take a late pull request that's based on v5.11-rc1. > > Yeah, that's a known problem. I asked about this Arnd and Olof in the > past and got reply with two solutions: > 1. Apply current version of patch without defines, just hard-coded > numbers. After merging to Linus, replace the numbers with defines. > > 2. Wait with DTS till dependencies reach Linus. What I've done occasionally in the past was to put these kinds of patches into a separate "dt-bindings" branch that I could use to resolve dependencies from device tree files. The ARM SoC maintainers never had any issues with that approach. I guess this is a bit of a special case, because the DT includes are ultimately really a part of the device tree, so mixing them both isn't problematic. Thierry
On Thu, Nov 26, 2020 at 07:02:55PM +0100, Thierry Reding wrote: > On Thu, Nov 26, 2020 at 06:39:22PM +0100, Krzysztof Kozlowski wrote: > > On Thu, Nov 26, 2020 at 06:26:05PM +0100, Thierry Reding wrote: > > > On Wed, Nov 04, 2020 at 07:48:53PM +0300, Dmitry Osipenko wrote: > > > > Each memory client has unique hardware ID, add these IDs. > > > > > > > > Acked-by: Rob Herring <robh@kernel.org> > > > > Signed-off-by: Dmitry Osipenko <digetx@gmail.com> > > > > --- > > > > include/dt-bindings/memory/tegra20-mc.h | 53 +++++++++++++++++++++++++ > > > > 1 file changed, 53 insertions(+) > > > > > > Is there any chance you could drop these dt-bindings include patches > > > (17, 18 and 19) so that I can pick them up into the Tegra tree? The > > > device tree changes that I was going to pick up depend on this and > > > fail to build if applied as-is. > > > > > > I was looking at your linux-mem-ctrl tree and had initially thought I > > > could just pull in one of the branches to get these dependencies, but it > > > looks like the dt-bindings patches are on the for-v5.11/tegra-mc branch, > > > which the ARM SoC maintainers wouldn't like to see me pull in for a > > > dependency on device tree changes. > > > > Partially you answered here. :) Since you should not pull my branch into > > a DT branch, you also should not put these include/dt-bindings patches > > there. SoC guys will complain about this as well. > > > > These patches are also needed for the driver, so if you take them, I > > would need them back in a pull request. SoC folks could spot it as well > > and point that such merge should not happen. > > > > > If this is all fixed at this point, I'll just have to push back the > > > device tree changes to v5.12, or perhaps see if the ARM SoC maintainers > > > are willing to take a late pull request that's based on v5.11-rc1. > > > > Yeah, that's a known problem. I asked about this Arnd and Olof in the > > past and got reply with two solutions: > > 1. Apply current version of patch without defines, just hard-coded > > numbers. After merging to Linus, replace the numbers with defines. > > > > 2. Wait with DTS till dependencies reach Linus. > > What I've done occasionally in the past was to put these kinds of > patches into a separate "dt-bindings" branch that I could use to resolve > dependencies from device tree files. The ARM SoC maintainers never had > any issues with that approach. > > I guess this is a bit of a special case, because the DT includes are > ultimately really a part of the device tree, so mixing them both isn't > problematic. Indeed, that way could work... and no one would spot it. :) Many times these headers were for clock symbols so if they go via SoC/DT tree, merge back to clock tree could be accepted. Best regards, Krzysztof
diff --git a/include/dt-bindings/memory/tegra20-mc.h b/include/dt-bindings/memory/tegra20-mc.h index 35e131eee198..6f8829508ad0 100644 --- a/include/dt-bindings/memory/tegra20-mc.h +++ b/include/dt-bindings/memory/tegra20-mc.h @@ -18,4 +18,57 @@ #define TEGRA20_MC_RESET_VDE 13 #define TEGRA20_MC_RESET_VI 14 +#define TEGRA20_MC_DISPLAY0A 0 +#define TEGRA20_MC_DISPLAY0AB 1 +#define TEGRA20_MC_DISPLAY0B 2 +#define TEGRA20_MC_DISPLAY0BB 3 +#define TEGRA20_MC_DISPLAY0C 4 +#define TEGRA20_MC_DISPLAY0CB 5 +#define TEGRA20_MC_DISPLAY1B 6 +#define TEGRA20_MC_DISPLAY1BB 7 +#define TEGRA20_MC_EPPUP 8 +#define TEGRA20_MC_G2PR 9 +#define TEGRA20_MC_G2SR 10 +#define TEGRA20_MC_MPEUNIFBR 11 +#define TEGRA20_MC_VIRUV 12 +#define TEGRA20_MC_AVPCARM7R 13 +#define TEGRA20_MC_DISPLAYHC 14 +#define TEGRA20_MC_DISPLAYHCB 15 +#define TEGRA20_MC_FDCDRD 16 +#define TEGRA20_MC_G2DR 17 +#define TEGRA20_MC_HOST1XDMAR 18 +#define TEGRA20_MC_HOST1XR 19 +#define TEGRA20_MC_IDXSRD 20 +#define TEGRA20_MC_MPCORER 21 +#define TEGRA20_MC_MPE_IPRED 22 +#define TEGRA20_MC_MPEAMEMRD 23 +#define TEGRA20_MC_MPECSRD 24 +#define TEGRA20_MC_PPCSAHBDMAR 25 +#define TEGRA20_MC_PPCSAHBSLVR 26 +#define TEGRA20_MC_TEXSRD 27 +#define TEGRA20_MC_VDEBSEVR 28 +#define TEGRA20_MC_VDEMBER 29 +#define TEGRA20_MC_VDEMCER 30 +#define TEGRA20_MC_VDETPER 31 +#define TEGRA20_MC_EPPU 32 +#define TEGRA20_MC_EPPV 33 +#define TEGRA20_MC_EPPY 34 +#define TEGRA20_MC_MPEUNIFBW 35 +#define TEGRA20_MC_VIWSB 36 +#define TEGRA20_MC_VIWU 37 +#define TEGRA20_MC_VIWV 38 +#define TEGRA20_MC_VIWY 39 +#define TEGRA20_MC_G2DW 40 +#define TEGRA20_MC_AVPCARM7W 41 +#define TEGRA20_MC_FDCDWR 42 +#define TEGRA20_MC_HOST1XW 43 +#define TEGRA20_MC_ISPW 44 +#define TEGRA20_MC_MPCOREW 45 +#define TEGRA20_MC_MPECSWR 46 +#define TEGRA20_MC_PPCSAHBDMAW 47 +#define TEGRA20_MC_PPCSAHBSLVW 48 +#define TEGRA20_MC_VDEBSEVW 49 +#define TEGRA20_MC_VDEMBEW 50 +#define TEGRA20_MC_VDETPMW 51 + #endif