From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 958F5C636D4 for ; Fri, 10 Feb 2023 15:36:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232819AbjBJPgi (ORCPT ); Fri, 10 Feb 2023 10:36:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36614 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232809AbjBJPgg (ORCPT ); Fri, 10 Feb 2023 10:36:36 -0500 Received: from mail-qv1-xf2e.google.com (mail-qv1-xf2e.google.com [IPv6:2607:f8b0:4864:20::f2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0894F77BB2 for ; Fri, 10 Feb 2023 07:36:28 -0800 (PST) Received: by mail-qv1-xf2e.google.com with SMTP id j5so1545164qvi.3 for ; Fri, 10 Feb 2023 07:36:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ndufresne-ca.20210112.gappssmtp.com; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:from:to:cc:subject :date:message-id:reply-to; bh=yns5dIgTI6JxWbAph1O5r62njQOhGCrBzKQvo54B6zU=; b=qt0dTy3gVXkMeMMY1z1PZwzdNHzVX7V43gDb6L3hzCqa+olBH07sWy3wRrodzDIMG4 6hhWqr1Vobg7UcTDxPhcBKvvutcBaIlcdZt315xhTaQQG8r5n/M+uOuTOrVicwmwyKAU 064uvXHrbIh3mtaWOU4aybOMWgkXvkOzKL0b8uQUjc/v2XlzXgc0DQpTPFVMok0FMsQM 08vESDuFXllzb2iR8QrHNONx/wudIUxbhG5sODlHnj3/KUNblwg71nM5dxt/l0oVqdMr /nlLhaPAjSj5IgprhRQcEHPcPMcz3AcuIRCJk9+PrV5mMO/ejuZ4Rbocq4ZekG0vV8P9 JnZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:user-agent:content-transfer-encoding:references :in-reply-to:date:cc:to:from:subject:message-id:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=yns5dIgTI6JxWbAph1O5r62njQOhGCrBzKQvo54B6zU=; b=3soJjxVsC+C36LXWI7Qoa6U+cpi89aNNxyfP4Z6/hwBMdq9dKEIldspXw3hLjQP6X2 Mxx1sUHojgVMkgk4Li6OS0538Pgwsesa9UYPgSO50xnvyjcqvVrFAR7YAPLKhUSQcKCM mHWQ4HP0/NRUwyBvuHsCfvQZqyk5LJipaW/uJOO4P+f/OnppHMFjX9QgWrqiSqzrw/wG gDWCSdtH5rlqEBoNOeSfH64/XRWtfGn7y3Jf+yN+eKumP3J+8rkcJ2eqwCMjQ37me4ci RZxRZfO4VO2t3DDuJyIg9D/oF15cLUwXNdBb1mz52h46Vtvpff6uoQmp/7YopjwQ8QHt yEWw== X-Gm-Message-State: AO0yUKW6qzuLnAehNOtcKwq4jAvqalafaWPep1mQXWLlNa2scKUKW35f HHKvnh1IiVxP/yhlzLivGVC4Ow== X-Google-Smtp-Source: AK7set/9kH5iClIq96ImXMXxCRZP3o6rb/SFdyOqAvYoxsx641uTIbYLyp0hit6CJig0eeQHDNzzWg== X-Received: by 2002:a05:6214:1bc9:b0:537:7484:8d1c with SMTP id m9-20020a0562141bc900b0053774848d1cmr29006106qvc.30.1676043388060; Fri, 10 Feb 2023 07:36:28 -0800 (PST) Received: from nicolas-tpx395.localdomain (192-222-136-102.qc.cable.ebox.net. [192.222.136.102]) by smtp.gmail.com with ESMTPSA id r129-20020a37a887000000b006cec8001bf4sm3758407qke.26.2023.02.10.07.36.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 10 Feb 2023 07:36:27 -0800 (PST) Message-ID: Subject: Re: [PATCH v2] media: mediatek: vcodec: Force capture queue format to MM21 From: Nicolas Dufresne To: Yunfei Dong , Chen-Yu Tsai , Hans Verkuil , AngeloGioacchino Del Regno , Benjamin Gaignard , Tiffany Lin Cc: Mauro Carvalho Chehab , Matthias Brugger , Hsin-Yi Wang , Fritz Koenig , Daniel Vetter , Steve Cho , 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 Date: Fri, 10 Feb 2023 10:36:25 -0500 In-Reply-To: <20230210055518.6017-1-yunfei.dong@mediatek.com> References: <20230210055518.6017-1-yunfei.dong@mediatek.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.3 (3.46.3-1.fc37) MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org Le vendredi 10 f=C3=A9vrier 2023 =C3=A0 13:55 +0800, Yunfei Dong a =C3=A9cr= it=C2=A0: > 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 at current period. Please rework this text, it is hard to understand. >=20 > Fixes: 7501edef6b1f ("media: mediatek: vcodec: Different codec using diff= erent capture format") > Signed-off-by: Yunfei Dong > --- > changed with v1: > - add Fixes tag. > --- > drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) >=20 > diff --git a/drivers/media/platform/mediatek/vcodec/mtk_vcodec_dec.c b/dr= ivers/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 =3D 0, i; > - bool ret =3D true; > + bool ret =3D false; > =20 > for (i =3D 0; i < *dec_pdata->num_formats; i++) { > if (dec_pdata->vdec_formats[i].type !=3D 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 =3D=3D V4L2_PIX_FMT_MM21) > - ret =3D false; > + ret =3D true; This makes the VP8 and the other cases identical, leaving anything that tou= ches MT21 as dead code. I'm not sure, cause I cannot test it, but it should in t= heory render MT8192 unusable, unless a new firmware has been submitted to linux- firmware with MM21 support ? > break; > default: > ret =3D true;