Re: [PATCH v2] arm64: dts: qcom: agatti: enable FastRPC on the ADSP

[Ekansh Gupta]

On 3/30/2026 4:07 PM, Konrad Dybcio wrote:
> On 3/30/26 6:54 AM, Sumit Garg wrote:
>> On Tue, Jan 13, 2026 at 06:41:59PM +0200, Dmitry Baryshkov wrote:
>>> On Agatti platform the ADSP provides FastRPC support. Add corresponding
>>> device node, in order to be able to utilize the DSP offload from the
>>> Linux side.
>>>
>>> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@xxxxxxxxxxxxxxxx>
>>> ---
>>> Changes in v2:
>>> - Add more FastRPC context banks (6, 7)
>>> - Link to v1: https://lore.kernel.org/r/20260113-agatti-fastrpc-v1-1-e210903ffcb1@xxxxxxxxxxxxxxxx
>>> ---
>>>  arch/arm64/boot/dts/qcom/agatti.dtsi | 41 ++++++++++++++++++++++++++++++++++++
>>>  1 file changed, 41 insertions(+)
>>>
>> This patch causes a critical boot regression on RB1 as per the CI test
>> report here [1]. I see this change already landed in this merge window.
>> So, either this commit has to be reverted for v7.0 release or an
>> appropriate fix is required.
>>
>> [1] https://github.com/qualcomm-linux/kernel/issues/359
> Why has that issue been opened 2 weeks ago with no action since?
>
> FWIW, copying the broader log from the LAVA job:
>
>
> [[0;32m  OK  [0m] Reached target [0;1;39mBasic System[0m.
>          Starting [0;1;39maDSP RPC daemon[0m...
>          Starting [0;1;39maudiopd aDSP RPC daemon[0m...
>          Starting [0;1;39mAndroid Debug Bridge[0m...
>          Starting [0;1;39mAvahi mDNS/DNS-SD Stack[0m...
>          Starting [0;1;39mBluetooth service[0m...
>          Starting [0;1;39mD-Bus System Message Bus[0m...
> [   17.318840] qcom,fastrpc-cb ab00000.remoteproc:glink-edge:fastrpc:compute-cb@4: mem mmap error, fd 11, vaddr ffffae380000, size 262144
> [   17.327877] qcom_q6v5_pas ab00000.remoteproc: fatal error received: SFR Init: wdog or kernel error suspected.
> [   17.343248] remoteproc remoteproc1: crash detected in adsp: type fatal error
> [   17.350567] qcom_q6v5_pas ab00000.remoteproc: Handover signaled, but it already happened
> [   17.358869] remoteproc remoteproc1: handling crash #1 in adsp
> [   17.364730] remoteproc remoteproc1: recovering adsp
>
> Format: Log Type - Time(microsec) - Message - Optional Info
> Log Type: B - Since Boot(Power On Reset),  D - Delta,  S - Statistic
> <ded>
>
> It seems like this only ends up being a problem once the userland
> daemon starting poking at the channel - +Ekansh, have you seen this
> before?
Looks like daemon attaching to PD is causing some DSP privileged PD crash. Checking this crash
now, will update here if I have any findings.
>
> Konrad
>
>