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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 4C326C433EF for ; Fri, 17 Jun 2022 06:46:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To: Content-Transfer-Encoding:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=fQNGQ/zJse2gbHWfa6pF660SRacSRW0Fy9uu/huJD4Y=; b=FyuxsPNBimgwoA9f9DQMx2n5cw 0CjYgHWqyLRs7NCEM1OdY/jd4POY5Y4RdasdIcyvRwt4VJMynpZg23DuVPthcF4r4pkWp6J2NS1Un iq1PuNnEhKQIJ0s3T+2ytwT2gkwkeIovOx1aTKyRhUOm7IkzU0R6tLzJ2G0MgAK24mGmIY3xCbBc8 LzN0WjTDOLXJEhrQq4NRRNZIxREPobXYdEQLmmdke8TYJVBnOGGKBXkTuycOna6EmAcOmFvs/9QZn PBJvwe6gppQhTl0zCR2qUZUXxHCvR+XcnrJNoSzniWKrBGTEP3Fxuwn5KSaF0ePSIQYOm695iN5Mt wahgagog==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o25ke-005mXd-D5; Fri, 17 Jun 2022 06:46:40 +0000 Received: from mail-pg1-x52a.google.com ([2607:f8b0:4864:20::52a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o25kR-005mQo-QZ for linux-mediatek@lists.infradead.org; Fri, 17 Jun 2022 06:46:29 +0000 Received: by mail-pg1-x52a.google.com with SMTP id 31so3274116pgv.11 for ; Thu, 16 Jun 2022 23:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=fQNGQ/zJse2gbHWfa6pF660SRacSRW0Fy9uu/huJD4Y=; b=JPLW1+w8/z8WGKViSxKlFYB1DJFO5f4d4rwynmLj7wx/0qK2bG0tNVGdJOrTjCJVPW d0ZiMJQDidl1w4ljJIZMpCkOlhOZkW6+5BzSe4i3dZhcyh+oDngZ/gJaVlL8+QGNmUTL nqKpdtg55DdMsoRsLoHIj2LgXDVZ6dwdIBG8U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=fQNGQ/zJse2gbHWfa6pF660SRacSRW0Fy9uu/huJD4Y=; b=6utkmdB+nQpGFMejAKazGzALuKffBgBXHP+bBWq0IXrP8sK4QtdL9pYwwkc5jSzuxM ccHlNre31n2q0dt6p4GDBMrUuAx6sWRDVDL5ItHYe7gB5G/CujCdK2pTJ4QIpfYuoeSV Di9GrYaEhZGsr60IYv894vdadBjVf4cUwSpaKll6JzZDMf1FPDRmxHaK3jQbG3cJrpdm jd/rvAZIZc/GPbQ7z0aKatIubqDdItXu7x1qpQrQXdOzlW6I7vSXr0ZpVibojdgdgFrG s9efe2wN8NqIduuCl5SgELkVHJhbpaL0PeikBTm5hoJ4f0Yo+A/zUMdV8gFnDYbjDrii qoMg== X-Gm-Message-State: AJIora8Ke+pgFrmdSWeJR4qFOSbKeLW1YOwS1wyW0thc+39TwvBQqdft 0Qo2276X7cQGmyGZi6+tx4JAlQ== X-Google-Smtp-Source: AGRyM1uENT2OwXii6KksNBQ4MXQhZdrl+ulN/85OXID2dCsUxVB+lOZD0za0PfnLmxj1+jHPwjAROA== X-Received: by 2002:a63:80c8:0:b0:405:186f:fa39 with SMTP id j191-20020a6380c8000000b00405186ffa39mr7960592pgd.84.1655448384322; Thu, 16 Jun 2022 23:46:24 -0700 (PDT) Received: from google.com ([2401:fa00:1:10:e12:c024:d152:7ca]) by smtp.gmail.com with ESMTPSA id fs20-20020a17090af29400b001ea75a02805sm4833237pjb.52.2022.06.16.23.46.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jun 2022 23:46:23 -0700 (PDT) Date: Fri, 17 Jun 2022 14:46:18 +0800 From: Chen-Yu Tsai To: Nicolas Dufresne Cc: Yunfei Dong , Alexandre Courbot , Hans Verkuil , Tzung-Bi Shih , AngeloGioacchino Del Regno , Benjamin Gaignard , Tiffany Lin , Andrew-CT Chen , Mauro Carvalho Chehab , Rob Herring , Matthias Brugger , Tomasz Figa , George Sun , Xiaoyong Lu , Hsin-Yi Wang , Fritz Koenig , Dafna Hirschfeld , Daniel Vetter , dri-devel , Irui Wang , Steve Cho , linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, srv_heupstream@mediatek.com, linux-mediatek@lists.infradead.org, Project_Global_Chrome_Upstream_Group@mediatek.com Subject: Re: [PATCH v7, 04/15] media: mtk-vcodec: Read max resolution from dec_capability Message-ID: References: <20220223034008.15781-1-yunfei.dong@mediatek.com> <20220223034008.15781-5-yunfei.dong@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220616_234627_916658_E060E85A X-CRM114-Status: GOOD ( 27.07 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org Hi, On Mon, Feb 28, 2022 at 04:29:15PM -0500, Nicolas Dufresne wrote: > Hi Yunfei, > > this patch does not work unless userland calls enum_framesizes, which is > completely optional. See comment and suggestion below. > > Le mercredi 23 février 2022 à 11:39 +0800, Yunfei Dong a écrit : > > Supported max resolution for different platforms are not the same: 2K > > or 4K, getting it according to dec_capability. > > > > Signed-off-by: Yunfei Dong > > Reviewed-by: Tzung-Bi Shih > > --- > > .../platform/mtk-vcodec/mtk_vcodec_dec.c | 29 +++++++++++-------- > > .../platform/mtk-vcodec/mtk_vcodec_drv.h | 4 +++ > > 2 files changed, 21 insertions(+), 12 deletions(-) > > > > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c > > index 130ecef2e766..304f5afbd419 100644 > > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c > > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c > > @@ -445,7 +447,7 @@ static int vidioc_vdec_s_fmt(struct file *file, void *priv, > > return -EINVAL; > > > > q_data->fmt = fmt; > > - vidioc_try_fmt(f, q_data->fmt); > > + vidioc_try_fmt(ctx, f, q_data->fmt); > > if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) { > > q_data->sizeimage[0] = pix_mp->plane_fmt[0].sizeimage; > > q_data->coded_width = pix_mp->width; > > @@ -545,6 +547,9 @@ static int vidioc_enum_framesizes(struct file *file, void *priv, > > fsize->stepwise.min_height, > > fsize->stepwise.max_height, > > fsize->stepwise.step_height); > > + > > + ctx->max_width = fsize->stepwise.max_width; > > + ctx->max_height = fsize->stepwise.max_height; > > The spec does not require calling enum_fmt, so changing the maximum here is > incorrect (and fail with GStreamer). If userland never enum the framesizes, the > resolution get limited to 1080p. > > As this only depends and the OUTPUT format and the device being open() > (condition being dev_capability being set and OUTPUT format being known / not > VP8), you could initialize the cxt max inside s_fmt(OUTPUT) instead, which is a > mandatory call. I have tested this change to verify this: > > > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c > index 044e3dfbdd8c..3e7c571526a4 100644 > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c > @@ -484,6 +484,14 @@ static int vidioc_vdec_s_fmt(struct file *file, void *priv, > if (fmt == NULL) > return -EINVAL; > > + if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE && > + !(ctx->dev->dec_capability & VCODEC_CAPABILITY_4K_DISABLED) && > + fmt->fourcc != V4L2_PIX_FMT_VP8_FRAME) { > + mtk_v4l2_debug(3, "4K is enabled"); > + ctx->max_width = VCODEC_DEC_4K_CODED_WIDTH; > + ctx->max_height = VCODEC_DEC_4K_CODED_HEIGHT; > + } > + > q_data->fmt = fmt; > vidioc_try_fmt(ctx, f, q_data->fmt); > if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) { > @@ -574,15 +582,9 @@ static int vidioc_enum_framesizes(struct file *file, void *priv, > > fsize->type = V4L2_FRMSIZE_TYPE_STEPWISE; > fsize->stepwise = dec_pdata->vdec_framesizes[i].stepwise; > - if (!(ctx->dev->dec_capability & > - VCODEC_CAPABILITY_4K_DISABLED) && > - fsize->pixel_format != V4L2_PIX_FMT_VP8_FRAME) { > - mtk_v4l2_debug(3, "4K is enabled"); > - fsize->stepwise.max_width = > - VCODEC_DEC_4K_CODED_WIDTH; > - fsize->stepwise.max_height = > - VCODEC_DEC_4K_CODED_HEIGHT; > - } > + fsize->stepwise.max_width = ctx->max_width; > + fsize->stepwise.max_height = ctx->max_height; > + Recent testing on ChromeOS suggests this doesn't work. The spec implies that querying capabilities could happen before the output format is set. And also, supported frame sizes are detected for each given format, which may not be the one current set. So the if block above has to be reintroduced in some form. I'll take a look at this. Regards ChenYu > mtk_v4l2_debug(1, "%x, %d %d %d %d %d %d", > ctx->dev->dec_capability, > fsize->stepwise.min_width, > @@ -592,8 +594,6 @@ static int vidioc_enum_framesizes(struct file *file, void *priv, > fsize->stepwise.max_height, > fsize->stepwise.step_height); > > - ctx->max_width = fsize->stepwise.max_width; > - ctx->max_height = fsize->stepwise.max_height; > return 0; > } > > > > > return 0; > > } > > [...] 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 3B1F1C43334 for ; Fri, 17 Jun 2022 06:47:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=evCb1gimETzOAeRGqHBlJFdmt5lj6wrclzsPFTeSHMQ=; b=affSKQzEL3hURG NobpqnBtXQtPPLmnoGt3B7Jh4GCWArZN+T9qzQVBy7rFIXs7Nhc14caBZYlyU6776dpfHWsKh6NSy 7DugD/IaJKXhpBRhryYK7VqUBcjDXeolAodTE3Zsa0iDWhdHcM/Epl2aMND191vnRg5G3abNPzYpe tugwKUaA7/b2ZTrwpI/Vcf60NAFIq20ESCuczCHk9DZ0dw4qcWIylLQlqB+5yXNmA98gtnom4UU7s ABrtRC3uT6WFCy2bscc5bjZTADoA0vZsQ4wD0+dJoUrNqUkBKRNTW6h1HBMgLtghhSDk4g4MvGFT1 9p1MSMs0YLKnl0CdazlQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1o25kV-005mSi-4c; Fri, 17 Jun 2022 06:46:31 +0000 Received: from mail-pf1-x42b.google.com ([2607:f8b0:4864:20::42b]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1o25kR-005mQn-Pp for linux-arm-kernel@lists.infradead.org; Fri, 17 Jun 2022 06:46:29 +0000 Received: by mail-pf1-x42b.google.com with SMTP id i64so3410585pfc.8 for ; Thu, 16 Jun 2022 23:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=fQNGQ/zJse2gbHWfa6pF660SRacSRW0Fy9uu/huJD4Y=; b=JPLW1+w8/z8WGKViSxKlFYB1DJFO5f4d4rwynmLj7wx/0qK2bG0tNVGdJOrTjCJVPW d0ZiMJQDidl1w4ljJIZMpCkOlhOZkW6+5BzSe4i3dZhcyh+oDngZ/gJaVlL8+QGNmUTL nqKpdtg55DdMsoRsLoHIj2LgXDVZ6dwdIBG8U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=fQNGQ/zJse2gbHWfa6pF660SRacSRW0Fy9uu/huJD4Y=; b=NEZPKrO5qH2lnWx5A8FeGes65lWziYptgDtkfJbQ4wmc3j0rZGc/wFpOIp4DCCI4MU lzr7dgZgqA7IR9j2Us5vEUbd9SZHHtjMQ9C3nkhhYkn7N3AEatHrLZyqoI7E6eDtjICP bgHx5p33msOvy6Izu5F5+eCO2DLTM3grILnFuad/1TwYvtvODvSx4k5hEnyp70H8UHs0 A/BQ2SGVNISQ8InY8vtg0Ppz/5oY874iwZByTUAIkUts8fbZpZ7yLwVOYrz9jwVBJmKZ +UqVgadtGnyqFoRRn+9tof3JPW055FkDILGOvYuU455fd7mSYe8Mjhxb/eV0s5kpU+W+ aYHw== X-Gm-Message-State: AJIora/gMqyrdtcZTmAXJKiQKvfGUx7Vy+0mUXY8dw+CTtr+e2SZXfFs mjIPVveRHh4Frbfododn8YU4UQ== X-Google-Smtp-Source: AGRyM1uENT2OwXii6KksNBQ4MXQhZdrl+ulN/85OXID2dCsUxVB+lOZD0za0PfnLmxj1+jHPwjAROA== X-Received: by 2002:a63:80c8:0:b0:405:186f:fa39 with SMTP id j191-20020a6380c8000000b00405186ffa39mr7960592pgd.84.1655448384322; Thu, 16 Jun 2022 23:46:24 -0700 (PDT) Received: from google.com ([2401:fa00:1:10:e12:c024:d152:7ca]) by smtp.gmail.com with ESMTPSA id fs20-20020a17090af29400b001ea75a02805sm4833237pjb.52.2022.06.16.23.46.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jun 2022 23:46:23 -0700 (PDT) Date: Fri, 17 Jun 2022 14:46:18 +0800 From: Chen-Yu Tsai To: Nicolas Dufresne Cc: Yunfei Dong , Alexandre Courbot , Hans Verkuil , Tzung-Bi Shih , AngeloGioacchino Del Regno , Benjamin Gaignard , Tiffany Lin , Andrew-CT Chen , Mauro Carvalho Chehab , Rob Herring , Matthias Brugger , Tomasz Figa , George Sun , Xiaoyong Lu , Hsin-Yi Wang , Fritz Koenig , Dafna Hirschfeld , Daniel Vetter , dri-devel , Irui Wang , Steve Cho , linux-media@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, srv_heupstream@mediatek.com, linux-mediatek@lists.infradead.org, Project_Global_Chrome_Upstream_Group@mediatek.com Subject: Re: [PATCH v7, 04/15] media: mtk-vcodec: Read max resolution from dec_capability Message-ID: References: <20220223034008.15781-1-yunfei.dong@mediatek.com> <20220223034008.15781-5-yunfei.dong@mediatek.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220616_234627_916798_675FD5B3 X-CRM114-Status: GOOD ( 28.15 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi, On Mon, Feb 28, 2022 at 04:29:15PM -0500, Nicolas Dufresne wrote: > Hi Yunfei, > = > this patch does not work unless userland calls enum_framesizes, which is > completely optional. See comment and suggestion below. > = > Le mercredi 23 f=E9vrier 2022 =E0 11:39 +0800, Yunfei Dong a =E9crit=A0: > > Supported max resolution for different platforms are not the same: 2K > > or 4K, getting it according to dec_capability. > > = > > Signed-off-by: Yunfei Dong > > Reviewed-by: Tzung-Bi Shih > > --- > > .../platform/mtk-vcodec/mtk_vcodec_dec.c | 29 +++++++++++-------- > > .../platform/mtk-vcodec/mtk_vcodec_drv.h | 4 +++ > > 2 files changed, 21 insertions(+), 12 deletions(-) > > = > > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c b/drive= rs/media/platform/mtk-vcodec/mtk_vcodec_dec.c > > index 130ecef2e766..304f5afbd419 100644 > > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c > > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c > > @@ -445,7 +447,7 @@ static int vidioc_vdec_s_fmt(struct file *file, voi= d *priv, > > return -EINVAL; > > = > > q_data->fmt =3D fmt; > > - vidioc_try_fmt(f, q_data->fmt); > > + vidioc_try_fmt(ctx, f, q_data->fmt); > > if (f->type =3D=3D V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) { > > q_data->sizeimage[0] =3D pix_mp->plane_fmt[0].sizeimage; > > q_data->coded_width =3D pix_mp->width; > > @@ -545,6 +547,9 @@ static int vidioc_enum_framesizes(struct file *file= , void *priv, > > fsize->stepwise.min_height, > > fsize->stepwise.max_height, > > fsize->stepwise.step_height); > > + > > + ctx->max_width =3D fsize->stepwise.max_width; > > + ctx->max_height =3D fsize->stepwise.max_height; > = > The spec does not require calling enum_fmt, so changing the maximum here = is > incorrect (and fail with GStreamer). If userland never enum the framesize= s, the > resolution get limited to 1080p. > = > As this only depends and the OUTPUT format and the device being open() > (condition being dev_capability being set and OUTPUT format being known /= not > VP8), you could initialize the cxt max inside s_fmt(OUTPUT) instead, whic= h is a > mandatory call. I have tested this change to verify this: > = > = > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c b/drivers= /media/platform/mtk-vcodec/mtk_vcodec_dec.c > index 044e3dfbdd8c..3e7c571526a4 100644 > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c > @@ -484,6 +484,14 @@ static int vidioc_vdec_s_fmt(struct file *file, void= *priv, > if (fmt =3D=3D NULL) > return -EINVAL; > = > + if (f->type =3D=3D V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE && > + !(ctx->dev->dec_capability & VCODEC_CAPABILITY_4K_DISABLED) && > + fmt->fourcc !=3D V4L2_PIX_FMT_VP8_FRAME) { > + mtk_v4l2_debug(3, "4K is enabled"); > + ctx->max_width =3D VCODEC_DEC_4K_CODED_WIDTH; > + ctx->max_height =3D VCODEC_DEC_4K_CODED_HEIGHT; > + } > + > q_data->fmt =3D fmt; > vidioc_try_fmt(ctx, f, q_data->fmt); > if (f->type =3D=3D V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) { > @@ -574,15 +582,9 @@ static int vidioc_enum_framesizes(struct file *file,= void *priv, > = > fsize->type =3D V4L2_FRMSIZE_TYPE_STEPWISE; > fsize->stepwise =3D dec_pdata->vdec_framesizes[i].stepwise; > - if (!(ctx->dev->dec_capability & > - VCODEC_CAPABILITY_4K_DISABLED) && > - fsize->pixel_format !=3D V4L2_PIX_FMT_VP8_FRAME) { > - mtk_v4l2_debug(3, "4K is enabled"); > - fsize->stepwise.max_width =3D > - VCODEC_DEC_4K_CODED_WIDTH; > - fsize->stepwise.max_height =3D > - VCODEC_DEC_4K_CODED_HEIGHT; > - } > + fsize->stepwise.max_width =3D ctx->max_width; > + fsize->stepwise.max_height =3D ctx->max_height; > + Recent testing on ChromeOS suggests this doesn't work. The spec implies that querying capabilities could happen before the output format is set. And also, supported frame sizes are detected for each given format, which may not be the one current set. So the if block above has to be reintroduced in some form. I'll take a look at this. Regards ChenYu > mtk_v4l2_debug(1, "%x, %d %d %d %d %d %d", > ctx->dev->dec_capability, > fsize->stepwise.min_width, > @@ -592,8 +594,6 @@ static int vidioc_enum_framesizes(struct file *file, = void *priv, > fsize->stepwise.max_height, > fsize->stepwise.step_height); > = > - ctx->max_width =3D fsize->stepwise.max_width; > - ctx->max_height =3D fsize->stepwise.max_height; > return 0; > } > = > = > = > > return 0; > > } > > = [...] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel 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 gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id CC735C43334 for ; Fri, 17 Jun 2022 06:46:26 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 6892C11A671; Fri, 17 Jun 2022 06:46:25 +0000 (UTC) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) by gabe.freedesktop.org (Postfix) with ESMTPS id CE06F11A671 for ; Fri, 17 Jun 2022 06:46:24 +0000 (UTC) Received: by mail-pf1-x42a.google.com with SMTP id 187so3404966pfu.9 for ; Thu, 16 Jun 2022 23:46:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=fQNGQ/zJse2gbHWfa6pF660SRacSRW0Fy9uu/huJD4Y=; b=JPLW1+w8/z8WGKViSxKlFYB1DJFO5f4d4rwynmLj7wx/0qK2bG0tNVGdJOrTjCJVPW d0ZiMJQDidl1w4ljJIZMpCkOlhOZkW6+5BzSe4i3dZhcyh+oDngZ/gJaVlL8+QGNmUTL nqKpdtg55DdMsoRsLoHIj2LgXDVZ6dwdIBG8U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=fQNGQ/zJse2gbHWfa6pF660SRacSRW0Fy9uu/huJD4Y=; b=0rcI2SjtCfMcpLRHrc+MZcmDv63XxDiA7cU/PtFHrXiobhn9y/kmRXpkAoBnNhOQs3 Mgxq05M8xk2a5y8PoNX/+SRs780BFzMVbGxhWwmeeNoagGL63HMEAVqsoLcF4xI0QgI3 0nvdsgbViy1WLkai1OIQ4PpZ658+otfAGD/cBt/Z0xP8m+dV1cBB56dLt2aOHo9kqJhq cEH+aL78MtyVV/Xz2akHI36+Q6D6FWA7sCbafl4Tz6zI0P0ak3w2UmEH8cUnPXRs/kxM o+SCa1GQU/HyhETtvTBk5nc3IzhvpA6WaL6qirt+GT2CxkLeRkNIG/gPhFAdCvtCOPCD tV5g== X-Gm-Message-State: AJIora8zGstmAufbrIlKeykz9uFQyaepvYmQIy6mD6WllzsEIyOi4HxZ AFAS4rz5z4Dioi26p3aWOiYTCFEsG1chQA== X-Google-Smtp-Source: AGRyM1uENT2OwXii6KksNBQ4MXQhZdrl+ulN/85OXID2dCsUxVB+lOZD0za0PfnLmxj1+jHPwjAROA== X-Received: by 2002:a63:80c8:0:b0:405:186f:fa39 with SMTP id j191-20020a6380c8000000b00405186ffa39mr7960592pgd.84.1655448384322; Thu, 16 Jun 2022 23:46:24 -0700 (PDT) Received: from google.com ([2401:fa00:1:10:e12:c024:d152:7ca]) by smtp.gmail.com with ESMTPSA id fs20-20020a17090af29400b001ea75a02805sm4833237pjb.52.2022.06.16.23.46.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Jun 2022 23:46:23 -0700 (PDT) Date: Fri, 17 Jun 2022 14:46:18 +0800 From: Chen-Yu Tsai To: Nicolas Dufresne Subject: Re: [PATCH v7, 04/15] media: mtk-vcodec: Read max resolution from dec_capability Message-ID: References: <20220223034008.15781-1-yunfei.dong@mediatek.com> <20220223034008.15781-5-yunfei.dong@mediatek.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Andrew-CT Chen , Dafna Hirschfeld , Yunfei Dong , dri-devel , Xiaoyong Lu , Steve Cho , Irui Wang , George Sun , Benjamin Gaignard , Project_Global_Chrome_Upstream_Group@mediatek.com, Fritz Koenig , linux-media@vger.kernel.org, devicetree@vger.kernel.org, Tzung-Bi Shih , Tiffany Lin , Tomasz Figa , Rob Herring , linux-mediatek@lists.infradead.org, Hsin-Yi Wang , Matthias Brugger , Mauro Carvalho Chehab , linux-arm-kernel@lists.infradead.org, AngeloGioacchino Del Regno , srv_heupstream@mediatek.com, Alexandre Courbot , linux-kernel@vger.kernel.org, Hans Verkuil Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" Hi, On Mon, Feb 28, 2022 at 04:29:15PM -0500, Nicolas Dufresne wrote: > Hi Yunfei, > > this patch does not work unless userland calls enum_framesizes, which is > completely optional. See comment and suggestion below. > > Le mercredi 23 février 2022 à 11:39 +0800, Yunfei Dong a écrit : > > Supported max resolution for different platforms are not the same: 2K > > or 4K, getting it according to dec_capability. > > > > Signed-off-by: Yunfei Dong > > Reviewed-by: Tzung-Bi Shih > > --- > > .../platform/mtk-vcodec/mtk_vcodec_dec.c | 29 +++++++++++-------- > > .../platform/mtk-vcodec/mtk_vcodec_drv.h | 4 +++ > > 2 files changed, 21 insertions(+), 12 deletions(-) > > > > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c > > index 130ecef2e766..304f5afbd419 100644 > > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c > > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c > > @@ -445,7 +447,7 @@ static int vidioc_vdec_s_fmt(struct file *file, void *priv, > > return -EINVAL; > > > > q_data->fmt = fmt; > > - vidioc_try_fmt(f, q_data->fmt); > > + vidioc_try_fmt(ctx, f, q_data->fmt); > > if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) { > > q_data->sizeimage[0] = pix_mp->plane_fmt[0].sizeimage; > > q_data->coded_width = pix_mp->width; > > @@ -545,6 +547,9 @@ static int vidioc_enum_framesizes(struct file *file, void *priv, > > fsize->stepwise.min_height, > > fsize->stepwise.max_height, > > fsize->stepwise.step_height); > > + > > + ctx->max_width = fsize->stepwise.max_width; > > + ctx->max_height = fsize->stepwise.max_height; > > The spec does not require calling enum_fmt, so changing the maximum here is > incorrect (and fail with GStreamer). If userland never enum the framesizes, the > resolution get limited to 1080p. > > As this only depends and the OUTPUT format and the device being open() > (condition being dev_capability being set and OUTPUT format being known / not > VP8), you could initialize the cxt max inside s_fmt(OUTPUT) instead, which is a > mandatory call. I have tested this change to verify this: > > > diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c > index 044e3dfbdd8c..3e7c571526a4 100644 > --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c > +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_dec.c > @@ -484,6 +484,14 @@ static int vidioc_vdec_s_fmt(struct file *file, void *priv, > if (fmt == NULL) > return -EINVAL; > > + if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE && > + !(ctx->dev->dec_capability & VCODEC_CAPABILITY_4K_DISABLED) && > + fmt->fourcc != V4L2_PIX_FMT_VP8_FRAME) { > + mtk_v4l2_debug(3, "4K is enabled"); > + ctx->max_width = VCODEC_DEC_4K_CODED_WIDTH; > + ctx->max_height = VCODEC_DEC_4K_CODED_HEIGHT; > + } > + > q_data->fmt = fmt; > vidioc_try_fmt(ctx, f, q_data->fmt); > if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE) { > @@ -574,15 +582,9 @@ static int vidioc_enum_framesizes(struct file *file, void *priv, > > fsize->type = V4L2_FRMSIZE_TYPE_STEPWISE; > fsize->stepwise = dec_pdata->vdec_framesizes[i].stepwise; > - if (!(ctx->dev->dec_capability & > - VCODEC_CAPABILITY_4K_DISABLED) && > - fsize->pixel_format != V4L2_PIX_FMT_VP8_FRAME) { > - mtk_v4l2_debug(3, "4K is enabled"); > - fsize->stepwise.max_width = > - VCODEC_DEC_4K_CODED_WIDTH; > - fsize->stepwise.max_height = > - VCODEC_DEC_4K_CODED_HEIGHT; > - } > + fsize->stepwise.max_width = ctx->max_width; > + fsize->stepwise.max_height = ctx->max_height; > + Recent testing on ChromeOS suggests this doesn't work. The spec implies that querying capabilities could happen before the output format is set. And also, supported frame sizes are detected for each given format, which may not be the one current set. So the if block above has to be reintroduced in some form. I'll take a look at this. Regards ChenYu > mtk_v4l2_debug(1, "%x, %d %d %d %d %d %d", > ctx->dev->dec_capability, > fsize->stepwise.min_width, > @@ -592,8 +594,6 @@ static int vidioc_enum_framesizes(struct file *file, void *priv, > fsize->stepwise.max_height, > fsize->stepwise.step_height); > > - ctx->max_width = fsize->stepwise.max_width; > - ctx->max_height = fsize->stepwise.max_height; > return 0; > } > > > > > return 0; > > } > > [...]