[PATCH] arm: dts: j7200: dtb sync with Linux 6.5-rc1

[Nishanth Menon]

On 15:01-20230823, reidt wrote:
[...]

> > &mcu_ringacc {
> > 	bootph-pre-ram;
> > };
> > NOTE: you only need to override reg-names and reg in R5.dtsi not u-boot.dtsi.
> > 
> > &mcu_udmap {
> > 	bootph-pre-ram;
> > };
> 
> I saw you mentioned at [0] that mcu_ringacc (and I assume mcu_udmap)
> need to be retained for now. If moved to r5.dts, something breaks, as dhcp 
> fails then [1]. Should the full nodes remain for now until 6.6-rc1 sync? I'll
> still take them outside of mcu_navss.
> 
> [0] https://lore.kernel.org/all/20230816114445.c4c7rgdp5arhmiaq@polyester/
> [1] https://gist.github.com/Glockn/f0cf1ae8f8fd92e70f4e798c6221e81a

True.. But, I understand the overrides are only for the R5 usage
when DM is'nt around to support us. So, yes override it in R5 dts - Now
why without a A72 override it breaks is beyond me and I'd suggest poking
Vignesh or someone more knowledgable about DMA/CPSW for help there.

[..]

> > >  &wkup_i2c0 {
> > >  	bootph-pre-ram;
> > > +
> > > +	lp876441: lp876441 at 4c {
> > 
> > NAK. Why is this new stuff coming in -> should'nt be here.
> > 
> 
> This was left because &wkup_vtm0 uses &buck1_reg below which isn't apart
> of the kernel dt files.

Please send it upstream kernel. What breaks if we keep that out of tree?

My vague recollection is avs0 is mandatory for j7200?

> 
> > 
> > hbmc -> arch/arm64/boot/dts/ti/k3-j7200-som-p0.dtsi: flash at 0,0 weird
> > that does'nt throw a dtbs_check warning
> > 
> > WARNING: u-boot,mux-autoprobe -> this is'nt supported.
> > 
> 
> change these to bootph-pre-ram?

No, I was just surprised to see a new u-boot property.. dont really know
what it does. I doubt switching it to bootph-pre-ram will work there.

[...]
> > > -&wkup_i2c0 {
> > > -	bootph-pre-ram;
> > > -	lp876441: lp876441 at 4c {
> > > -		compatible = "ti,lp876441";
> > 
> > There is no such driver in linux kernel compatible space. might need a
> > ticket to implement the driver.
> > 
> 
> Interesting - I'll look into it. Makes me wonder about the buck1_reg for
> wkup_vtm0 and what's going on there.

Alright - checkout AVS0 - maybe Keerthy or someone can help guide.

[..]
> > >  };
> > >  
> > >  &wkup_vtm0 {
> > > +	compatible = "ti,am654-vtm", "ti,j721e-avs";
> > 
> > &wkup_vtm0 -> there is already stuff coming in from kernel. why
> > do we need to define our own compatible "ti,am654-vtm", "ti,j721e-avs"?
> > there is already compatible = "ti,j7200-vtm";  if we need to fix the
> > driver as part of the series, please do as a path in the series.
> > 
> 
> ti,j7200-vtm doesn't work and throws a "AVS init failed: -19", so i'll
> work on that. The compatible I used was taken from our TI u-boot 

Sounds like a driver fixup needed in u-boot to match up with the
compatible that was accepted in upstream kernel. Also the classic
reason why we are now insisting that the device tree come in from
kernel pristine.


[...]

-- 
Regards,
Nishanth Menon
Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D