Received: by 2002:a05:6a10:a852:0:0:0:0 with SMTP id d18csp831871pxy; Wed, 5 May 2021 15:16:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzR6eb32r7MmwS0Ztp88JBrjkQdAm+Desnw1HCNDQ3u4FlCDk2xrYk7aiAjjr3Xv1l+CD87 X-Received: by 2002:a17:903:244:b029:ec:9666:9fc6 with SMTP id j4-20020a1709030244b02900ec96669fc6mr1250413plh.63.1620252994525; Wed, 05 May 2021 15:16:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620252994; cv=none; d=google.com; s=arc-20160816; b=XyLgN1UOlWNIPAaci+cvwWhOpROHBLKbCQlFG3qEFAYLqC7H7UFtXUWK4/6T+NLJ+g fW3utgdLH2Hf9xESqVlNZSDNwogrglZIoax/Vx402QV/521pToHuoJl+x4kU4SU0CXuA Wq1D65ASotPWisq1yY5EGP+NW4LjE03oHcx/guZEEtRYBDZgi7cV3AgP2IFkhJ7Ak/e3 24nMadUUgsMpsKu4TKjcTkFyXwAgyjYqOhYv81Dp0YulUdrb26CjDiRKa2EOOA+BkuRE 3DWiPESbrf2UfEITZhFPzKv50QX+dLccKH0Tky7pe6PLyikSCLDQE78rx4LHL6NxmFCj fe0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:organization:references:in-reply-to:date:cc:to:from :subject:message-id; bh=C9hfYTCfpdasjYKdX8qTGquKZMKPvGkmtuxoqq4EuTs=; b=pg4iaXrRUCQ43S12sAN6YLDmV7VFy6EAS6DXxL1eNocwTDNMPJ6YWZv5Tq3ukSJzY5 cEweMnll6KuZ+3USDNxm9yMiCxs/WE94x2ez/I196nAHOAdCtsz9wXbmYnRAI3SoDC2y uKJDBGRPha5Xf0qIdzq+ELlZJ5JzUmY3sO9QatcsNr3svmzVDSWLrkmVONsrvXqnxTjU 9tlyJxrx++SGgLM2cUqO5xDgaybktEIS5V/U+duu+Y48wEYQlpfj7Q3ukXWNEXTs5xfP YJCGXkSneeFo9cNmAQ5QoC/x+DXj11aVyX5tyxuvUCfUexxLJD/MwkQ5zGJCheCxFE8x K/LA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q3si768839pgq.284.2021.05.05.15.16.20; Wed, 05 May 2021 15:16:34 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=collabora.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235598AbhEEVCl (ORCPT + 99 others); Wed, 5 May 2021 17:02:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41418 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235097AbhEEVCi (ORCPT ); Wed, 5 May 2021 17:02:38 -0400 Received: from bhuna.collabora.co.uk (bhuna.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e3e3]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 63799C061574; Wed, 5 May 2021 14:01:41 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: ezequiel) with ESMTPSA id D21551F4322A Message-ID: Subject: Re: [PATCH v10 6/9] media: uapi: Add a control for HANTRO driver From: Ezequiel Garcia To: Hans Verkuil , Benjamin Gaignard , p.zabel@pengutronix.de, mchehab@kernel.org, robh+dt@kernel.org, shawnguo@kernel.org, s.hauer@pengutronix.de, festevam@gmail.com, lee.jones@linaro.org, gregkh@linuxfoundation.org, mripard@kernel.org, paul.kocialkowski@bootlin.com, wens@csie.org, jernej.skrabec@siol.net, emil.l.velikov@gmail.com Cc: kernel@pengutronix.de, linux-imx@nxp.com, linux-media@vger.kernel.org, linux-rockchip@lists.infradead.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org, kernel@collabora.com, cphealy@gmail.com Date: Wed, 05 May 2021 18:01:25 -0300 In-Reply-To: References: <20210420121046.181889-1-benjamin.gaignard@collabora.com> <20210420121046.181889-7-benjamin.gaignard@collabora.com> Organization: Collabora Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.38.2-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2021-05-05 at 16:55 +0200, Hans Verkuil wrote: > On 20/04/2021 14:10, Benjamin Gaignard wrote: > > The HEVC HANTRO driver needs to know the number of bits to skip at > > the beginning of the slice header. > > That is a hardware specific requirement so create a dedicated control > > for this purpose. > > > > Signed-off-by: Benjamin Gaignard > > --- > >  .../userspace-api/media/drivers/hantro.rst    | 19 +++++++++++++++++++ > >  .../userspace-api/media/drivers/index.rst     |  1 + > >  include/media/hevc-ctrls.h                    | 13 +++++++++++++ > >  3 files changed, 33 insertions(+) > >  create mode 100644 Documentation/userspace-api/media/drivers/hantro.rst > > > > diff --git a/Documentation/userspace-api/media/drivers/hantro.rst b/Documentation/userspace-api/media/drivers/hantro.rst > > new file mode 100644 > > index 000000000000..cd9754b4e005 > > --- /dev/null > > +++ b/Documentation/userspace-api/media/drivers/hantro.rst > > @@ -0,0 +1,19 @@ > > +.. SPDX-License-Identifier: GPL-2.0 > > + > > +Hantro video decoder driver > > +=========================== > > + > > +The Hantro video decoder driver implements the following driver-specific controls: > > + > > +``V4L2_CID_HANTRO_HEVC_SLICE_HEADER_SKIP (integer)`` > > +    Specifies to Hantro HEVC video decoder driver the number of data (in bits) to > > +    skip in the slice segment header. > > +    If non-IDR, the bits to be skipped go from syntax element "pic_output_flag" > > +    to before syntax element "slice_temporal_mvp_enabled_flag". > > +    If IDR, the skipped bits are just "pic_output_flag" > > +    (separate_colour_plane_flag is not supported). > > I'm not very keen on this. Without this information the video data cannot be > decoded, or will it just be suboptimal? > > The problem is that a generic decoder would have to know that the HW is a hantro, Applications can just query which controls are exposed by a video device, and if this control is found, then it means it needs to be set. > and then call this control. If they don't (and are testing on non-hantro HW), then > it won't work, thus defeating the purpose of the HW independent decoder API. > > Since hantro is widely used, and if there is no other way to do this beside explitely > setting this control, then perhaps this should be part of the standard HEVC API. > Non-hantro drivers that do not need this can just skip it. > The decision to move it out of the HEVC API is not really to avoid setting it. In the end, most/all applications will end up required to set this