| Message ID | 20201104164923.21238-18-digetx@gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | Chanwoo Choi |
| Headers | show |
| Series | Introduce memory interconnect for NVIDIA Tegra SoCs | expand |
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(+) Thanks, applied. Best regards, Krzysztof
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. 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. Thierry
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