Re: [PATCH] arm64: dts: qcom: sm8750: Add adsp fastrpc support

[Ekansh Gupta <quic_ekangupt@quicinc.com>]

On 5/12/2025 9:25 PM, Dmitry Baryshkov wrote:
> On Mon, May 12, 2025 at 09:25:13AM +0530, Ekansh Gupta wrote:
>>
>> On 5/10/2025 1:19 AM, Dmitry Baryshkov wrote:
>>> On Fri, May 09, 2025 at 09:12:30AM +0530, Ekansh Gupta wrote:
>>>> On 5/9/2025 4:27 AM, Konrad Dybcio wrote:
>>>>> On 5/9/25 12:20 AM, Alexey Klimov wrote:
>>>>>> On Fri May 2, 2025 at 10:38 AM BST, Konrad Dybcio wrote:
>>>>>>> On 5/2/25 3:15 AM, Alexey Klimov wrote:
>>>>>>>> While at this, also add required memory region for fastrpc.
>>>>>>>>
>>>>>>>> Tested on sm8750-mtp device with adsprpdcd.
>>>>>>>>
>>>>>>>> Cc: Ekansh Gupta <quic_ekangupt@quicinc.com>
>>>>>>>> Cc: Srinivas Kandagatla <srini@kernel.org>
>>>>>>>> Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
>>>>>>>> Signed-off-by: Alexey Klimov <alexey.klimov@linaro.org>
>>>>>>>> ---
>>>>>>>>  arch/arm64/boot/dts/qcom/sm8750.dtsi | 70 ++++++++++++++++++++++++++++
>>>>>>>>  1 file changed, 70 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
>>>>>>>> index 149d2ed17641..48ee66125a89 100644
>>>>>>>> --- a/arch/arm64/boot/dts/qcom/sm8750.dtsi
>>>>>>>> +++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi
>>>>>>>> @@ -7,6 +7,7 @@
>>>>>>>>  #include <dt-bindings/clock/qcom,sm8750-gcc.h>
>>>>>>>>  #include <dt-bindings/clock/qcom,sm8750-tcsr.h>
>>>>>>>>  #include <dt-bindings/dma/qcom-gpi.h>
>>>>>>>> +#include <dt-bindings/firmware/qcom,scm.h>
>>>>>>>>  #include <dt-bindings/interconnect/qcom,icc.h>
>>>>>>>>  #include <dt-bindings/interconnect/qcom,sm8750-rpmh.h>
>>>>>>>>  #include <dt-bindings/interrupt-controller/arm-gic.h>
>>>>>>>> @@ -523,6 +524,14 @@ llcc_lpi_mem: llcc-lpi@ff800000 {
>>>>>>>>  			reg = <0x0 0xff800000 0x0 0x800000>;
>>>>>>>>  			no-map;
>>>>>>>>  		};
>>>>>>>> +
>>>>>>>> +		adsp_rpc_remote_heap_mem: adsp-rpc-remote-heap {
>>>>>>>> +			compatible = "shared-dma-pool";
>>>>>>>> +			alloc-ranges = <0x0 0x00000000 0x0 0xffffffff>;
>>>>>>>> +			alignment = <0x0 0x400000>;
>>>>>>>> +			size = <0x0 0xc00000>;
>>>>>>>> +			reusable;
>>>>>>>> +		};
>>>>>>>>  	};
>>>>>>>>  
>>>>>>>>  	smp2p-adsp {
>>>>>>>> @@ -2237,6 +2246,67 @@ q6prmcc: clock-controller {
>>>>>>>>  						};
>>>>>>>>  					};
>>>>>>>>  				};
>>>>>>>> +
>>>>>>>> +				fastrpc {
>>>>>>>> +					compatible = "qcom,fastrpc";
>>>>>>>> +					qcom,glink-channels = "fastrpcglink-apps-dsp";
>>>>>>>> +					label = "adsp";
>>>>>>>> +					memory-region = <&adsp_rpc_remote_heap_mem>;
>>>>>>> IIUC the driver only considers this on the sensor DSP
>>>>>> Memory region is required for audio protection domain + adsprpdcd as far as I know.
>>>>> next-20250508
>>>>>
>>>>> rmem_node = of_parse_phandle(rdev->of_node, "memory-region", 0);
>>>>> if (domain_id == SDSP_DOMAIN_ID && rmem_node) {
>>>>> 	// ...
>>>>> }
>>>>>
>>>>> maybe some driver changes are still pending?
>>>> Would like to add some more details here:
>>>>
>>>> Memory region is required for audio PD for dynamic loading and remote heap memory
>>>> requirements. Some initial memory(~2MB) is allocated initially when audio daemon
>>>> is getting attached[1] and this memory is added to audio PD memory pool.
>>> How is being handled for the audio PD case? Could you please point it
>>> out in? Currently, as Konrad pointed out, it is only being used for
>>> Sensors domain (unless I miss some obvious usage handled by the core).
>> The reserved-memory support was actually first added for audio PD only[1].
> Okay, so it uses an API which I missed, excuse me. But then... How does
> it work? of_reserved_mem_device_init_by_idx() requires
> rmem->ops->device_init() to be present, which is not set for a
> reserved-memory nodes without a compat string. However on all two and a
> half platforms where I see the ADSP remote heap, it is declared without
> extra compat.

Yes, of_reserved_mem_device_init_by_idx() will fail if the compat
string is not included in the reserved-memory nodes. To understand
this better, I tested the reserved-memory both with and without the
compat string. Despite this, I did not observe any allocation
failures in either case. The only difference was the appearance of
the log message "no reserved DMA memory for FASTRPC" when the compat
string was not added, although the allocation was still successful.
The correct approach is to include the compat string, and it's
unclear why it was omitted for existing platforms.

//Ekansh

>
>> The usage of reserved-memory is audio PD:
>>
>> This memory is used by audio PD for it's dynamic loading and remote heap
>> requirements as I had mentioned earlier. I'll give more details here:
>> When audio PD starts, it expects some initial memory for it's dynamic
>> loading and other allocation requirements. To fulfill this, the audio
>> daemon allocates[2] some initial memory(~2MB) and moves the ownership to
>> the audio specific VMIDs that are configured in DT[3]. Audio PD then uses
>> this memory for it's initial operations. If there is any more memory
>> needed, audio PD makes a request to allocate memory from HLOS which is
>> again allocated from the same region[4] and then the ownership is moved
>> to the configured VMIDs[5].
>>
>> The sensors domain that you are pointing was an extension of this and as
>> pointed earlier, it was added to support SDSP use cases on some old platform
>> where there are no dedicated SDSP context banks.
>>
>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/misc/fastrpc.c?id=1ce91d45ba77a4f6bf9209d142d5c89c42cf877a
>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1274
>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/arch/arm64/boot/dts/qcom/sa8775p.dtsi#n5334
>> [4] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1884
>> [5] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1927
>>
>> //Ekansh
>>
>>>> Additionally, if there is some additional memory requirement from audio PD, the
>>>> PD can request for more memory using remote heap request[2]
>>>>
>>>> The support for SDSP was added sometime back[3] to support SDSP usecases on some old
>>>> platform as there were no dedicated context banks for SDSP there. On recent platforms,
>>>> context banks are available wherever SDSP is supported. 
>>>>
>>>> [1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1273
>>>> [2] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/misc/fastrpc.c#n1884
>>>> [3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/misc/fastrpc.c?id=c3c0363bc72d4d0907a6d446d7424b3f022ce82a
>>>>
>>>> //Ekansh
>>>>
>>>>> Konrad
>>>>>