Message-ID: <sysdgcspvxhytyudknnyj4hu6lc47we5ijkrsssi6askysqyo2@bdzl5cvzc4be>
Date: Fri, 5 Dec 2025 16:17:56 -0600
From: Bjorn Andersson <andersson@...nel.org>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
Cc: Mukesh Ojha <mukesh.ojha@....qualcomm.com>, 
	Mathieu Poirier <mathieu.poirier@...aro.org>, Rob Herring <robh@...nel.org>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>, 
	Manivannan Sadhasivam <mani@...nel.org>, Konrad Dybcio <konradybcio@...nel.org>, 
	linux-arm-msm@...r.kernel.org, linux-remoteproc@...r.kernel.org, devicetree@...r.kernel.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 11/14] firmware: qcom_scm: Add
 qcom_scm_pas_get_rsc_table() to get resource table

On Fri, Dec 05, 2025 at 02:15:00PM +0100, Konrad Dybcio wrote:
> On 12/4/25 1:28 PM, Mukesh Ojha wrote:
> > On Wed, Dec 03, 2025 at 01:36:32PM +0100, Konrad Dybcio wrote:
> >> On 11/24/25 4:25 PM, Mukesh Ojha wrote:
> >>> On Mon, Nov 24, 2025 at 12:48:31PM +0100, Konrad Dybcio wrote:
> >>>> On 11/21/25 12:01 PM, Mukesh Ojha wrote:
> >>>>> Qualcomm remote processor may rely on Static and Dynamic resources for
> >>>>> it to be functional. Static resources are fixed like for example,
> >>>>> memory-mapped addresses required by the subsystem and dynamic
> >>>>> resources, such as shared memory in DDR etc., are determined at
> >>>>> runtime during the boot process.
> >>>>>
> >>>>> For most of the Qualcomm SoCs, when run with Gunyah or older QHEE
> >>>>> hypervisor, all the resources whether it is static or dynamic, is
> >>>>> managed by the hypervisor. Dynamic resources if it is present for a
> >>>>> remote processor will always be coming from secure world via SMC call
> >>>>> while static resources may be present in remote processor firmware
> >>>>> binary or it may be coming qcom_scm_pas_get_rsc_table() SMC call along
> >>>>> with dynamic resources.
> 
> [...]
> 
> > Just to avoid iteration, are you suggesting that we can keep this
> > guesswork as part of __qcom_scm_pas_get_rsc_table() and start with
> > something smaller than SZ_16K?
> > 
> > I kind of agree with the first part, but SZ_16K was the recommended size
> > from the firmware for Lemans to start with, in order to pass the SMC
> > successfully on the first try. However, the same size was failing for
> > Glymur, and it required a second attempt with the correct size.
> 
> It depends on the payload, which you're probably much more familiar with.
> If 95% of them will be closer to e.g. 1K in size, it perhaps makes sense
> to use up the additional few dozen cycles on our amazingly fast CPUs and
> retry as necessary, instead of blindly reserving a whole bunch of memory.
> 

Those "few dozen cycles", is tasked with sending messages to RPMh for
voting and unvoting the buses, then tzmem will hopefully hit the
genpool, twice, and then radix updates, and then more genpool updated
and more radix tree work. And then of course there's the one context
switch to secure world.

If we don't have space in the genpool, we're going to grow
dma_alloc_coherent, extend the genpool, call secure world to register
the new tzmem. And then for all those cases where the allocation wasn't
enough, the retry (with updated size) will not fit in the
PAGE_ALIGN(size) genpool that was created, so we'll do this twice.

Fortunately the tzmem growing should only happen on first remoteproc
boot, but I think it's a bit optimistic to say "a few dozen"...


The drawback with making it 16KB is that we're not going to test that
error path very often. But the more idiomatic form of first calling with
a size of 0, then allocate and pass the proper size, seems a bit
wasteful to me as well - in particular if we do it anew each subsystem
boot.

PS. 16KB is 0.03% of the ADSP carveout (or 3% of the ADSP DeviceTree
carveout...).

Regards,
Bjorn

> Konrad

Powered by blists - more mailing lists