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;
Date:   Fri, 13 Jan 2023 10:02:40 -0500
From:   =?utf-8?B?TsOtY29sYXMgRi4gUi4gQS4=?= Prado 
        <nfraprado@collabora.com>
To:     Yunfei Dong =?utf-8?B?KOiRo+S6kemjnik=?= 
        <Yunfei.Dong@mediatek.com>
Cc:     "angelogioacchino.delregno@collabora.com" 
        <angelogioacchino.delregno@collabora.com>,
        "nicolas@ndufresne.ca" <nicolas@ndufresne.ca>,
        "robh+dt@kernel.org" <robh+dt@kernel.org>,
        George Sun =?utf-8?B?KOWtmeaelyk=?= <George.Sun@mediatek.com>,
        Tiffany Lin =?utf-8?B?KOael+aFp+ePiik=?= 
        <tiffany.lin@mediatek.com>,
        "stevecho@chromium.org" <stevecho@chromium.org>,
        "frkoenig@chromium.org" <frkoenig@chromium.org>,
        Xiaoyong Lu =?utf-8?B?KOWNouWwj+WLhyk=?= 
        <Xiaoyong.Lu@mediatek.com>,
        "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
        "linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "mchehab@kernel.org" <mchehab@kernel.org>,
        "daniel@ffwll.ch" <daniel@ffwll.ch>,
        "linux-mediatek@lists.infradead.org" 
        <linux-mediatek@lists.infradead.org>,
        "dri-devel@lists.freedesktop.org" <dri-devel@lists.freedesktop.org>,
        Irui Wang =?utf-8?B?KOeOi+eRnik=?= <Irui.Wang@mediatek.com>,
        "tfiga@google.com" <tfiga@google.com>,
        "benjamin.gaignard@collabora.com" <benjamin.gaignard@collabora.com>,
        "hverkuil-cisco@xs4all.nl" <hverkuil-cisco@xs4all.nl>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        "hsinyi@chromium.org" <hsinyi@chromium.org>,
        "matthias.bgg@gmail.com" <matthias.bgg@gmail.com>,
        Project_Global_Chrome_Upstream_Group 
        <Project_Global_Chrome_Upstream_Group@mediatek.com>,
        Andrew-CT Chen =?utf-8?B?KOmZs+aZuui/qik=?= 
        <Andrew-CT.Chen@mediatek.com>,
        "acourbot@chromium.org" <acourbot@chromium.org>
Subject: Re: [PATCH v7, 5/7] media: mediatek: vcodec: Different codec using
 different capture format
Message-ID: <20230113150240.6tqi3kc7cdu3xr65@notapiano>
References: <20220518123004.18286-1-yunfei.dong@mediatek.com>
 <20220518123004.18286-6-yunfei.dong@mediatek.com>
 <20230112205825.wb5qcqhh5kwvyi3y@notapiano>
 <2fe7132f2fcc3fb4724a34c3c4a918b821c845a3.camel@mediatek.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <2fe7132f2fcc3fb4724a34c3c4a918b821c845a3.camel@mediatek.com>
Precedence: bulk

On Fri, Jan 13, 2023 at 03:25:46AM +0000, Yunfei Dong (董云飞) wrote:
> Hi Nicolas,
> 
> Thanks for your information.
> On Thu, 2023-01-12 at 15:58 -0500, Nícolas F. R. A. Prado wrote:
> > On Wed, May 18, 2022 at 08:30:02PM +0800, Yunfei Dong wrote:
> > > Vp8 need to use MM21, but vp9 and h264 need to use HyFbc mode
> > > for mt8195. Vp8/vp9/h264 use the same MM21 format for mt8192.
> > 
> > Hi Yunfei,
> > 
> > why do VP9 and H264 need to use HyFbc (is this the same as MT21C?)
> > mode on
> > MT8195? The SCP firmware on linux-firmware for MT8195 [1] only has
> > MM21
> > available and based on my testing it works just fine. And contrary to
> > what the
> > commit message states this logic is also being applied to MT8192,
> > preventing it
> > to use MM21 when there are more than one format available.
> > 
> The kernel driver not support dynamic switch mt21c and mm21. The driver
> flow as below:
> 1: If there are mt21c and mm21: h264/vp9/av1 will use mt21c(vp8 use
> mm21 always);
> 2: If there are only mt21c or mm21 will use this format only.
> 
> But the scp.img is changed to support mt21c and mm21, the kernel driver
> will use mt21c. Or force the kernel driver only support mm21(small
> effort).
> 
> But the best solution is changed the driver to dynamic switch mt21c and
> mm21, need to discuss the enum and set format flow(middle effort).

Agreed. The aim should be to get this dynamic format switching implemented in
the driver so that the firmware can expose both formats and userspace can
select any of them to use.

However, as you said that solution will take more effort, so in the meantime,
given that currently only mm21 is supported by gstreamer, I think forcing the
kernel driver to always select mm21 makes the most sense right now. That way it
doesn't matter whether the firmware has mm21 or mm21+mt21c, decoding will keep
working with gstreamer using mm21.

Thanks,
Nícolas