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 8CC2BC43334 for ; Fri, 17 Jun 2022 06:46:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1380328AbiFQGq3 (ORCPT ); Fri, 17 Jun 2022 02:46:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56084 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243756AbiFQGq1 (ORCPT ); Fri, 17 Jun 2022 02:46:27 -0400 Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CB10126AF8 for ; Thu, 16 Jun 2022 23:46:24 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id x4so3403157pfj.10 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=4IEmq2s0H5INbZP3njnbDPmGb0DEl5Kk4G9GrJIgdk4e/C2NC4NQgXHc28C0VxN36V Cjys4utZlk1TrrO8D16xBD3dZMitOCrFKvb/o3cTNirZNApiUntTUIjiIKUzCjKpPHQP Ltibn29I4FP7q/MHRt+0CjSXKo7XFoiZbEaRXeS22gLvQBpBmEs0QroD3glsgNZVWl/8 VK5V50K3QIaWQbQVniRXiEuR0dfYjBMZV9cQ9a+wNKVXgeR9pZoZArYBVxYbJe5Jyfht no6Wvg9u31BzO2wQVfACQcmgtMlpkcMOIwlMew380NjGstF2L6kysAnaTGAv4bGxrT3E RMhA== X-Gm-Message-State: AJIora9f5y/JFAV8kr5vAnWvjvMG1IevH6MGRGLVYElr/zB7BGDMI78w H3gSg+/j9n4t2Iab7L0X54mn6Q== 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: Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.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; > > } > > [...]