Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp412920rwb; Thu, 12 Jan 2023 07:43:26 -0800 (PST) X-Google-Smtp-Source: AMrXdXvwroAPrs50ktWg/nsCB9WnN3LxtTbihuRqvprDPc1it5dMY6P9AsdO74xZhrG8B9P7utG3 X-Received: by 2002:a05:6402:3786:b0:496:873:bb43 with SMTP id et6-20020a056402378600b004960873bb43mr22072856edb.16.1673538206149; Thu, 12 Jan 2023 07:43:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673538206; cv=none; d=google.com; s=arc-20160816; b=oqUU7J3Qe8q/Hm+IHb3poPzl1nf1GAPSZtrmQfN7948FMzX146wd/4Uj/WZVQajJOF wOMzjBMus4WjByAMWq4i8L1q/Zv6xpL+QzC1PpjObMoxnULgjH0bW7UVlJAC0mYKIQQr oNjG5XOgD1vYQ5fstUqRQ/t398ML2DDmBRnZU62YUvG7V3/McOqsL8IvxBLKgBhIwyWj WSj9NiTU7y6FT2T30lRhTGyRGr2HEjnrMZIUuW8sT8acBc0TjXsvpCj23IPUSNBbxWCZ IFF2FbvqxSCkVkJsNyT63efQ8IXxiUoEHgm9q7t4kJmsjtfi3LldibMY+ftm6zNlH6TT QHYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=iKwwjEGopbISTrCjxgfQJsmoWWl/0HgOwyebrt0JLGA=; b=vGokyzhpK8KiYlBhdcr7MDGpPCMIZ/+g9T8nvTzWPSIK/sHmvvQKfne17qZyuIe+gP vdLWDHJpAk5zEZCJxIlShIIf1AAkOFK9BOLv2Uji55kH8ZV1vA4CAY1PKGhKwJRYf8ZE 1vnSzr9gZnuBDJ6cLEzOO6HqpOA50Y95A7yHpD9tKpON6fdnQKnOW3N/i3Nd3gno7lT0 ugfFMn3ogwnNQgVmiNuIW7WWjYVrd+rSY4g+OBvi1mCWkOsGOQQ460RJFmWH3fgo7psP QgR1UetJgtHA+K/gBvPu/RJEoqi1RQyBJE84w9yHKw0fccHUuPawXOY6uZRdEn0Hboqb ZEEg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@vanguardiasur-com-ar.20210112.gappssmtp.com header.s=20210112 header.b=QbI169xh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f17-20020a50d551000000b004782d6db359si17056117edj.146.2023.01.12.07.43.13; Thu, 12 Jan 2023 07:43:26 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@vanguardiasur-com-ar.20210112.gappssmtp.com header.s=20210112 header.b=QbI169xh; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240561AbjALPk2 (ORCPT + 50 others); Thu, 12 Jan 2023 10:40:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53460 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240552AbjALPjo (ORCPT ); Thu, 12 Jan 2023 10:39:44 -0500 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0E77B532B3 for ; Thu, 12 Jan 2023 07:30:25 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id j17so28974840lfr.3 for ; Thu, 12 Jan 2023 07:30:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vanguardiasur-com-ar.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=iKwwjEGopbISTrCjxgfQJsmoWWl/0HgOwyebrt0JLGA=; b=QbI169xhV8vhsr4V43oKe3t3ypXsYwuhSqv+U3fpDtFAZlimhEns/OKDdeLbZoZmIh vBTAIdpXaeEx1D8wnaC3SOK1pmpgvLkcH52Ack0AR7xityglMY5G15apEjxBliyOTcKf KFFNUZ/wh5OgRKL1qOxea/YdXalez4QJD7y6CWBklcPj8VmiUF9OHe+7zenmpRYbEwyj vVdl99EChOEYB09vc3Xi2oVNySDI1Kr72mtUi2hElBPN5ZCghAltKgpET/OaAgmQjr1y KGcH3IH4RklrAMcPgz1IyWMrFqQh8AnpD12cHrk5PQxIO3ZQD7ZqWRNC9TEbE+lVRNPl asWA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=iKwwjEGopbISTrCjxgfQJsmoWWl/0HgOwyebrt0JLGA=; b=l1Mr9voyg7+X8ad2cNdUs1iEBEraJ1oGXlE5Sko+MOIIMXJW7ce73Nde+GXYjFDgku M8Cm6e7lOOdC7k97TY6OxbfQS4vxjsbPP9yR5Iu4/QIBZ6uwSZFRj0ZvVAlba6GCLVye 4owjVcgg5dXxmfvGtiFiyRuyrzXOFWWGWMAVjwicNQkR7A4Lcl70BeLOzfN6YO163WcN Z/DOv7mzFeb6StiZXZGx/xLxPBRem9NVD4f7ZoaDipfVNV+G5tOloXQXDJ484PIpeaO4 ksLXx/vkaIxVGWBLrJ4pz3vf+9XY7VEE3Cqya9/NjHuf9oejDuv85oTeCJrvIpmuyQTo f4tQ== X-Gm-Message-State: AFqh2koauogp+N5MCRPmOfWhuVf0rqmJ4A52BhujFuPIt8DBNrXV0laq pReDjv/Q/iedUsF5PN/EOhrv3C4x9NQgND9TsVFcxA== X-Received: by 2002:a05:6512:2805:b0:4b5:b18a:c52d with SMTP id cf5-20020a056512280500b004b5b18ac52dmr7967483lfb.299.1673537423283; Thu, 12 Jan 2023 07:30:23 -0800 (PST) MIME-Version: 1.0 References: <20230101-patch-series-v2-6-2-rc1-v2-0-fa1897efac14@collabora.com> <20230101-patch-series-v2-6-2-rc1-v2-6-fa1897efac14@collabora.com> In-Reply-To: <20230101-patch-series-v2-6-2-rc1-v2-6-fa1897efac14@collabora.com> From: Ezequiel Garcia Date: Thu, 12 Jan 2023 12:30:11 -0300 Message-ID: Subject: Re: [PATCH v2 06/12] staging: media: rkvdec: Add a valid pixel format check as callback To: Sebastian Fricke Cc: Mauro Carvalho Chehab , Greg Kroah-Hartman , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, linux-rockchip@lists.infradead.org, linux-staging@lists.linux.dev, Jonas Karlman , Alex Bee , Nicolas Dufresne , Collabora Kernel-domain , Robert Beckett , Laurent Pinchart , Andrzej Pietrasiewicz , Benjamin Gaignard Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Sebastian, On Thu, Jan 12, 2023 at 9:56 AM Sebastian Fricke wrote: > > Provide a callback for codec variant drivers to indicate the correct > output pixel-format. It will either utilize the SPS structure stored via > the S_CTRL IOCTL or return the default pixel-format. > > Signed-off-by: Jonas Karlman > Signed-off-by: Sebastian Fricke > --- > drivers/staging/media/rkvdec/rkvdec.c | 45 +++++++++++++++++++++++++++++------ > drivers/staging/media/rkvdec/rkvdec.h | 1 + > 2 files changed, 39 insertions(+), 7 deletions(-) > > diff --git a/drivers/staging/media/rkvdec/rkvdec.c b/drivers/staging/media/rkvdec/rkvdec.c > index e0e95d06e216..a46f918926a2 100644 > --- a/drivers/staging/media/rkvdec/rkvdec.c > +++ b/drivers/staging/media/rkvdec/rkvdec.c > @@ -38,6 +38,20 @@ static int rkvdec_queue_busy(struct rkvdec_ctx *ctx, enum v4l2_buf_type buf_type > return 0; > } > > +/* > + * Use the current SPS, set by the user via the VIDIOC_S_CTRL IOCTL, > + * to determine the optimal pixel-format. Each codec is responsible > + * for choosing the appropriate pixel-format for a given parameter set. > + */ It seems this assumes there's always only one valid format. Do you think that will hold true always for RKVDEC and for all codecs? How about we approach this differently? Instead of having a callback for codecs to implement, we just maintain a list of valid decoded formats (in the context) and re-create the list when the SPS is changed (in the S_CTRL). Possibly simpler and less invasive, not sure if there are any caveats. Thanks, Ezequiel > +static int rkvdec_get_valid_fmt(struct rkvdec_ctx *ctx) > +{ > + const struct rkvdec_coded_fmt_desc *coded_desc = ctx->coded_fmt_desc; > + > + if (coded_desc->ops->valid_fmt) > + return coded_desc->ops->valid_fmt(ctx); > + return ctx->coded_fmt_desc->decoded_fmts[0]; > +} > + > static int rkvdec_try_ctrl(struct v4l2_ctrl *ctrl) > { > struct rkvdec_ctx *ctx = container_of(ctrl->handler, struct rkvdec_ctx, ctrl_hdl); > @@ -200,8 +214,9 @@ static void rkvdec_reset_coded_fmt(struct rkvdec_ctx *ctx) > static void rkvdec_reset_decoded_fmt(struct rkvdec_ctx *ctx) > { > struct v4l2_format *f = &ctx->decoded_fmt; > + u32 valid_fmt = rkvdec_get_valid_fmt(ctx); > > - rkvdec_reset_fmt(ctx, f, ctx->coded_fmt_desc->decoded_fmts[0]); > + rkvdec_reset_fmt(ctx, f, valid_fmt); > f->type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE; > v4l2_fill_pixfmt_mp(&f->fmt.pix_mp, > ctx->coded_fmt_desc->decoded_fmts[0], > @@ -260,13 +275,17 @@ static int rkvdec_try_capture_fmt(struct file *file, void *priv, > if (WARN_ON(!coded_desc)) > return -EINVAL; > > - for (i = 0; i < coded_desc->num_decoded_fmts; i++) { > - if (coded_desc->decoded_fmts[i] == pix_mp->pixelformat) > - break; > - } > + if (ctx->sps) { > + pix_mp->pixelformat = rkvdec_get_valid_fmt(ctx); > + } else { > + for (i = 0; i < coded_desc->num_decoded_fmts; i++) { > + if (coded_desc->decoded_fmts[i] == pix_mp->pixelformat) > + break; > + } > > - if (i == coded_desc->num_decoded_fmts) > - pix_mp->pixelformat = coded_desc->decoded_fmts[0]; > + if (i == coded_desc->num_decoded_fmts) > + pix_mp->pixelformat = coded_desc->decoded_fmts[0]; > + } > > /* Always apply the frmsize constraint of the coded end. */ > pix_mp->width = max(pix_mp->width, ctx->coded_fmt.fmt.pix_mp.width); > @@ -435,6 +454,18 @@ static int rkvdec_enum_capture_fmt(struct file *file, void *priv, > if (WARN_ON(!ctx->coded_fmt_desc)) > return -EINVAL; > > + /* > + * According to the specification the driver can only return formats > + * that are supported by both the current encoded format and the > + * provided controls > + */ > + if (ctx->sps) { > + if (f->index) > + return -EINVAL; > + f->pixelformat = rkvdec_get_valid_fmt(ctx); > + return 0; > + } > + > if (f->index >= ctx->coded_fmt_desc->num_decoded_fmts) > return -EINVAL; > > diff --git a/drivers/staging/media/rkvdec/rkvdec.h b/drivers/staging/media/rkvdec/rkvdec.h > index 332126e7b812..e353a4403e5b 100644 > --- a/drivers/staging/media/rkvdec/rkvdec.h > +++ b/drivers/staging/media/rkvdec/rkvdec.h > @@ -66,6 +66,7 @@ vb2_to_rkvdec_decoded_buf(struct vb2_buffer *buf) > struct rkvdec_coded_fmt_ops { > int (*adjust_fmt)(struct rkvdec_ctx *ctx, > struct v4l2_format *f); > + u32 (*valid_fmt)(struct rkvdec_ctx *ctx); > int (*start)(struct rkvdec_ctx *ctx); > void (*stop)(struct rkvdec_ctx *ctx); > int (*run)(struct rkvdec_ctx *ctx); > > -- > 2.25.1