Re: [PATCH v6, 06/15] media: mtk-vcodec: Refactor get and put capture buffer flow

Le jeudi 17 février 2022 à 17:03 +0800, yunfei.dong@mediatek.com a écrit :

quoted

quoted

-	ret = vdec_if_decode(ctx, bs_src, dst_buf, &res_chg);
+	ret = vdec_if_decode(ctx, bs_src, NULL, &res_chg);
  	if (ret) {
  		mtk_v4l2_err(" <===[%d], src_buf[%d] sz=0x%zx pts=%llu
vdec_if_decode() ret=%d res_chg=%d===>",
  			     ctx->id, vb2_src->index, bs_src->size,

@@ -220,12 +266,9 @@ static void mtk_vdec_worker(struct work_struct

*work)
  		}
  	}
  
-	mtk_vdec_stateless_set_dst_payload(ctx, dst_buf);
-
-	v4l2_m2m_buf_done_and_job_finish(dev->m2m_dev_dec, ctx-

quoted

m2m_ctx,

-					 ret ? VB2_BUF_STATE_ERROR :
VB2_BUF_STATE_DONE);
-
+	mtk_vdec_stateless_out_to_done(ctx, bs_src, ret);

v4l2_m2m_buf_done_and_job_finish() was specially crafted to prevent
developer
from implementing the signalling of the request at the wrong moment.
This patch
broke this strict ordering. The relevant comment in the helper
function:

As we discussed in chat, please help to check whether it's possible to
let lat and core decode in parallel.

Thanks, Benjamin is looking into that. For the mailing list here, here's some
prior art for a similar problem found by downstream RPi4 HEVC driver developer.
The general problem here is that we don't want to signal the request until the
decode have complete, yet we want to pick and run second (concurrent job) so
that parallel decoding is made possible. For RPi4 it is not multi-core, but the
decoding is split in 2 stages, and the decoder run both stages concurrently,
which basically means, we need to be able to run two jobs at the same time
whenever possible.

https://github.com/raspberrypi/linux/commit/964be1d20e2f1335915a6bf8c82a3199bfddf8ac

This introduce media_request_pin/unpin, but being able to pin a request and not
have it bound to any other object lifetime anymore seems a bit error prone in
comparison to the current restrictions. Comments welcome !

I will continue to fix h264 issue.

Thanks.

Thanks for your help.

Best Regards,
Yunfei Dong