[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <31b850f0-7ee4-67e0-8cdb-39b9651a9d57@quicinc.com>
Date: Wed, 31 May 2023 13:04:00 +0530
From: Vikash Garodia <quic_vgarodia@...cinc.com>
To: Stephan Gerhold <stephan@...hold.net>
CC: Stanimir Varbanov <stanimir.k.varbanov@...il.com>,
Andy Gross <agross@...nel.org>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konrad.dybcio@...aro.org>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
<linux-media@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] media: venus: firmware: Use of_reserved_mem_lookup()
On 5/31/2023 12:26 PM, Stephan Gerhold wrote:
> On Wed, May 31, 2023 at 11:36:52AM +0530, Vikash Garodia wrote:
>> On 5/29/2023 11:46 PM, Stephan Gerhold wrote:
>>> Reserved memory can be either looked up using the generic function
>>> of_address_to_resource() or using the special of_reserved_mem_lookup().
>>> The latter has the advantage that it ensures that the referenced memory
>>> region was really reserved and is not e.g. status = "disabled".
>>>
>>> of_reserved_mem also supports allocating reserved memory dynamically at
>>> boot time. This works only when using of_reserved_mem_lookup() since
>>> there won't be a fixed address in the device tree.
>> IIUC, this would avoid precomputing the hard range for different firmware
>> regions and also make it more flexible to adjust the sizes, if anyone wants a
>> bigger size later.
>> Incase a specific firmware needs a dedicate start address, do we have an option
>> to specify the same ?
>>
>
> If you want a specific start address (or in other words: a fixed base
> address) then you should continue using static reservation for that
> component. You can mix static and dynamic reservations. The static ones
> (with fixed addresses) will be reserved first, then the dynamic ones
> will be allocated from the free space.
>
> I have this example for one device in my proposal at [1]:
>
> /* Firmware must be loaded at address 0x8b600000 */
> wcnss_mem: wcnss@...00000 {
> reg = <0x8b600000 0x600000>;
> no-map;
> };
> /* Firmware can be loaded anywhere with 1 MiB alignment */
> venus_mem: venus {
> size = <0x500000>;
> alignment = <0x100000>;
> no-map;
> };
>
> The wcnss_mem will be always at 0x8b600000, but the venus_mem can be
> loaded somewhere around that. If only certain regions need a fixed
> address this still provides the flexibility to change sizes more easily.
>
> Does that answer your question? I wasn't sure what exactly you mean with
> a "dedicated start address". :)
Yes, it clarified the need if any subsystem wants a specific start address.
One more thing, lets say, we keep it dynamic allocation and at the same time we
need to pass the start address to TZ call in [1]. How do we get that allocated
address so as to pass in [1] ?
Thanks,
Vikash
[1]:
https://elixir.bootlin.com/linux/v6.4-rc4/source/drivers/soc/qcom/mdt_loader.c#L249
Powered by blists - more mailing lists