From: Simon Horman <horms@verge.net.au>
To: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: Yoshihiro Kaneko <ykaneko0929@gmail.com>,
linux-media@vger.kernel.org,
Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
Magnus Damm <magnus.damm@gmail.com>,
linux-sh@vger.kernel.org
Subject: Re: [PATCH] media: soc_camera: rcar_vin: Fix alignment of clipping size
Date: Thu, 20 Nov 2014 01:45:47 +0000 [thread overview]
Message-ID: <20141120014547.GA29752@verge.net.au> (raw)
In-Reply-To: <5453915E.3020100@cogentembedded.com>
Hi,
On Fri, Oct 31, 2014 at 04:40:46PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 10/31/2014 12:10 PM, Yoshihiro Kaneko wrote:
>
> >From: Koji Matsuoka <koji.matsuoka.xm@renesas.com>
>
> >Since the Start Line Pre-Clip register, the Start Pixel Pre-Clip
> >register and the End Line Post-Clip register do not have restriction
>
> Hm, my R-Car H1 manual says to specify an even number for the Start Pixel
> Pre-Clip Register.
Thanks. I have confirmed with Matsuoka-san that you are correct.
It seems to me that the following portion of the patch should be removed
accordingly.
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -1558,8 +1558,8 @@ static int rcar_vin_set_crop(struct soc_camera_device *icd,
cam->width = mf.width;
cam->height = mf.height;
- cam->vin_left = rect->left & ~1;
- cam->vin_top = rect->top & ~1;
+ cam->vin_left = rect->left;
+ cam->vin_top = rect->top;
/* Use VIN cropping to crop to the new window. */
ret = rcar_vin_set_rect(icd);
> >of H/W to a setting value, the processing of alignment is unnecessary.
> >This patch corrects so that processing of alignment is not performed.
>
> >However, the End Pixel Post-Clip register has restriction
> >of H/W which must be an even number value at the time of the
> >output of YCbCr-422 format. By this patch, the processing of
> >alignment to an even number value is added on the above-mentioned
> >conditions.
>
> Well, the R-Car H1/M1A manuals don't specify such restriction.
Thanks, I have confirmed with Matsuoka-san that the above text
is somewhat misleading. And I think it should read something more like this:
In the case where YCbCr-422 is used and
(End pixel post clip) - (Start pixel post clip) is
odd one will be added by the hardware to round it up
to an even number.
I see this in section 26.2.11 Video n End Pixel Post-Clip Register (VnEPPoC)
if the R-Car Gen 2 manual.
> >The variable set to a register is as follows.
>
> > - Start Line Pre-Clip register
> > cam->vin_top
> > - Start Pixel Pre-Clip register
> > cam->vin_left
> > - End Line Post-Clip register
> > pix->height
> > - End Pixel Post-Clip register
> > pix->width
>
> >Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com>
> >Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
> >---
> > drivers/media/platform/soc_camera/rcar_vin.c | 18 ++++++++++++++----
> > 1 file changed, 14 insertions(+), 4 deletions(-)
>
> >diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c
> >index d3d2f7d..1934e15 100644
> >--- a/drivers/media/platform/soc_camera/rcar_vin.c
> >+++ b/drivers/media/platform/soc_camera/rcar_vin.c
> [...]
> >@@ -1761,8 +1761,18 @@ static int rcar_vin_try_fmt(struct soc_camera_device *icd,
> > }
> >
> > /* FIXME: calculate using depth and bus width */
> >- v4l_bound_align_image(&pix->width, 2, VIN_MAX_WIDTH, 1,
> >- &pix->height, 4, VIN_MAX_HEIGHT, 2, 0);
> >+ /*
> >+ * When performing a YCbCr-422 format output, even if it performs
> >+ * odd number clipping by pixel post clip processing, it is outputted
>
> s/outputted/output/ -- it's an irregular verb.
>
> >+ * to a memory per even pixels.
> >+ */
> >+ if ((pixfmt = V4L2_PIX_FMT_NV16) || (pixfmt = V4L2_PIX_FMT_YUYV) ||
> >+ (pixfmt = V4L2_PIX_FMT_UYVY))
>
> This is certainly asking to be a *switch* statement instead...
>
> >+ v4l_bound_align_image(&pix->width, 5, VIN_MAX_WIDTH, 1,
> >+ &pix->height, 2, VIN_MAX_HEIGHT, 0, 0);
> >+ else
> >+ v4l_bound_align_image(&pix->width, 5, VIN_MAX_WIDTH, 0,
> >+ &pix->height, 2, VIN_MAX_HEIGHT, 0, 0);
>
> WBR, Sergei
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@verge.net.au>
To: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Cc: Yoshihiro Kaneko <ykaneko0929@gmail.com>,
linux-media@vger.kernel.org,
Guennadi Liakhovetski <g.liakhovetski@gmx.de>,
Magnus Damm <magnus.damm@gmail.com>,
linux-sh@vger.kernel.org
Subject: Re: [PATCH] media: soc_camera: rcar_vin: Fix alignment of clipping size
Date: Thu, 20 Nov 2014 10:45:47 +0900 [thread overview]
Message-ID: <20141120014547.GA29752@verge.net.au> (raw)
In-Reply-To: <5453915E.3020100@cogentembedded.com>
Hi,
On Fri, Oct 31, 2014 at 04:40:46PM +0300, Sergei Shtylyov wrote:
> Hello.
>
> On 10/31/2014 12:10 PM, Yoshihiro Kaneko wrote:
>
> >From: Koji Matsuoka <koji.matsuoka.xm@renesas.com>
>
> >Since the Start Line Pre-Clip register, the Start Pixel Pre-Clip
> >register and the End Line Post-Clip register do not have restriction
>
> Hm, my R-Car H1 manual says to specify an even number for the Start Pixel
> Pre-Clip Register.
Thanks. I have confirmed with Matsuoka-san that you are correct.
It seems to me that the following portion of the patch should be removed
accordingly.
--- a/drivers/media/platform/soc_camera/rcar_vin.c
+++ b/drivers/media/platform/soc_camera/rcar_vin.c
@@ -1558,8 +1558,8 @@ static int rcar_vin_set_crop(struct soc_camera_device *icd,
cam->width = mf.width;
cam->height = mf.height;
- cam->vin_left = rect->left & ~1;
- cam->vin_top = rect->top & ~1;
+ cam->vin_left = rect->left;
+ cam->vin_top = rect->top;
/* Use VIN cropping to crop to the new window. */
ret = rcar_vin_set_rect(icd);
> >of H/W to a setting value, the processing of alignment is unnecessary.
> >This patch corrects so that processing of alignment is not performed.
>
> >However, the End Pixel Post-Clip register has restriction
> >of H/W which must be an even number value at the time of the
> >output of YCbCr-422 format. By this patch, the processing of
> >alignment to an even number value is added on the above-mentioned
> >conditions.
>
> Well, the R-Car H1/M1A manuals don't specify such restriction.
Thanks, I have confirmed with Matsuoka-san that the above text
is somewhat misleading. And I think it should read something more like this:
In the case where YCbCr-422 is used and
(End pixel post clip) - (Start pixel post clip) is
odd one will be added by the hardware to round it up
to an even number.
I see this in section 26.2.11 Video n End Pixel Post-Clip Register (VnEPPoC)
if the R-Car Gen 2 manual.
> >The variable set to a register is as follows.
>
> > - Start Line Pre-Clip register
> > cam->vin_top
> > - Start Pixel Pre-Clip register
> > cam->vin_left
> > - End Line Post-Clip register
> > pix->height
> > - End Pixel Post-Clip register
> > pix->width
>
> >Signed-off-by: Koji Matsuoka <koji.matsuoka.xm@renesas.com>
> >Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
> >---
> > drivers/media/platform/soc_camera/rcar_vin.c | 18 ++++++++++++++----
> > 1 file changed, 14 insertions(+), 4 deletions(-)
>
> >diff --git a/drivers/media/platform/soc_camera/rcar_vin.c b/drivers/media/platform/soc_camera/rcar_vin.c
> >index d3d2f7d..1934e15 100644
> >--- a/drivers/media/platform/soc_camera/rcar_vin.c
> >+++ b/drivers/media/platform/soc_camera/rcar_vin.c
> [...]
> >@@ -1761,8 +1761,18 @@ static int rcar_vin_try_fmt(struct soc_camera_device *icd,
> > }
> >
> > /* FIXME: calculate using depth and bus width */
> >- v4l_bound_align_image(&pix->width, 2, VIN_MAX_WIDTH, 1,
> >- &pix->height, 4, VIN_MAX_HEIGHT, 2, 0);
> >+ /*
> >+ * When performing a YCbCr-422 format output, even if it performs
> >+ * odd number clipping by pixel post clip processing, it is outputted
>
> s/outputted/output/ -- it's an irregular verb.
>
> >+ * to a memory per even pixels.
> >+ */
> >+ if ((pixfmt == V4L2_PIX_FMT_NV16) || (pixfmt == V4L2_PIX_FMT_YUYV) ||
> >+ (pixfmt == V4L2_PIX_FMT_UYVY))
>
> This is certainly asking to be a *switch* statement instead...
>
> >+ v4l_bound_align_image(&pix->width, 5, VIN_MAX_WIDTH, 1,
> >+ &pix->height, 2, VIN_MAX_HEIGHT, 0, 0);
> >+ else
> >+ v4l_bound_align_image(&pix->width, 5, VIN_MAX_WIDTH, 0,
> >+ &pix->height, 2, VIN_MAX_HEIGHT, 0, 0);
>
> WBR, Sergei
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2014-11-20 1:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-31 9:09 [PATCH] media: soc_camera: rcar_vin: Fix interrupt enable in progressive Yoshihiro Kaneko
2014-10-31 9:09 ` Yoshihiro Kaneko
2014-10-31 9:10 ` [PATCH] media: soc_camera: rcar_vin: Fix alignment of clipping size Yoshihiro Kaneko
2014-10-31 9:10 ` Yoshihiro Kaneko
2014-10-31 13:40 ` Sergei Shtylyov
2014-10-31 13:40 ` Sergei Shtylyov
2014-11-20 1:45 ` Simon Horman [this message]
2014-11-20 1:45 ` Simon Horman
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=20141120014547.GA29752@verge.net.au \
--to=horms@verge.net.au \
--cc=g.liakhovetski@gmx.de \
--cc=linux-media@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=sergei.shtylyov@cogentembedded.com \
--cc=ykaneko0929@gmail.com \
/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: link
Be 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.