From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 646C21572 for ; Tue, 15 Feb 2022 14:18:01 +0000 (UTC) Received: by mail-wm1-f47.google.com with SMTP id m126-20020a1ca384000000b0037bb8e379feso1557163wme.5 for ; Tue, 15 Feb 2022 06:18:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kynesim-co-uk.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:references:in-reply-to :user-agent:mime-version:content-transfer-encoding; bh=CG3P56xlFsoBU79QJPpFdYrXPhtp38683i1XknICllQ=; b=B4qU0nqAzx/qiAZj1y+v9vFn/1D1VF+7O5sDkagPNYxDPi0kKEDrxFZs59OTl0Q0wY +gZeTMkypecV6C9sbnkn/iWF4WBmLGQVjJ86A/QxUaiuPJdegV/WiPXQeKegfhW4YYQf ZiP33FZa+o14B2hlB+rkDBhQDgsgAzXFfQJwEmUOQUX5ocXMvBD1rBKTg+usfVBT3eXk W3snXxRd0TjHDF3iuZxPAoRxuBfBYv0DL+/HYH0oqE7X7/To4U7FjrQLRggIcqjxV6U0 BX477H1cBINxU2jers608Krj60f/PiKnpjkqR2utsR4s5n/fTMF9ZTHgMUXl3OzsmG1u T4oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:references :in-reply-to:user-agent:mime-version:content-transfer-encoding; bh=CG3P56xlFsoBU79QJPpFdYrXPhtp38683i1XknICllQ=; b=ikw6N6U2pGiQQDVev7zi1/MoUtw8KcXVxX+W8QPX7gyiQg4Qd7NrPsig5yzkbqSEey vQoTwB78U5rfaQAIxH9jB4ctrbmKVU0by4vVC6s22MbOrrndkPuFsYnsUByHVRTYNCho QryhXJeS3oxKAuLl+QEILkRmNXiy+BKeyplsGOqsLlQrTpuSLCYksCwh91b6gTtdmw5q SxDP125Go3hshqfRyOye+y5ZAYvqywsS1DUroo2DKfkvEwip6dg0x3kB2+kOiUSLKTVu EkDD5rVhrZoNDZnhDK1SL4++BQMheo+1OerLoYIRJ8FMXkLTpjh/cgdY+Fa+o7C4v+bs gmOg== X-Gm-Message-State: AOAM5314iYSU6c0AXwZNIHmh4ZkcphpaiUDTydHhTgSAV7rcif+wbS91 h3jwRG1RxK0sFl7bhIawsdBC4g== X-Google-Smtp-Source: ABdhPJwXgJ7HnZxlPFUESAzSmrFq3Y5J8UCvZ0uCcLzfXnoYTam1CrM5dvh2jkgKvzQJEZNfaKqtxg== X-Received: by 2002:a05:600c:4e0a:b0:37b:c548:622a with SMTP id b10-20020a05600c4e0a00b0037bc548622amr3398548wmq.55.1644934679483; Tue, 15 Feb 2022 06:17:59 -0800 (PST) Received: from CTHALPA.outer.uphall.net (cpc1-cmbg20-2-0-cust759.5-4.cable.virginm.net. [86.21.218.248]) by smtp.gmail.com with ESMTPSA id o20sm14929542wmq.21.2022.02.15.06.17.57 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Tue, 15 Feb 2022 06:17:58 -0800 (PST) From: John Cox To: Benjamin Gaignard Cc: mchehab@kernel.org, ezequiel@vanguardiasur.com.ar, p.zabel@pengutronix.de, gregkh@linuxfoundation.org, mripard@kernel.org, paul.kocialkowski@bootlin.com, wens@csie.org, jernej.skrabec@gmail.com, hverkuil-cisco@xs4all.nl, jonas@kwiboo.se, nicolas@ndufresne.ca, linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, linux-staging@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, kernel@collabora.com, knaerzche@gmail.com, Benjamin Gaignard Subject: Re: [RFC v2 6/8] media: uapi: Remove bit_size field from v4l2_ctrl_hevc_slice_params Date: Tue, 15 Feb 2022 14:17:57 +0000 Message-ID: References: <20220215110103.241297-1-benjamin.gaignard@collabora.com> <20220215110103.241297-7-benjamin.gaignard@collabora.com> In-Reply-To: <20220215110103.241297-7-benjamin.gaignard@collabora.com> User-Agent: ForteAgent/8.00.32.1272 Precedence: bulk X-Mailing-List: linux-sunxi@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi >The bit size of the slice could be deduced from the buffer payload >so remove bit_size field to avoid duplicated the information. I think this is a bad idea. In the future we are (I hope) going to want to have an array (variable) of slice headers all referring to the same bit buffer. When we do that we will need this field. >Signed-off-by: Benjamin Gaignard >--- > .../userspace-api/media/v4l/ext-ctrls-codec.rst | 3 --- > drivers/staging/media/sunxi/cedrus/cedrus_h265.c | 11 ++++------- > include/uapi/linux/v4l2-controls.h | 3 +-- > 3 files changed, 5 insertions(+), 12 deletions(-) > >diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst = b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst >index 3296ac3b9fca..c3ae97657fa7 100644 >--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst >+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst >@@ -2965,9 +2965,6 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - > :stub-columns: 0 > :widths: 1 1 2 >=20 >- * - __u32 >- - ``bit_size`` >- - Size (in bits) of the current slice data. > * - __u32 > - ``data_bit_offset`` > - Offset (in bits) to the video data in the current slice data. >diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c = b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c >index 8ab2d9c6f048..db8c7475eeb8 100644 >--- a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c >+++ b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c >@@ -312,8 +312,8 @@ static void cedrus_h265_setup(struct cedrus_ctx = *ctx, > const struct v4l2_hevc_pred_weight_table *pred_weight_table; > unsigned int width_in_ctb_luma, ctb_size_luma; > unsigned int log2_max_luma_coding_block_size; >+ size_t slice_bytes; > dma_addr_t src_buf_addr; >- dma_addr_t src_buf_end_addr; > u32 chroma_log2_weight_denom; > u32 output_pic_list_index; > u32 pic_order_cnt[2]; >@@ -370,8 +370,8 @@ static void cedrus_h265_setup(struct cedrus_ctx = *ctx, >=20 > cedrus_write(dev, VE_DEC_H265_BITS_OFFSET, 0); >=20 >- reg =3D slice_params->bit_size; >- cedrus_write(dev, VE_DEC_H265_BITS_LEN, reg); >+ slice_bytes =3D vb2_get_plane_payload(&run->src->vb2_buf, 0); >+ cedrus_write(dev, VE_DEC_H265_BITS_LEN, slice_bytes); I think one of these must be wrong. bit_size is in bits, vb2_get_plane_payload is in bytes? Regards John Cox =20 > /* Source beginning and end addresses. */ >=20 >@@ -384,10 +384,7 @@ static void cedrus_h265_setup(struct cedrus_ctx = *ctx, >=20 > cedrus_write(dev, VE_DEC_H265_BITS_ADDR, reg); >=20 >- src_buf_end_addr =3D src_buf_addr + >- DIV_ROUND_UP(slice_params->bit_size, 8); >- >- reg =3D VE_DEC_H265_BITS_END_ADDR_BASE(src_buf_end_addr); >+ reg =3D VE_DEC_H265_BITS_END_ADDR_BASE(src_buf_addr + slice_bytes); > cedrus_write(dev, VE_DEC_H265_BITS_END_ADDR, reg); >=20 > /* Coding tree block address */ >diff --git a/include/uapi/linux/v4l2-controls.h = b/include/uapi/linux/v4l2-controls.h >index b1a3dc05f02f..27f5d272dc43 100644 >--- a/include/uapi/linux/v4l2-controls.h >+++ b/include/uapi/linux/v4l2-controls.h >@@ -2457,7 +2457,6 @@ struct v4l2_hevc_pred_weight_table { > #define V4L2_HEVC_SLICE_PARAMS_FLAG_DEPENDENT_SLICE_SEGMENT (1ULL << 9) >=20 > struct v4l2_ctrl_hevc_slice_params { >- __u32 bit_size; > __u32 data_bit_offset; >=20 > /* ISO/IEC 23008-2, ITU-T Rec. H.265: NAL unit header */ >@@ -2484,7 +2483,7 @@ struct v4l2_ctrl_hevc_slice_params { > /* ISO/IEC 23008-2, ITU-T Rec. H.265: Picture timing SEI message */ > __u8 pic_struct; >=20 >- __u8 reserved; >+ __u8 reserved[5]; >=20 > /* ISO/IEC 23008-2, ITU-T Rec. H.265: General slice segment header */ > __u32 slice_segment_addr; 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 3B5B8C433EF for ; Tue, 15 Feb 2022 14:19:21 +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:MIME-Version:In-Reply-To:References: Message-ID:Date:Subject:Cc:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=bNWN45+JKmDyDleeDlbYBo30+s+KQT1Ltvh/coFqrZ0=; b=h+/dqCrSIUvxY+ 8dsxClHossM64ZczkJYXZn9EeoLfSVzfzQG5zfOyn+0ecBSGe+MLvb2giW2r8rh3Qj311bCuoojy4 KxLWGiL/bW9ygTpjvHqtEAQpfWo8Bz+XgzXRCbyea0hLgWc/ssv4WZkCzs8G2H9ZRu9WNHlGkfaeb Y2GD8TK2X1xj4zkdQUjaCRHmF++eIdiZlJ2XtyKB9dQIUAoKlIy+cNnOl/QhDKULaVu7HCYK0P1ip dFVujSyoG9Ox1D9eMPdfdgFu0Naybw1nN2DRkPfy/hoXmAHBoesmN8tECCsEbXyWGeFZlY79LVJon ddG6ptwEq2Ab0yTBE4GA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nJyec-002zIK-Cf; Tue, 15 Feb 2022 14:18:06 +0000 Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nJyeY-002zH2-0D for linux-arm-kernel@lists.infradead.org; Tue, 15 Feb 2022 14:18:04 +0000 Received: by mail-wm1-x336.google.com with SMTP id k127-20020a1ca185000000b0037bc4be8713so1563287wme.3 for ; Tue, 15 Feb 2022 06:18:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kynesim-co-uk.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:references:in-reply-to :user-agent:mime-version:content-transfer-encoding; bh=CG3P56xlFsoBU79QJPpFdYrXPhtp38683i1XknICllQ=; b=B4qU0nqAzx/qiAZj1y+v9vFn/1D1VF+7O5sDkagPNYxDPi0kKEDrxFZs59OTl0Q0wY +gZeTMkypecV6C9sbnkn/iWF4WBmLGQVjJ86A/QxUaiuPJdegV/WiPXQeKegfhW4YYQf ZiP33FZa+o14B2hlB+rkDBhQDgsgAzXFfQJwEmUOQUX5ocXMvBD1rBKTg+usfVBT3eXk W3snXxRd0TjHDF3iuZxPAoRxuBfBYv0DL+/HYH0oqE7X7/To4U7FjrQLRggIcqjxV6U0 BX477H1cBINxU2jers608Krj60f/PiKnpjkqR2utsR4s5n/fTMF9ZTHgMUXl3OzsmG1u T4oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:references :in-reply-to:user-agent:mime-version:content-transfer-encoding; bh=CG3P56xlFsoBU79QJPpFdYrXPhtp38683i1XknICllQ=; b=F9hwrVMbIym6w/C03zFSFI09K8qUyikIBjXXAEmJDeV/O1ohprx/P1GmgcYG1g9J05 +IsDMmHbQwc39fjNHSpY5s10J6rGIE14CGZizL4W5IrT0hr1ZaCebwOhvhtP7AG7wOcD 5Pk818go+ts/pkwEzqBz9M0M6eEa+TNF3XNHw6h+72MduBa7KYZfovhuqjpIlOwgd/I+ tWchQl5/IMmn8dObAtnExoRnrd6OCgwmzCPsendVN2np1qtxLNduhbu1dfMUsyPY3FDx 25dl0QQMTIA10/0lqQREJ1X6N7U/6KDSuD8MnUihq9UobE2ypvpXUBQdwlQlEcfXGSpp Rvrw== X-Gm-Message-State: AOAM532lBbSQ8SBbbFvaatxFi0+05RXzmhiRnPhmiCf36HYNAJDIUySw 5MXqYW0gurTRO/epdzGHXOA/XA== X-Google-Smtp-Source: ABdhPJwXgJ7HnZxlPFUESAzSmrFq3Y5J8UCvZ0uCcLzfXnoYTam1CrM5dvh2jkgKvzQJEZNfaKqtxg== X-Received: by 2002:a05:600c:4e0a:b0:37b:c548:622a with SMTP id b10-20020a05600c4e0a00b0037bc548622amr3398548wmq.55.1644934679483; Tue, 15 Feb 2022 06:17:59 -0800 (PST) Received: from CTHALPA.outer.uphall.net (cpc1-cmbg20-2-0-cust759.5-4.cable.virginm.net. [86.21.218.248]) by smtp.gmail.com with ESMTPSA id o20sm14929542wmq.21.2022.02.15.06.17.57 (version=TLS1 cipher=ECDHE-ECDSA-AES128-SHA bits=128/128); Tue, 15 Feb 2022 06:17:58 -0800 (PST) From: John Cox To: Benjamin Gaignard Cc: mchehab@kernel.org, ezequiel@vanguardiasur.com.ar, p.zabel@pengutronix.de, gregkh@linuxfoundation.org, mripard@kernel.org, paul.kocialkowski@bootlin.com, wens@csie.org, jernej.skrabec@gmail.com, hverkuil-cisco@xs4all.nl, jonas@kwiboo.se, nicolas@ndufresne.ca, linux-media@vger.kernel.org, linux-kernel@vger.kernel.org, linux-staging@lists.linux.dev, linux-arm-kernel@lists.infradead.org, linux-sunxi@lists.linux.dev, kernel@collabora.com, knaerzche@gmail.com, Benjamin Gaignard Subject: Re: [RFC v2 6/8] media: uapi: Remove bit_size field from v4l2_ctrl_hevc_slice_params Date: Tue, 15 Feb 2022 14:17:57 +0000 Message-ID: References: <20220215110103.241297-1-benjamin.gaignard@collabora.com> <20220215110103.241297-7-benjamin.gaignard@collabora.com> In-Reply-To: <20220215110103.241297-7-benjamin.gaignard@collabora.com> User-Agent: ForteAgent/8.00.32.1272 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220215_061802_116535_1681BEE2 X-CRM114-Status: GOOD ( 14.50 ) 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="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi >The bit size of the slice could be deduced from the buffer payload >so remove bit_size field to avoid duplicated the information. I think this is a bad idea. In the future we are (I hope) going to want to have an array (variable) of slice headers all referring to the same bit buffer. When we do that we will need this field. >Signed-off-by: Benjamin Gaignard >--- > .../userspace-api/media/v4l/ext-ctrls-codec.rst | 3 --- > drivers/staging/media/sunxi/cedrus/cedrus_h265.c | 11 ++++------- > include/uapi/linux/v4l2-controls.h | 3 +-- > 3 files changed, 5 insertions(+), 12 deletions(-) > >diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst >index 3296ac3b9fca..c3ae97657fa7 100644 >--- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst >+++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst >@@ -2965,9 +2965,6 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - > :stub-columns: 0 > :widths: 1 1 2 > >- * - __u32 >- - ``bit_size`` >- - Size (in bits) of the current slice data. > * - __u32 > - ``data_bit_offset`` > - Offset (in bits) to the video data in the current slice data. >diff --git a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c >index 8ab2d9c6f048..db8c7475eeb8 100644 >--- a/drivers/staging/media/sunxi/cedrus/cedrus_h265.c >+++ b/drivers/staging/media/sunxi/cedrus/cedrus_h265.c >@@ -312,8 +312,8 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx, > const struct v4l2_hevc_pred_weight_table *pred_weight_table; > unsigned int width_in_ctb_luma, ctb_size_luma; > unsigned int log2_max_luma_coding_block_size; >+ size_t slice_bytes; > dma_addr_t src_buf_addr; >- dma_addr_t src_buf_end_addr; > u32 chroma_log2_weight_denom; > u32 output_pic_list_index; > u32 pic_order_cnt[2]; >@@ -370,8 +370,8 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx, > > cedrus_write(dev, VE_DEC_H265_BITS_OFFSET, 0); > >- reg = slice_params->bit_size; >- cedrus_write(dev, VE_DEC_H265_BITS_LEN, reg); >+ slice_bytes = vb2_get_plane_payload(&run->src->vb2_buf, 0); >+ cedrus_write(dev, VE_DEC_H265_BITS_LEN, slice_bytes); I think one of these must be wrong. bit_size is in bits, vb2_get_plane_payload is in bytes? Regards John Cox > /* Source beginning and end addresses. */ > >@@ -384,10 +384,7 @@ static void cedrus_h265_setup(struct cedrus_ctx *ctx, > > cedrus_write(dev, VE_DEC_H265_BITS_ADDR, reg); > >- src_buf_end_addr = src_buf_addr + >- DIV_ROUND_UP(slice_params->bit_size, 8); >- >- reg = VE_DEC_H265_BITS_END_ADDR_BASE(src_buf_end_addr); >+ reg = VE_DEC_H265_BITS_END_ADDR_BASE(src_buf_addr + slice_bytes); > cedrus_write(dev, VE_DEC_H265_BITS_END_ADDR, reg); > > /* Coding tree block address */ >diff --git a/include/uapi/linux/v4l2-controls.h b/include/uapi/linux/v4l2-controls.h >index b1a3dc05f02f..27f5d272dc43 100644 >--- a/include/uapi/linux/v4l2-controls.h >+++ b/include/uapi/linux/v4l2-controls.h >@@ -2457,7 +2457,6 @@ struct v4l2_hevc_pred_weight_table { > #define V4L2_HEVC_SLICE_PARAMS_FLAG_DEPENDENT_SLICE_SEGMENT (1ULL << 9) > > struct v4l2_ctrl_hevc_slice_params { >- __u32 bit_size; > __u32 data_bit_offset; > > /* ISO/IEC 23008-2, ITU-T Rec. H.265: NAL unit header */ >@@ -2484,7 +2483,7 @@ struct v4l2_ctrl_hevc_slice_params { > /* ISO/IEC 23008-2, ITU-T Rec. H.265: Picture timing SEI message */ > __u8 pic_struct; > >- __u8 reserved; >+ __u8 reserved[5]; > > /* ISO/IEC 23008-2, ITU-T Rec. H.265: General slice segment header */ > __u32 slice_segment_addr; _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel