Re: [PATCH v2] media: mtk-jpeg: drain hardware completion before freeing context

[Nicolas Dufresne <nicolas.dufresne@collabora.com>]

[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]

Hi,

Le mardi 21 juillet 2026 à 17:15 +0800, Guangshuo Li a écrit :
> Would you prefer a correctness-first change that moves job_finish() to
> the hardware completion paths, accepting that serialization, or is
> there an existing v4l2-m2m mechanism for representing several
> concurrent hardware jobs that I have missed?

This one predates me as a maintainer, so I'm a bit in catchup mode. I think your
work shows how much problems/complexity this method introduce. I'm currently
tracking two proposal, an RKVDEC and an RGA2 proposal. I think the second method
is worth looking into. The first one might have had the same issue as this one,
as it called job_finish() immediatly in device_run() (which is equivalent of
doing it in a worker like MTK codecs do in general**. 

https://lore.kernel.org/all/20260606-spu-rga3multicore-v1-0-3ec2b15675f7@pengutronix.de/

And you'll find the patch:

[PATCH 05/17] media: v4l2-mem2mem: support running multiple jobs in parallel

That adds parallel job in the mem2mem, so that you can have a single m2m context
for multiple cores, handling multiple jobs, and the tear down is happening on
all cores. Now, I'm not forcing you to do that path, but I think its a better
solution long term, as open coding custom tear down is error prone. Let me know
your thought, of course I'd like if you could work with Sven on a common
solution.

Nicolas


** Most of MTK codecs worker are not needed, since the m2m framework already has
a worker and is re-entrent safe for triggering the next job. But MTK code uses a
lot of condition wait, turning async operation into synchronous, and once multi-
core, it just break apart.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]