Hi Tim
On Fri, 2021-08-27 at 08:12 -0700, Tim Harvey wrote:
...
+++ b/arch/arm/dts/imx8mm-binman.dtsi
is it really necessary to create a new binman include?
No, I guess not. That's just what we loosely discussed. But this is also exactly why I only posted it as an RFC to get such feedback.
I have added the nodes for imx8mp directly to the imx8mp-u-boot.dtsi. I guess you did this because not all boards are converted yet. But I have tried this when I moved binman to the common include for imx8mp. As the phycore- imx8mp was also not converted at that point. It did not hurt having the binman nodes included. At least back then.
Yes, maybe we can indeed just put it all into the same imx8mp-u-boot.dtsi. If nobody objects to that idea I can try it that way for a v2.
I just not like to see that the file structure diverges. If there is a good reason I'd rather also move the binman nodes for imx8mp to a imx8mp-binman.dtsi.
No, I guess either way will work. Let's hope we get some more feedback on what the others prefer. Thanks!
I'm not sure if I understand correctly but if the suggestion is to create a dtsi that is shared between the imx8mm and imx8mp I don't think that would be a good idea as there are differences in addresses and such. In fact, there's a difference in DDR training firmware between ddr3 and lpddr4 so trying to even combine them into an imx8mm-u-boot.dtsi doesn't even make sense to me. If anything maybe it should be a imx8mm-binman-lpddr4-u-boot.dtsi or something like that?
No, I don't think it is our intention to combine anything from imx8mm and imx8mp at this point. As far as I understood, rather than introducing a new imx8mm-binman.dtsi the suggestion is to put that into the existing imx8mm-u-boot.dtsi as well similar to how Teresa did that for phycore-imx8mp and the imx8mp-u-boot.dtsi.
Perhaps ifdef's could handle these differences allowing you to combine ddr types and SoC's?
No, I don't really think that would improve anything over just having separate imx8mm-u-boot.dtsi and imx8mp-u- boot.dtsi files. On the other hand, I also don't see that anything would stop us from still going down that route of further combining imx8mm and imx8mp stuff in the future should we really want to.
Tim
Cheers
Marcel