public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephan Gerhold <stephan@gerhold.net>
To: Mukesh Ojha <quic_mojha@quicinc.com>
Cc: Vikash Garodia <quic_vgarodia@quicinc.com>,
	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
Subject: Re: [PATCH] media: venus: firmware: Use of_reserved_mem_lookup()
Date: Wed, 31 May 2023 11:23:22 +0200	[thread overview]
Message-ID: <ZHcSAbu1yYuhnKSc@gerhold.net> (raw)
In-Reply-To: <eefd371e-9c9c-2e29-8d6e-d657ee0db237@quicinc.com>

On Wed, May 31, 2023 at 01:15:26PM +0530, Mukesh Ojha wrote:
> 
> 
> 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 ?
> 

Yes, when using of_reserved_mem_lookup() the allocated address is
available in rmem->base. If you have this patch applied then it should
be given to the TZ call as expected.

Thanks,
Stephan

  reply	other threads:[~2023-05-31  9:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-29 18:16 [PATCH] media: venus: firmware: Use of_reserved_mem_lookup() Stephan Gerhold
2023-05-29 18:36 ` Konrad Dybcio
2023-05-29 18:43   ` Stephan Gerhold
2023-05-31  6:06 ` Vikash Garodia
2023-05-31  6:56   ` Stephan Gerhold
2023-05-31  7:34     ` Vikash Garodia
2023-05-31  7:45       ` Mukesh Ojha
2023-05-31  9:23         ` Stephan Gerhold [this message]
2023-05-31  8:55 ` Vikash Garodia
2023-08-02  8:57 ` Stephan Gerhold
2023-08-02 11:55   ` Stanimir Varbanov

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=ZHcSAbu1yYuhnKSc@gerhold.net \
    --to=stephan@gerhold.net \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=quic_mojha@quicinc.com \
    --cc=quic_vgarodia@quicinc.com \
    --cc=stanimir.k.varbanov@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox