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+rene...@ragnatech.se> > --- > 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