* [PATCH] media: v4l: vsp1: Fix offset calculation for plane cropping
@ 2022-02-28 12:00 Laurent Pinchart
2022-02-28 12:35 ` Kieran Bingham
2022-03-02 11:00 ` Michael Rodin
0 siblings, 2 replies; 7+ messages in thread
From: Laurent Pinchart @ 2022-02-28 12:00 UTC (permalink / raw)
To: linux-media; +Cc: linux-renesas-soc, Michael Rodin, LUU HOAI, Kieran Bingham
From: Michael Rodin <mrodin@de.adit-jv.com>
The vertical subsampling factor is currently not considered in the
offset calculation for plane cropping done in rpf_configure_partition.
This causes a distortion (shift of the color plane) when formats with
the vsub factor larger than 1 are used (e.g. NV12, see
vsp1_video_formats in vsp1_pipe.c). This commit considers vsub factor
for all planes except plane 0 (luminance).
Fixes: e5ad37b64de9 ("[media] v4l: vsp1: Add cropping support")
Signed-off-by: Michael Rodin <mrodin@de.adit-jv.com>
Signed-off-by: LUU HOAI <hoai.luu.ub@renesas.com>
Drop generalization of the offset calculation to reduce the binary size.
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
drivers/media/platform/vsp1/vsp1_rpf.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c b/drivers/media/platform/vsp1/vsp1_rpf.c
index 85587c1b6a37..75083cb234fe 100644
--- a/drivers/media/platform/vsp1/vsp1_rpf.c
+++ b/drivers/media/platform/vsp1/vsp1_rpf.c
@@ -291,11 +291,11 @@ static void rpf_configure_partition(struct vsp1_entity *entity,
+ crop.left * fmtinfo->bpp[0] / 8;
if (format->num_planes > 1) {
+ unsigned int bpl = format->plane_fmt[1].bytesperline;
unsigned int offset;
- offset = crop.top * format->plane_fmt[1].bytesperline
- + crop.left / fmtinfo->hsub
- * fmtinfo->bpp[1] / 8;
+ offset = crop.top / fmtinfo->vsub * bpl
+ + crop.left / fmtinfo->hsub * fmtinfo->bpp[1] / 8;
mem.addr[1] += offset;
mem.addr[2] += offset;
}
--
Regards,
Laurent Pinchart
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [PATCH] media: v4l: vsp1: Fix offset calculation for plane cropping
2022-02-28 12:00 [PATCH] media: v4l: vsp1: Fix offset calculation for plane cropping Laurent Pinchart
@ 2022-02-28 12:35 ` Kieran Bingham
2022-03-02 11:00 ` Michael Rodin
1 sibling, 0 replies; 7+ messages in thread
From: Kieran Bingham @ 2022-02-28 12:35 UTC (permalink / raw)
To: Laurent Pinchart, linux-media; +Cc: linux-renesas-soc, Michael Rodin, LUU HOAI
Quoting Laurent Pinchart (2022-02-28 12:00:58)
> From: Michael Rodin <mrodin@de.adit-jv.com>
>
> The vertical subsampling factor is currently not considered in the
> offset calculation for plane cropping done in rpf_configure_partition.
> This causes a distortion (shift of the color plane) when formats with
> the vsub factor larger than 1 are used (e.g. NV12, see
> vsp1_video_formats in vsp1_pipe.c). This commit considers vsub factor
> for all planes except plane 0 (luminance).
>
> Fixes: e5ad37b64de9 ("[media] v4l: vsp1: Add cropping support")
> Signed-off-by: Michael Rodin <mrodin@de.adit-jv.com>
> Signed-off-by: LUU HOAI <hoai.luu.ub@renesas.com>
>
> Drop generalization of the offset calculation to reduce the binary size.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Looks fine to me, and I now see that the extra tests identify the
failure experienced and resolve it so...
Reviewed-by: Kieran Bingham <kieran.bingham+renesas@ideasonboard.com>
> ---
> drivers/media/platform/vsp1/vsp1_rpf.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c b/drivers/media/platform/vsp1/vsp1_rpf.c
> index 85587c1b6a37..75083cb234fe 100644
> --- a/drivers/media/platform/vsp1/vsp1_rpf.c
> +++ b/drivers/media/platform/vsp1/vsp1_rpf.c
> @@ -291,11 +291,11 @@ static void rpf_configure_partition(struct vsp1_entity *entity,
> + crop.left * fmtinfo->bpp[0] / 8;
>
> if (format->num_planes > 1) {
> + unsigned int bpl = format->plane_fmt[1].bytesperline;
> unsigned int offset;
>
> - offset = crop.top * format->plane_fmt[1].bytesperline
> - + crop.left / fmtinfo->hsub
> - * fmtinfo->bpp[1] / 8;
> + offset = crop.top / fmtinfo->vsub * bpl
> + + crop.left / fmtinfo->hsub * fmtinfo->bpp[1] / 8;
> mem.addr[1] += offset;
> mem.addr[2] += offset;
> }
> --
> Regards,
>
> Laurent Pinchart
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] media: v4l: vsp1: Fix offset calculation for plane cropping
2022-02-28 12:00 [PATCH] media: v4l: vsp1: Fix offset calculation for plane cropping Laurent Pinchart
2022-02-28 12:35 ` Kieran Bingham
@ 2022-03-02 11:00 ` Michael Rodin
2022-04-14 14:20 ` Laurent Pinchart
1 sibling, 1 reply; 7+ messages in thread
From: Michael Rodin @ 2022-03-02 11:00 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-media, linux-renesas-soc, Michael Rodin, LUU HOAI, Kieran Bingham
Hi Laurent,
thank you for your work!
On Mon, Feb 28, 2022 at 02:00:58PM +0200, Laurent Pinchart wrote:
> From: Michael Rodin <mrodin@de.adit-jv.com>
>
> The vertical subsampling factor is currently not considered in the
> offset calculation for plane cropping done in rpf_configure_partition.
> This causes a distortion (shift of the color plane) when formats with
> the vsub factor larger than 1 are used (e.g. NV12, see
> vsp1_video_formats in vsp1_pipe.c). This commit considers vsub factor
> for all planes except plane 0 (luminance).
>
> Fixes: e5ad37b64de9 ("[media] v4l: vsp1: Add cropping support")
> Signed-off-by: Michael Rodin <mrodin@de.adit-jv.com>
> Signed-off-by: LUU HOAI <https://urldefense.proofpoint.com/v2/url?u=http-3A__hoai.luu.ub-40renesas.com&d=DwIDAQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=sWsgk3pKkv5GeIDM2RZlPY8TjNFU2D0oBeOj6QNBadE&m=nh16dwdZnPwCY5XIxQPE0ZD_5QL0r5Z--1UUoxkfyrU&s=OjqLr2oazZuor0qk9BfVD8w1mz9vKoHq6g0SNCFmFrY&e=>
>
> Drop generalization of the offset calculation to reduce the binary size.
Dropping generalization which I have done in my initial patch [1] is ok as
long as this will not cause any troubles. I am not aware of any case where
bytesperline and bpp could be different between the chroma planes, so
probably it's fine.
>
> Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> drivers/media/platform/vsp1/vsp1_rpf.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c b/drivers/media/platform/vsp1/vsp1_rpf.c
> index 85587c1b6a37..75083cb234fe 100644
> --- a/drivers/media/platform/vsp1/vsp1_rpf.c
> +++ b/drivers/media/platform/vsp1/vsp1_rpf.c
> @@ -291,11 +291,11 @@ static void rpf_configure_partition(struct vsp1_entity *entity,
> + crop.left * fmtinfo->bpp[0] / 8;
>
> if (format->num_planes > 1) {
> + unsigned int bpl = format->plane_fmt[1].bytesperline;
> unsigned int offset;
>
> - offset = crop.top * format->plane_fmt[1].bytesperline
> - + crop.left / fmtinfo->hsub
> - * fmtinfo->bpp[1] / 8;
> + offset = crop.top / fmtinfo->vsub * bpl
> + + crop.left / fmtinfo->hsub * fmtinfo->bpp[1] / 8;
Probably it makes sense to do the division after all multiplications are
done in order to avoid rounding errors? Consider the case when left = 3,
hsub = 2, bpp = 32. Then we would get for the second part of the offset:
3 / 2 * 32 / 8 = 1 * 32 / 8 = 4
and if we do division as the last operation:
(3 * 32) / (8 * 2) = 96 / 16 = 6
The first part of the offset can probably also cause the same rounding
issue.
> mem.addr[1] += offset;
> mem.addr[2] += offset;
> }
> --
> Regards,
>
> Laurent Pinchart
>
[1] https://lore.kernel.org/all/1637679566-76975-1-git-send-email-mrodin@de.adit-jv.com/T/
--
Best Regards,
Michael
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] media: v4l: vsp1: Fix offset calculation for plane cropping
2022-03-02 11:00 ` Michael Rodin
@ 2022-04-14 14:20 ` Laurent Pinchart
2022-04-19 10:22 ` Michael Rodin
0 siblings, 1 reply; 7+ messages in thread
From: Laurent Pinchart @ 2022-04-14 14:20 UTC (permalink / raw)
To: Michael Rodin; +Cc: linux-media, linux-renesas-soc, LUU HOAI, Kieran Bingham
Hi Michael,
Your previous mail slipped through the cracks, sorry about that.
On Wed, Mar 02, 2022 at 12:00:12PM +0100, Michael Rodin wrote:
> Hi Laurent,
>
> thank you for your work!
>
> On Mon, Feb 28, 2022 at 02:00:58PM +0200, Laurent Pinchart wrote:
> > From: Michael Rodin <mrodin@de.adit-jv.com>
> >
> > The vertical subsampling factor is currently not considered in the
> > offset calculation for plane cropping done in rpf_configure_partition.
> > This causes a distortion (shift of the color plane) when formats with
> > the vsub factor larger than 1 are used (e.g. NV12, see
> > vsp1_video_formats in vsp1_pipe.c). This commit considers vsub factor
> > for all planes except plane 0 (luminance).
> >
> > Fixes: e5ad37b64de9 ("[media] v4l: vsp1: Add cropping support")
> > Signed-off-by: Michael Rodin <mrodin@de.adit-jv.com>
> > Signed-off-by: LUU HOAI <hoai.luu.ub@renesas.com>
> >
> > Drop generalization of the offset calculation to reduce the binary size.
>
> Dropping generalization which I have done in my initial patch [1] is ok as
> long as this will not cause any troubles. I am not aware of any case where
> bytesperline and bpp could be different between the chroma planes, so
> probably it's fine.
>
> > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > ---
> > drivers/media/platform/vsp1/vsp1_rpf.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c b/drivers/media/platform/vsp1/vsp1_rpf.c
> > index 85587c1b6a37..75083cb234fe 100644
> > --- a/drivers/media/platform/vsp1/vsp1_rpf.c
> > +++ b/drivers/media/platform/vsp1/vsp1_rpf.c
> > @@ -291,11 +291,11 @@ static void rpf_configure_partition(struct vsp1_entity *entity,
> > + crop.left * fmtinfo->bpp[0] / 8;
> >
> > if (format->num_planes > 1) {
> > + unsigned int bpl = format->plane_fmt[1].bytesperline;
> > unsigned int offset;
> >
> > - offset = crop.top * format->plane_fmt[1].bytesperline
> > - + crop.left / fmtinfo->hsub
> > - * fmtinfo->bpp[1] / 8;
> > + offset = crop.top / fmtinfo->vsub * bpl
> > + + crop.left / fmtinfo->hsub * fmtinfo->bpp[1] / 8;
>
> Probably it makes sense to do the division after all multiplications are
> done in order to avoid rounding errors? Consider the case when left = 3,
> hsub = 2, bpp = 32. Then we would get for the second part of the offset:
> 3 / 2 * 32 / 8 = 1 * 32 / 8 = 4
> and if we do division as the last operation:
> (3 * 32) / (8 * 2) = 96 / 16 = 6
This was actually done on purpose :-) If the horizontal subsampling
factor is equal to 2, for instance for the NV12 chroma plane, the
horizontal offset must effectively be a multiple of 2. Otherwise you'll
swap the Cr and Cb components.
Taking your above example with a NV12 format (left=3, hsub=2, but
bpp=16), with the rounding in this patch,
offset = crop.top / fmtinfo->vsub * bpl
+ crop.left / fmtinfo->hsub * fmtinfo->bpp[1] / 8;
= [vertical offset]
+ 3 / 2 * 16 / 8;
= [vertical offset]
+ 2;
Byte: 0 1 2 3 4 5
Cr Cb Cr Cb Cr Cb ...
^
offset
With your rounding proposal,
offset = crop.top / fmtinfo->vsub * bpl
+ (crop.left * fmtinfo->bpp[1]) / (fmtinfo->hsub * 8);
= [vertical offset]
+ (3 * 16) / (2 * 8);
= [vertical offset]
+ 3;
Byte: 0 1 2 3 4 5
Cr Cb Cr Cb Cr Cb ...
^
offset
> The first part of the offset can probably also cause the same rounding
> issue.
>
> > mem.addr[1] += offset;
> > mem.addr[2] += offset;
> > }
> >
>
> [1] https://lore.kernel.org/all/1637679566-76975-1-git-send-email-mrodin@de.adit-jv.com/T/
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] media: v4l: vsp1: Fix offset calculation for plane cropping
2022-04-14 14:20 ` Laurent Pinchart
@ 2022-04-19 10:22 ` Michael Rodin
2022-05-06 9:58 ` Michael Rodin
0 siblings, 1 reply; 7+ messages in thread
From: Michael Rodin @ 2022-04-19 10:22 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Michael Rodin, linux-media, linux-renesas-soc, LUU HOAI, Kieran Bingham
Hi Laurent,
On Thu, Apr 14, 2022 at 05:20:14PM +0300, Laurent Pinchart wrote:
> Hi Michael,
>
> Your previous mail slipped through the cracks, sorry about that.
>
> On Wed, Mar 02, 2022 at 12:00:12PM +0100, Michael Rodin wrote:
> > Hi Laurent,
> >
> > thank you for your work!
> >
> > On Mon, Feb 28, 2022 at 02:00:58PM +0200, Laurent Pinchart wrote:
> > > From: Michael Rodin <mrodin@de.adit-jv.com>
> > >
> > > The vertical subsampling factor is currently not considered in the
> > > offset calculation for plane cropping done in rpf_configure_partition.
> > > This causes a distortion (shift of the color plane) when formats with
> > > the vsub factor larger than 1 are used (e.g. NV12, see
> > > vsp1_video_formats in vsp1_pipe.c). This commit considers vsub factor
> > > for all planes except plane 0 (luminance).
> > >
> > > Fixes: e5ad37b64de9 ("[media] v4l: vsp1: Add cropping support")
> > > Signed-off-by: Michael Rodin <mrodin@de.adit-jv.com>
> > > Signed-off-by: LUU HOAI <https://urldefense.proofpoint.com/v2/url?u=http-3A__hoai.luu.ub-40renesas.com&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=sWsgk3pKkv5GeIDM2RZlPY8TjNFU2D0oBeOj6QNBadE&m=XAmHpGpli5fGaRsYAxJsReuojH4FFIzGmp2Njkwt8ko&s=l9CsK_BwOB0w3jdi3p2OFRTiGdlxWl2EHtxac3eVSTU&e=>
> > >
> > > Drop generalization of the offset calculation to reduce the binary size.
> >
> > Dropping generalization which I have done in my initial patch [1] is ok as
> > long as this will not cause any troubles. I am not aware of any case where
> > bytesperline and bpp could be different between the chroma planes, so
> > probably it's fine.
> >
> > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > > ---
> > > drivers/media/platform/vsp1/vsp1_rpf.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c b/drivers/media/platform/vsp1/vsp1_rpf.c
> > > index 85587c1b6a37..75083cb234fe 100644
> > > --- a/drivers/media/platform/vsp1/vsp1_rpf.c
> > > +++ b/drivers/media/platform/vsp1/vsp1_rpf.c
> > > @@ -291,11 +291,11 @@ static void rpf_configure_partition(struct vsp1_entity *entity,
> > > + crop.left * fmtinfo->bpp[0] / 8;
> > >
> > > if (format->num_planes > 1) {
> > > + unsigned int bpl = format->plane_fmt[1].bytesperline;
> > > unsigned int offset;
> > >
> > > - offset = crop.top * format->plane_fmt[1].bytesperline
> > > - + crop.left / fmtinfo->hsub
> > > - * fmtinfo->bpp[1] / 8;
> > > + offset = crop.top / fmtinfo->vsub * bpl
> > > + + crop.left / fmtinfo->hsub * fmtinfo->bpp[1] / 8;
> >
> > Probably it makes sense to do the division after all multiplications are
> > done in order to avoid rounding errors? Consider the case when left = 3,
> > hsub = 2, bpp = 32. Then we would get for the second part of the offset:
> > 3 / 2 * 32 / 8 = 1 * 32 / 8 = 4
> > and if we do division as the last operation:
> > (3 * 32) / (8 * 2) = 96 / 16 = 6
>
> This was actually done on purpose :-) If the horizontal subsampling
> factor is equal to 2, for instance for the NV12 chroma plane, the
> horizontal offset must effectively be a multiple of 2. Otherwise you'll
> swap the Cr and Cb components.
>
> Taking your above example with a NV12 format (left=3, hsub=2, but
> bpp=16), with the rounding in this patch,
>
> offset = crop.top / fmtinfo->vsub * bpl
> + crop.left / fmtinfo->hsub * fmtinfo->bpp[1] / 8;
> = [vertical offset]
> + 3 / 2 * 16 / 8;
> = [vertical offset]
> + 2;
>
> Byte: 0 1 2 3 4 5
> Cr Cb Cr Cb Cr Cb ...
> ^
> offset
>
> With your rounding proposal,
>
> offset = crop.top / fmtinfo->vsub * bpl
> + (crop.left * fmtinfo->bpp[1]) / (fmtinfo->hsub * 8);
> = [vertical offset]
> + (3 * 16) / (2 * 8);
> = [vertical offset]
> + 3;
>
> Byte: 0 1 2 3 4 5
> Cr Cb Cr Cb Cr Cb ...
> ^
> offset
Thank you very much for the clarification, I have missed this point!
Now the patch looks fine to me.
Reviewed-by: Michael Rodin <mrodin@de.adit-jv.com>
> > The first part of the offset can probably also cause the same rounding
> > issue.
> >
> > > mem.addr[1] += offset;
> > > mem.addr[2] += offset;
> > > }
> > >
> >
> > [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_all_1637679566-2D76975-2D1-2Dgit-2Dsend-2Demail-2Dmrodin-40de.adit-2Djv.com_T_&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=sWsgk3pKkv5GeIDM2RZlPY8TjNFU2D0oBeOj6QNBadE&m=XAmHpGpli5fGaRsYAxJsReuojH4FFIzGmp2Njkwt8ko&s=zwktftJ_aVV0iA0D8dcfCy1_rRg5PSdi5OXfTZBs648&e=
>
> --
> Regards,
>
> Laurent Pinchart
--
Best Regards,
Michael
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] media: v4l: vsp1: Fix offset calculation for plane cropping
2022-04-19 10:22 ` Michael Rodin
@ 2022-05-06 9:58 ` Michael Rodin
2022-05-07 21:16 ` Laurent Pinchart
0 siblings, 1 reply; 7+ messages in thread
From: Michael Rodin @ 2022-05-06 9:58 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Michael Rodin, linux-media, linux-renesas-soc, LUU HOAI, Kieran Bingham
Hi Laurent,
do you see any open points for this patch? If not, do you know maybe when
it will be available on linux-media or maybe mainline branch?
Thank you!
On Tue, Apr 19, 2022 at 12:22:15PM +0200, Michael Rodin wrote:
> Hi Laurent,
>
> On Thu, Apr 14, 2022 at 05:20:14PM +0300, Laurent Pinchart wrote:
> > Hi Michael,
> >
> > Your previous mail slipped through the cracks, sorry about that.
> >
> > On Wed, Mar 02, 2022 at 12:00:12PM +0100, Michael Rodin wrote:
> > > Hi Laurent,
> > >
> > > thank you for your work!
> > >
> > > On Mon, Feb 28, 2022 at 02:00:58PM +0200, Laurent Pinchart wrote:
> > > > From: Michael Rodin <mrodin@de.adit-jv.com>
> > > >
> > > > The vertical subsampling factor is currently not considered in the
> > > > offset calculation for plane cropping done in rpf_configure_partition.
> > > > This causes a distortion (shift of the color plane) when formats with
> > > > the vsub factor larger than 1 are used (e.g. NV12, see
> > > > vsp1_video_formats in vsp1_pipe.c). This commit considers vsub factor
> > > > for all planes except plane 0 (luminance).
> > > >
> > > > Fixes: e5ad37b64de9 ("[media] v4l: vsp1: Add cropping support")
> > > > Signed-off-by: Michael Rodin <mrodin@de.adit-jv.com>
> > > > Signed-off-by: LUU HOAI <https://urldefense.proofpoint.com/v2/url?u=http-3A__hoai.luu.ub-40renesas.com&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=sWsgk3pKkv5GeIDM2RZlPY8TjNFU2D0oBeOj6QNBadE&m=XAmHpGpli5fGaRsYAxJsReuojH4FFIzGmp2Njkwt8ko&s=l9CsK_BwOB0w3jdi3p2OFRTiGdlxWl2EHtxac3eVSTU&e=>
> > > >
> > > > Drop generalization of the offset calculation to reduce the binary size.
> > >
> > > Dropping generalization which I have done in my initial patch [1] is ok as
> > > long as this will not cause any troubles. I am not aware of any case where
> > > bytesperline and bpp could be different between the chroma planes, so
> > > probably it's fine.
> > >
> > > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > > > ---
> > > > drivers/media/platform/vsp1/vsp1_rpf.c | 6 +++---
> > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c b/drivers/media/platform/vsp1/vsp1_rpf.c
> > > > index 85587c1b6a37..75083cb234fe 100644
> > > > --- a/drivers/media/platform/vsp1/vsp1_rpf.c
> > > > +++ b/drivers/media/platform/vsp1/vsp1_rpf.c
> > > > @@ -291,11 +291,11 @@ static void rpf_configure_partition(struct vsp1_entity *entity,
> > > > + crop.left * fmtinfo->bpp[0] / 8;
> > > >
> > > > if (format->num_planes > 1) {
> > > > + unsigned int bpl = format->plane_fmt[1].bytesperline;
> > > > unsigned int offset;
> > > >
> > > > - offset = crop.top * format->plane_fmt[1].bytesperline
> > > > - + crop.left / fmtinfo->hsub
> > > > - * fmtinfo->bpp[1] / 8;
> > > > + offset = crop.top / fmtinfo->vsub * bpl
> > > > + + crop.left / fmtinfo->hsub * fmtinfo->bpp[1] / 8;
> > >
> > > Probably it makes sense to do the division after all multiplications are
> > > done in order to avoid rounding errors? Consider the case when left = 3,
> > > hsub = 2, bpp = 32. Then we would get for the second part of the offset:
> > > 3 / 2 * 32 / 8 = 1 * 32 / 8 = 4
> > > and if we do division as the last operation:
> > > (3 * 32) / (8 * 2) = 96 / 16 = 6
> >
> > This was actually done on purpose :-) If the horizontal subsampling
> > factor is equal to 2, for instance for the NV12 chroma plane, the
> > horizontal offset must effectively be a multiple of 2. Otherwise you'll
> > swap the Cr and Cb components.
> >
> > Taking your above example with a NV12 format (left=3, hsub=2, but
> > bpp=16), with the rounding in this patch,
> >
> > offset = crop.top / fmtinfo->vsub * bpl
> > + crop.left / fmtinfo->hsub * fmtinfo->bpp[1] / 8;
> > = [vertical offset]
> > + 3 / 2 * 16 / 8;
> > = [vertical offset]
> > + 2;
> >
> > Byte: 0 1 2 3 4 5
> > Cr Cb Cr Cb Cr Cb ...
> > ^
> > offset
> >
> > With your rounding proposal,
> >
> > offset = crop.top / fmtinfo->vsub * bpl
> > + (crop.left * fmtinfo->bpp[1]) / (fmtinfo->hsub * 8);
> > = [vertical offset]
> > + (3 * 16) / (2 * 8);
> > = [vertical offset]
> > + 3;
> >
> > Byte: 0 1 2 3 4 5
> > Cr Cb Cr Cb Cr Cb ...
> > ^
> > offset
>
> Thank you very much for the clarification, I have missed this point!
> Now the patch looks fine to me.
>
> Reviewed-by: Michael Rodin <mrodin@de.adit-jv.com>
>
> > > The first part of the offset can probably also cause the same rounding
> > > issue.
> > >
> > > > mem.addr[1] += offset;
> > > > mem.addr[2] += offset;
> > > > }
> > > >
> > >
> > > [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__lore.kernel.org_all_1637679566-2D76975-2D1-2Dgit-2Dsend-2Demail-2Dmrodin-40de.adit-2Djv.com_T_&d=DwICaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=sWsgk3pKkv5GeIDM2RZlPY8TjNFU2D0oBeOj6QNBadE&m=XAmHpGpli5fGaRsYAxJsReuojH4FFIzGmp2Njkwt8ko&s=zwktftJ_aVV0iA0D8dcfCy1_rRg5PSdi5OXfTZBs648&e=
> >
> > --
> > Regards,
> >
> > Laurent Pinchart
>
> --
> Best Regards,
> Michael
--
Best Regards,
Michael
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH] media: v4l: vsp1: Fix offset calculation for plane cropping
2022-05-06 9:58 ` Michael Rodin
@ 2022-05-07 21:16 ` Laurent Pinchart
0 siblings, 0 replies; 7+ messages in thread
From: Laurent Pinchart @ 2022-05-07 21:16 UTC (permalink / raw)
To: Michael Rodin; +Cc: linux-media, linux-renesas-soc, LUU HOAI, Kieran Bingham
Hi Michael,
On Fri, May 06, 2022 at 11:58:21AM +0200, Michael Rodin wrote:
> Hi Laurent,
>
> do you see any open points for this patch? If not, do you know maybe when
> it will be available on linux-media or maybe mainline branch?
I've just sent a pull request that includes this fix, I hope it will
make it to v5.19.
> On Tue, Apr 19, 2022 at 12:22:15PM +0200, Michael Rodin wrote:
> > On Thu, Apr 14, 2022 at 05:20:14PM +0300, Laurent Pinchart wrote:
> > > Hi Michael,
> > >
> > > Your previous mail slipped through the cracks, sorry about that.
> > >
> > > On Wed, Mar 02, 2022 at 12:00:12PM +0100, Michael Rodin wrote:
> > > > Hi Laurent,
> > > >
> > > > thank you for your work!
> > > >
> > > > On Mon, Feb 28, 2022 at 02:00:58PM +0200, Laurent Pinchart wrote:
> > > > > From: Michael Rodin <mrodin@de.adit-jv.com>
> > > > >
> > > > > The vertical subsampling factor is currently not considered in the
> > > > > offset calculation for plane cropping done in rpf_configure_partition.
> > > > > This causes a distortion (shift of the color plane) when formats with
> > > > > the vsub factor larger than 1 are used (e.g. NV12, see
> > > > > vsp1_video_formats in vsp1_pipe.c). This commit considers vsub factor
> > > > > for all planes except plane 0 (luminance).
> > > > >
> > > > > Fixes: e5ad37b64de9 ("[media] v4l: vsp1: Add cropping support")
> > > > > Signed-off-by: Michael Rodin <mrodin@de.adit-jv.com>
> > > > > Signed-off-by: LUU HOAI <hoai.luu.ub@renesas.com>
> > > > >
> > > > > Drop generalization of the offset calculation to reduce the binary size.
> > > >
> > > > Dropping generalization which I have done in my initial patch [1] is ok as
> > > > long as this will not cause any troubles. I am not aware of any case where
> > > > bytesperline and bpp could be different between the chroma planes, so
> > > > probably it's fine.
> > > >
> > > > > Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> > > > > ---
> > > > > drivers/media/platform/vsp1/vsp1_rpf.c | 6 +++---
> > > > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > > > >
> > > > > diff --git a/drivers/media/platform/vsp1/vsp1_rpf.c b/drivers/media/platform/vsp1/vsp1_rpf.c
> > > > > index 85587c1b6a37..75083cb234fe 100644
> > > > > --- a/drivers/media/platform/vsp1/vsp1_rpf.c
> > > > > +++ b/drivers/media/platform/vsp1/vsp1_rpf.c
> > > > > @@ -291,11 +291,11 @@ static void rpf_configure_partition(struct vsp1_entity *entity,
> > > > > + crop.left * fmtinfo->bpp[0] / 8;
> > > > >
> > > > > if (format->num_planes > 1) {
> > > > > + unsigned int bpl = format->plane_fmt[1].bytesperline;
> > > > > unsigned int offset;
> > > > >
> > > > > - offset = crop.top * format->plane_fmt[1].bytesperline
> > > > > - + crop.left / fmtinfo->hsub
> > > > > - * fmtinfo->bpp[1] / 8;
> > > > > + offset = crop.top / fmtinfo->vsub * bpl
> > > > > + + crop.left / fmtinfo->hsub * fmtinfo->bpp[1] / 8;
> > > >
> > > > Probably it makes sense to do the division after all multiplications are
> > > > done in order to avoid rounding errors? Consider the case when left = 3,
> > > > hsub = 2, bpp = 32. Then we would get for the second part of the offset:
> > > > 3 / 2 * 32 / 8 = 1 * 32 / 8 = 4
> > > > and if we do division as the last operation:
> > > > (3 * 32) / (8 * 2) = 96 / 16 = 6
> > >
> > > This was actually done on purpose :-) If the horizontal subsampling
> > > factor is equal to 2, for instance for the NV12 chroma plane, the
> > > horizontal offset must effectively be a multiple of 2. Otherwise you'll
> > > swap the Cr and Cb components.
> > >
> > > Taking your above example with a NV12 format (left=3, hsub=2, but
> > > bpp=16), with the rounding in this patch,
> > >
> > > offset = crop.top / fmtinfo->vsub * bpl
> > > + crop.left / fmtinfo->hsub * fmtinfo->bpp[1] / 8;
> > > = [vertical offset]
> > > + 3 / 2 * 16 / 8;
> > > = [vertical offset]
> > > + 2;
> > >
> > > Byte: 0 1 2 3 4 5
> > > Cr Cb Cr Cb Cr Cb ...
> > > ^
> > > offset
> > >
> > > With your rounding proposal,
> > >
> > > offset = crop.top / fmtinfo->vsub * bpl
> > > + (crop.left * fmtinfo->bpp[1]) / (fmtinfo->hsub * 8);
> > > = [vertical offset]
> > > + (3 * 16) / (2 * 8);
> > > = [vertical offset]
> > > + 3;
> > >
> > > Byte: 0 1 2 3 4 5
> > > Cr Cb Cr Cb Cr Cb ...
> > > ^
> > > offset
> >
> > Thank you very much for the clarification, I have missed this point!
> > Now the patch looks fine to me.
> >
> > Reviewed-by: Michael Rodin <mrodin@de.adit-jv.com>
> >
> > > > The first part of the offset can probably also cause the same rounding
> > > > issue.
> > > >
> > > > > mem.addr[1] += offset;
> > > > > mem.addr[2] += offset;
> > > > > }
> > > > >
> > > >
> > > > [1] https://lore.kernel.org/all/1637679566-2D76975-1-git-send-email-mrodin-40de.adit-jv.com/T/
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-05-07 21:16 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-02-28 12:00 [PATCH] media: v4l: vsp1: Fix offset calculation for plane cropping Laurent Pinchart
2022-02-28 12:35 ` Kieran Bingham
2022-03-02 11:00 ` Michael Rodin
2022-04-14 14:20 ` Laurent Pinchart
2022-04-19 10:22 ` Michael Rodin
2022-05-06 9:58 ` Michael Rodin
2022-05-07 21:16 ` Laurent Pinchart
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.