From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DDBAE3FB7F2; Fri, 10 Jul 2026 09:56:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=213.167.242.64 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783677398; cv=none; b=dMHMD6O5h57oGWDeZV7Vz6y0bQIZ13/N2NiZL95oa+tnAlpHb34wPalQMBCuiMO/aZgpkHltc/k6h4SagzHAW27TX4RdXEFBDCPCIJMYiIX8JcSep76g6YhfNKWUqfGDzfnpz1emSuEPOlc7ChBPCVuB6ermoq5zJpGO1gu9Dxc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783677398; c=relaxed/simple; bh=cUAYZzxr3znTTToR3UQeu5Ibb8WeFw+KkgCr8E8GNTM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=jOxXEHHeJ6TqSW3agrQpBfQ45fXgtnyX0df5Ccgg0l9LAzSJv1dc6csZUNm21opEQnH/q3Oe2RtzEjpnnBEYkYI1qHEx5Y1Q5zzFGC9/IpQNGv2Ej3SDk96QBUmfxei/f78bsBueKCD2tiClN+PEz7A0MBqErVEnZUkCv22lJwo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com; spf=pass smtp.mailfrom=ideasonboard.com; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b=UiJ3mvEb; arc=none smtp.client-ip=213.167.242.64 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ideasonboard.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="UiJ3mvEb" Received: from ideasonboard.com (mob-109-113-15-151.net.vodafone.it [109.113.15.151]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id E5E9312F; Fri, 10 Jul 2026 11:55:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1783677342; bh=cUAYZzxr3znTTToR3UQeu5Ibb8WeFw+KkgCr8E8GNTM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UiJ3mvEbI5orMKvbU+g4bzqtgUp4mUtjCSPCqwmDCzKKfXpFJbyaJ2bP3c8+cFPkY SggjMI2NX5Te9Dzh2aZSIPpB8ETDtkSnnKIKy6UGCr0lOzjQqnqJLbCXJGDhEf90Rt DH7iKrm1QE91CMep9fzd/UE+PMlfkaZaHcrFvvUQ= Date: Fri, 10 Jul 2026 11:56:29 +0200 From: Jacopo Mondi To: Sven =?utf-8?Q?P=C3=BCschel?= Cc: Jacopo Mondi , Tommaso Merciai , tomm.merciai@gmail.com, linux-renesas-soc@vger.kernel.org, biju.das.jz@bp.renesas.com, Lad Prabhakar , Mauro Carvalho Chehab , Hans Verkuil , Nicolas Dufresne , Sakari Ailus , Laurent Pinchart , Mehdi Djait , Marek Szyprowski , Isaac Scott , Paul Cercueil , Daniel Scally , linux-media@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 3/4] media: v4l2-common: Add kernel-doc for v4l2_fill_pixfmt_mp_aligned() Message-ID: References: <20260708161406.396183-1-tommaso.merciai.xr@bp.renesas.com> <20260708161406.396183-4-tommaso.merciai.xr@bp.renesas.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Hi Sven On Fri, Jul 10, 2026 at 10:57:41AM +0200, Sven Püschel wrote: > Hi Jacopo, > > On 7/9/26 11:51 AM, Jacopo Mondi wrote: > > Hi Tommaso > > > > On Wed, Jul 08, 2026 at 06:14:04PM +0200, Tommaso Merciai wrote: > > > Replace the bare placeholder comment with a full kernel-doc block > > > documenting all parameters, the function behaviour for both single > > > memory plane (mem_planes == 1) and multiple memory plane (mem_planes > 1) > > > formats, and the return value. > > > > > > Signed-off-by: Tommaso Merciai > > > --- > > > v2->v3: > > > - Moved to PATCH 3/4 > > > - Fixed documentation as suggested by Sven Püschel > > > > > > v1->v2: > > > - New patch > > > > > > include/media/v4l2-common.h | 28 +++++++++++++++++++++++++++- > > > 1 file changed, 27 insertions(+), 1 deletion(-) > > > > > > diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h > > > index be4dd9762196..f2b0c336ac81 100644 > > > --- a/include/media/v4l2-common.h > > > +++ b/include/media/v4l2-common.h > > > @@ -591,7 +591,33 @@ static inline int v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, > > > return v4l2_fill_pixfmt_aligned(pixfmt, pixelformat, width, height, 1); > > > } > > > > > > -/* @stride_alignment is a power of 2 value in bytes */ > > > +/** > > > + * v4l2_fill_pixfmt_mp_aligned - Fill in a &struct v4l2_pix_format_mplane with > > > + * stride alignment requirements. > > > + * > > > + * @pixfmt: pointer to the &struct v4l2_pix_format_mplane to be filled > > > + * @pixelformat: the V4L2 pixel format (V4L2_PIX_FMT_*) > > > + * @width: image width in pixels > > > + * @height: image height in pixels > > > + * @stride_alignment: stride alignment in bytes; must be a power of 2 > > > + * > > > + * Fills all fields of @pixfmt for the given pixel format, dimensions, and > > > + * stride alignment. > > > + * > > > + * For formats stored in a single memory plane (mem_planes == 1), the > > > + * behaviour matches v4l2_fill_pixfmt_aligned(): plane_fmt[0].bytesperline > > > + * is set to the primary plane stride. The strides of all components are > > > + * aligned to the @stride_alignment. To keep the chroma strides consistently > > > + * derivable from the luma stride, strides may be aligned to a multiple of > > > + * the @stride_alignment instead. plane_fmt[0].sizeimage covers all > > > > I guess this > > > > "To keep the chroma strides consistently derivable from the luma > > stride, strides may be aligned to a multiple of the @stride_alignment > > instead." > > > > comes from teh v4l2_format_plane_stride() implementation. > > > > I admit is not 100% clear to me why the chroma strides is multiplied > > and to which format this applies. But this is not on this patch... > > When not using multi-planar formats, we only have the stride value for the Y > component and the other stride values are derived from it. This is the cause > of this whole scaling. > > E.g. for YUV420 4x2px picture, we have 4 bytes stride in the y plane and 2 > byte in the cb and cr plane. If we align the stride to 4 bytes (in all > planes), we want both values to be a multiple of 4. As the cb/cr stride is > derived from the y stride, we have to set the y stride to 8 bytes to get the > desired 4 bytes stride in the cb/cr planes. > > The rare case for scaling the component stride is NV24/42 (at least this is > the only one I currently know of), where we actually have 4:4:4 sub-sampling > and have the cb/cr parts interleaved. So for a 1x2px picture we have 1 bytes > in the y plane and 2 bytes in the c plane. To align to 4 bytes we need to > set the c plane stride to 8 to be able to set the y plane stride to 4. I see, I was probably confusing strides and strides -alignments-. Thanks for the explanation. > > > For multi-planar formats we have a separate stride for each component, so we > just align all component strides to the given alignment. > > > Sincerely >     Sven > >