From: Laurent Pinchart <laurent.pinchart@ideasonboard.com> To: Hans Verkuil <hverkuil@xs4all.nl> Cc: Boris Brezillon <boris.brezillon@collabora.com>, Mauro Carvalho Chehab <mchehab@kernel.org>, Hans Verkuil <hans.verkuil@cisco.com>, Sakari Ailus <sakari.ailus@iki.fi>, linux-media@vger.kernel.org, Tomasz Figa <tfiga@chromium.org>, Nicolas Dufresne <nicolas@ndufresne.ca>, kernel@collabora.com, Paul Kocialkowski <paul.kocialkowski@bootlin.com>, Ezequiel Garcia <ezequiel@collabora.com>, Jonas Karlman <jonas@kwiboo.se>, linux-rockchip@lists.infradead.org, Heiko Stuebner <heiko@sntech.de>, Kieran Bingham <kieran.bingham@ideasonboard.com> Subject: Re: [PATCH v5 03/15] media: v4l2-common: Support custom imagesize/bytesperline in fill_pixfmt() Date: Fri, 10 May 2019 14:28:47 +0300 [thread overview] Message-ID: <20190510112847.GA4972@pendragon.ideasonboard.com> (raw) In-Reply-To: <0c5a648c-27a8-8195-8ad9-8cefb4369837@xs4all.nl> Hi Hans, (CC'ing Kieran) On Fri, May 10, 2019 at 10:57:26AM +0200, Hans Verkuil wrote: > On 5/3/19 1:47 PM, Boris Brezillon wrote: > > Users can define custom sizeimage and bytesperline as long as they're > > big enough to store the amount of pixels required for a specific > > width/height under a specific format. Avoid overriding those fields in > > this case. > > > > Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> > > --- > > Hello Hans, > > > > The sizeimage/bytesperline check on !MPLANE formats is still not 100% > > sure, as custom bytesperline might induce bigger sizeimage than what > > we calculate. > > > > I tried implementing something smarter taking the per-component plane > > bpp + hdiv param as we discussed the other day but decided to step > > back after realizing the per-component plane macro block might also > > differ at least in theory (not sure that's true in practice) and that > > has an impact on bytesperline too. > > > > Let me know how you want to handle that case. > > > > Regards, > > > > Boris > > > > Changes in v5: > > * New patch > > --- > > drivers/media/v4l2-core/v4l2-common.c | 54 +++++++++++++++++++-------- > > 1 file changed, 39 insertions(+), 15 deletions(-) > > > > diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c > > index 3c6f5c115fc5..37bfc984a8b5 100644 > > --- a/drivers/media/v4l2-core/v4l2-common.c > > +++ b/drivers/media/v4l2-core/v4l2-common.c > > @@ -563,9 +563,10 @@ int v4l2_fill_pixfmt_mp(struct v4l2_pix_format_mplane *pixfmt, > > pixfmt->num_planes = info->mem_planes; > > > > if (info->mem_planes == 1) { > > + u32 bytesperline, sizeimage = 0; > > + > > plane = &pixfmt->plane_fmt[0]; > > - plane->bytesperline = ALIGN(width, v4l2_format_block_width(info, 0)) * info->bpp[0]; > > - plane->sizeimage = 0; > > + bytesperline = ALIGN(width, v4l2_format_block_width(info, 0)) * info->bpp[0]; > > > > for (i = 0; i < info->comp_planes; i++) { > > unsigned int hdiv = (i == 0) ? 1 : info->hdiv; > > @@ -576,10 +577,17 @@ int v4l2_fill_pixfmt_mp(struct v4l2_pix_format_mplane *pixfmt, > > aligned_width = ALIGN(width, v4l2_format_block_width(info, i)); > > aligned_height = ALIGN(height, v4l2_format_block_height(info, i)); > > > > - plane->sizeimage += info->bpp[i] * > > - DIV_ROUND_UP(aligned_width, hdiv) * > > - DIV_ROUND_UP(aligned_height, vdiv); > > + sizeimage += info->bpp[i] * > > + DIV_ROUND_UP(aligned_width, hdiv) * > > + DIV_ROUND_UP(aligned_height, vdiv); > > } > > + > > + /* > > + * The user might have specified custom sizeimage/bytesperline, > > + * only override them if they're not big enough. > > + */ > > + plane->sizeimage = max(sizeimage, plane->sizeimage); > > + plane->bytesperline = max(bytesperline, plane->bytesperline); > > Let's just set bytesperline, ignoring the value the user supplied. There are very > few drivers that allow the user to set bytesperline anyway, so it's not a big deal > to drop support for that for now. We can add it back later. > > Just add a comment that a user-defined bytesperline value isn't currently supported. Kieran recently ran into an issue related to this, when sharing buffers between a CSI-2 receiver and an ISP. The ISP has alignment constraints in both the horizontal and vertical directions on the line stride and total image size. Out software framework currently allocates buffers from the CSI-2 receiver which doesn't have those constraints, and not being able to specify sizeimage is thus a problem. We have worked around this by allocating buffers on the ISP side but that departed from the normal way of operation, and it may not be a good idea to carry that forward. I wonder how we should solve these issues long term. A central memory allocator is probably the way to go. > > } else { > > for (i = 0; i < info->comp_planes; i++) { > > unsigned int hdiv = (i == 0) ? 1 : info->hdiv; > > @@ -591,10 +599,20 @@ int v4l2_fill_pixfmt_mp(struct v4l2_pix_format_mplane *pixfmt, > > aligned_height = ALIGN(height, v4l2_format_block_height(info, i)); > > > > plane = &pixfmt->plane_fmt[i]; > > - plane->bytesperline = > > - info->bpp[i] * DIV_ROUND_UP(aligned_width, hdiv); > > - plane->sizeimage = > > - plane->bytesperline * DIV_ROUND_UP(aligned_height, vdiv); > > + > > + /* > > + * The user might have specified custom > > + * sizeimage/bytesperline, only override them if > > + * they're not big enough. > > + */ > > + plane->bytesperline = max_t(u32, > > + info->bpp[i] * > > + DIV_ROUND_UP(aligned_width, hdiv), > > + plane->bytesperline); > > + plane->sizeimage = max_t(u32, > > + plane->bytesperline * > > + DIV_ROUND_UP(aligned_height, vdiv), > > + plane->sizeimage); > > } > > } > > return 0; > > @@ -605,6 +623,7 @@ int v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, u32 pixelformat, > > u32 width, u32 height) > > { > > const struct v4l2_format_info *info; > > + u32 bytesperline, sizeimage = 0; > > int i; > > > > info = v4l2_format_info(pixelformat); > > @@ -618,8 +637,7 @@ int v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, u32 pixelformat, > > pixfmt->width = width; > > pixfmt->height = height; > > pixfmt->pixelformat = pixelformat; > > - pixfmt->bytesperline = ALIGN(width, v4l2_format_block_width(info, 0)) * info->bpp[0]; > > - pixfmt->sizeimage = 0; > > + bytesperline = ALIGN(width, v4l2_format_block_width(info, 0)) * info->bpp[0]; > > > > for (i = 0; i < info->comp_planes; i++) { > > unsigned int hdiv = (i == 0) ? 1 : info->hdiv; > > @@ -629,11 +647,17 @@ int v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, u32 pixelformat, > > > > aligned_width = ALIGN(width, v4l2_format_block_width(info, i)); > > aligned_height = ALIGN(height, v4l2_format_block_height(info, i)); > > - > > - pixfmt->sizeimage += info->bpp[i] * > > - DIV_ROUND_UP(aligned_width, hdiv) * > > - DIV_ROUND_UP(aligned_height, vdiv); > > + sizeimage += info->bpp[i] * DIV_ROUND_UP(aligned_width, hdiv) * > > + DIV_ROUND_UP(aligned_height, vdiv); > > } > > + > > + /* > > + * The user might have specified its own sizeimage/bytesperline values, > > + * only override them if they're not big enough. > > + */ > > + pixfmt->sizeimage = max(sizeimage, pixfmt->sizeimage); > > + pixfmt->bytesperline = max(bytesperline, pixfmt->bytesperline); > > + > > return 0; > > } > > EXPORT_SYMBOL_GPL(v4l2_fill_pixfmt); -- Regards, Laurent Pinchart
WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> To: Hans Verkuil <hverkuil-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org> Cc: Nicolas Dufresne <nicolas-dDhyB4GVkw9AFePFGvp55w@public.gmane.org>, kernel-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org, Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>, Jonas Karlman <jonas-uIzNG4q0ceqzQB+pC5nmwQ@public.gmane.org>, Kieran Bingham <kieran.bingham-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org>, Tomasz Figa <tfiga-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>, Paul Kocialkowski <paul.kocialkowski-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>, linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org, Boris Brezillon <boris.brezillon-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>, Sakari Ailus <sakari.ailus-X3B1VOXEql0@public.gmane.org>, Hans Verkuil <hans.verkuil-FYB4Gu1CFyUAvxtiuMwx3w@public.gmane.org>, Mauro Carvalho Chehab <mchehab-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Ezequiel Garcia <ezequiel-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org>, linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: Re: [PATCH v5 03/15] media: v4l2-common: Support custom imagesize/bytesperline in fill_pixfmt() Date: Fri, 10 May 2019 14:28:47 +0300 [thread overview] Message-ID: <20190510112847.GA4972@pendragon.ideasonboard.com> (raw) In-Reply-To: <0c5a648c-27a8-8195-8ad9-8cefb4369837-qWit8jRvyhVmR6Xm/wNWPw@public.gmane.org> Hi Hans, (CC'ing Kieran) On Fri, May 10, 2019 at 10:57:26AM +0200, Hans Verkuil wrote: > On 5/3/19 1:47 PM, Boris Brezillon wrote: > > Users can define custom sizeimage and bytesperline as long as they're > > big enough to store the amount of pixels required for a specific > > width/height under a specific format. Avoid overriding those fields in > > this case. > > > > Signed-off-by: Boris Brezillon <boris.brezillon-ZGY8ohtN/8qB+jHODAdFcQ@public.gmane.org> > > --- > > Hello Hans, > > > > The sizeimage/bytesperline check on !MPLANE formats is still not 100% > > sure, as custom bytesperline might induce bigger sizeimage than what > > we calculate. > > > > I tried implementing something smarter taking the per-component plane > > bpp + hdiv param as we discussed the other day but decided to step > > back after realizing the per-component plane macro block might also > > differ at least in theory (not sure that's true in practice) and that > > has an impact on bytesperline too. > > > > Let me know how you want to handle that case. > > > > Regards, > > > > Boris > > > > Changes in v5: > > * New patch > > --- > > drivers/media/v4l2-core/v4l2-common.c | 54 +++++++++++++++++++-------- > > 1 file changed, 39 insertions(+), 15 deletions(-) > > > > diff --git a/drivers/media/v4l2-core/v4l2-common.c b/drivers/media/v4l2-core/v4l2-common.c > > index 3c6f5c115fc5..37bfc984a8b5 100644 > > --- a/drivers/media/v4l2-core/v4l2-common.c > > +++ b/drivers/media/v4l2-core/v4l2-common.c > > @@ -563,9 +563,10 @@ int v4l2_fill_pixfmt_mp(struct v4l2_pix_format_mplane *pixfmt, > > pixfmt->num_planes = info->mem_planes; > > > > if (info->mem_planes == 1) { > > + u32 bytesperline, sizeimage = 0; > > + > > plane = &pixfmt->plane_fmt[0]; > > - plane->bytesperline = ALIGN(width, v4l2_format_block_width(info, 0)) * info->bpp[0]; > > - plane->sizeimage = 0; > > + bytesperline = ALIGN(width, v4l2_format_block_width(info, 0)) * info->bpp[0]; > > > > for (i = 0; i < info->comp_planes; i++) { > > unsigned int hdiv = (i == 0) ? 1 : info->hdiv; > > @@ -576,10 +577,17 @@ int v4l2_fill_pixfmt_mp(struct v4l2_pix_format_mplane *pixfmt, > > aligned_width = ALIGN(width, v4l2_format_block_width(info, i)); > > aligned_height = ALIGN(height, v4l2_format_block_height(info, i)); > > > > - plane->sizeimage += info->bpp[i] * > > - DIV_ROUND_UP(aligned_width, hdiv) * > > - DIV_ROUND_UP(aligned_height, vdiv); > > + sizeimage += info->bpp[i] * > > + DIV_ROUND_UP(aligned_width, hdiv) * > > + DIV_ROUND_UP(aligned_height, vdiv); > > } > > + > > + /* > > + * The user might have specified custom sizeimage/bytesperline, > > + * only override them if they're not big enough. > > + */ > > + plane->sizeimage = max(sizeimage, plane->sizeimage); > > + plane->bytesperline = max(bytesperline, plane->bytesperline); > > Let's just set bytesperline, ignoring the value the user supplied. There are very > few drivers that allow the user to set bytesperline anyway, so it's not a big deal > to drop support for that for now. We can add it back later. > > Just add a comment that a user-defined bytesperline value isn't currently supported. Kieran recently ran into an issue related to this, when sharing buffers between a CSI-2 receiver and an ISP. The ISP has alignment constraints in both the horizontal and vertical directions on the line stride and total image size. Out software framework currently allocates buffers from the CSI-2 receiver which doesn't have those constraints, and not being able to specify sizeimage is thus a problem. We have worked around this by allocating buffers on the ISP side but that departed from the normal way of operation, and it may not be a good idea to carry that forward. I wonder how we should solve these issues long term. A central memory allocator is probably the way to go. > > } else { > > for (i = 0; i < info->comp_planes; i++) { > > unsigned int hdiv = (i == 0) ? 1 : info->hdiv; > > @@ -591,10 +599,20 @@ int v4l2_fill_pixfmt_mp(struct v4l2_pix_format_mplane *pixfmt, > > aligned_height = ALIGN(height, v4l2_format_block_height(info, i)); > > > > plane = &pixfmt->plane_fmt[i]; > > - plane->bytesperline = > > - info->bpp[i] * DIV_ROUND_UP(aligned_width, hdiv); > > - plane->sizeimage = > > - plane->bytesperline * DIV_ROUND_UP(aligned_height, vdiv); > > + > > + /* > > + * The user might have specified custom > > + * sizeimage/bytesperline, only override them if > > + * they're not big enough. > > + */ > > + plane->bytesperline = max_t(u32, > > + info->bpp[i] * > > + DIV_ROUND_UP(aligned_width, hdiv), > > + plane->bytesperline); > > + plane->sizeimage = max_t(u32, > > + plane->bytesperline * > > + DIV_ROUND_UP(aligned_height, vdiv), > > + plane->sizeimage); > > } > > } > > return 0; > > @@ -605,6 +623,7 @@ int v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, u32 pixelformat, > > u32 width, u32 height) > > { > > const struct v4l2_format_info *info; > > + u32 bytesperline, sizeimage = 0; > > int i; > > > > info = v4l2_format_info(pixelformat); > > @@ -618,8 +637,7 @@ int v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, u32 pixelformat, > > pixfmt->width = width; > > pixfmt->height = height; > > pixfmt->pixelformat = pixelformat; > > - pixfmt->bytesperline = ALIGN(width, v4l2_format_block_width(info, 0)) * info->bpp[0]; > > - pixfmt->sizeimage = 0; > > + bytesperline = ALIGN(width, v4l2_format_block_width(info, 0)) * info->bpp[0]; > > > > for (i = 0; i < info->comp_planes; i++) { > > unsigned int hdiv = (i == 0) ? 1 : info->hdiv; > > @@ -629,11 +647,17 @@ int v4l2_fill_pixfmt(struct v4l2_pix_format *pixfmt, u32 pixelformat, > > > > aligned_width = ALIGN(width, v4l2_format_block_width(info, i)); > > aligned_height = ALIGN(height, v4l2_format_block_height(info, i)); > > - > > - pixfmt->sizeimage += info->bpp[i] * > > - DIV_ROUND_UP(aligned_width, hdiv) * > > - DIV_ROUND_UP(aligned_height, vdiv); > > + sizeimage += info->bpp[i] * DIV_ROUND_UP(aligned_width, hdiv) * > > + DIV_ROUND_UP(aligned_height, vdiv); > > } > > + > > + /* > > + * The user might have specified its own sizeimage/bytesperline values, > > + * only override them if they're not big enough. > > + */ > > + pixfmt->sizeimage = max(sizeimage, pixfmt->sizeimage); > > + pixfmt->bytesperline = max(bytesperline, pixfmt->bytesperline); > > + > > return 0; > > } > > EXPORT_SYMBOL_GPL(v4l2_fill_pixfmt); -- Regards, Laurent Pinchart
next prev parent reply other threads:[~2019-05-10 11:29 UTC|newest] Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-05-03 11:47 [PATCH v5 00/15] Add MPEG-2 decoding to Rockchip VPU Boris Brezillon 2019-05-03 11:47 ` Boris Brezillon 2019-05-03 11:47 ` [PATCH v5 01/15] media: v4l2-common: Fix v4l2_fill_pixfmt[_mp]() prototypes Boris Brezillon 2019-05-03 11:47 ` Boris Brezillon 2019-05-03 11:47 ` [PATCH v5 02/15] media: v4l2-common: Add an helper to apply frmsize constraints Boris Brezillon 2019-05-03 11:47 ` Boris Brezillon 2019-05-03 11:47 ` [PATCH v5 03/15] media: v4l2-common: Support custom imagesize/bytesperline in fill_pixfmt() Boris Brezillon 2019-05-03 11:47 ` Boris Brezillon 2019-05-10 8:57 ` Hans Verkuil 2019-05-10 8:57 ` Hans Verkuil 2019-05-10 11:28 ` Laurent Pinchart [this message] 2019-05-10 11:28 ` Laurent Pinchart 2019-05-10 12:17 ` Hans Verkuil 2019-05-10 12:17 ` Hans Verkuil 2019-05-10 12:24 ` Laurent Pinchart 2019-05-10 12:24 ` Laurent Pinchart 2019-05-10 12:30 ` Hans Verkuil 2019-05-10 12:30 ` Hans Verkuil 2019-05-10 13:51 ` Nicolas Dufresne 2019-05-10 13:51 ` Nicolas Dufresne 2019-05-10 14:07 ` Hans Verkuil 2019-05-10 14:07 ` Hans Verkuil 2019-05-10 16:01 ` Nicolas Dufresne 2019-05-10 16:01 ` Nicolas Dufresne 2019-05-03 11:47 ` [PATCH v5 04/15] rockchip/vpu: Use v4l2_apply_frmsize_constraints() where appropriate Boris Brezillon 2019-05-03 11:47 ` Boris Brezillon 2019-05-03 11:47 ` [PATCH v5 05/15] rockchip/vpu: Open-code media controller register Boris Brezillon 2019-05-03 11:47 ` Boris Brezillon 2019-05-03 11:47 ` [PATCH v5 06/15] rockchip/vpu: Support the Request API Boris Brezillon 2019-05-03 11:47 ` Boris Brezillon 2019-05-03 11:47 ` [PATCH v5 07/15] rockchip/vpu: Rename rockchip_vpu_common.h into rockchip_vpu_v4l2.h Boris Brezillon 2019-05-03 11:47 ` Boris Brezillon 2019-05-03 11:47 ` [PATCH v5 08/15] rockchip/vpu: Move encoder logic to a common place Boris Brezillon 2019-05-03 11:47 ` Boris Brezillon 2019-05-03 11:47 ` [PATCH v5 09/15] rockchip/vpu: Provide a helper to reset both src and dst formats Boris Brezillon 2019-05-03 11:47 ` Boris Brezillon 2019-05-03 11:47 ` [PATCH v5 10/15] rockchip/vpu: Prepare things to support decoders Boris Brezillon 2019-05-03 11:47 ` Boris Brezillon 2019-05-03 11:47 ` [PATCH v5 11/15] rockchip/vpu: Add decoder boilerplate Boris Brezillon 2019-05-03 11:47 ` Boris Brezillon 2019-05-03 11:47 ` [PATCH v5 12/15] rockchip/vpu: Add support for non-standard controls Boris Brezillon 2019-05-03 11:47 ` Boris Brezillon 2019-05-03 11:47 ` [PATCH v5 13/15] rockchip/vpu: Add infra to support MPEG-2 decoding Boris Brezillon 2019-05-03 11:47 ` Boris Brezillon 2019-05-03 11:47 ` [PATCH v5 14/15] rockchip/vpu: Add MPEG2 decoding support to RK3399 Boris Brezillon 2019-05-03 11:47 ` Boris Brezillon 2019-05-03 11:47 ` [PATCH v5 15/15] rockchip/vpu: Add support for MPEG-2 decoding on RK3288 Boris Brezillon 2019-05-03 11:47 ` Boris Brezillon
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190510112847.GA4972@pendragon.ideasonboard.com \ --to=laurent.pinchart@ideasonboard.com \ --cc=boris.brezillon@collabora.com \ --cc=ezequiel@collabora.com \ --cc=hans.verkuil@cisco.com \ --cc=heiko@sntech.de \ --cc=hverkuil@xs4all.nl \ --cc=jonas@kwiboo.se \ --cc=kernel@collabora.com \ --cc=kieran.bingham@ideasonboard.com \ --cc=linux-media@vger.kernel.org \ --cc=linux-rockchip@lists.infradead.org \ --cc=mchehab@kernel.org \ --cc=nicolas@ndufresne.ca \ --cc=paul.kocialkowski@bootlin.com \ --cc=sakari.ailus@iki.fi \ --cc=tfiga@chromium.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.