Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <eefd371e-9c9c-2e29-8d6e-d657ee0db237@quicinc.com>
Date:   Wed, 31 May 2023 13:15:26 +0530
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Subject: Re: [PATCH] media: venus: firmware: Use of_reserved_mem_lookup()
To:     Vikash Garodia <quic_vgarodia@quicinc.com>,
        Stephan Gerhold <stephan@gerhold.net>
CC:     Stanimir Varbanov <stanimir.k.varbanov@gmail.com>,
        Andy Gross <agross@kernel.org>,
        Bjorn Andersson <andersson@kernel.org>,
        Konrad Dybcio <konrad.dybcio@linaro.org>,
        Mauro Carvalho Chehab <mchehab@kernel.org>,
        <linux-media@vger.kernel.org>, <linux-arm-msm@vger.kernel.org>,
        <linux-kernel@vger.kernel.org>
References: <20230529-venus-of-rmem-v1-1-dfcdc5047ffb@gerhold.net>
 <38a627a2-040d-23e2-5637-32f199d0fc31@quicinc.com>
 <ZHbvkDkkS_pZltMG@gerhold.net>
 <31b850f0-7ee4-67e0-8cdb-39b9651a9d57@quicinc.com>
Content-Language: en-US
From:   Mukesh Ojha <quic_mojha@quicinc.com>
In-Reply-To: <31b850f0-7ee4-67e0-8cdb-39b9651a9d57@quicinc.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 5/31/2023 1:04 PM, Vikash Garodia wrote:
> 
> 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@8b600000 {
>> 		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] ?

+	*mem_phys = rmem->base;

It will provide the start, is not it ?

-- Mukesh

> 
> Thanks,
> Vikash
> 
> [1]:
> https://elixir.bootlin.com/linux/v6.4-rc4/source/drivers/soc/qcom/mdt_loader.c#L249