On Fri, Dec 05, 2025 at 04:17:56PM -0600, Bjorn Andersson wrote: > 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...).
What you suggest ? 0x36c8 bytes was the size for CDSP resource table on Lemans. -- -Mukesh Ojha
