[2/5] mx2_camera: remove emma limitation for RGB565

Message ID 1280828276-483-3-git-send-email-m.grzeschik@pengutronix.de (mailing list archive)
State Superseded, archived
Headers

Commit Message

Michael Grzeschik Aug. 3, 2010, 9:37 a.m. UTC
  In the current source status the emma has no limitation for any PIXFMT
since the data is parsed raw and unprocessed into the memory.

Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
---
 drivers/media/video/mx2_camera.c |    8 --------
 1 files changed, 0 insertions(+), 8 deletions(-)
  

Comments

Guennadi Liakhovetski Aug. 4, 2010, 9:55 a.m. UTC | #1
On Tue, 3 Aug 2010, Michael Grzeschik wrote:

> In the current source status the emma has no limitation for any PIXFMT
> since the data is parsed raw and unprocessed into the memory.

I'd like some explanation for this one too, please. What about

+	/*
+	 * We only use the EMMA engine to get rid of the broken
+	 * DMA Engine. No color space consversion at the moment.
+	 * We adjust incoming and outgoing pixelformat to rgb16
+	 * and adjust the bytesperline accordingly.
+	 */
+	writel(PRP_CNTL_CH1EN |
+			PRP_CNTL_CSIEN |
+			PRP_CNTL_DATA_IN_RGB16 |
+			PRP_CNTL_CH1_OUT_RGB16 |
+			PRP_CNTL_CH1_LEN |
+			PRP_CNTL_CH1BYP |
+			PRP_CNTL_CH1_TSKIP(0) |
+			PRP_CNTL_IN_TSKIP(0),
+			pcdev->base_emma + PRP_CNTL);
+
+	writel(((bytesperline >> 1) << 16) | icd->user_height,
+			pcdev->base_emma + PRP_SRC_FRAME_SIZE);
+	writel(((bytesperline >> 1) << 16) | icd->user_height,
+			pcdev->base_emma + PRP_CH1_OUT_IMAGE_SIZE);
+	writel(bytesperline,
+			pcdev->base_emma + PRP_DEST_CH1_LINE_STRIDE);
+	writel(0x2ca00565, /* RGB565 */
+			pcdev->base_emma + PRP_SRC_PIXEL_FORMAT_CNTL);
+	writel(0x2ca00565, /* RGB565 */
+			pcdev->base_emma + PRP_CH1_PIXEL_FORMAT_CNTL);

To me it looks like the eMMA is configured for RGB565. What's the trick?

Thanks
Guennadi

> 
> Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
> ---
>  drivers/media/video/mx2_camera.c |    8 --------
>  1 files changed, 0 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
> index c77a673..ae27640 100644
> --- a/drivers/media/video/mx2_camera.c
> +++ b/drivers/media/video/mx2_camera.c
> @@ -897,10 +897,6 @@ static int mx2_camera_set_fmt(struct soc_camera_device *icd,
>  		return -EINVAL;
>  	}
>  
> -	/* eMMA can only do RGB565 */
> -	if (mx27_camera_emma(pcdev) && pix->pixelformat != V4L2_PIX_FMT_RGB565)
> -		return -EINVAL;
> -
>  	mf.width	= pix->width;
>  	mf.height	= pix->height;
>  	mf.field	= pix->field;
> @@ -944,10 +940,6 @@ static int mx2_camera_try_fmt(struct soc_camera_device *icd,
>  
>  	/* FIXME: implement MX27 limits */
>  
> -	/* eMMA can only do RGB565 */
> -	if (mx27_camera_emma(pcdev) && pixfmt != V4L2_PIX_FMT_RGB565)
> -		return -EINVAL;
> -
>  	/* limit to MX25 hardware capabilities */
>  	if (cpu_is_mx25()) {
>  		if (xlate->host_fmt->bits_per_sample <= 8)
> -- 
> 1.7.1
> 
> 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  
Michael Grzeschik Aug. 4, 2010, 10:27 a.m. UTC | #2
On Wed, Aug 04, 2010 at 11:55:39AM +0200, Guennadi Liakhovetski wrote:
> On Tue, 3 Aug 2010, Michael Grzeschik wrote:
> 
> > In the current source status the emma has no limitation for any PIXFMT
> > since the data is parsed raw and unprocessed into the memory.
> 
> I'd like some explanation for this one too, please. What about
> 
> +	/*
> +	 * We only use the EMMA engine to get rid of the broken
> +	 * DMA Engine. No color space consversion at the moment.
> +	 * We adjust incoming and outgoing pixelformat to rgb16
> +	 * and adjust the bytesperline accordingly.
> +	 */
> +	writel(PRP_CNTL_CH1EN |
> +			PRP_CNTL_CSIEN |
> +			PRP_CNTL_DATA_IN_RGB16 |
> +			PRP_CNTL_CH1_OUT_RGB16 |
> +			PRP_CNTL_CH1_LEN |
> +			PRP_CNTL_CH1BYP |
> +			PRP_CNTL_CH1_TSKIP(0) |
> +			PRP_CNTL_IN_TSKIP(0),
> +			pcdev->base_emma + PRP_CNTL);
> +
> +	writel(((bytesperline >> 1) << 16) | icd->user_height,
> +			pcdev->base_emma + PRP_SRC_FRAME_SIZE);
> +	writel(((bytesperline >> 1) << 16) | icd->user_height,
> +			pcdev->base_emma + PRP_CH1_OUT_IMAGE_SIZE);
> +	writel(bytesperline,
> +			pcdev->base_emma + PRP_DEST_CH1_LINE_STRIDE);
> +	writel(0x2ca00565, /* RGB565 */
> +			pcdev->base_emma + PRP_SRC_PIXEL_FORMAT_CNTL);
> +	writel(0x2ca00565, /* RGB565 */
> +			pcdev->base_emma + PRP_CH1_PIXEL_FORMAT_CNTL);
> 
> To me it looks like the eMMA is configured for RGB565. What's the trick?
> 

Yes, it seems to be an indication, but the emma currently does not touch
any pixels, since the SRC_PIXEL_FORMAT and CH1_PIXEL_FORMAT are
identical. It will be needed in the future when we are going to do some
resizing operations with the emma or the SRC_PIXEL_FORMAT will differ to
the output channels. But at that time, the simple condition check for
RGB565 wouldn't be enough. So we should better remove them now.

Michael

> 
> > 
> > Signed-off-by: Michael Grzeschik <m.grzeschik@pengutronix.de>
> > ---
> >  drivers/media/video/mx2_camera.c |    8 --------
> >  1 files changed, 0 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
> > index c77a673..ae27640 100644
> > --- a/drivers/media/video/mx2_camera.c
> > +++ b/drivers/media/video/mx2_camera.c
> > @@ -897,10 +897,6 @@ static int mx2_camera_set_fmt(struct soc_camera_device *icd,
> >  		return -EINVAL;
> >  	}
> >  
> > -	/* eMMA can only do RGB565 */
> > -	if (mx27_camera_emma(pcdev) && pix->pixelformat != V4L2_PIX_FMT_RGB565)
> > -		return -EINVAL;
> > -
> >  	mf.width	= pix->width;
> >  	mf.height	= pix->height;
> >  	mf.field	= pix->field;
> > @@ -944,10 +940,6 @@ static int mx2_camera_try_fmt(struct soc_camera_device *icd,
> >  
> >  	/* FIXME: implement MX27 limits */
> >  
> > -	/* eMMA can only do RGB565 */
> > -	if (mx27_camera_emma(pcdev) && pixfmt != V4L2_PIX_FMT_RGB565)
> > -		return -EINVAL;
> > -
> >  	/* limit to MX25 hardware capabilities */
> >  	if (cpu_is_mx25()) {
> >  		if (xlate->host_fmt->bits_per_sample <= 8)
> > -- 
> > 1.7.1
> > 
> >
  
Guennadi Liakhovetski Aug. 5, 2010, 7:25 p.m. UTC | #3
On Wed, 4 Aug 2010, Michael Grzeschik wrote:

> On Wed, Aug 04, 2010 at 11:55:39AM +0200, Guennadi Liakhovetski wrote:
> > On Tue, 3 Aug 2010, Michael Grzeschik wrote:
> > 
> > > In the current source status the emma has no limitation for any PIXFMT
> > > since the data is parsed raw and unprocessed into the memory.
> > 
> > I'd like some explanation for this one too, please. What about
> > 
> > +	/*
> > +	 * We only use the EMMA engine to get rid of the broken
> > +	 * DMA Engine. No color space consversion at the moment.
> > +	 * We adjust incoming and outgoing pixelformat to rgb16
> > +	 * and adjust the bytesperline accordingly.
> > +	 */
> > +	writel(PRP_CNTL_CH1EN |
> > +			PRP_CNTL_CSIEN |
> > +			PRP_CNTL_DATA_IN_RGB16 |
> > +			PRP_CNTL_CH1_OUT_RGB16 |
> > +			PRP_CNTL_CH1_LEN |
> > +			PRP_CNTL_CH1BYP |
> > +			PRP_CNTL_CH1_TSKIP(0) |
> > +			PRP_CNTL_IN_TSKIP(0),
> > +			pcdev->base_emma + PRP_CNTL);
> > +
> > +	writel(((bytesperline >> 1) << 16) | icd->user_height,
> > +			pcdev->base_emma + PRP_SRC_FRAME_SIZE);
> > +	writel(((bytesperline >> 1) << 16) | icd->user_height,
> > +			pcdev->base_emma + PRP_CH1_OUT_IMAGE_SIZE);
> > +	writel(bytesperline,
> > +			pcdev->base_emma + PRP_DEST_CH1_LINE_STRIDE);
> > +	writel(0x2ca00565, /* RGB565 */
> > +			pcdev->base_emma + PRP_SRC_PIXEL_FORMAT_CNTL);
> > +	writel(0x2ca00565, /* RGB565 */
> > +			pcdev->base_emma + PRP_CH1_PIXEL_FORMAT_CNTL);
> > 
> > To me it looks like the eMMA is configured for RGB565. What's the trick?
> > 
> 
> Yes, it seems to be an indication, but the emma currently does not touch
> any pixels, since the SRC_PIXEL_FORMAT and CH1_PIXEL_FORMAT are
> identical. It will be needed in the future when we are going to do some
> resizing operations with the emma or the SRC_PIXEL_FORMAT will differ to
> the output channels. But at that time, the simple condition check for
> RGB565 wouldn't be enough. So we should better remove them now.

Then at least, please fix the above comment:

> > +	 * We adjust incoming and outgoing pixelformat to rgb16
> > +	 * and adjust the bytesperline accordingly.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
  

Patch

diff --git a/drivers/media/video/mx2_camera.c b/drivers/media/video/mx2_camera.c
index c77a673..ae27640 100644
--- a/drivers/media/video/mx2_camera.c
+++ b/drivers/media/video/mx2_camera.c
@@ -897,10 +897,6 @@  static int mx2_camera_set_fmt(struct soc_camera_device *icd,
 		return -EINVAL;
 	}
 
-	/* eMMA can only do RGB565 */
-	if (mx27_camera_emma(pcdev) && pix->pixelformat != V4L2_PIX_FMT_RGB565)
-		return -EINVAL;
-
 	mf.width	= pix->width;
 	mf.height	= pix->height;
 	mf.field	= pix->field;
@@ -944,10 +940,6 @@  static int mx2_camera_try_fmt(struct soc_camera_device *icd,
 
 	/* FIXME: implement MX27 limits */
 
-	/* eMMA can only do RGB565 */
-	if (mx27_camera_emma(pcdev) && pixfmt != V4L2_PIX_FMT_RGB565)
-		return -EINVAL;
-
 	/* limit to MX25 hardware capabilities */
 	if (cpu_is_mx25()) {
 		if (xlate->host_fmt->bits_per_sample <= 8)