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?
Does it make sense to attach instead of creating?
--srini
>>> + }
>>> + spin_unlock_irqrestore(&cctx->lock, flags);
>>>
>>> args[2].ptr = (u64)(uintptr_t) pages;
>>> args[2].length = sizeof(*pages);
