Re: [PATCH v1 2/5] misc: fastrpc: Move all remote heap allocations to a new list
From: Dmitry Baryshkov
Date: Thu Jun 12 2025 - 07:16:43 EST
On 12/06/2025 08:13, Ekansh Gupta wrote:
On 5/22/2025 5:39 PM, Dmitry Baryshkov wrote:
On Thu, 22 May 2025 at 07:54, Ekansh Gupta
<ekansh.gupta@xxxxxxxxxxxxxxxx> wrote:
On 5/19/2025 6:59 PM, Dmitry Baryshkov wrote:
On Mon, May 19, 2025 at 04:36:13PM +0530, Ekansh Gupta wrote:
On 5/19/2025 3:46 PM, Dmitry Baryshkov wrote:
On Tue, May 13, 2025 at 09:58:22AM +0530, Ekansh Gupta wrote:
Remote heap allocations are not organized in a maintainable manner,
leading to potential issues with memory management. As the remote
Which issues? I think I have been asking this question previously.
Please expand the commit message here.
This is mostly related to the memory clean-up and the other patch where
unmap request was added, I'll try to pull more details about the issue
scenario.
Thanks.
heap allocations are maintained in fl mmaps list, the allocations
will go away if the audio daemon process is killed but there are
What is audio daemon process?
As audio PD on DSP is static, there is HLOS process(audio daemon) required to
attach to audio PD to fulfill it's memory and file operation requirements.
This daemon can be thought of to be somewhat similar to rootPD(adsprpcd) or
sensorsPD(sscrpcd) daemons. Although, there is a slight difference in case of audio
daemon as it is required to take additional information and resources to audio PD
while attaching.
I find it a little bit strange to see 'required' here, while we have
working audio setup on all up platforms up to and including SM8750
without any additional daemons. This is the primary reason for my
question: what is it, why is it necessary, when is it necessary, etc.
This daemon is critical to facilitate dynamic loading and memory
requirement for audio PD(running on DSP for audio processing). Even
for audio testing on SM8750, I believe Alexey was enabling this daemon.
Could you please point out the daemon sources?
As far as I remember, we didn't need it on any of the platforms up to
and including SM8650, that's why I'm asking.
This source was used for testing audio use case on SM8750:
https://github.com/quic/fastrpc/blob/development/src/adsprpcd.c
The use case tried by Alexey as per my knowledge is audio playback where dynamic
loading was needed but he can give more details on the use case.
Okay.
You need to be more specific in the commit messages.
- It is a normal adsprpcd.
- It is only required for compressed audio playback.
He was observing failures and panic which got resolved after picking this patch series.
Which failures? Panic in which driver?
What is it?
- HLOS process to attached to audio PD to fulfill the requirements that
cannot be met by DSP alone(like file operations, memory etc.)
Why is it necessary?
- There are limitation on DSP for which the PD requirements needs to be
taken to HLOS. For example, DSP does not have it's own file system, so
any file operation request it PD(say for dynamic loading) needs to be
taken to HLOS(using listener/reverse calls) and is fulfilled there.
Similarly memory requirement is another example.
When is it necessary?
- When audio PD needs to perform any task that requires HLOS relying
operations like dynamic loading etc.
This doesn't exactly answer the question. I can play and capture audio
on most of the platforms that I tested without using extra daemon. So,
when is it necessary?
For use case details, I'll let Alexey comment here.
The daemons major requirement is to facilitate any dynamic loading or memory
requirements from DSP audio PD. The daemons are already supported for
different types of static PDs to facilitate these requirements(fops and memory).
So... compressed audio only or a normal playback / capture too?
--
With best wishes
Dmitry