Message ID | 20230314072557.29669-1-yunfei.dong@mediatek.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp1615443wrd; Tue, 14 Mar 2023 00:36:39 -0700 (PDT) X-Google-Smtp-Source: AK7set8tbm1xCZeomkuJwZUZ4vWMqydhZTWIfDyoakZstjAqWjq4QjdBoN6hUOvkA070LG5wpkAL X-Received: by 2002:a05:6a20:8e05:b0:cb:c2a8:2c48 with SMTP id y5-20020a056a208e0500b000cbc2a82c48mr45499277pzj.17.1678779398897; Tue, 14 Mar 2023 00:36:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1678779398; cv=none; d=google.com; s=arc-20160816; b=EyVzTv0xHKTZSbWFbqo8c4HZ0IjzL6Usjcsh85r61QpU3VkDduLTd/LExIj0zZNSuW BIeJIOyS2OSVHIWNPfn9dcRgiMe5F7C7pgSjTedaOmyGfn6Ikp2xnYPodSNcDK3yJqm6 S7AatqmrxXsPZq/eVVnJW9RuJEej3nSlfNvgTI5Me2Y1kTNfO7SBOXTZkkQDhTKo67ru hhfQOvLNKC6wDsjPcweFi0R7Y9RasnFFqL/LL92T//FWs28SkAdbgU9hwGMlKqjaKRyp Sm6/onPhuFTb2g4FJPxG5pxZ/qdySf7XbIWIaZx/4tOVi0LgdsLF/Q3SoW8niZibhwnv znNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=0BSMzhQxV0HjibSsjHG5IXMuBDWYtIn/i372U14mmuQ=; b=DsrZrmplUpvV1auMhWbs4mmcau3PZpx+kdJx2KyEWGpXS0osVVvEJJ6gmBS5bZhJO3 slop8fzEeHwiQzsmC1R9Pudfthp63kqSWrnGkHHKAUbw2zavGR0dam6+8IGuYlHlsiU+ U3DYOD8qPTBi+iaOqaqvhDKev1VgkTqAh+e4zG+mQ0C6zxePItv3xc1i+KUchiduW/Mc nwkCUwH85dxzsZzU0HI5uxgFIw/dyf6zojTot1cb+BnlV40PuCgOzzjCijzDKciCmHsh BAOl17oOQgo1uXB7vmeIRNKSjRxD1C30uUd8Vtsvir0r/1oi4ML51OiDrLC7Oa6GIiDS FYdg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mediatek.com header.s=dk header.b="L5fz/pIt"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=mediatek.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f3-20020a631003000000b00507681d47bcsi1540750pgl.567.2023.03.14.00.36.23; Tue, 14 Mar 2023 00:36:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@mediatek.com header.s=dk header.b="L5fz/pIt"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=mediatek.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230284AbjCNH0X (ORCPT <rfc822;realc9580@gmail.com> + 99 others); Tue, 14 Mar 2023 03:26:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35474 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230265AbjCNH0S (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 14 Mar 2023 03:26:18 -0400 Received: from mailgw01.mediatek.com (unknown [60.244.123.138]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C12DC74A72; Tue, 14 Mar 2023 00:26:10 -0700 (PDT) X-UUID: 7ac013c6c23911eda06fc9ecc4dadd91-20230314 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mediatek.com; s=dk; h=Content-Type:Content-Transfer-Encoding:MIME-Version:Message-ID:Date:Subject:CC:To:From; bh=0BSMzhQxV0HjibSsjHG5IXMuBDWYtIn/i372U14mmuQ=; b=L5fz/pItbq8eqOTJPwmfa0a4j7Pr7V0rOFdt1ryyWZkCtCk1RCIj5O6SY0ZOEgMf/ak//+jDRjBIEGnL1q1JQBsRmGTNpqfK3zMND0iY6GQqL67JmIXtz46P9slbmyUcGUlOEn0Ul01mA+FHigrGQIi600WxAlrieXeJ7r/X6Rs=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.20,REQID:2e37b784-acc2-412e-8397-bdb7ef68ade7,IP:0,U RL:0,TC:0,Content:0,EDM:25,RT:0,SF:0,FILE:0,BULK:0,RULE:Release_Ham,ACTION :release,TS:25 X-CID-META: VersionHash:25b5999,CLOUDID:20a3bcf5-ddba-41c3-91d9-10eeade8eac7,B ulkID:nil,BulkQuantity:0,Recheck:0,SF:102,TC:nil,Content:0,EDM:5,IP:nil,UR L:0,File:nil,Bulk:nil,QS:nil,BEC:nil,COL:0,OSI:0,OSA:0,AV:0 X-CID-BVR: 0,NGT X-UUID: 7ac013c6c23911eda06fc9ecc4dadd91-20230314 Received: from mtkmbs11n1.mediatek.inc [(172.21.101.185)] by mailgw01.mediatek.com (envelope-from <yunfei.dong@mediatek.com>) (Generic MTA with TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 256/256) with ESMTP id 1904697292; Tue, 14 Mar 2023 15:26:04 +0800 Received: from mtkmbs13n1.mediatek.inc (172.21.101.193) by mtkmbs11n1.mediatek.inc (172.21.101.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.25; Tue, 14 Mar 2023 15:25:59 +0800 Received: from mhfsdcap04.gcn.mediatek.inc (10.17.3.154) by mtkmbs13n1.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.1118.25 via Frontend Transport; Tue, 14 Mar 2023 15:25:59 +0800 From: Yunfei Dong <yunfei.dong@mediatek.com> To: Yunfei Dong <yunfei.dong@mediatek.com>, Chen-Yu Tsai <wenst@chromium.org>, Nicolas Dufresne <nicolas@ndufresne.ca>, Hans Verkuil <hverkuil-cisco@xs4all.nl>, AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>, Benjamin Gaignard <benjamin.gaignard@collabora.com>, =?utf-8?q?N=C3=ADcolas?= =?utf-8?q?_F_=2E_R_=2E_A_=2E_Prado?= <nfraprado@collabora.com> CC: Matthias Brugger <matthias.bgg@gmail.com>, Hsin-Yi Wang <hsinyi@chromium.org>, Fritz Koenig <frkoenig@chromium.org>, Daniel Vetter <daniel@ffwll.ch>, Steve Cho <stevecho@chromium.org>, <linux-media@vger.kernel.org>, <devicetree@vger.kernel.org>, <linux-kernel@vger.kernel.org>, <linux-arm-kernel@lists.infradead.org>, <linux-mediatek@lists.infradead.org>, <Project_Global_Chrome_Upstream_Group@mediatek.com> Subject: [PATCH v3] media: mediatek: vcodec: Force capture queue format to MM21 Date: Tue, 14 Mar 2023 15:25:57 +0800 Message-ID: <20230314072557.29669-1-yunfei.dong@mediatek.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-MTK: N X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS, T_SPF_TEMPERROR,UNPARSEABLE_RELAY,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1757422920855705120?= X-GMAIL-MSGID: =?utf-8?q?1760327786776624930?= |
Series |
[v3] media: mediatek: vcodec: Force capture queue format to MM21
|
|
Commit Message
Yunfei Dong (董云飞)
March 14, 2023, 7:25 a.m. UTC
Libyuv is one software library used to covert format. Only covert
mediatek uncompressed mode MM21 to standard yuv420 for MT21 is
compressed mode. Need to set capture queue format to MM21 in order
to use Libyuv when scp firmware support MM21 and MT21.
Fixes: 7501edef6b1f ("media: mediatek: vcodec: Different codec using different capture format")
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com>
---
changed with v2:
- re-write commit message.
- change the driver flow.
changed with v1:
- add Fixes tag.
---
.../platform/mediatek/vcodec/mtk_vcodec_dec.c | 24 +++----------------
1 file changed, 3 insertions(+), 21 deletions(-)
Comments
Il 14/03/23 08:25, Yunfei Dong ha scritto: > Libyuv is one software library used to covert format. Only covert > mediatek uncompressed mode MM21 to standard yuv420 for MT21 is > compressed mode. Need to set capture queue format to MM21 in order > to use Libyuv when scp firmware support MM21 and MT21. > > Fixes: 7501edef6b1f ("media: mediatek: vcodec: Different codec using different capture format") > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> After the firmware gets sent to linux-firmware *and ONLY after that*: Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> > --- > changed with v2: > - re-write commit message. > - change the driver flow. > changed with v1: > - add Fixes tag. > --- > .../platform/mediatek/vcodec/mtk_vcodec_dec.c | 24 +++---------------- > 1 file changed, 3 insertions(+), 21 deletions(-) > > diff --git a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c > index 641f533c417f..c99705681a03 100644 > --- a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c > +++ b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c > @@ -39,10 +39,9 @@ static bool mtk_vdec_get_cap_fmt(struct mtk_vcodec_ctx *ctx, int format_index) > { > const struct mtk_vcodec_dec_pdata *dec_pdata = ctx->dev->vdec_pdata; > const struct mtk_video_fmt *fmt; > - struct mtk_q_data *q_data; > int num_frame_count = 0, i; > - bool ret = true; > > + fmt = &dec_pdata->vdec_formats[format_index]; > for (i = 0; i < *dec_pdata->num_formats; i++) { > if (dec_pdata->vdec_formats[i].type != MTK_FMT_FRAME) > continue; > @@ -50,27 +49,10 @@ static bool mtk_vdec_get_cap_fmt(struct mtk_vcodec_ctx *ctx, int format_index) > num_frame_count++; > } > > - if (num_frame_count == 1) > + if (num_frame_count == 1 || fmt->fourcc == V4L2_PIX_FMT_MM21) > return true; > > - fmt = &dec_pdata->vdec_formats[format_index]; > - q_data = &ctx->q_data[MTK_Q_DATA_SRC]; > - switch (q_data->fmt->fourcc) { > - case V4L2_PIX_FMT_VP8_FRAME: > - if (fmt->fourcc == V4L2_PIX_FMT_MM21) > - ret = true; > - break; > - case V4L2_PIX_FMT_H264_SLICE: > - case V4L2_PIX_FMT_VP9_FRAME: > - if (fmt->fourcc == V4L2_PIX_FMT_MM21) > - ret = false; > - break; > - default: > - ret = true; > - break; > - } > - > - return ret; > + return false; > } > > static struct mtk_q_data *mtk_vdec_get_q_data(struct mtk_vcodec_ctx *ctx,
On Tue, 2023-03-14 at 10:45 +0100, AngeloGioacchino Del Regno wrote: > Il 14/03/23 08:25, Yunfei Dong ha scritto: > > Libyuv is one software library used to covert format. Only covert > > mediatek uncompressed mode MM21 to standard yuv420 for MT21 is > > compressed mode. Need to set capture queue format to MM21 in order > > to use Libyuv when scp firmware support MM21 and MT21. > > > > Fixes: 7501edef6b1f ("media: mediatek: vcodec: Different codec using different capture format") > > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> > > > After the firmware gets sent to linux-firmware *and ONLY after that*: > > Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> The firmwares are sent to linux-firmware. https://lore.kernel.org/linux-firmware/a43524a089a783f70adbe89b83eeb01fbd405d04.camel@mediatek.com/T/#u > > > --- > > changed with v2: > > - re-write commit message. > > - change the driver flow. > > changed with v1: > > - add Fixes tag. > > --- > > .../platform/mediatek/vcodec/mtk_vcodec_dec.c | 24 +++---------------- > > 1 file changed, 3 insertions(+), 21 deletions(-) > > > > diff --git a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c > > index 641f533c417f..c99705681a03 100644 > > --- a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c > > +++ b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c > > @@ -39,10 +39,9 @@ static bool mtk_vdec_get_cap_fmt(struct mtk_vcodec_ctx *ctx, int format_index) > > { > > const struct mtk_vcodec_dec_pdata *dec_pdata = ctx->dev->vdec_pdata; > > const struct mtk_video_fmt *fmt; > > - struct mtk_q_data *q_data; > > int num_frame_count = 0, i; > > - bool ret = true; > > > > + fmt = &dec_pdata->vdec_formats[format_index]; > > for (i = 0; i < *dec_pdata->num_formats; i++) { > > if (dec_pdata->vdec_formats[i].type != MTK_FMT_FRAME) > > continue; > > @@ -50,27 +49,10 @@ static bool mtk_vdec_get_cap_fmt(struct mtk_vcodec_ctx *ctx, int format_index) > > num_frame_count++; > > } > > > > - if (num_frame_count == 1) > > + if (num_frame_count == 1 || fmt->fourcc == V4L2_PIX_FMT_MM21) > > return true; > > > > - fmt = &dec_pdata->vdec_formats[format_index]; > > - q_data = &ctx->q_data[MTK_Q_DATA_SRC]; > > - switch (q_data->fmt->fourcc) { > > - case V4L2_PIX_FMT_VP8_FRAME: > > - if (fmt->fourcc == V4L2_PIX_FMT_MM21) > > - ret = true; > > - break; > > - case V4L2_PIX_FMT_H264_SLICE: > > - case V4L2_PIX_FMT_VP9_FRAME: > > - if (fmt->fourcc == V4L2_PIX_FMT_MM21) > > - ret = false; > > - break; > > - default: > > - ret = true; > > - break; > > - } > > - > > - return ret; > > + return false; > > } > > > > static struct mtk_q_data *mtk_vdec_get_q_data(struct mtk_vcodec_ctx *ctx, > > -- Best regards, TingHan
Hi Yunfei, thanks for the patch. On Tue, Mar 14, 2023 at 03:25:57PM +0800, Yunfei Dong wrote: > Libyuv is one software library used to covert format. Only covert > mediatek uncompressed mode MM21 to standard yuv420 for MT21 is > compressed mode. Need to set capture queue format to MM21 in order > to use Libyuv when scp firmware support MM21 and MT21. This commit message is a bit confusing still. Here's a suggestion: While the decoder can produce frames in both MM21 and MT21C formats, only MM21 is currently supported by userspace tools (like gstreamer and libyuv). In order to ensure userspace keeps working after the SCP firmware is updated to support both MM21 and MT21C formats, force the MM21 format for the capture queue. This is meant as a stopgap solution while dynamic format switching between MM21 and MT21C isn't implemented in the driver. > > Fixes: 7501edef6b1f ("media: mediatek: vcodec: Different codec using different capture format") > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> > --- > changed with v2: > - re-write commit message. > - change the driver flow. > changed with v1: > - add Fixes tag. > --- > .../platform/mediatek/vcodec/mtk_vcodec_dec.c | 24 +++---------------- > 1 file changed, 3 insertions(+), 21 deletions(-) > While this change works (that is, I'm able to run fluster tests on both MT8192 and MT8195 using the new MM21+MT21C firmware), it causes a regression on v4l2-compliance: [..] Format ioctls: [..] fail: v4l2-test-formats.cpp(478): pixelformat 3132544d (MT21) for buftype 9 not reported by ENUM_FMT test VIDIOC_G_FMT: FAIL fail: v4l2-test-formats.cpp(478): pixelformat 3132544d (MT21) for buftype 9 not reported by ENUM_FMT test VIDIOC_TRY_FMT: FAIL fail: v4l2-test-formats.cpp(478): pixelformat 3132544d (MT21) for buftype 9 not reported by ENUM_FMT test VIDIOC_S_FMT: FAIL [..] Total for mtk-vcodec-dec device /dev/video2: 46, Succeeded: 43, Failed: 3, Warnings: 0 The patch makes only MM21 show in VIDIOC_ENUM_FMT, but VIDIOC_S_FMT, VIDIOC_G_FMT and VIDIOC_TRY_FMT still show MT21. So I think you need to do the same forcing of MM21 for those ioctls. Thanks, Nícolas > diff --git a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c > index 641f533c417f..c99705681a03 100644 > --- a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c > +++ b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c > @@ -39,10 +39,9 @@ static bool mtk_vdec_get_cap_fmt(struct mtk_vcodec_ctx *ctx, int format_index) > { > const struct mtk_vcodec_dec_pdata *dec_pdata = ctx->dev->vdec_pdata; > const struct mtk_video_fmt *fmt; > - struct mtk_q_data *q_data; > int num_frame_count = 0, i; > - bool ret = true; > > + fmt = &dec_pdata->vdec_formats[format_index]; > for (i = 0; i < *dec_pdata->num_formats; i++) { > if (dec_pdata->vdec_formats[i].type != MTK_FMT_FRAME) > continue; > @@ -50,27 +49,10 @@ static bool mtk_vdec_get_cap_fmt(struct mtk_vcodec_ctx *ctx, int format_index) > num_frame_count++; > } > > - if (num_frame_count == 1) > + if (num_frame_count == 1 || fmt->fourcc == V4L2_PIX_FMT_MM21) > return true; > > - fmt = &dec_pdata->vdec_formats[format_index]; > - q_data = &ctx->q_data[MTK_Q_DATA_SRC]; > - switch (q_data->fmt->fourcc) { > - case V4L2_PIX_FMT_VP8_FRAME: > - if (fmt->fourcc == V4L2_PIX_FMT_MM21) > - ret = true; > - break; > - case V4L2_PIX_FMT_H264_SLICE: > - case V4L2_PIX_FMT_VP9_FRAME: > - if (fmt->fourcc == V4L2_PIX_FMT_MM21) > - ret = false; > - break; > - default: > - ret = true; > - break; > - } > - > - return ret; > + return false; > } > > static struct mtk_q_data *mtk_vdec_get_q_data(struct mtk_vcodec_ctx *ctx, > -- > 2.25.1 >
Hi Nicolas, Thanks for your suggestion. On Thu, 2023-03-16 at 16:51 -0400, Nícolas F. R. A. Prado wrote: > Hi Yunfei, > > thanks for the patch. > > On Tue, Mar 14, 2023 at 03:25:57PM +0800, Yunfei Dong wrote: > > Libyuv is one software library used to covert format. Only covert > > mediatek uncompressed mode MM21 to standard yuv420 for MT21 is > > compressed mode. Need to set capture queue format to MM21 in order > > to use Libyuv when scp firmware support MM21 and MT21. > > This commit message is a bit confusing still. Here's a suggestion: > > While the decoder can produce frames in both MM21 and MT21C > formats, only MM21 > is currently supported by userspace tools (like gstreamer and > libyuv). In order > to ensure userspace keeps working after the SCP firmware is > updated to support > both MM21 and MT21C formats, force the MM21 format for the > capture queue. > > This is meant as a stopgap solution while dynamic format > switching between > MM21 and MT21C isn't implemented in the driver. > Will change it like this. > > > > Fixes: 7501edef6b1f ("media: mediatek: vcodec: Different codec > > using different capture format") > > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.com> > > --- > > changed with v2: > > - re-write commit message. > > - change the driver flow. > > changed with v1: > > - add Fixes tag. > > --- > > .../platform/mediatek/vcodec/mtk_vcodec_dec.c | 24 +++---------- > > ------ > > 1 file changed, 3 insertions(+), 21 deletions(-) > > > > While this change works (that is, I'm able to run fluster tests on > both MT8192 > and MT8195 using the new MM21+MT21C firmware), it causes a regression > on > v4l2-compliance: > > [..] > Format ioctls: > [..] > fail: v4l2-test-formats.cpp(478): pixelformat > 3132544d (MT21) for buftype 9 not reported by ENUM_FMT > test VIDIOC_G_FMT: FAIL > fail: v4l2-test-formats.cpp(478): pixelformat > 3132544d (MT21) for buftype 9 not reported by ENUM_FMT > test VIDIOC_TRY_FMT: FAIL > fail: v4l2-test-formats.cpp(478): pixelformat > 3132544d (MT21) for buftype 9 not reported by ENUM_FMT > test VIDIOC_S_FMT: FAIL > [..] > Total for mtk-vcodec-dec device /dev/video2: 46, Succeeded: 43, > Failed: 3, Warnings: 0 > Need to add one patch to change MM21 as the default capture queue format. Best Regards, Yunfei Dong > The patch makes only MM21 show in VIDIOC_ENUM_FMT, but VIDIOC_S_FMT, > VIDIOC_G_FMT and VIDIOC_TRY_FMT still show MT21. So I think you need > to do the > same forcing of MM21 for those ioctls. > > Thanks, > Nícolas > > > diff --git > > a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c > > b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c > > index 641f533c417f..c99705681a03 100644 > > --- a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c > > +++ b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c > > @@ -39,10 +39,9 @@ static bool mtk_vdec_get_cap_fmt(struct > > mtk_vcodec_ctx *ctx, int format_index) > > { > > const struct mtk_vcodec_dec_pdata *dec_pdata = ctx->dev- > > >vdec_pdata; > > const struct mtk_video_fmt *fmt; > > - struct mtk_q_data *q_data; > > int num_frame_count = 0, i; > > - bool ret = true; > > > > + fmt = &dec_pdata->vdec_formats[format_index]; > > for (i = 0; i < *dec_pdata->num_formats; i++) { > > if (dec_pdata->vdec_formats[i].type != MTK_FMT_FRAME) > > continue; > > @@ -50,27 +49,10 @@ static bool mtk_vdec_get_cap_fmt(struct > > mtk_vcodec_ctx *ctx, int format_index) > > num_frame_count++; > > } > > > > - if (num_frame_count == 1) > > + if (num_frame_count == 1 || fmt->fourcc == V4L2_PIX_FMT_MM21) > > return true; > > > > - fmt = &dec_pdata->vdec_formats[format_index]; > > - q_data = &ctx->q_data[MTK_Q_DATA_SRC]; > > - switch (q_data->fmt->fourcc) { > > - case V4L2_PIX_FMT_VP8_FRAME: > > - if (fmt->fourcc == V4L2_PIX_FMT_MM21) > > - ret = true; > > - break; > > - case V4L2_PIX_FMT_H264_SLICE: > > - case V4L2_PIX_FMT_VP9_FRAME: > > - if (fmt->fourcc == V4L2_PIX_FMT_MM21) > > - ret = false; > > - break; > > - default: > > - ret = true; > > - break; > > - } > > - > > - return ret; > > + return false; > > } > > > > static struct mtk_q_data *mtk_vdec_get_q_data(struct > > mtk_vcodec_ctx *ctx, > > -- > > 2.25.1 > > > >
diff --git a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c index 641f533c417f..c99705681a03 100644 --- a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c +++ b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c @@ -39,10 +39,9 @@ static bool mtk_vdec_get_cap_fmt(struct mtk_vcodec_ctx *ctx, int format_index) { const struct mtk_vcodec_dec_pdata *dec_pdata = ctx->dev->vdec_pdata; const struct mtk_video_fmt *fmt; - struct mtk_q_data *q_data; int num_frame_count = 0, i; - bool ret = true; + fmt = &dec_pdata->vdec_formats[format_index]; for (i = 0; i < *dec_pdata->num_formats; i++) { if (dec_pdata->vdec_formats[i].type != MTK_FMT_FRAME) continue; @@ -50,27 +49,10 @@ static bool mtk_vdec_get_cap_fmt(struct mtk_vcodec_ctx *ctx, int format_index) num_frame_count++; } - if (num_frame_count == 1) + if (num_frame_count == 1 || fmt->fourcc == V4L2_PIX_FMT_MM21) return true; - fmt = &dec_pdata->vdec_formats[format_index]; - q_data = &ctx->q_data[MTK_Q_DATA_SRC]; - switch (q_data->fmt->fourcc) { - case V4L2_PIX_FMT_VP8_FRAME: - if (fmt->fourcc == V4L2_PIX_FMT_MM21) - ret = true; - break; - case V4L2_PIX_FMT_H264_SLICE: - case V4L2_PIX_FMT_VP9_FRAME: - if (fmt->fourcc == V4L2_PIX_FMT_MM21) - ret = false; - break; - default: - ret = true; - break; - } - - return ret; + return false; } static struct mtk_q_data *mtk_vdec_get_q_data(struct mtk_vcodec_ctx *ctx,