mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Yunfei Dong (董云飞)" <Yunfei.Dong@mediatek.com>
To: "nfraprado@collabora.com" <nfraprado@collabora.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"nicolas@ndufresne.ca" <nicolas@ndufresne.ca>,
	"frkoenig@chromium.org" <frkoenig@chromium.org>,
	"Tiffany Lin (林慧珊)" <tiffany.lin@mediatek.com>,
	"wenst@chromium.org" <wenst@chromium.org>,
	"linux-media@vger.kernel.org" <linux-media@vger.kernel.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"stevecho@chromium.org" <stevecho@chromium.org>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"mchehab@kernel.org" <mchehab@kernel.org>,
	"daniel@ffwll.ch" <daniel@ffwll.ch>,
	Project_Global_Chrome_Upstream_Group
	<Project_Global_Chrome_Upstream_Group@mediatek.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>,
	"angelogioacchino.delregno@collabora.com"
	<angelogioacchino.delregno@collabora.com>
Subject: Re: [PATCH v2] media: mediatek: vcodec: Force capture queue format to MM21
Date: Tue, 14 Mar 2023 09:20:00 +0000	[thread overview]
Message-ID: <0f4a279beb8bf442c5eec41957d0bf2db36d31b7.camel@mediatek.com> (raw)
In-Reply-To: <20230228220336.gnainmcyi42l2a6r@notapiano>

Hi Nicolas,

Thanks for your suggestion.
On Tue, 2023-02-28 at 17:03 -0500, Nícolas F. R. A. Prado wrote:
> On Mon, Feb 27, 2023 at 02:17:08AM +0000, Yunfei Dong (董云飞) wrote:
> > Hi Nicolas,
> > 
> > Thanks for your suggestion.
> > On Wed, 2023-02-22 at 16:11 -0500, Nícolas F. R. A. Prado wrote:
> > > Hi,
> > > 
> > > On Tue, Feb 14, 2023 at 02:28:04AM +0000, Yunfei Dong (董云飞)
> > > wrote:
> > > > Hi Nicolas,
> > > > 
> > > > Thanks for your suggestion.
> > > > On Fri, 2023-02-10 at 10:36 -0500, Nicolas Dufresne wrote:
> > > > > Le vendredi 10 février 2023 à 13:55 +0800, Yunfei Dong a
> > > > > écrit :
> 
> [..]
> > > > > > 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;
> > > 
> > > This change doesn't do anything, so I'd drop it.
> > > 
> > 
> > This change is useful when capture fourcc is MT21 will return
> > false,
> > not support even if scp support mm21 and mt21.
> 
> But you have
> 
> 	default:
> 		ret = true;
> 		break;
> 
> down below, so you're handling all cases in the switch, and the
> original value
> doesn't matter. It could even be left uninitialized.
> 
> > > > > >  
> > > > > >  	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;
> > > > > 
> > > > > This makes the VP8 and the other cases identical, leaving
> > > > > anything
> > > > > that touches
> > > > > MT21 as dead code. I'm not sure, cause I cannot test it, but
> > > > > it
> > > > > should in theory
> > > > > render MT8192 unusable, unless a new firmware has been
> > > > > submitted
> > > > > to
> > > > > linux-
> > > > > firmware with MM21 support ?
> > > > > 
> > > > 
> > > > If the firmware only support MT21 => won't exist for vp8 need
> > > > to
> > > > use
> > > > MM21.
> > > 
> > > And that's the issue, the scp.img for MT8192 on linux-firmware
> > > only
> > > supports
> > > MT21 [1]. Can you please update it to support both MM21 and MT21?
> > > 
> > > For MT8195, only MM21 is supported in scp.img [2], but since the
> > > hardware
> > > supports both MM21 and MT21, the firmware should also support
> > > both.
> > > So please
> > > also update it on linux-firmware.
> > > 
> > > [1] 
> > > 
https://lore.kernel.org/all/20230112204626.ciaff4amseoidybw@notapiano/
> > > [2] 
> > > 
https://lore.kernel.org/all/20230112205825.wb5qcqhh5kwvyi3y@notapiano/
> > > 
> > > Thanks,
> > > Nícolas
> > > 
> > 
> > MT8192 always use MM21 from the beginning, MT21 have not been
> > enabled.
> 
> That's not true, and you can verify through the following:
> 
> 	$ curl 
> https://urldefense.com/v3/__https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/plain/mediatek/mt8192/scp.img__;!!CTRNKA9wMg0ARbw!i1Sq64yV1SsKzkxtFsZh4pfu8YwGA7ThO2zWtGyDRC4QDlzpmKxYJRvw3toH3oVDlHDxOpT73DZVWfe9OWeyj6if$
> $   > /lib/firmware/mediatek/mt8192/scp.img
> 
I have send the patch v3 to be reviewed. And Tinghan will help to
upstream mt8192 and mt8195's firmware scp.img which support MM21 and
MT21 at the same time.

Best Regards,
Yunfei Dong
> 	$ sha256sum /lib/firmware/mediatek/mt8192/scp.img
> 	fb9b4727f5e7cd82b2c63a8a2604d02e8c0f390eae2e9fd87aa1ae0797fb01b
> 3  /lib/firmware/mediatek/mt8192/scp.img
> 
> 	$ v4l2-ctl -d1 --list-formats -D
> 	Driver Info:
> 		Driver name      : mtk-vcodec-dec
> 		Card type        : MT8192 video decoder
> 		Bus info         : platform:16000000.video-codec
> 		Driver version   : 6.2.0
> 		Capabilities     : 0x84204000
> 			Video Memory-to-Memory Multiplanar
> 			Streaming
> 			Extended Pix Format
> 			Device Capabilities
> 		Device Caps      : 0x04204000
> 			Video Memory-to-Memory Multiplanar
> 			Streaming
> 			Extended Pix Format
> 	Media Driver Info:
> 		Driver name      : mtk-vcodec-dec
> 		Model            : mtk-vcodec-dec
> 		Serial           :
> 		Bus info         : platform:16000000.video-codec
> 		Media version    : 6.2.0
> 		Hardware revision: 0x00000000 (0)
> 		Driver version   : 6.2.0
> 	Interface Info:
> 		ID               : 0x0300000c
> 		Type             : V4L Video
> 	Entity Info:
> 		ID               : 0x00000001 (1)
> 		Name             : mtk-vcodec-dec-source
> 		Function         : V4L2 I/O
> 		Pad 0x01000002   : 0: Source
> 		 Link 0x02000008: to remote pad 0x1000004 of entity
> 'mtk-vcodec-dec-proc' (Video Decoder): Data, Enabled, Immutable
> 	ioctl: VIDIOC_ENUM_FMT
> 		Type: Video Capture Multiplanar
> 
> 		[0]: 'MT21' (Mediatek Compressed Format, compressed)
> 
> 
> So the decoder video node is clearly only exposing MT21 in the
> capture pad.
> 
> Furthermore, with
> 
> 	$ echo module mtk_vcodec_dec +pmf >
> /sys/kernel/debug/dynamic_debug/control
> 
> and re-running the v4l2-ctl command, you'll see
> 
> 	[ 3164.998781] mtk_vcodec_dec:fops_vcodec_open:
> fops_vcodec_open(),212: decoder capability 740
> 
> and if you check
> drivers/media/platform/mediatek/vcodec/mtk_vcodec_drv.h:
> 
> 	enum mtk_vdec_format_types {
> 		MTK_VDEC_FORMAT_MM21 = 0x20,
> 		MTK_VDEC_FORMAT_MT21C = 0x40,
> 		MTK_VDEC_FORMAT_H264_SLICE = 0x100,
> 		MTK_VDEC_FORMAT_VP8_FRAME = 0x200,
> 		MTK_VDEC_FORMAT_VP9_FRAME = 0x400,
> 		MTK_VCODEC_INNER_RACING = 0x20000,
> 	};
> 
> meaning the scp.img firmware is exposing the MT21C but not the MM21
> format.
> 
> So, again, the mt8192 scp.img firmware needs to be fixed.
> 
> Thanks,
> Nícolas

  reply	other threads:[~2023-03-14  9:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-10  5:55 Yunfei Dong
2023-02-10 15:36 ` Nicolas Dufresne
2023-02-14  2:28   ` Yunfei Dong (董云飞)
2023-02-22 21:11     ` Nícolas F. R. A. Prado
2023-02-27  2:17       ` Yunfei Dong (董云飞)
2023-02-28 22:03         ` Nícolas F. R. A. Prado
2023-03-14  9:20           ` Yunfei Dong (董云飞) [this message]
2023-02-14  2:29   ` Yunfei Dong (董云飞)
2023-03-14  2:04   ` Yunfei Dong (董云飞)

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=0f4a279beb8bf442c5eec41957d0bf2db36d31b7.camel@mediatek.com \
    --to=yunfei.dong@mediatek.com \
    --cc=Project_Global_Chrome_Upstream_Group@mediatek.com \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=benjamin.gaignard@collabora.com \
    --cc=daniel@ffwll.ch \
    --cc=devicetree@vger.kernel.org \
    --cc=frkoenig@chromium.org \
    --cc=hsinyi@chromium.org \
    --cc=hverkuil-cisco@xs4all.nl \
    --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=matthias.bgg@gmail.com \
    --cc=mchehab@kernel.org \
    --cc=nfraprado@collabora.com \
    --cc=nicolas@ndufresne.ca \
    --cc=stevecho@chromium.org \
    --cc=tiffany.lin@mediatek.com \
    --cc=wenst@chromium.org \
    /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

all inboxes | Powered by JetHome®