All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Kumar, Udit" <u-kumar1@ti.com>
To: Nishanth Menon <nm@ti.com>
Cc: Andrew Davis <afd@ti.com>, Neha Malcom Francis <n-francis@ti.com>,
	"Dasan, Nikhil" <n-dasan@ti.com>,
	"trini@konsulko.com" <trini@konsulko.com>,
	"u-boot@lists.denx.de" <u-boot@lists.denx.de>,
	"Raghavendra, Vignesh" <vigneshr@ti.com>, <u-kumar1@ti.com>
Subject: Re: [PATCH v2] arch: arm: mach-k3: Delete tifs node in DT fixup
Date: Wed, 3 May 2023 15:00:22 +0530	[thread overview]
Message-ID: <ca8cf647-7279-9f1e-b59f-e7bb5feb535f@ti.com> (raw)
In-Reply-To: <20230502230022.5pjywy6h7oqrkmwh@elusive>

Hi Nishanth,

On 5/3/2023 4:30 AM, Nishanth Menon wrote:
> 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,
>>>>>> [..]
>>>>>> [..]
>>>>>>
>>>>> 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.
ok
> 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.

you mean , keep full view of SRAM and update size of reserved node.

BTW, L3-cache and tifs will be reserved by default.

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

      reply	other threads:[~2023-05-03  9:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-19  6:13 [PATCH] arch: arm: mach-k3: Delete tifs node in DT fixup Udit Kumar
2023-04-19 15:52 ` Nishanth Menon
2023-04-20  7:58   ` Kumar, Udit
2023-04-20  8:11 ` [PATCH v2] " Udit Kumar
2023-04-26  9:26   ` Neha Malcom Francis
2023-04-26 10:05     ` Kumar, Udit
2023-04-26 10:31       ` Neha Malcom Francis
2023-04-26 10:39         ` Kumar, Udit
2023-04-26 12:01           ` Neha Malcom Francis
2023-04-26 13:37             ` Nishanth Menon
2023-04-26 14:13             ` Kumar, Udit
2023-05-01 14:46               ` Andrew Davis
2023-05-02  7:04                 ` Neha Malcom Francis
2023-05-02  7:27                 ` Kumar, Udit
2023-05-02 23:00                   ` Nishanth Menon
2023-05-03  9:30                     ` Kumar, Udit [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ca8cf647-7279-9f1e-b59f-e7bb5feb535f@ti.com \
    --to=u-kumar1@ti.com \
    --cc=afd@ti.com \
    --cc=n-dasan@ti.com \
    --cc=n-francis@ti.com \
    --cc=nm@ti.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    --cc=vigneshr@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.