Re: [PATCH 1/2] media: venus: vdec: signal EOS with a real buffer

[Bryan O'Donoghue <bod@kernel.org>]

On 16/10/2026 14:34, David Heidelberg wrote:
> On 09/10/2026 11:15,bod@kernel.org wrote:
>> On 2026-09-28 23:40 +0200, David Heidelberg wrote:
>>> The decoder tells the firmware about the end of the stream with an empty
>>> buffer command whose address is a dummy (0xdeadb000), because the host
>>> has no input buffer to name. The SDM845 (Venus v4) firmware validates
>>> that address and rejects it:
>>>
>>>     IsBufferProtected(1087): VenusCoreCtrl: CP_UNKNOWN, buffer straddles
>>>     CP & non-CP regions
>>>     vDec_EmptyBuffer(1932): Invalidate buffer in ETB
>>>
>>> and raises HFI_ERR_SESSION_FATAL, reported by the driver as
>>>
>>>     qcom-venus aa00000.video-codec: session error: event id:1001 (deadb000)
>>>
>>> Both queues are then put into an error state, so the drain never
>>> completes and every V4L2_DEC_CMD_STOP ends the stream with an error:
>>> GStreamer's poll() fails at end of file, ffmpeg aborts.
>>>
>>> Allocate a small buffer the first time a decoder instance is drained and
>>> use its device address for the EOS command, so the firmware gets an
>>> address that is mapped and outside the protected regions. The firmware
>>> then drains normally: all frames are returned and the last capture
>>> buffer carries V4L2_BUF_FLAG_LAST. The NULL address used by old IRIS2
>>> firmware is left alone.
>>>
>>> Assisted-by: LLM
>>> Fixes: beac82904a87 ("media: venus: make decoder compliant with stateful codec API")
>>> Signed-off-by: David Heidelberg<david@ixit.cz>
>> The logic stacks up as I read it but, I want to see this a) work on sdm845
>> and b) not break on sm8250 before applying.
> On sdm845 it works great (tested multiple sdm845 phones with `livi --demo-h264`
> and loop enabled. I don't have sm8250, thus that's up to someone with the device 🙂
> 
> David

heh I do have it.

I will test ;)

---
bod