Re: [PATCH] media: v4l: vsp1: Fix offset calculation for plane cropping

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Laurent,

thank you for your work!

On Mon, Feb 28, 2022 at 02:00:58PM +0200, Laurent Pinchart wrote:
> From: Michael Rodin <mrodin@xxxxxxxxxxxxxx>
> 
> 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@xxxxxxxxxxxxxx>
> 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@xxxxxxxxxxxxxxxx>
> ---
>  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@xxxxxxxxxxxxxx/T/

-- 
Best Regards,
Michael



[Index of Archives]     [Linux Samsung SOC]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]

  Powered by Linux