On 02-07-2026 12:16, Srinivas Kandagatla wrote:
>
>
> On 7/2/26 5:02 AM, Ekansh Gupta wrote:
>>>> @@ -1409,8 +1395,17 @@ static int
>>>> fastrpc_init_create_static_process(struct fastrpc_user *fl,
>>>> args[1].length = inbuf.namelen;
>>>> args[1].fd = -1;
>>>>
>>>> - pages[0].addr = fl->cctx->remote_heap->dma_addr;
>>>> - pages[0].size = fl->cctx->remote_heap->size;
>>>> + spin_lock_irqsave(&cctx->lock, flags);
>>>> + if (!cctx->audio_init_mem) {
>>>> + pages[0].addr = cctx->remote_heap->dma_addr;
>>>> + pages[0].size = cctx->remote_heap->size;
>>>> + cctx->audio_init_mem = true;
>>>> + inbuf.pageslen = 1;
>>>> + } else {
>>>> + pages[0].addr = 0;
>>>> + pages[0].size = 0;
>>> What is the expected behavoiur in this case?
>> Audio daemon is expected to take the memory information to DSP audio PD
>> only the first time it goes and attaches there.
>>
>> This is the case where daemon was killed but audio PD session is still
>> running. In such cases, daemon is not expected to take any memory
>> information to audio PD as the earlier shared information is already
>> there with audio PD which it is using irrespective of daemon state.>
> Wow, this behavior is not documented or pl consider adding a comment
> here, Can we not query the dsp before creating new audiopd service?
Agree with your point about documentation, maybe Jianping can add the
information.
audio PD is generally not aware/affected by the state of daemon
process(other than the reverse request break) and there is no such query
supported to see if the audio PD already has the memory information.>
>
> Does it make sense to attach instead of creating?
Calling it attach as PD creation is not done by the daemon, PD is
statically created upon DSP boot-up, the daemon just acts as a listener
for that PD to take up reverse fastrpc request.>
> --srini
>
>>>> + }
>>>> + spin_unlock_irqrestore(&cctx->lock, flags);
>>>>
>>>> args[2].ptr = (u64)(uintptr_t) pages;
>>>> args[2].length = sizeof(*pages);
>
