On 4/29/2025 3:13 PM, Bryan O'Donoghue wrote:
On 28/04/2025 10:28, Dikshita Agarwal wrote:
+ /* + * during stream on, skip destroying internal(DPB) buffer + * if firmware did not return it. + * during close, destroy all buffers irrespectively. + */ + if (!force && buf->attr & BUF_ATTR_QUEUED) + continue;
What's the effect of the firmware not having dequeued the buffer though ?
My main concern here is APSS and firmware have a different view of DMA memory.
We release on the APSS side but firmware has not.
Surely failure to release buffers by the time we get to Linux::close() is a failure of the software contract sufficient to require resetting the firmware ?
i.e. we release memory on the APSS side but firmware writes into it anyway ...
As I mentioned earlier as well, during STOP issued before close, firmware is expected to release all these internal buffers and the check I added now in this patch will also ensures that. Firmware also has a check to make sure all buffers queued are released as part of STOP and then only firmware sends the STOP_DONE response to driver. STOP is a synchronous call and driver doesn't proceed without receiving the response for the same from firmware. So we will never run into this issue where driver release buffers which are still being accessed by firmware. Please note, these are internal buffers which are allocated and managed by driver only.
Thanks, Dikshita
?
bod