[PATCH v2] arch: arm: mach-k3: Delete tifs node in DT fixup

[Nishanth Menon]

On 12:57-20230502, Kumar, Udit wrote:
> 
> On 5/1/2023 8:16 PM, Andrew Davis wrote:
> > On 4/26/23 9:13 AM, Kumar, Udit wrote:
> > > Hi Neha,
> > > 
> > > On 4/26/2023 5:31 PM, Neha Malcom Francis wrote:
> > > > Hi Udit
> > > > 
> > > > On 26/04/23 16:09, Kumar, Udit wrote:
> > > > > Hi Neha,
> > > > > 
> > > > > > Hi Udit,
> > > > > 
> > > > > [..]
> > > > > 
> > > > > > > > 
> > > > > > > > I do have a general doubt; why do we have only atf-sram sub-node in
> > > > > > > > msmc_sram in all other devices (j721e, j7200 and
> > > > > > > > am65) except j721s2?
> > > > > > > 
> > > > > > > let me know, which source code you are referring to
> > > > > > > 
> > > > > > 
> > > > > > In U-Boot, for j721e, j7200 and am65; they *only* contain atf-sram?
> > > > > 
> > > > > For u-boot please see
> > > > > 
> > > > > https://elixir.bootlin.com/u-boot/latest/source/arch/arm/dts/k3-j721s2-main.dtsi#L16
> > > > > 
> > > > > 
> > > > > > > I could see for j721s2 as well, in uboot[0] and Linux[1]
> > > > > [..]
> > > > > 
> > > > 
> > > > What I mean to ask is, why aren't there tifs or l3cache subnodes
> > > > in j721e, j7200 and am65?
> > > > 
> > > I think,  above platform is doing in right way,
> > > 
> > > AFAIK,  if we have to provide then we can provide size of this.
> > > 
> > > l3-cache can not be addressable.
> > > 
> > 
> > 
> > So the history here is we used to have the SRAM node in DT sized
> > to the actual size in hardware. L3 cache size can be set at boot
> > time (in SYSFW board-config file), and that uses up some of the
> > SRAM, so the end address moves in. We could represent this as
> > a reserved node inside the full SRAM node, or by shrinking the
> > SRAM node and hiding this. Same story for TIFS and ATF, they
> > use some variable amount of the end of SRAM.
> > 
> Ah, I have other view.
> 
> We shrunk SRAM size already, having reserved node on top of SRAM
> 
> is good as removing this.

How about we do this:
a) Start by discussing in k.org with a patch as to how we think it
   should be and what the rationale is.

b) SRAM size fixup is a consequence of firmware being flexible.. Since,
   the tifs reserved sram etc, base description exists even after
   "hardware reconfiguration", u-boot may adjust, but not delete such nodes.
   "reserved" is part of complete description and indication that this
   specific OS is not supposed to use this region. That region is protected by
   firewall and mechanisms to make such access fail, but that is the
   point of "reserved" nodes.

c) Standardize this across the SoCs that use MSMC (WITHOUT BREAKING
   FORWARD AND BACKWARD COMPATIBILITY of u-boot vs dtb).

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