Hi Nishanth, On 06:44-20230816, Nishanth Menon wrote: > On 14:53-20230816, Manorit Chawdhry wrote: > > The following commit syncs the device tree from Linux tag > > next-20230815 to U-boot and fixes the following to be compatible with > > the future syncs - > > NAK - please use 6.5-rc1 as baseline to integrate. we can use v6.6-rc1 > once that occurs to clean up further.
Sure, would use 6.5-rc1 as baseline. > > [..] > Nice first attempt, but there is more to do: - Same comments apply for > am68, so please take it there as well. > > > > > All these have been put in a single commit to not break the > > bisectability. > > > > Signed-off-by: Manorit Chawdhry <m-chawd...@ti.com> > > --- > [..] > > > &wkup_i2c0 { > > bootph-pre-ram; > > }; > > @@ -35,16 +17,17 @@ > > bootph-pre-ram; > > }; > > > > -&cbass_mcu_wakeup { > > - bootph-pre-ram; > > - > > - timer1: timer@40400000 { > > - compatible = "ti,omap5430-timer"; > > - reg = <0x0 0x40400000 0x0 0x80>; > > +&mcu_timer0 { > > + /delete-property/ power-domains; > > + /delete-property/ assigned-clocks; > > + /delete-property/ assigned-clock-parents; > > NAK - this should come in from R5 data. > > ti,timer-alwon; > NAK. > > clock-frequency = <250000000>; > > bootph-pre-ram; > > - }; > > you should just have: > &mcu_timer0 { > clock-frequency = <250000000>; > bootph-pre-ram; > }; > > Introduce the required data into the power / clock data for R5. > A72 side should just work fine with this since DM should be up and > running by this time. Let me give this a try to see if that works as I believe Udit was having some problems with this.. > > > +}; > > + > > +&cbass_mcu_wakeup { > > + bootph-pre-ram; > > > > chipid@43000014 { > > bootph-pre-ram; > > @@ -56,12 +39,6 @@ > > }; > > > > &mcu_ringacc { > > - reg = <0x0 0x2b800000 0x0 0x400000>, > > - <0x0 0x2b000000 0x0 0x400000>, > > - <0x0 0x28590000 0x0 0x100>, > > - <0x0 0x2a500000 0x0 0x40000>, > > - <0x0 0x28440000 0x0 0x40000>; > > - reg-names = "rt", "fifos", "proxy_gcfg", "proxy_target", "cfg"; > > You need to retain this for v6.5-rc1 in 6.6-rc1 sync we will do this change. > Sure, would do the needful! > > bootph-pre-ram; > > }; > > > > @@ -129,19 +106,6 @@ > > bootph-pre-ram; > > }; > > > > -&mcu_cpsw { > > - reg = <0x0 0x46000000 0x0 0x200000>, > > - <0x0 0x40f00200 0x0 0x8>; > > - reg-names = "cpsw_nuss", "mac_efuse"; > > - /delete-property/ ranges; > > - > > - cpsw-phy-sel@40f04040 { > > - compatible = "ti,am654-cpsw-phy-sel"; > > - reg= <0x0 0x40f04040 0x0 0x4>; > > - reg-names = "gmii-sel"; > > - }; > > -}; > > - > > &main_sdhci0 { > > bootph-pre-ram; > > }; > > [...] > > > diff --git a/arch/arm/dts/k3-j721s2-r5-common-proc-board.dts > > b/arch/arm/dts/k3-j721s2-r5-common-proc-board.dts > > index c74e8e58ae81..dd1c371ba6b5 100644 > > --- a/arch/arm/dts/k3-j721s2-r5-common-proc-board.dts > > +++ b/arch/arm/dts/k3-j721s2-r5-common-proc-board.dts > > @@ -5,7 +5,7 @@ > > > > /dts-v1/; > > > > -#include "k3-j721s2-som-p0.dtsi" > > +#include <k3-j721s2-common-proc-board.dts> > > Why <> instead of ""? Ah, I can keep it "", don't know why I went with <> > > Is there a reason to go with proc-board instead of som-p0? I see the same in k3-am625-r5-sk.dts.. #include "k3-am625-sk.dts" #include "k3-am62x-sk-ddr4-1600MTs.dtsi" #include "k3-am62-ddr.dtsi" #include "k3-am625-sk-u-boot.dtsi" And I believe the reason must be so that all the Linux fixes get propagated to R5 dts as I mentioned in the commit message. > > [snip] > > - Include k3-j721s2-common-proc-board.dts file > > > > Remove the duplicated pinmuxes from r5 and -u-boot.dtsi files and > > include k3-j721s2-common-proc-board.dts for Linux fixes to propagate > > to U-boot. > > [snip] Let me know if the reasoning is wrong.. > > > #include "k3-j721s2-ddr-evm-lp4-4266.dtsi" > > #include "k3-j721s2-ddr.dtsi" > > #include "k3-j721s2-binman.dtsi" > > @@ -14,7 +14,7 @@ > > chosen { > > firmware-loader = &fs_loader0; > > stdout-path = &main_uart8; > > - tick-timer = &timer1; > > + tick-timer = &mcu_timer0; > > }; > > > > aliases { > > @@ -51,38 +51,22 @@ > > bootph-pre-ram; > > }; > > > > - clk_19_2mhz: dummy_clock_19_2mhz { > > - compatible = "fixed-clock"; > > - #clock-cells = <0>; > > - clock-frequency = <19200000>; > > - bootph-pre-ram; > > - }; > > }; > > Why do you need the clk_200mhz ? we have a clock and dm functionality. This was being used by some sdhci things so I didn't touch this as I wasn't sure how to handle that, maybe some clk-data/dev-data is missing that is causing all these hacks to come. Would have to look at what is missing and how to make this work without these dummy clocks > > Why do you need fs_loader0 anymore? there is no phandlepart property. > > [...] > > did you check for overlaps between u-boot.dtsi and r5.dts? > &sms for example has duplicate bootph-pre-ram property. Ah no, haven't checked this, Thanks for the reminder! > > > > > &main_sdhci0 { > > /delete-property/ power-domains; > > /delete-property/ assigned-clocks; > > @@ -182,11 +105,8 @@ > > /delete-property/ power-domains; > > /delete-property/ assigned-clocks; > > /delete-property/ assigned-clock-parents; > > Why do you need to delete-property of power-domains, assigned-clocks > etc? you should be able to rely on clock and power domain data in R5 > SPL. This had been existing previously only and I didn't touch it thinking it was required, would revisit these changes to see how they can work without these things. > > > - pinctrl-0 = <&main_mmc1_pins_default>; > > - pinctrl-names = "default"; > > clock-names = "clk_xin"; > > clocks = <&clk_200mhz>; > > - ti,driver-strength-ohm = <50>; > > Is this even correct? > > }; > > > > &mcu_ringacc { > > I see that you are overriding &mcu_udmap -> But I have not seen kernel > patches to clean that up to introduce reg-names "rchan" "tchan" and "rflow". I believe the patch is posted Nishanth if you are asking about mcu_udmap, I had added that in the cover letter, You can have a look at [0]. Vignesh is handling adding those nodes in Linux. [0]: https://lore.kernel.org/all/20230810174356.3322583-4-vigne...@ti.com/ > > Why not? looks like 6.6-rc1 wont have things cleaned up either. > > > [...] > > Move the #include "k3-j721s2-common-proc-board-u-boot.dtsi" > to the top. > > The order should be: > > #include "board.dts" I see that you are also using board.dts here and not som-p0.dts, let me know what should be done about it. As I recall you having a previous comment mentioning about this. Thanks and Regards, Manorit > #include "ddr-timing.dtsi" > #include "ddr.dtsi" > #include "board-uboot.dtsi" > > -- > Regards, > Nishanth Menon > Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3 1A34 DDB5 > 849D 1736 249D