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

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/[email protected]/

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.

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQTvDVKBFcTDwhoEbxLZQZRRKWBy9AUCal95lQAKCRDZQZRRKWBy
9N7TAQCbjR0A6T7HbDRxSk17zQqfY5E7SUwkbbXmxf5iwXhsYgD/X514Y0Jl9eql
56dJ1F+qySkpOeItyxeg3Oz4q2gi6wk=
=2P1k
-----END PGP SIGNATURE-----