From: Tzung-Bi Shih <tzungbi@google.com>
To: Irui Wang <irui.wang@mediatek.com>
Cc: Hans Verkuil <hverkuil-cisco@xs4all.nl>,
Tzung-Bi Shih <tzungbi@chromium.org>,
Alexandre Courbot <acourbot@chromium.org>,
Tiffany Lin <tiffany.lin@mediatek.com>,
Andrew-CT Chen <andrew-ct.chen@mediatek.com>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
Rob Herring <robh+dt@kernel.org>,
Matthias Brugger <matthias.bgg@gmail.com>,
Tomasz Figa <tfiga@google.com>, Yong Wu <yong.wu@mediatek.com>,
Hsin-Yi Wang <hsinyi@chromium.org>,
Maoguang Meng <maoguang.meng@mediatek.com>,
Longfei Wang <longfei.wang@mediatek.com>,
Yunfei Dong <yunfei.dong@mediatek.com>,
Fritz Koenig <frkoenig@chromium.org>,
linux-media@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
srv_heupstream@mediatek.com, linux-mediatek@lists.infradead.org,
Project_Global_Chrome_Upstream_Group@mediatek.com
Subject: Re: [PATCH 7/9] media: mtk-vcodec: Add frame racing mode encode process
Date: Wed, 25 Aug 2021 03:20:39 +0800 [thread overview]
Message-ID: <YSVGh0/6mAgHFmPb@google.com> (raw)
In-Reply-To: <20210816105934.28265-8-irui.wang@mediatek.com>
On Mon, Aug 16, 2021 at 06:59:32PM +0800, Irui Wang wrote:
> The frame_racing mode encoding is try to use the two venc cores:
s/is try/tries/
> frame#0 use core#0, frame#1 use core#1, frame#2 use core#0...,
s/use/uses/g
> Lock the device and enabe the clock by used core, for sequence
s/enabe/enable/
> header encoding, it always used core#0.
s/used/uses/
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h
> @@ -273,6 +273,7 @@ struct vdec_pic_info {
> * @decoded_frame_cnt: number of decoded frames
> * @lock: protect variables accessed by V4L2 threads and worker thread such as
> * mtk_video_dec_buf.
> + * @enc_idx: used to record encoded frame count
> */
> struct mtk_vcodec_ctx {
> enum mtk_instance_type type;
> @@ -313,6 +314,8 @@ struct mtk_vcodec_ctx {
> int decoded_frame_cnt;
> struct mutex lock;
>
> + int hw_id;
> + int enc_idx;
hw_id lacks of kerneldoc which could introduce smatch warning.
> --- a/drivers/media/platform/mtk-vcodec/venc_drv_if.c
> +++ b/drivers/media/platform/mtk-vcodec/venc_drv_if.c
> @@ -15,6 +15,7 @@
>
> #include "mtk_vcodec_enc.h"
> #include "mtk_vcodec_enc_pm.h"
> +#include "mtk_vcodec_enc_hw.h"
Please try to maintain the order.
> @@ -34,9 +35,9 @@ int venc_if_init(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
> return -EINVAL;
> }
>
> - mtk_venc_lock(ctx);
> + mtk_venc_lock(ctx, 0);
Does it make more sense to use ctx->hw_id instead 0 (even if it is always 0 in the path)?
> ret = ctx->enc_if->init(ctx);
> - mtk_venc_unlock(ctx);
> + mtk_venc_unlock(ctx, 0);
Same.
> @@ -46,9 +47,9 @@ int venc_if_set_param(struct mtk_vcodec_ctx *ctx,
> {
> int ret = 0;
>
> - mtk_venc_lock(ctx);
> + mtk_venc_lock(ctx, 0);
Same.
> ret = ctx->enc_if->set_param(ctx->drv_handle, type, in);
> - mtk_venc_unlock(ctx);
> + mtk_venc_unlock(ctx, 0);
Same.
> @@ -87,11 +76,67 @@ int venc_if_deinit(struct mtk_vcodec_ctx *ctx)
> if (!ctx->drv_handle)
> return 0;
>
> - mtk_venc_lock(ctx);
> + mtk_venc_lock(ctx, 0);
Same.
> ret = ctx->enc_if->deinit(ctx->drv_handle);
> - mtk_venc_unlock(ctx);
> + mtk_venc_unlock(ctx, 0);
Same.
> +void venc_encode_unprepare(struct mtk_vcodec_ctx *ctx,
> + enum venc_start_opt opt)
> +{
> + unsigned long flags;
> + struct mtk_venc_comp_dev *venc;
> +
> + /*clock off and unlock after irq done*/
> + if (ctx->dev->venc_pdata->hw_mode == VENC_FRAME_RACING_MODE) {
> + if (opt == VENC_START_OPT_ENCODE_SEQUENCE_HEADER) {
> + mtk_vcodec_enc_clock_off(ctx->dev, ctx->hw_id);
> + spin_lock_irqsave(&ctx->dev->irqlock, flags);
> + venc = ctx->dev->enc_comp_dev[ctx->hw_id];
> + venc->curr_ctx = NULL;
> + spin_unlock_irqrestore(&ctx->dev->irqlock, flags);
> + mtk_venc_unlock(ctx, ctx->hw_id);
> + }
> + } else {
> + mtk_vcodec_enc_clock_off(ctx->dev, ctx->hw_id);
> + spin_lock_irqsave(&ctx->dev->irqlock, flags);
> + ctx->dev->curr_ctx = NULL;
> + spin_unlock_irqrestore(&ctx->dev->irqlock, flags);
> + mtk_venc_unlock(ctx, ctx->hw_id);
The few statements are identical. Should try to reuse them.
next prev parent reply other threads:[~2021-08-24 19:20 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-16 10:59 [PATCH 0/9] Enable two H264 encoder cores on MT8195 Irui Wang
2021-08-16 10:59 ` [PATCH 1/9] dt-bindings: media: mtk-vcodec: Add binding for MT8195 two venc cores Irui Wang
2021-08-18 0:09 ` Rob Herring
2021-08-24 11:02 ` Ezequiel Garcia
2021-08-25 2:02 ` Irui Wang (王瑞)
2021-08-25 3:49 ` Ezequiel Garcia
2021-08-25 7:16 ` Irui Wang (王瑞)
2021-08-16 10:59 ` [PATCH 2/9] media: mtk-vcodec: Use component framework to manage encoder hardware Irui Wang
2021-08-23 10:01 ` Tzung-Bi Shih
2021-08-16 10:59 ` [PATCH 3/9] media: mtk-vcodec: Rewrite venc power manage interface Irui Wang
2021-08-23 10:16 ` Tzung-Bi Shih
2021-08-16 10:59 ` [PATCH 4/9] media: mtk-vcodec: Add venc power on/off interface Irui Wang
2021-08-24 9:53 ` Tzung-Bi Shih
2021-08-16 10:59 ` [PATCH 5/9] media: mtk-vcodec: Rewrite venc clock interface Irui Wang
2021-08-24 10:24 ` Tzung-Bi Shih
2021-08-16 10:59 ` [PATCH 6/9] media: mtk-vcodec: Add new venc drv interface for frame_racing mode Irui Wang
2021-08-24 18:54 ` Tzung-Bi Shih
2021-08-16 10:59 ` [PATCH 7/9] media: mtk-vcodec: Add frame racing mode encode process Irui Wang
2021-08-24 19:20 ` Tzung-Bi Shih [this message]
2021-08-16 10:59 ` [PATCH 8/9] media: mtk-vcodec: Return encode result to client Irui Wang
2021-08-16 10:59 ` [PATCH 9/9] media: mtk-vcodec: Add delayed worker for encode timeout Irui Wang
2021-11-25 10:17 ` [PATCH 0/9] Enable two H264 encoder cores on MT8195 AngeloGioacchino Del Regno
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YSVGh0/6mAgHFmPb@google.com \
--to=tzungbi@google.com \
--cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
--cc=acourbot@chromium.org \
--cc=andrew-ct.chen@mediatek.com \
--cc=devicetree@vger.kernel.org \
--cc=frkoenig@chromium.org \
--cc=hsinyi@chromium.org \
--cc=hverkuil-cisco@xs4all.nl \
--cc=irui.wang@mediatek.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=longfei.wang@mediatek.com \
--cc=maoguang.meng@mediatek.com \
--cc=matthias.bgg@gmail.com \
--cc=mchehab@kernel.org \
--cc=robh+dt@kernel.org \
--cc=srv_heupstream@mediatek.com \
--cc=tfiga@google.com \
--cc=tiffany.lin@mediatek.com \
--cc=tzungbi@chromium.org \
--cc=yong.wu@mediatek.com \
--cc=yunfei.dong@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).