[RFC PATCH 0/5] media: iris: ffmpeg decoder flow changes, for reference only

[Christian Cortner <ccortner@gmail.com>]

These are the local changes behind my report "[BUG] media: iris:
resolution change handling stops ffmpeg's h264_v4l2m2m decoder on
glymur" [1], posted because Bryan asked for the code [2]. They are for
reference only, not for merging, and carry no Signed-off-by, because I
can't review or defend kernel code myself. An AI coding assistant
(Claude, by Anthropic) traced the driver, wrote the changes, their
commit messages and a test client, and ran the tests below, in a long
interactive session that started from "make hardware video decoding
work on this laptop". Each patch has an Assisted-by tag.

Patch 5 does not work for most real streams, see [3]. It resumes the
firmware through iris_vdec_start_cmd() while the driver's internal
buffers are still sized for four frame buffers, so streams that need
more, x264 at its default settings among them, end in a fatal
firmware error. It is included only to show where the driver could
resume a first source change itself; a working version would have to
re-create the internal buffers first, or resume only when they fit.
The commit message of patch 4 notes that re-creating them at a later
VIDIOC_STREAMON(CAPTURE), in a different situation, made the firmware
return nothing at all.

The patches and the problems in [1] they address:

  1/5  Don't flag an empty source change LAST buffer as an error  (2)
  2/5  Update the CAPTURE stride and size on S_FMT(OUTPUT)        (5)
  3/5  Signal V4L2_EVENT_EOS only at the end of a drain           (3)
  4/5  Let a resolution change drain before stopping CAPTURE      (4)
  5/5  Resume the first source change if it fits the CAPTURE
       setup                                                      (1)

Testing: the same changes, in the form that applies to the linux-msm
laptops tree, ran on the glymur laptop from [1]; the functions they
change are the same there and in media-committers next, apart from one
line of context. These versions, on media-committers next, are
build-tested only: each builds with W=1, sparse and smatch without new
warnings, and checkpatch --strict warns only about the missing
Signed-off-by and, because my clone is shallow, the commit ids in the
Fixes tags. The H.264 and HEVC results in [1] came from clips encoded
with -preset ultrafast. With x264-default clips at 640x360, 1024x576
and 1280x720, the test client from [3] decoded bit-exact when it set
up CAPTURE after the first event, so that patch 5 did not act. Not
tested at all: other SoCs, and HFI gen1, which patches 3 and 4 touch.

[1] https://lore.kernel.org/linux-media/20261026160952.22082-1-ccortner@gmail.com/
[2] https://lore.kernel.org/linux-media/36201ae2-1cee-4d8d-9381-dfc9013c522e@kernel.org/
[3] https://lore.kernel.org/linux-media/179306719855.20070.15625203453374418392.iris-rfc-reply@gmail.com/

Christian Cortner (5):
  media: iris: Don't flag an empty source change LAST buffer as an error
  media: iris: Update the CAPTURE stride and size on S_FMT(OUTPUT)
  media: iris: Signal V4L2_EVENT_EOS only at the end of a drain
  media: iris: Let a resolution change drain before stopping CAPTURE
  media: iris: Resume the first source change if it fits the CAPTURE
    setup

 .../media/platform/qcom/iris/iris_buffer.c    |   7 +-
 .../media/platform/qcom/iris/iris_common.c    |   3 +
 .../qcom/iris/iris_hfi_gen2_response.c        |  40 +++++-
 .../media/platform/qcom/iris/iris_instance.h  |   7 ++
 drivers/media/platform/qcom/iris/iris_state.c |   8 +-
 drivers/media/platform/qcom/iris/iris_vb2.c   |  23 +++-
 drivers/media/platform/qcom/iris/iris_vdec.c  | 117 +++++++++++++-----
 drivers/media/platform/qcom/iris/iris_vdec.h  |   3 +
 drivers/media/platform/qcom/iris/iris_vidc.c  |   1 +
 9 files changed, 176 insertions(+), 33 deletions(-)


base-commit: d7e7bca7169873b46e857c025c10f3336c1258d8
-- 
2.56.0