On 12/5/25 11:17 PM, 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...).
Hm, perhaps 16 is not a bad choice then Konrad
