Hello Niklas,
On Thu, 2019-09-05 at 23:25 +0200, Niklas Söderlund wrote:
> The image size is doubled for NV16 and is calculated as bytesperline *
> height * 2 to accommodate the split of UV data. When writing the offset
> to hardware width is used instead of bytesperline, fix this.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@xxxxxxxxxxxx>
> ---
> drivers/media/platform/rcar-vin/rcar-dma.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/platform/rcar-vin/rcar-dma.c b/drivers/media/platform/rcar-vin/rcar-dma.c
> index c7859b329dd4f02a..af4f774149f08597 100644
> --- a/drivers/media/platform/rcar-vin/rcar-dma.c
> +++ b/drivers/media/platform/rcar-vin/rcar-dma.c
> @@ -703,8 +703,8 @@ static int rvin_setup(struct rvin_dev *vin)
> switch (vin->format.pixelformat) {
> case V4L2_PIX_FMT_NV16:
> rvin_write(vin,
> - ALIGN(vin->format.width * vin->format.height, 0x80),
> - VNUVAOF_REG);
> + ALIGN(vin->format.bytesperline * vin->format.height,
> + 0x80), VNUVAOF_REG);
You can make your life easier by simply pulling the pixel format helper
and let someone figure out the math. See v4l2_fill_pixfmt and friends.
Avoiding these type of subtle issues is why we have them.
Eze
