Re: [PATCH v2 01/23] media: iris: Skip destroying internal buffer if not dequeued

[Dikshita Agarwal <quic_dikshita@quicinc.com>]

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