Message ID | 20230209074025.1816-1-yunfei.dong@mediatek.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp192881wrn; Wed, 8 Feb 2023 23:43:24 -0800 (PST) X-Google-Smtp-Source: AK7set/mOsummpzxMkW8AZszMTWt4iDSUNeB03764/Qrg87MFU61+//neSDTDcHFc/zHgC/n/h2u X-Received: by 2002:a17:907:3e95:b0:885:a62c:5a5c with SMTP id hs21-20020a1709073e9500b00885a62c5a5cmr15378435ejc.46.1675928604351; Wed, 08 Feb 2023 23:43:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675928604; cv=none; d=google.com; s=arc-20160816; b=PXwHHnNrVzdZnKlY4bRmqBBuzkVI7sc9SsZu4XTdtC3sV46pJJBLGL4lVZ/gwcw0ZW Q+hIp2q/8b6utmlpR5iIBe48MgUE5W+I0JMrA0lBKv2n41q0cyPcNiQzCFI43IFDtkCi 3Wtrf5a/yMHVa4hBnm9ITcIv+BHSSy327sMPh9daCMniMeXG6QLmwWOCYn/vWeC77+/A 65sIIoD1ZazfuOxRJP+jjBj86K61TiT3kYFztxco2qh/emQzkz2bTlsFcc8s1DnJPtdo XcJ5dGr67pwt9sUhKh0/ZnuZpdtZRO7CYikjOETflHdhB3sGnjo9gqmaR3pIvB3+ddMK zBFA== 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=9ueEDOzSLy4hgT0sgq3Tpiss3SjJVIgmjkG1FZhZ+pw=; b=GYfDILONby04lxeiUkdLotCLC0Y5/xpScWoOLYHS0oWckaIezfTUugoSPlXTg+e//9 jxdsQI44wSawSCcTonucYTEtMBos06n29ApHldswxkMHzmA3ElBEp5ANAjIRFCy80G1t MSokuIwYY9SWpiY6uDObWkqgNu+ps2Idn9vJhC5WJBKj9l1icP9KAhIzudKsWgZJSCtb XiDvU87F6A8+TIAvN3auMY2dtSS/KDDAaF9E32Pw7+mG6YxAfFhm+Y6bWulqq47W6hM9 DzpTQFP/LuSb8FcmoL7Igk66OXt3YtncnAolfIm+AOu48GBCKWm4Luz2qIpxLamZE0Js YWRA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@mediatek.com header.s=dk header.b=T7yRDpPF; 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 25-20020a170906001900b00888161349d0si2116186eja.665.2023.02.08.23.43.01; Wed, 08 Feb 2023 23:43:24 -0800 (PST) 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=T7yRDpPF; 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 S229865AbjBIHkj (ORCPT <rfc822;ybw1215001957@gmail.com> + 99 others); Thu, 9 Feb 2023 02:40:39 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45190 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229479AbjBIHkg (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 9 Feb 2023 02:40:36 -0500 Received: from mailgw01.mediatek.com (unknown [60.244.123.138]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9A8DF244A0; Wed, 8 Feb 2023 23:40:32 -0800 (PST) X-UUID: 05c721bea84d11eda06fc9ecc4dadd91-20230209 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=9ueEDOzSLy4hgT0sgq3Tpiss3SjJVIgmjkG1FZhZ+pw=; b=T7yRDpPF4NTAc6ah7Iu383tyWwJEAgD/qsxhGtO9AyC3OwgE/+ZDVhkIqXvyilJEUoGaMgdzJyEFMZ5yRyPeu6InOphQOa5qPV0KJGI+hZ0L5JsaALb6TY8sn+1uSOqSLZgrRU1IRkHgV14WdViwcWYutjnpisbQJMVpSJi4nRc=; X-CID-P-RULE: Release_Ham X-CID-O-INFO: VERSION:1.1.19,REQID:d2424df5-c65c-4c03-971d-9b903a960ae6,IP:0,U RL:0,TC:0,Content:-5,EDM:0,RT:0,SF:0,FILE:0,BULK:0,RULE:Release_Ham,ACTION :release,TS:-5 X-CID-META: VersionHash:885ddb2,CLOUDID:8616eff7-ff42-4fb0-b929-626456a83c14,B ulkID:nil,BulkQuantity:0,Recheck:0,SF:102,TC:nil,Content:0,EDM:-3,IP:nil,U RL:0,File:nil,Bulk:nil,QS:nil,BEC:nil,COL:0,OSI:0,OSA:0,AV:0 X-CID-BVR: 0,NGT X-UUID: 05c721bea84d11eda06fc9ecc4dadd91-20230209 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 1697651023; Thu, 09 Feb 2023 15:40:28 +0800 Received: from mtkmbs11n2.mediatek.inc (172.21.101.187) by mtkmbs10n1.mediatek.inc (172.21.101.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 9 Feb 2023 15:40:26 +0800 Received: from mhfsdcap04.gcn.mediatek.inc (10.17.3.154) by mtkmbs11n2.mediatek.inc (172.21.101.73) with Microsoft SMTP Server id 15.2.792.15 via Frontend Transport; Thu, 9 Feb 2023 15:40:25 +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>, Tiffany Lin <tiffany.lin@mediatek.com> CC: Mauro Carvalho Chehab <mchehab@kernel.org>, 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] media: mediatek: vcodec: Force capture queue format to MM21 Date: Thu, 9 Feb 2023 15:40:25 +0800 Message-ID: <20230209074025.1816-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, SPF_PASS,UNPARSEABLE_RELAY 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?1757338512122932541?= X-GMAIL-MSGID: =?utf-8?q?1757338512122932541?= |
Series |
media: mediatek: vcodec: Force capture queue format to MM21
|
|
Commit Message
Yunfei Dong (董云飞)
Feb. 9, 2023, 7:40 a.m. UTC
In order to conver the format of capture queue from mediatek MM21 to
standard yuv420 with Libyuv, need to force capture queue format to
MM21 for Libyuv can't covert mediatek MT21 format.
Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.org>
---
drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Comments
Hi Yunfei Dong, On Thu, Feb 09, 2023 at 03:40:25PM +0800, Yunfei Dong wrote: > In order to conver the format of capture queue from mediatek MM21 to > standard yuv420 with Libyuv, need to force capture queue format to > MM21 for Libyuv can't covert mediatek MT21 format. Sorry, just some clarifications on my side, just to understand :) The problem is that libyuv can't convert mm21 format into yuv420 than you need to use mm21 (forcing this). Did I understand correctly? Thanks in advance, Tommaso > > Signed-off-by: Yunfei Dong <yunfei.dong@mediatek.org> > --- > drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 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..4f5e9c20214f 100644 > --- a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c > +++ b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c > @@ -41,7 +41,7 @@ static bool mtk_vdec_get_cap_fmt(struct mtk_vcodec_ctx *ctx, int format_index) > const struct mtk_video_fmt *fmt; > struct mtk_q_data *q_data; > int num_frame_count = 0, i; > - bool ret = true; > + bool ret = false; > > for (i = 0; i < *dec_pdata->num_formats; i++) { > if (dec_pdata->vdec_formats[i].type != MTK_FMT_FRAME) > @@ -63,7 +63,7 @@ static bool mtk_vdec_get_cap_fmt(struct mtk_vcodec_ctx *ctx, int format_index) > case V4L2_PIX_FMT_H264_SLICE: > case V4L2_PIX_FMT_VP9_FRAME: > if (fmt->fourcc == V4L2_PIX_FMT_MM21) > - ret = false; > + ret = true; > break; > default: > ret = true; > -- > 2.18.0 >
Il 09/02/23 09:57, Tommaso Merciai ha scritto: > Hi Yunfei Dong, > > On Thu, Feb 09, 2023 at 03:40:25PM +0800, Yunfei Dong wrote: >> In order to conver the format of capture queue from mediatek MM21 to >> standard yuv420 with Libyuv, need to force capture queue format to >> MM21 for Libyuv can't covert mediatek MT21 format. > > Sorry, just some clarifications on my side, just to understand :) > The problem is that libyuv can't convert mm21 format into yuv420 > than you need to use mm21 (forcing this). > Did I understand correctly? > vcodec can output either MM21 or MT21C; libyuv can't handle the MT21C format, at least for now, hence he is forcing vcodec to always give MM21 for things to actually work... at a later time, I hope and suppose that this driver will change to not force anything anymore. > Thanks in advance, > Tommaso > Yunfei, since this is required to get "basic" functionality, this commit needs a Fixes tag: can you please add the right one? Thanks! Angelo
Hi AngeloGioacchino, Thanks for your suggestion. Add Fixes tag in patch v2. Best Regards, Yunfei Dong On Thu, 2023-02-09 at 13:56 +0100, AngeloGioacchino Del Regno wrote: > Il 09/02/23 09:57, Tommaso Merciai ha scritto: > > Hi Yunfei Dong, > > > > On Thu, Feb 09, 2023 at 03:40:25PM +0800, Yunfei Dong wrote: > > > In order to conver the format of capture queue from mediatek MM21 > > > to > > > standard yuv420 with Libyuv, need to force capture queue format > > > to > > > MM21 for Libyuv can't covert mediatek MT21 format. > > > > Sorry, just some clarifications on my side, just to understand :) > > The problem is that libyuv can't convert mm21 format into yuv420 > > than you need to use mm21 (forcing this). > > Did I understand correctly? > > > > vcodec can output either MM21 or MT21C; libyuv can't handle the MT21C > format, > at least for now, hence he is forcing vcodec to always give MM21 for > things > to actually work... at a later time, I hope and suppose that this > driver will > change to not force anything anymore. > > > Thanks in advance, > > Tommaso > > > > Yunfei, since this is required to get "basic" functionality, this > commit needs > a Fixes tag: can you please add the right one? > > Thanks! > Angelo > >
Hi Angelo, On Thu, Feb 09, 2023 at 01:56:45PM +0100, AngeloGioacchino Del Regno wrote: > Il 09/02/23 09:57, Tommaso Merciai ha scritto: > > Hi Yunfei Dong, > > > > On Thu, Feb 09, 2023 at 03:40:25PM +0800, Yunfei Dong wrote: > > > In order to conver the format of capture queue from mediatek MM21 to > > > standard yuv420 with Libyuv, need to force capture queue format to > > > MM21 for Libyuv can't covert mediatek MT21 format. > > > > Sorry, just some clarifications on my side, just to understand :) > > The problem is that libyuv can't convert mm21 format into yuv420 > > than you need to use mm21 (forcing this). > > Did I understand correctly? > > > > vcodec can output either MM21 or MT21C; libyuv can't handle the MT21C format, > at least for now, hence he is forcing vcodec to always give MM21 for things > to actually work... at a later time, I hope and suppose that this driver will > change to not force anything anymore. Thanks for the explanation! Regards, Tommaso > > > Thanks in advance, > > Tommaso > > > > Yunfei, since this is required to get "basic" functionality, this commit needs > a Fixes tag: can you please add the right one? > > Thanks! > Angelo > >
diff --git a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c index 641f533c417f..4f5e9c20214f 100644 --- a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c +++ b/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c @@ -41,7 +41,7 @@ static bool mtk_vdec_get_cap_fmt(struct mtk_vcodec_ctx *ctx, int format_index) const struct mtk_video_fmt *fmt; struct mtk_q_data *q_data; int num_frame_count = 0, i; - bool ret = true; + bool ret = false; for (i = 0; i < *dec_pdata->num_formats; i++) { if (dec_pdata->vdec_formats[i].type != MTK_FMT_FRAME) @@ -63,7 +63,7 @@ static bool mtk_vdec_get_cap_fmt(struct mtk_vcodec_ctx *ctx, int format_index) case V4L2_PIX_FMT_H264_SLICE: case V4L2_PIX_FMT_VP9_FRAME: if (fmt->fourcc == V4L2_PIX_FMT_MM21) - ret = false; + ret = true; break; default: ret = true;