[PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed

[PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed

[hvaibhav]

From: Vaibhav Hiremath <hvaibhav@ti.com>

In case of 720P with 90/270 degree rotation, the system reports
GFX_FIFO_UNDERFLOW error which usually happens if DSS DMA is not able to fill
the FIFO as per requirement.

In TRM (section 11.2.6.1.3), where is has been clearly mentioned that,

"To improve the performance on 90 degree rotation, split the data access on
write side and not read side."

That means, read should always happen on 0 degree and write should go to
respective rotation view.

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
---
 drivers/video/omap2/omapfb/omapfb-main.c |   85 +++++++++++++++++++----------
 1 files changed, 56 insertions(+), 29 deletions(-)

diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 4a76917..fea6b08 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -184,6 +184,11 @@ static unsigned omapfb_get_vrfb_offset(const struct omapfb_info *ofbi, int rot)
 static u32 omapfb_get_region_rot_paddr(const struct omapfb_info *ofbi, int rot)
 {
 	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
+		if (rot == FB_ROTATE_CW)
+			rot = FB_ROTATE_CCW;
+		else if (rot == FB_ROTATE_CCW)
+			rot = FB_ROTATE_CW;
+
 		return ofbi->region.vrfb.paddr[rot]
 			+ omapfb_get_vrfb_offset(ofbi, rot);
 	} else {
@@ -191,20 +196,32 @@ static u32 omapfb_get_region_rot_paddr(const struct omapfb_info *ofbi, int rot)
 	}
 }
 
-static u32 omapfb_get_region_paddr(const struct omapfb_info *ofbi)
+static u32 omapfb_get_region_paddr(struct omapfb_info *ofbi, int rot)
 {
-	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
-		return ofbi->region.vrfb.paddr[0];
-	else
+	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
+		if (rot == FB_ROTATE_CW)
+			rot = FB_ROTATE_CCW;
+		else if (rot == FB_ROTATE_CCW)
+			rot = FB_ROTATE_CW;
+
+		return ofbi->region.vrfb.paddr[rot];
+	} else {
 		return ofbi->region.paddr;
+	}
 }
 
-static void __iomem *omapfb_get_region_vaddr(const struct omapfb_info *ofbi)
+static void __iomem *omapfb_get_region_vaddr(struct omapfb_info *ofbi, int rot)
 {
-	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
-		return ofbi->region.vrfb.vaddr[0];
-	else
+	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
+		if (rot == FB_ROTATE_CW)
+			rot = FB_ROTATE_CCW;
+		else if (rot == FB_ROTATE_CCW)
+			rot = FB_ROTATE_CW;
+
+		return ofbi->region.vrfb.vaddr[rot];
+	} else {
 		return ofbi->region.vaddr;
+	}
 }
 
 static struct omapfb_colormode omapfb_colormodes[] = {
@@ -503,7 +520,7 @@ static int setup_vrfb_rotation(struct fb_info *fbi)
 	unsigned bytespp;
 	bool yuv_mode;
 	enum omap_color_mode mode;
-	int r;
+	int r, rotation = var->rotate;
 	bool reconf;
 
 	if (!rg->size || ofbi->rotation_type != OMAP_DSS_ROT_VRFB)
@@ -511,6 +528,11 @@ static int setup_vrfb_rotation(struct fb_info *fbi)
 
 	DBG("setup_vrfb_rotation\n");
 
+	if (rotation == FB_ROTATE_CW)
+		rotation = FB_ROTATE_CCW;
+	else if (rotation == FB_ROTATE_CCW)
+		rotation = FB_ROTATE_CW;
+
 	r = fb_mode_to_dss_mode(var, &mode);
 	if (r)
 		return r;
@@ -534,32 +556,35 @@ static int setup_vrfb_rotation(struct fb_info *fbi)
 			vrfb->yres != var->yres_virtual)
 		reconf = true;
 
-	if (vrfb->vaddr[0] && reconf) {
+	if (vrfb->vaddr[rotation] && reconf) {
 		fbi->screen_base = NULL;
 		fix->smem_start = 0;
 		fix->smem_len = 0;
-		iounmap(vrfb->vaddr[0]);
-		vrfb->vaddr[0] = NULL;
+		iounmap(vrfb->vaddr[rotation]);
+		vrfb->vaddr[rotation] = NULL;
 		DBG("setup_vrfb_rotation: reset fb\n");
 	}
 
-	if (vrfb->vaddr[0])
+	if (vrfb->vaddr[rotation])
 		return 0;
 
-	omap_vrfb_setup(&rg->vrfb, rg->paddr,
-			var->xres_virtual,
-			var->yres_virtual,
-			bytespp, yuv_mode);
+	if (rotation == FB_ROTATE_CW || rotation == FB_ROTATE_CCW)
+		omap_vrfb_setup(&rg->vrfb, rg->paddr,
+				var->yres_virtual, var->xres_virtual,
+				bytespp, yuv_mode);
+	else
+		omap_vrfb_setup(&rg->vrfb, rg->paddr,
+				var->xres_virtual, var->yres_virtual,
+				bytespp, yuv_mode);
 
-	/* Now one can ioremap the 0 angle view */
-	r = omap_vrfb_map_angle(vrfb, var->yres_virtual, 0);
+	/* Now one can ioremap the rotation angle view */
+	r = omap_vrfb_map_angle(vrfb, var->yres_virtual, rotation);
 	if (r)
 		return r;
-
 	/* used by open/write in fbmem.c */
-	fbi->screen_base = ofbi->region.vrfb.vaddr[0];
+	fbi->screen_base = ofbi->region.vrfb.vaddr[rotation];
 
-	fix->smem_start = ofbi->region.vrfb.paddr[0];
+	fix->smem_start = ofbi->region.vrfb.paddr[rotation];
 
 	switch (var->nonstd) {
 	case OMAPFB_COLOR_YUV422:
@@ -603,7 +628,8 @@ void set_fb_fix(struct fb_info *fbi)
 	DBG("set_fb_fix\n");
 
 	/* used by open/write in fbmem.c */
-	fbi->screen_base = (char __iomem *)omapfb_get_region_vaddr(ofbi);
+	fbi->screen_base = (char __iomem *)omapfb_get_region_vaddr(ofbi,
+			var->rotate);
 
 	/* used by mmap in fbmem.c */
 	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
@@ -626,7 +652,7 @@ void set_fb_fix(struct fb_info *fbi)
 		fix->smem_len = rg->size;
 	}
 
-	fix->smem_start = omapfb_get_region_paddr(ofbi);
+	fix->smem_start = omapfb_get_region_paddr(ofbi, var->rotate);
 
 	fix->type = FB_TYPE_PACKED_PIXELS;
 
@@ -862,15 +888,15 @@ static int omapfb_setup_overlay(struct fb_info *fbi, struct omap_overlay *ovl,
 
 
 	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
-		data_start_p = omapfb_get_region_rot_paddr(ofbi, rotation);
+		data_start_p = omapfb_get_region_rot_paddr(ofbi, 0);
 		data_start_v = NULL;
 	} else {
-		data_start_p = omapfb_get_region_paddr(ofbi);
-		data_start_v = omapfb_get_region_vaddr(ofbi);
+		data_start_p = omapfb_get_region_paddr(ofbi, 0);
+		data_start_v = omapfb_get_region_vaddr(ofbi, 0);
 	}
 
 	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
-		offset = calc_rotation_offset_vrfb(var, fix, rotation);
+		offset = calc_rotation_offset_vrfb(var, fix, 0);
 	else
 		offset = calc_rotation_offset_dma(var, fix, rotation);
 
@@ -1078,6 +1104,7 @@ static struct vm_operations_struct mmap_user_ops = {
 static int omapfb_mmap(struct fb_info *fbi, struct vm_area_struct *vma)
 {
 	struct omapfb_info *ofbi = FB2OFB(fbi);
+	struct fb_var_screeninfo *var = &fbi->var;
 	struct fb_fix_screeninfo *fix = &fbi->fix;
 	unsigned long off;
 	unsigned long start;
@@ -1089,7 +1116,7 @@ static int omapfb_mmap(struct fb_info *fbi, struct vm_area_struct *vma)
 		return -EINVAL;
 	off = vma->vm_pgoff << PAGE_SHIFT;
 
-	start = omapfb_get_region_paddr(ofbi);
+	start = omapfb_get_region_paddr(ofbi, var->rotate);
 	len = fix->smem_len;
 	if (off >= len)
 		return -EINVAL;
-- 
1.6.2.4

RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Hiremath, Vaibhav
> Sent: Monday, March 22, 2010 6:40 PM
> To: linux-omap@vger.kernel.org
> Cc: tomi.valkeinen@nokia.com; Hiremath, Vaibhav
> Subject: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> 
> From: Vaibhav Hiremath <hvaibhav@ti.com>
> 
> In case of 720P with 90/270 degree rotation, the system reports
> GFX_FIFO_UNDERFLOW error which usually happens if DSS DMA is not able to
> fill
> the FIFO as per requirement.
> 
> In TRM (section 11.2.6.1.3), where is has been clearly mentioned that,
> 
> "To improve the performance on 90 degree rotation, split the data access on
> write side and not read side."
> 
> That means, read should always happen on 0 degree and write should go to
> respective rotation view.


[Hiremath, Vaibhav] Tomi,

Any comment on this patch.

Thanks,
Vaibhav

> 
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> ---
>  drivers/video/omap2/omapfb/omapfb-main.c |   85 +++++++++++++++++++--------
> --
>  1 files changed, 56 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
> b/drivers/video/omap2/omapfb/omapfb-main.c
> index 4a76917..fea6b08 100644
> --- a/drivers/video/omap2/omapfb/omapfb-main.c
> +++ b/drivers/video/omap2/omapfb/omapfb-main.c
> @@ -184,6 +184,11 @@ static unsigned omapfb_get_vrfb_offset(const struct
> omapfb_info *ofbi, int rot)
>  static u32 omapfb_get_region_rot_paddr(const struct omapfb_info *ofbi, int
> rot)
>  {
>  	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
> +		if (rot == FB_ROTATE_CW)
> +			rot = FB_ROTATE_CCW;
> +		else if (rot == FB_ROTATE_CCW)
> +			rot = FB_ROTATE_CW;
> +
>  		return ofbi->region.vrfb.paddr[rot]
>  			+ omapfb_get_vrfb_offset(ofbi, rot);
>  	} else {
> @@ -191,20 +196,32 @@ static u32 omapfb_get_region_rot_paddr(const struct
> omapfb_info *ofbi, int rot)
>  	}
>  }
> 
> -static u32 omapfb_get_region_paddr(const struct omapfb_info *ofbi)
> +static u32 omapfb_get_region_paddr(struct omapfb_info *ofbi, int rot)
>  {
> -	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
> -		return ofbi->region.vrfb.paddr[0];
> -	else
> +	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
> +		if (rot == FB_ROTATE_CW)
> +			rot = FB_ROTATE_CCW;
> +		else if (rot == FB_ROTATE_CCW)
> +			rot = FB_ROTATE_CW;
> +
> +		return ofbi->region.vrfb.paddr[rot];
> +	} else {
>  		return ofbi->region.paddr;
> +	}
>  }
> 
> -static void __iomem *omapfb_get_region_vaddr(const struct omapfb_info
> *ofbi)
> +static void __iomem *omapfb_get_region_vaddr(struct omapfb_info *ofbi, int
> rot)
>  {
> -	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
> -		return ofbi->region.vrfb.vaddr[0];
> -	else
> +	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
> +		if (rot == FB_ROTATE_CW)
> +			rot = FB_ROTATE_CCW;
> +		else if (rot == FB_ROTATE_CCW)
> +			rot = FB_ROTATE_CW;
> +
> +		return ofbi->region.vrfb.vaddr[rot];
> +	} else {
>  		return ofbi->region.vaddr;
> +	}
>  }
> 
>  static struct omapfb_colormode omapfb_colormodes[] = {
> @@ -503,7 +520,7 @@ static int setup_vrfb_rotation(struct fb_info *fbi)
>  	unsigned bytespp;
>  	bool yuv_mode;
>  	enum omap_color_mode mode;
> -	int r;
> +	int r, rotation = var->rotate;
>  	bool reconf;
> 
>  	if (!rg->size || ofbi->rotation_type != OMAP_DSS_ROT_VRFB)
> @@ -511,6 +528,11 @@ static int setup_vrfb_rotation(struct fb_info *fbi)
> 
>  	DBG("setup_vrfb_rotation\n");
> 
> +	if (rotation == FB_ROTATE_CW)
> +		rotation = FB_ROTATE_CCW;
> +	else if (rotation == FB_ROTATE_CCW)
> +		rotation = FB_ROTATE_CW;
> +
>  	r = fb_mode_to_dss_mode(var, &mode);
>  	if (r)
>  		return r;
> @@ -534,32 +556,35 @@ static int setup_vrfb_rotation(struct fb_info *fbi)
>  			vrfb->yres != var->yres_virtual)
>  		reconf = true;
> 
> -	if (vrfb->vaddr[0] && reconf) {
> +	if (vrfb->vaddr[rotation] && reconf) {
>  		fbi->screen_base = NULL;
>  		fix->smem_start = 0;
>  		fix->smem_len = 0;
> -		iounmap(vrfb->vaddr[0]);
> -		vrfb->vaddr[0] = NULL;
> +		iounmap(vrfb->vaddr[rotation]);
> +		vrfb->vaddr[rotation] = NULL;
>  		DBG("setup_vrfb_rotation: reset fb\n");
>  	}
> 
> -	if (vrfb->vaddr[0])
> +	if (vrfb->vaddr[rotation])
>  		return 0;
> 
> -	omap_vrfb_setup(&rg->vrfb, rg->paddr,
> -			var->xres_virtual,
> -			var->yres_virtual,
> -			bytespp, yuv_mode);
> +	if (rotation == FB_ROTATE_CW || rotation == FB_ROTATE_CCW)
> +		omap_vrfb_setup(&rg->vrfb, rg->paddr,
> +				var->yres_virtual, var->xres_virtual,
> +				bytespp, yuv_mode);
> +	else
> +		omap_vrfb_setup(&rg->vrfb, rg->paddr,
> +				var->xres_virtual, var->yres_virtual,
> +				bytespp, yuv_mode);
> 
> -	/* Now one can ioremap the 0 angle view */
> -	r = omap_vrfb_map_angle(vrfb, var->yres_virtual, 0);
> +	/* Now one can ioremap the rotation angle view */
> +	r = omap_vrfb_map_angle(vrfb, var->yres_virtual, rotation);
>  	if (r)
>  		return r;
> -
>  	/* used by open/write in fbmem.c */
> -	fbi->screen_base = ofbi->region.vrfb.vaddr[0];
> +	fbi->screen_base = ofbi->region.vrfb.vaddr[rotation];
> 
> -	fix->smem_start = ofbi->region.vrfb.paddr[0];
> +	fix->smem_start = ofbi->region.vrfb.paddr[rotation];
> 
>  	switch (var->nonstd) {
>  	case OMAPFB_COLOR_YUV422:
> @@ -603,7 +628,8 @@ void set_fb_fix(struct fb_info *fbi)
>  	DBG("set_fb_fix\n");
> 
>  	/* used by open/write in fbmem.c */
> -	fbi->screen_base = (char __iomem *)omapfb_get_region_vaddr(ofbi);
> +	fbi->screen_base = (char __iomem *)omapfb_get_region_vaddr(ofbi,
> +			var->rotate);
> 
>  	/* used by mmap in fbmem.c */
>  	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
> @@ -626,7 +652,7 @@ void set_fb_fix(struct fb_info *fbi)
>  		fix->smem_len = rg->size;
>  	}
> 
> -	fix->smem_start = omapfb_get_region_paddr(ofbi);
> +	fix->smem_start = omapfb_get_region_paddr(ofbi, var->rotate);
> 
>  	fix->type = FB_TYPE_PACKED_PIXELS;
> 
> @@ -862,15 +888,15 @@ static int omapfb_setup_overlay(struct fb_info *fbi,
> struct omap_overlay *ovl,
> 
> 
>  	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
> -		data_start_p = omapfb_get_region_rot_paddr(ofbi, rotation);
> +		data_start_p = omapfb_get_region_rot_paddr(ofbi, 0);
>  		data_start_v = NULL;
>  	} else {
> -		data_start_p = omapfb_get_region_paddr(ofbi);
> -		data_start_v = omapfb_get_region_vaddr(ofbi);
> +		data_start_p = omapfb_get_region_paddr(ofbi, 0);
> +		data_start_v = omapfb_get_region_vaddr(ofbi, 0);
>  	}
> 
>  	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
> -		offset = calc_rotation_offset_vrfb(var, fix, rotation);
> +		offset = calc_rotation_offset_vrfb(var, fix, 0);
>  	else
>  		offset = calc_rotation_offset_dma(var, fix, rotation);
> 
> @@ -1078,6 +1104,7 @@ static struct vm_operations_struct mmap_user_ops = {
>  static int omapfb_mmap(struct fb_info *fbi, struct vm_area_struct *vma)
>  {
>  	struct omapfb_info *ofbi = FB2OFB(fbi);
> +	struct fb_var_screeninfo *var = &fbi->var;
>  	struct fb_fix_screeninfo *fix = &fbi->fix;
>  	unsigned long off;
>  	unsigned long start;
> @@ -1089,7 +1116,7 @@ static int omapfb_mmap(struct fb_info *fbi, struct
> vm_area_struct *vma)
>  		return -EINVAL;
>  	off = vma->vm_pgoff << PAGE_SHIFT;
> 
> -	start = omapfb_get_region_paddr(ofbi);
> +	start = omapfb_get_region_paddr(ofbi, var->rotate);
>  	len = fix->smem_len;
>  	if (off >= len)
>  		return -EINVAL;
> --
> 1.6.2.4

Re: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed

[Tomi Valkeinen]

On Mon, 2010-03-22 at 14:09 +0100, ext hvaibhav@ti.com wrote:
> From: Vaibhav Hiremath <hvaibhav@ti.com>
> 
> In case of 720P with 90/270 degree rotation, the system reports
> GFX_FIFO_UNDERFLOW error which usually happens if DSS DMA is not able to fill
> the FIFO as per requirement.
> 
> In TRM (section 11.2.6.1.3), where is has been clearly mentioned that,
> 
> "To improve the performance on 90 degree rotation, split the data access on
> write side and not read side."
> 
> That means, read should always happen on 0 degree and write should go to
> respective rotation view.

I haven't had time to look at this patch yet. I'll try to do it next
week.

However, I knew that TRM text when I was writing the code. The reason I
chose to use 0 degree view for omapfb and change the view from DSS side
was that it was difficult to handle mmapped areas in this case, if I
recall right. I have to say I don't exactly remember what the problems
were, so I need to read the code and think about this again.

Hmm, perhaps it was so that if you choose to change omapfb's VRFB view,
you can only do that if nothing is mmapped. Which means that either you
can only use one rotation angle defined at boot time, or you need
carefully to remove all mmappings, including fb console, then change the
view and recreate the mapping. And one requirement was that the rotation
should be changeable at runtime, which made the select the current
approach.

 Tomi

RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> Sent: Thursday, April 01, 2010 7:12 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> 
> On Mon, 2010-03-22 at 14:09 +0100, ext hvaibhav@ti.com wrote:
> > From: Vaibhav Hiremath <hvaibhav@ti.com>
> >
> > In case of 720P with 90/270 degree rotation, the system reports
> > GFX_FIFO_UNDERFLOW error which usually happens if DSS DMA is not able to
> fill
> > the FIFO as per requirement.
> >
> > In TRM (section 11.2.6.1.3), where is has been clearly mentioned that,
> >
> > "To improve the performance on 90 degree rotation, split the data access
> on
> > write side and not read side."
> >
> > That means, read should always happen on 0 degree and write should go to
> > respective rotation view.
> 
> I haven't had time to look at this patch yet. I'll try to do it next
> week.
[Hiremath, Vaibhav] Tomi,

Have you had a chance to look at this patch/issue?

Thanks,
Vaibhav

> 
> However, I knew that TRM text when I was writing the code. The reason I
> chose to use 0 degree view for omapfb and change the view from DSS side
> was that it was difficult to handle mmapped areas in this case, if I
> recall right. I have to say I don't exactly remember what the problems
> were, so I need to read the code and think about this again.
> 
> Hmm, perhaps it was so that if you choose to change omapfb's VRFB view,
> you can only do that if nothing is mmapped. Which means that either you
> can only use one rotation angle defined at boot time, or you need
> carefully to remove all mmappings, including fb console, then change the
> view and recreate the mapping. And one requirement was that the rotation
> should be changeable at runtime, which made the select the current
> approach.
> 
>  Tomi
> 

RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed

[Tomi Valkeinen]

On Mon, 2010-04-12 at 13:47 +0200, ext Hiremath, Vaibhav wrote:
> > -----Original Message-----
> > From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> > Sent: Thursday, April 01, 2010 7:12 PM
> > To: Hiremath, Vaibhav
> > Cc: linux-omap@vger.kernel.org
> > Subject: Re: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> > 
> > On Mon, 2010-03-22 at 14:09 +0100, ext hvaibhav@ti.com wrote:
> > > From: Vaibhav Hiremath <hvaibhav@ti.com>
> > >
> > > In case of 720P with 90/270 degree rotation, the system reports
> > > GFX_FIFO_UNDERFLOW error which usually happens if DSS DMA is not able to
> > fill
> > > the FIFO as per requirement.
> > >
> > > In TRM (section 11.2.6.1.3), where is has been clearly mentioned that,
> > >
> > > "To improve the performance on 90 degree rotation, split the data access
> > on
> > > write side and not read side."
> > >
> > > That means, read should always happen on 0 degree and write should go to
> > > respective rotation view.
> > 
> > I haven't had time to look at this patch yet. I'll try to do it next
> > week.
> [Hiremath, Vaibhav] Tomi,
> 
> Have you had a chance to look at this patch/issue?

Sorry, no I haven't. It's on my list. But did you consider my
explanation? Does your implementation support changing the rotation
dynamically?

 Tomi

RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> Sent: Monday, April 12, 2010 5:32 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org
> Subject: RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> 
> On Mon, 2010-04-12 at 13:47 +0200, ext Hiremath, Vaibhav wrote:
> > > -----Original Message-----
> > > From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> > > Sent: Thursday, April 01, 2010 7:12 PM
> > > To: Hiremath, Vaibhav
> > > Cc: linux-omap@vger.kernel.org
> > > Subject: Re: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> > >
> > > On Mon, 2010-03-22 at 14:09 +0100, ext hvaibhav@ti.com wrote:
> > > > From: Vaibhav Hiremath <hvaibhav@ti.com>
> > > >
> > > > In case of 720P with 90/270 degree rotation, the system reports
> > > > GFX_FIFO_UNDERFLOW error which usually happens if DSS DMA is not able
> to
> > > fill
> > > > the FIFO as per requirement.
> > > >
> > > > In TRM (section 11.2.6.1.3), where is has been clearly mentioned that,
> > > >
> > > > "To improve the performance on 90 degree rotation, split the data
> access
> > > on
> > > > write side and not read side."
> > > >
> > > > That means, read should always happen on 0 degree and write should go
> to
> > > > respective rotation view.
> > >
> > > I haven't had time to look at this patch yet. I'll try to do it next
> > > week.
> > [Hiremath, Vaibhav] Tomi,
> >
> > Have you had a chance to look at this patch/issue?
> 
> Sorry, no I haven't. It's on my list. But did you consider my
> explanation? Does your implementation support changing the rotation
> dynamically?
[Hiremath, Vaibhav] Yes, I have validated it here at my end for some rotation angles. Just to clarify more on this, below is the test environment -

	- Enable the rotation through bootargs,

Bootargs: omapfb.rotate=1 omapfb.rotate_type=y vram=10M vram.fb=0:10

	- Boot the system and configure the rotation using FBIOPUT_VSCREENINFO by using var.rotate field.

	- Normal test case which I run -

Var.rotate = 0	(0 degree)
Var.rotate = 1	(90 degree)

Thanks,
Vaibhav

> 
>  Tomi
> 

Re: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed

[Tomi Valkeinen]

On Mon, 2010-03-22 at 14:09 +0100, ext hvaibhav@ti.com wrote:
> From: Vaibhav Hiremath <hvaibhav@ti.com>
> 
> In case of 720P with 90/270 degree rotation, the system reports
> GFX_FIFO_UNDERFLOW error which usually happens if DSS DMA is not able to fill
> the FIFO as per requirement.
> 
> In TRM (section 11.2.6.1.3), where is has been clearly mentioned that,
> 
> "To improve the performance on 90 degree rotation, split the data access on
> write side and not read side."
> 
> That means, read should always happen on 0 degree and write should go to
> respective rotation view.
> 

With this patch my db test app (from
git://gitorious.org/linux-omap-dss2/omapfb-tests.git) shows a lot of
tearing when rotation != 0. I tested this on 3430SDP using the LCD.

 Tomi


> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> ---
>  drivers/video/omap2/omapfb/omapfb-main.c |   85 +++++++++++++++++++----------
>  1 files changed, 56 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
> index 4a76917..fea6b08 100644
> --- a/drivers/video/omap2/omapfb/omapfb-main.c
> +++ b/drivers/video/omap2/omapfb/omapfb-main.c
> @@ -184,6 +184,11 @@ static unsigned omapfb_get_vrfb_offset(const struct omapfb_info *ofbi, int rot)
>  static u32 omapfb_get_region_rot_paddr(const struct omapfb_info *ofbi, int rot)
>  {
>  	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
> +		if (rot == FB_ROTATE_CW)
> +			rot = FB_ROTATE_CCW;
> +		else if (rot == FB_ROTATE_CCW)
> +			rot = FB_ROTATE_CW;
> +
>  		return ofbi->region.vrfb.paddr[rot]
>  			+ omapfb_get_vrfb_offset(ofbi, rot);
>  	} else {
> @@ -191,20 +196,32 @@ static u32 omapfb_get_region_rot_paddr(const struct omapfb_info *ofbi, int rot)
>  	}
>  }
>  
> -static u32 omapfb_get_region_paddr(const struct omapfb_info *ofbi)
> +static u32 omapfb_get_region_paddr(struct omapfb_info *ofbi, int rot)
>  {
> -	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
> -		return ofbi->region.vrfb.paddr[0];
> -	else
> +	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
> +		if (rot == FB_ROTATE_CW)
> +			rot = FB_ROTATE_CCW;
> +		else if (rot == FB_ROTATE_CCW)
> +			rot = FB_ROTATE_CW;
> +
> +		return ofbi->region.vrfb.paddr[rot];
> +	} else {
>  		return ofbi->region.paddr;
> +	}
>  }
>  
> -static void __iomem *omapfb_get_region_vaddr(const struct omapfb_info *ofbi)
> +static void __iomem *omapfb_get_region_vaddr(struct omapfb_info *ofbi, int rot)
>  {
> -	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
> -		return ofbi->region.vrfb.vaddr[0];
> -	else
> +	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
> +		if (rot == FB_ROTATE_CW)
> +			rot = FB_ROTATE_CCW;
> +		else if (rot == FB_ROTATE_CCW)
> +			rot = FB_ROTATE_CW;
> +
> +		return ofbi->region.vrfb.vaddr[rot];
> +	} else {
>  		return ofbi->region.vaddr;
> +	}
>  }
>  
>  static struct omapfb_colormode omapfb_colormodes[] = {
> @@ -503,7 +520,7 @@ static int setup_vrfb_rotation(struct fb_info *fbi)
>  	unsigned bytespp;
>  	bool yuv_mode;
>  	enum omap_color_mode mode;
> -	int r;
> +	int r, rotation = var->rotate;
>  	bool reconf;
>  
>  	if (!rg->size || ofbi->rotation_type != OMAP_DSS_ROT_VRFB)
> @@ -511,6 +528,11 @@ static int setup_vrfb_rotation(struct fb_info *fbi)
>  
>  	DBG("setup_vrfb_rotation\n");
>  
> +	if (rotation == FB_ROTATE_CW)
> +		rotation = FB_ROTATE_CCW;
> +	else if (rotation == FB_ROTATE_CCW)
> +		rotation = FB_ROTATE_CW;
> +
>  	r = fb_mode_to_dss_mode(var, &mode);
>  	if (r)
>  		return r;
> @@ -534,32 +556,35 @@ static int setup_vrfb_rotation(struct fb_info *fbi)
>  			vrfb->yres != var->yres_virtual)
>  		reconf = true;
>  
> -	if (vrfb->vaddr[0] && reconf) {
> +	if (vrfb->vaddr[rotation] && reconf) {
>  		fbi->screen_base = NULL;
>  		fix->smem_start = 0;
>  		fix->smem_len = 0;
> -		iounmap(vrfb->vaddr[0]);
> -		vrfb->vaddr[0] = NULL;
> +		iounmap(vrfb->vaddr[rotation]);
> +		vrfb->vaddr[rotation] = NULL;
>  		DBG("setup_vrfb_rotation: reset fb\n");
>  	}
>  
> -	if (vrfb->vaddr[0])
> +	if (vrfb->vaddr[rotation])
>  		return 0;
>  
> -	omap_vrfb_setup(&rg->vrfb, rg->paddr,
> -			var->xres_virtual,
> -			var->yres_virtual,
> -			bytespp, yuv_mode);
> +	if (rotation == FB_ROTATE_CW || rotation == FB_ROTATE_CCW)
> +		omap_vrfb_setup(&rg->vrfb, rg->paddr,
> +				var->yres_virtual, var->xres_virtual,
> +				bytespp, yuv_mode);
> +	else
> +		omap_vrfb_setup(&rg->vrfb, rg->paddr,
> +				var->xres_virtual, var->yres_virtual,
> +				bytespp, yuv_mode);
>  
> -	/* Now one can ioremap the 0 angle view */
> -	r = omap_vrfb_map_angle(vrfb, var->yres_virtual, 0);
> +	/* Now one can ioremap the rotation angle view */
> +	r = omap_vrfb_map_angle(vrfb, var->yres_virtual, rotation);
>  	if (r)
>  		return r;
> -
>  	/* used by open/write in fbmem.c */
> -	fbi->screen_base = ofbi->region.vrfb.vaddr[0];
> +	fbi->screen_base = ofbi->region.vrfb.vaddr[rotation];
>  
> -	fix->smem_start = ofbi->region.vrfb.paddr[0];
> +	fix->smem_start = ofbi->region.vrfb.paddr[rotation];
>  
>  	switch (var->nonstd) {
>  	case OMAPFB_COLOR_YUV422:
> @@ -603,7 +628,8 @@ void set_fb_fix(struct fb_info *fbi)
>  	DBG("set_fb_fix\n");
>  
>  	/* used by open/write in fbmem.c */
> -	fbi->screen_base = (char __iomem *)omapfb_get_region_vaddr(ofbi);
> +	fbi->screen_base = (char __iomem *)omapfb_get_region_vaddr(ofbi,
> +			var->rotate);
>  
>  	/* used by mmap in fbmem.c */
>  	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
> @@ -626,7 +652,7 @@ void set_fb_fix(struct fb_info *fbi)
>  		fix->smem_len = rg->size;
>  	}
>  
> -	fix->smem_start = omapfb_get_region_paddr(ofbi);
> +	fix->smem_start = omapfb_get_region_paddr(ofbi, var->rotate);
>  
>  	fix->type = FB_TYPE_PACKED_PIXELS;
>  
> @@ -862,15 +888,15 @@ static int omapfb_setup_overlay(struct fb_info *fbi, struct omap_overlay *ovl,
>  
> 
>  	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
> -		data_start_p = omapfb_get_region_rot_paddr(ofbi, rotation);
> +		data_start_p = omapfb_get_region_rot_paddr(ofbi, 0);
>  		data_start_v = NULL;
>  	} else {
> -		data_start_p = omapfb_get_region_paddr(ofbi);
> -		data_start_v = omapfb_get_region_vaddr(ofbi);
> +		data_start_p = omapfb_get_region_paddr(ofbi, 0);
> +		data_start_v = omapfb_get_region_vaddr(ofbi, 0);
>  	}
>  
>  	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
> -		offset = calc_rotation_offset_vrfb(var, fix, rotation);
> +		offset = calc_rotation_offset_vrfb(var, fix, 0);
>  	else
>  		offset = calc_rotation_offset_dma(var, fix, rotation);
>  
> @@ -1078,6 +1104,7 @@ static struct vm_operations_struct mmap_user_ops = {
>  static int omapfb_mmap(struct fb_info *fbi, struct vm_area_struct *vma)
>  {
>  	struct omapfb_info *ofbi = FB2OFB(fbi);
> +	struct fb_var_screeninfo *var = &fbi->var;
>  	struct fb_fix_screeninfo *fix = &fbi->fix;
>  	unsigned long off;
>  	unsigned long start;
> @@ -1089,7 +1116,7 @@ static int omapfb_mmap(struct fb_info *fbi, struct vm_area_struct *vma)
>  		return -EINVAL;
>  	off = vma->vm_pgoff << PAGE_SHIFT;
>  
> -	start = omapfb_get_region_paddr(ofbi);
> +	start = omapfb_get_region_paddr(ofbi, var->rotate);
>  	len = fix->smem_len;
>  	if (off >= len)
>  		return -EINVAL;

RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> Sent: Friday, April 16, 2010 3:08 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org
> Subject: Re: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> 
> On Mon, 2010-03-22 at 14:09 +0100, ext hvaibhav@ti.com wrote:
> > From: Vaibhav Hiremath <hvaibhav@ti.com>
> >
> > In case of 720P with 90/270 degree rotation, the system reports
> > GFX_FIFO_UNDERFLOW error which usually happens if DSS DMA is not able to
> fill
> > the FIFO as per requirement.
> >
> > In TRM (section 11.2.6.1.3), where is has been clearly mentioned that,
> >
> > "To improve the performance on 90 degree rotation, split the data access
> on
> > write side and not read side."
> >
> > That means, read should always happen on 0 degree and write should go to
> > respective rotation view.
> >
> 
> With this patch my db test app (from
> git://gitorious.org/linux-omap-dss2/omapfb-tests.git) shows a lot of
> tearing when rotation != 0. I tested this on 3430SDP using the LCD.
> 
[Hiremath, Vaibhav] I had tested it with the sample application which draws color bars to the frame-buffer, let me once again check with your (omapfb-test) application.

Tomi,
I am going out of station so will be able to do this on Tuesday. 

Thanks,
Vaibhav

>  Tomi
> 
> 
> > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > ---
> >  drivers/video/omap2/omapfb/omapfb-main.c |   85 +++++++++++++++++++------
> ----
> >  1 files changed, 56 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/video/omap2/omapfb/omapfb-main.c
> b/drivers/video/omap2/omapfb/omapfb-main.c
> > index 4a76917..fea6b08 100644
> > --- a/drivers/video/omap2/omapfb/omapfb-main.c
> > +++ b/drivers/video/omap2/omapfb/omapfb-main.c
> > @@ -184,6 +184,11 @@ static unsigned omapfb_get_vrfb_offset(const struct
> omapfb_info *ofbi, int rot)
> >  static u32 omapfb_get_region_rot_paddr(const struct omapfb_info *ofbi,
> int rot)
> >  {
> >  	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
> > +		if (rot == FB_ROTATE_CW)
> > +			rot = FB_ROTATE_CCW;
> > +		else if (rot == FB_ROTATE_CCW)
> > +			rot = FB_ROTATE_CW;
> > +
> >  		return ofbi->region.vrfb.paddr[rot]
> >  			+ omapfb_get_vrfb_offset(ofbi, rot);
> >  	} else {
> > @@ -191,20 +196,32 @@ static u32 omapfb_get_region_rot_paddr(const struct
> omapfb_info *ofbi, int rot)
> >  	}
> >  }
> >
> > -static u32 omapfb_get_region_paddr(const struct omapfb_info *ofbi)
> > +static u32 omapfb_get_region_paddr(struct omapfb_info *ofbi, int rot)
> >  {
> > -	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
> > -		return ofbi->region.vrfb.paddr[0];
> > -	else
> > +	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
> > +		if (rot == FB_ROTATE_CW)
> > +			rot = FB_ROTATE_CCW;
> > +		else if (rot == FB_ROTATE_CCW)
> > +			rot = FB_ROTATE_CW;
> > +
> > +		return ofbi->region.vrfb.paddr[rot];
> > +	} else {
> >  		return ofbi->region.paddr;
> > +	}
> >  }
> >
> > -static void __iomem *omapfb_get_region_vaddr(const struct omapfb_info
> *ofbi)
> > +static void __iomem *omapfb_get_region_vaddr(struct omapfb_info *ofbi,
> int rot)
> >  {
> > -	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
> > -		return ofbi->region.vrfb.vaddr[0];
> > -	else
> > +	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
> > +		if (rot == FB_ROTATE_CW)
> > +			rot = FB_ROTATE_CCW;
> > +		else if (rot == FB_ROTATE_CCW)
> > +			rot = FB_ROTATE_CW;
> > +
> > +		return ofbi->region.vrfb.vaddr[rot];
> > +	} else {
> >  		return ofbi->region.vaddr;
> > +	}
> >  }
> >
> >  static struct omapfb_colormode omapfb_colormodes[] = {
> > @@ -503,7 +520,7 @@ static int setup_vrfb_rotation(struct fb_info *fbi)
> >  	unsigned bytespp;
> >  	bool yuv_mode;
> >  	enum omap_color_mode mode;
> > -	int r;
> > +	int r, rotation = var->rotate;
> >  	bool reconf;
> >
> >  	if (!rg->size || ofbi->rotation_type != OMAP_DSS_ROT_VRFB)
> > @@ -511,6 +528,11 @@ static int setup_vrfb_rotation(struct fb_info *fbi)
> >
> >  	DBG("setup_vrfb_rotation\n");
> >
> > +	if (rotation == FB_ROTATE_CW)
> > +		rotation = FB_ROTATE_CCW;
> > +	else if (rotation == FB_ROTATE_CCW)
> > +		rotation = FB_ROTATE_CW;
> > +
> >  	r = fb_mode_to_dss_mode(var, &mode);
> >  	if (r)
> >  		return r;
> > @@ -534,32 +556,35 @@ static int setup_vrfb_rotation(struct fb_info *fbi)
> >  			vrfb->yres != var->yres_virtual)
> >  		reconf = true;
> >
> > -	if (vrfb->vaddr[0] && reconf) {
> > +	if (vrfb->vaddr[rotation] && reconf) {
> >  		fbi->screen_base = NULL;
> >  		fix->smem_start = 0;
> >  		fix->smem_len = 0;
> > -		iounmap(vrfb->vaddr[0]);
> > -		vrfb->vaddr[0] = NULL;
> > +		iounmap(vrfb->vaddr[rotation]);
> > +		vrfb->vaddr[rotation] = NULL;
> >  		DBG("setup_vrfb_rotation: reset fb\n");
> >  	}
> >
> > -	if (vrfb->vaddr[0])
> > +	if (vrfb->vaddr[rotation])
> >  		return 0;
> >
> > -	omap_vrfb_setup(&rg->vrfb, rg->paddr,
> > -			var->xres_virtual,
> > -			var->yres_virtual,
> > -			bytespp, yuv_mode);
> > +	if (rotation == FB_ROTATE_CW || rotation == FB_ROTATE_CCW)
> > +		omap_vrfb_setup(&rg->vrfb, rg->paddr,
> > +				var->yres_virtual, var->xres_virtual,
> > +				bytespp, yuv_mode);
> > +	else
> > +		omap_vrfb_setup(&rg->vrfb, rg->paddr,
> > +				var->xres_virtual, var->yres_virtual,
> > +				bytespp, yuv_mode);
> >
> > -	/* Now one can ioremap the 0 angle view */
> > -	r = omap_vrfb_map_angle(vrfb, var->yres_virtual, 0);
> > +	/* Now one can ioremap the rotation angle view */
> > +	r = omap_vrfb_map_angle(vrfb, var->yres_virtual, rotation);
> >  	if (r)
> >  		return r;
> > -
> >  	/* used by open/write in fbmem.c */
> > -	fbi->screen_base = ofbi->region.vrfb.vaddr[0];
> > +	fbi->screen_base = ofbi->region.vrfb.vaddr[rotation];
> >
> > -	fix->smem_start = ofbi->region.vrfb.paddr[0];
> > +	fix->smem_start = ofbi->region.vrfb.paddr[rotation];
> >
> >  	switch (var->nonstd) {
> >  	case OMAPFB_COLOR_YUV422:
> > @@ -603,7 +628,8 @@ void set_fb_fix(struct fb_info *fbi)
> >  	DBG("set_fb_fix\n");
> >
> >  	/* used by open/write in fbmem.c */
> > -	fbi->screen_base = (char __iomem *)omapfb_get_region_vaddr(ofbi);
> > +	fbi->screen_base = (char __iomem *)omapfb_get_region_vaddr(ofbi,
> > +			var->rotate);
> >
> >  	/* used by mmap in fbmem.c */
> >  	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
> > @@ -626,7 +652,7 @@ void set_fb_fix(struct fb_info *fbi)
> >  		fix->smem_len = rg->size;
> >  	}
> >
> > -	fix->smem_start = omapfb_get_region_paddr(ofbi);
> > +	fix->smem_start = omapfb_get_region_paddr(ofbi, var->rotate);
> >
> >  	fix->type = FB_TYPE_PACKED_PIXELS;
> >
> > @@ -862,15 +888,15 @@ static int omapfb_setup_overlay(struct fb_info *fbi,
> struct omap_overlay *ovl,
> >
> >
> >  	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
> > -		data_start_p = omapfb_get_region_rot_paddr(ofbi, rotation);
> > +		data_start_p = omapfb_get_region_rot_paddr(ofbi, 0);
> >  		data_start_v = NULL;
> >  	} else {
> > -		data_start_p = omapfb_get_region_paddr(ofbi);
> > -		data_start_v = omapfb_get_region_vaddr(ofbi);
> > +		data_start_p = omapfb_get_region_paddr(ofbi, 0);
> > +		data_start_v = omapfb_get_region_vaddr(ofbi, 0);
> >  	}
> >
> >  	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
> > -		offset = calc_rotation_offset_vrfb(var, fix, rotation);
> > +		offset = calc_rotation_offset_vrfb(var, fix, 0);
> >  	else
> >  		offset = calc_rotation_offset_dma(var, fix, rotation);
> >
> > @@ -1078,6 +1104,7 @@ static struct vm_operations_struct mmap_user_ops = {
> >  static int omapfb_mmap(struct fb_info *fbi, struct vm_area_struct *vma)
> >  {
> >  	struct omapfb_info *ofbi = FB2OFB(fbi);
> > +	struct fb_var_screeninfo *var = &fbi->var;
> >  	struct fb_fix_screeninfo *fix = &fbi->fix;
> >  	unsigned long off;
> >  	unsigned long start;
> > @@ -1089,7 +1116,7 @@ static int omapfb_mmap(struct fb_info *fbi, struct
> vm_area_struct *vma)
> >  		return -EINVAL;
> >  	off = vma->vm_pgoff << PAGE_SHIFT;
> >
> > -	start = omapfb_get_region_paddr(ofbi);
> > +	start = omapfb_get_region_paddr(ofbi, var->rotate);
> >  	len = fix->smem_len;
> >  	if (off >= len)
> >  		return -EINVAL;
> 

RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed

[Hiremath, Vaibhav]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Hiremath, Vaibhav
> Sent: Friday, April 16, 2010 4:28 PM
> To: Tomi Valkeinen
> Cc: linux-omap@vger.kernel.org
> Subject: RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> 
> 
> > -----Original Message-----
> > From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> > Sent: Friday, April 16, 2010 3:08 PM
> > To: Hiremath, Vaibhav
> > Cc: linux-omap@vger.kernel.org
> > Subject: Re: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> >
> > On Mon, 2010-03-22 at 14:09 +0100, ext hvaibhav@ti.com wrote:
> > > From: Vaibhav Hiremath <hvaibhav@ti.com>
> > >
> > > In case of 720P with 90/270 degree rotation, the system reports
> > > GFX_FIFO_UNDERFLOW error which usually happens if DSS DMA is not able to
> > fill
> > > the FIFO as per requirement.
> > >
> > > In TRM (section 11.2.6.1.3), where is has been clearly mentioned that,
> > >
> > > "To improve the performance on 90 degree rotation, split the data access
> > on
> > > write side and not read side."
> > >
> > > That means, read should always happen on 0 degree and write should go to
> > > respective rotation view.
> > >
> >
> > With this patch my db test app (from
> > git://gitorious.org/linux-omap-dss2/omapfb-tests.git) shows a lot of
> > tearing when rotation != 0. I tested this on 3430SDP using the LCD.
[Hiremath, Vaibhav] Tomi,

Yes, just now I tried your db application and I am also seeing tearing effect. All other apps (including the one which I used for testing) works fine for other rotation angles.

Let me debug further before commenting anything on this, I just thought of updating you on this.

Thanks,
Vaibhav

> >
> [Hiremath, Vaibhav] I had tested it with the sample application which draws
> color bars to the frame-buffer, let me once again check with your (omapfb-
> test) application.
> 
> Tomi,
> I am going out of station so will be able to do this on Tuesday.
> 
> Thanks,
> Vaibhav
> 
> >  Tomi
> >
> >
<snip>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed

[Tomi Valkeinen]

On Wed, 2010-04-21 at 12:45 +0200, ext Hiremath, Vaibhav wrote:
> > -----Original Message-----
> > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > owner@vger.kernel.org] On Behalf Of Hiremath, Vaibhav
> > Sent: Friday, April 16, 2010 4:28 PM
> > To: Tomi Valkeinen
> > Cc: linux-omap@vger.kernel.org
> > Subject: RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> > 
> > 
> > > -----Original Message-----
> > > From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> > > Sent: Friday, April 16, 2010 3:08 PM
> > > To: Hiremath, Vaibhav
> > > Cc: linux-omap@vger.kernel.org
> > > Subject: Re: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> > >
> > > On Mon, 2010-03-22 at 14:09 +0100, ext hvaibhav@ti.com wrote:
> > > > From: Vaibhav Hiremath <hvaibhav@ti.com>
> > > >
> > > > In case of 720P with 90/270 degree rotation, the system reports
> > > > GFX_FIFO_UNDERFLOW error which usually happens if DSS DMA is not able to
> > > fill
> > > > the FIFO as per requirement.
> > > >
> > > > In TRM (section 11.2.6.1.3), where is has been clearly mentioned that,
> > > >
> > > > "To improve the performance on 90 degree rotation, split the data access
> > > on
> > > > write side and not read side."
> > > >
> > > > That means, read should always happen on 0 degree and write should go to
> > > > respective rotation view.
> > > >
> > >
> > > With this patch my db test app (from
> > > git://gitorious.org/linux-omap-dss2/omapfb-tests.git) shows a lot of
> > > tearing when rotation != 0. I tested this on 3430SDP using the LCD.
> [Hiremath, Vaibhav] Tomi,
> 
> Yes, just now I tried your db application and I am also seeing tearing effect. All other apps (including the one which I used for testing) works fine for other rotation angles.
> 
> Let me debug further before commenting anything on this, I just thought of updating you on this.

"db" app uses double buffering for updating the display, with maximum
update rate. There's also "pan" app, that does a bit similar thing using
fb offsets.

What kind of test apps you have?

 Tomi

RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> Sent: Wednesday, April 21, 2010 4:40 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org
> Subject: RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> 
> On Wed, 2010-04-21 at 12:45 +0200, ext Hiremath, Vaibhav wrote:
> > > -----Original Message-----
> > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > > owner@vger.kernel.org] On Behalf Of Hiremath, Vaibhav
> > > Sent: Friday, April 16, 2010 4:28 PM
> > > To: Tomi Valkeinen
> > > Cc: linux-omap@vger.kernel.org
> > > Subject: RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> > >
> > >
> > > > -----Original Message-----
> > > > From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> > > > Sent: Friday, April 16, 2010 3:08 PM
> > > > To: Hiremath, Vaibhav
> > > > Cc: linux-omap@vger.kernel.org
> > > > Subject: Re: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> > > >
> > > > On Mon, 2010-03-22 at 14:09 +0100, ext hvaibhav@ti.com wrote:
> > > > > From: Vaibhav Hiremath <hvaibhav@ti.com>
> > > > >
> > > > > In case of 720P with 90/270 degree rotation, the system reports
> > > > > GFX_FIFO_UNDERFLOW error which usually happens if DSS DMA is not
> able to
> > > > fill
> > > > > the FIFO as per requirement.
> > > > >
> > > > > In TRM (section 11.2.6.1.3), where is has been clearly mentioned
> that,
> > > > >
> > > > > "To improve the performance on 90 degree rotation, split the data
> access
> > > > on
> > > > > write side and not read side."
> > > > >
> > > > > That means, read should always happen on 0 degree and write should
> go to
> > > > > respective rotation view.
> > > > >
> > > >
> > > > With this patch my db test app (from
> > > > git://gitorious.org/linux-omap-dss2/omapfb-tests.git) shows a lot of
> > > > tearing when rotation != 0. I tested this on 3430SDP using the LCD.
> > [Hiremath, Vaibhav] Tomi,
> >
> > Yes, just now I tried your db application and I am also seeing tearing
> effect. All other apps (including the one which I used for testing) works
> fine for other rotation angles.
> >
> > Let me debug further before commenting anything on this, I just thought of
> updating you on this.
> 
> "db" app uses double buffering for updating the display, with maximum
> update rate. There's also "pan" app, that does a bit similar thing using
> fb offsets.
[Hiremath, Vaibhav] Sorry, was not at my desk. 

Tomi,
pan application works fine. The only issue I have seen is with db application.

> 
> What kind of test apps you have?
[Hiremath, Vaibhav] I have similar application which does panning using offset, it draws color bar pattern with giver rotation angle and keep on scrolling in 0,0 to max,max direction.

Thanks,
Vaibhav

> 
>  Tomi
> 

RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> Sent: Wednesday, April 21, 2010 4:40 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org
> Subject: RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> 
> On Wed, 2010-04-21 at 12:45 +0200, ext Hiremath, Vaibhav wrote:
> > > -----Original Message-----
> > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > > owner@vger.kernel.org] On Behalf Of Hiremath, Vaibhav
> > > Sent: Friday, April 16, 2010 4:28 PM
> > > To: Tomi Valkeinen
> > > Cc: linux-omap@vger.kernel.org
> > > Subject: RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> > >
> > >
> > > > -----Original Message-----
> > > > From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> > > > Sent: Friday, April 16, 2010 3:08 PM
> > > > To: Hiremath, Vaibhav
> > > > Cc: linux-omap@vger.kernel.org
> > > > Subject: Re: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> > > >
> > > > On Mon, 2010-03-22 at 14:09 +0100, ext hvaibhav@ti.com wrote:
> > > > > From: Vaibhav Hiremath <hvaibhav@ti.com>
> > > > >
> > > > > In case of 720P with 90/270 degree rotation, the system reports
> > > > > GFX_FIFO_UNDERFLOW error which usually happens if DSS DMA is not
> able to
> > > > fill
> > > > > the FIFO as per requirement.
> > > > >
> > > > > In TRM (section 11.2.6.1.3), where is has been clearly mentioned
> that,
> > > > >
> > > > > "To improve the performance on 90 degree rotation, split the data
> access
> > > > on
> > > > > write side and not read side."
> > > > >
> > > > > That means, read should always happen on 0 degree and write should
> go to
> > > > > respective rotation view.
> > > > >
> > > >
> > > > With this patch my db test app (from
> > > > git://gitorious.org/linux-omap-dss2/omapfb-tests.git) shows a lot of
> > > > tearing when rotation != 0. I tested this on 3430SDP using the LCD.
> > [Hiremath, Vaibhav] Tomi,
> >
> > Yes, just now I tried your db application and I am also seeing tearing
> effect. All other apps (including the one which I used for testing) works
> fine for other rotation angles.
> >
> > Let me debug further before commenting anything on this, I just thought of
> updating you on this.
> 
> "db" app uses double buffering for updating the display, with maximum
> update rate. There's also "pan" app, that does a bit similar thing using
> fb offsets.
> 
> What kind of test apps you have?
> 
>  Tomi
> 
[Hiremath, Vaibhav] Just thought of updating you,

I had a good review of the db.c code and I don't see any issues with this, so somewhere VRFB related issue which I am missing.
The only difference between db.c and pan.c (also my applications), it doesn't write/fill the entire buffer in pan loop everytime, whereas db.c file does.

I think I need to take a look at the patch and TRM once again for this issue.

Thanks,
Vaibhav

RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed

[Hiremath, Vaibhav]

[-- Attachment #1: Type: text/plain, Size: 2750 bytes --]


> -----Original Message-----
> From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> Sent: Wednesday, April 21, 2010 4:40 PM
> To: Hiremath, Vaibhav
> Cc: linux-omap@vger.kernel.org
> Subject: RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> 
> On Wed, 2010-04-21 at 12:45 +0200, ext Hiremath, Vaibhav wrote:
> > > -----Original Message-----
> > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > > owner@vger.kernel.org] On Behalf Of Hiremath, Vaibhav
> > > Sent: Friday, April 16, 2010 4:28 PM
> > > To: Tomi Valkeinen
> > > Cc: linux-omap@vger.kernel.org
> > > Subject: RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> > >
> > >
> > > > -----Original Message-----
> > > > From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> > > > Sent: Friday, April 16, 2010 3:08 PM
> > > > To: Hiremath, Vaibhav
> > > > Cc: linux-omap@vger.kernel.org
> > > > Subject: Re: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> > > >
> > > > On Mon, 2010-03-22 at 14:09 +0100, ext hvaibhav@ti.com wrote:
> > > > > From: Vaibhav Hiremath <hvaibhav@ti.com>
> > > > >
> > > > > In case of 720P with 90/270 degree rotation, the system reports
> > > > > GFX_FIFO_UNDERFLOW error which usually happens if DSS DMA is not
> able to
> > > > fill
> > > > > the FIFO as per requirement.
> > > > >
> > > > > In TRM (section 11.2.6.1.3), where is has been clearly mentioned
> that,
> > > > >
> > > > > "To improve the performance on 90 degree rotation, split the data
> access
> > > > on
> > > > > write side and not read side."
> > > > >
> > > > > That means, read should always happen on 0 degree and write should
> go to
> > > > > respective rotation view.
> > > > >
> > > >
> > > > With this patch my db test app (from
> > > > git://gitorious.org/linux-omap-dss2/omapfb-tests.git) shows a lot of
> > > > tearing when rotation != 0. I tested this on 3430SDP using the LCD.
> > [Hiremath, Vaibhav] Tomi,
> >
> > Yes, just now I tried your db application and I am also seeing tearing
> effect. All other apps (including the one which I used for testing) works
> fine for other rotation angles.
> >
> > Let me debug further before commenting anything on this, I just thought of
> updating you on this.
> 
> "db" app uses double buffering for updating the display, with maximum
> update rate. There's also "pan" app, that does a bit similar thing using
> fb offsets.
[Hiremath, Vaibhav] Tomi,

I found the bug which is causing tearing effect, I tested it here with both, mine and your applications and for me it is working fine.

Can you please check at your end?
(Sorry for the attachment)

Thanks,
Vaibhav

> 
> What kind of test apps you have?
> 
>  Tomi
> 


[-- Attachment #2: 0001-OMAP-DSS2-GFX-FIFO-UNDERFLOW-issue-fixed.patch --]
[-- Type: application/octet-stream, Size: 6503 bytes --]

From 1997555ab5bf2c8c8f88b75047bf666004a6c86a Mon Sep 17 00:00:00 2001
From: Vaibhav Hiremath <hvaibhav@ti.com>
Date: Mon, 22 Mar 2010 13:35:18 +0530
Subject: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed

In case of 720P with 90/270 degree rotation, the system reports
GFX_FIFO_UNDERFLOW error which usually happens if DSS DMA is not able to fill
the FIFO as per requirement.

In TRM (section 11.2.6.1.3), where is has been clearly mentioned that,

"To improve the performance on 90 degree rotation, split the data access on
write side and not read side."

That means, read should always happen on 0 degree and write should go to
respective rotation view.

Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
---
 drivers/video/omap2/omapfb/omapfb-main.c |   83 ++++++++++++++++++++----------
 1 files changed, 55 insertions(+), 28 deletions(-)

diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 4b4506d..9bfdd1e 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -185,6 +185,11 @@ static unsigned omapfb_get_vrfb_offset(const struct omapfb_info *ofbi, int rot)
 static u32 omapfb_get_region_rot_paddr(const struct omapfb_info *ofbi, int rot)
 {
 	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
+		if (rot == FB_ROTATE_CW)
+			rot = FB_ROTATE_CCW;
+		else if (rot == FB_ROTATE_CCW)
+			rot = FB_ROTATE_CW;
+
 		return ofbi->region.vrfb.paddr[rot]
 			+ omapfb_get_vrfb_offset(ofbi, rot);
 	} else {
@@ -192,20 +197,32 @@ static u32 omapfb_get_region_rot_paddr(const struct omapfb_info *ofbi, int rot)
 	}
 }
 
-static u32 omapfb_get_region_paddr(const struct omapfb_info *ofbi)
+static u32 omapfb_get_region_paddr(struct omapfb_info *ofbi, int rot)
 {
-	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
-		return ofbi->region.vrfb.paddr[0];
-	else
+	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
+		if (rot == FB_ROTATE_CW)
+			rot = FB_ROTATE_CCW;
+		else if (rot == FB_ROTATE_CCW)
+			rot = FB_ROTATE_CW;
+
+		return ofbi->region.vrfb.paddr[rot];
+	} else {
 		return ofbi->region.paddr;
+	}
 }
 
-static void __iomem *omapfb_get_region_vaddr(const struct omapfb_info *ofbi)
+static void __iomem *omapfb_get_region_vaddr(struct omapfb_info *ofbi, int rot)
 {
-	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
-		return ofbi->region.vrfb.vaddr[0];
-	else
+	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
+		if (rot == FB_ROTATE_CW)
+			rot = FB_ROTATE_CCW;
+		else if (rot == FB_ROTATE_CCW)
+			rot = FB_ROTATE_CW;
+
+		return ofbi->region.vrfb.vaddr[rot];
+	} else {
 		return ofbi->region.vaddr;
+	}
 }
 
 static struct omapfb_colormode omapfb_colormodes[] = {
@@ -504,7 +521,7 @@ static int setup_vrfb_rotation(struct fb_info *fbi)
 	unsigned bytespp;
 	bool yuv_mode;
 	enum omap_color_mode mode;
-	int r;
+	int r, rotation = var->rotate;
 	bool reconf;
 
 	if (!rg->size || ofbi->rotation_type != OMAP_DSS_ROT_VRFB)
@@ -512,6 +529,11 @@ static int setup_vrfb_rotation(struct fb_info *fbi)
 
 	DBG("setup_vrfb_rotation\n");
 
+	if (rotation == FB_ROTATE_CW)
+		rotation = FB_ROTATE_CCW;
+	else if (rotation == FB_ROTATE_CCW)
+		rotation = FB_ROTATE_CW;
+
 	r = fb_mode_to_dss_mode(var, &mode);
 	if (r)
 		return r;
@@ -535,32 +557,35 @@ static int setup_vrfb_rotation(struct fb_info *fbi)
 			vrfb->yres != var->yres_virtual)
 		reconf = true;
 
-	if (vrfb->vaddr[0] && reconf) {
+	if (vrfb->vaddr[rotation] && reconf) {
 		fbi->screen_base = NULL;
 		fix->smem_start = 0;
 		fix->smem_len = 0;
-		iounmap(vrfb->vaddr[0]);
-		vrfb->vaddr[0] = NULL;
+		iounmap(vrfb->vaddr[rotation]);
+		vrfb->vaddr[rotation] = NULL;
 		DBG("setup_vrfb_rotation: reset fb\n");
 	}
 
-	if (vrfb->vaddr[0])
+	if (vrfb->vaddr[rotation])
 		return 0;
 
-	omap_vrfb_setup(&rg->vrfb, rg->paddr,
-			var->xres_virtual,
-			var->yres_virtual,
-			bytespp, yuv_mode);
+	if (rotation == FB_ROTATE_CW || rotation == FB_ROTATE_CCW)
+		omap_vrfb_setup(&rg->vrfb, rg->paddr,
+				var->yres_virtual, var->xres_virtual,
+				bytespp, yuv_mode);
+	else
+		omap_vrfb_setup(&rg->vrfb, rg->paddr,
+				var->xres_virtual, var->yres_virtual,
+				bytespp, yuv_mode);
 
-	/* Now one can ioremap the 0 angle view */
-	r = omap_vrfb_map_angle(vrfb, var->yres_virtual, 0);
+	/* Now one can ioremap the rotation angle view */
+	r = omap_vrfb_map_angle(vrfb, var->yres_virtual, rotation);
 	if (r)
 		return r;
-
 	/* used by open/write in fbmem.c */
-	fbi->screen_base = ofbi->region.vrfb.vaddr[0];
+	fbi->screen_base = ofbi->region.vrfb.vaddr[rotation];
 
-	fix->smem_start = ofbi->region.vrfb.paddr[0];
+	fix->smem_start = ofbi->region.vrfb.paddr[rotation];
 
 	switch (var->nonstd) {
 	case OMAPFB_COLOR_YUV422:
@@ -604,7 +629,8 @@ void set_fb_fix(struct fb_info *fbi)
 	DBG("set_fb_fix\n");
 
 	/* used by open/write in fbmem.c */
-	fbi->screen_base = (char __iomem *)omapfb_get_region_vaddr(ofbi);
+	fbi->screen_base = (char __iomem *)omapfb_get_region_vaddr(ofbi,
+			var->rotate);
 
 	/* used by mmap in fbmem.c */
 	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
@@ -627,7 +653,7 @@ void set_fb_fix(struct fb_info *fbi)
 		fix->smem_len = rg->size;
 	}
 
-	fix->smem_start = omapfb_get_region_paddr(ofbi);
+	fix->smem_start = omapfb_get_region_paddr(ofbi, var->rotate);
 
 	fix->type = FB_TYPE_PACKED_PIXELS;
 
@@ -863,11 +889,11 @@ static int omapfb_setup_overlay(struct fb_info *fbi, struct omap_overlay *ovl,
 
 
 	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB) {
-		data_start_p = omapfb_get_region_rot_paddr(ofbi, rotation);
+		data_start_p = omapfb_get_region_rot_paddr(ofbi, 0);
 		data_start_v = NULL;
 	} else {
-		data_start_p = omapfb_get_region_paddr(ofbi);
-		data_start_v = omapfb_get_region_vaddr(ofbi);
+		data_start_p = omapfb_get_region_paddr(ofbi, 0);
+		data_start_v = omapfb_get_region_vaddr(ofbi, 0);
 	}
 
 	if (ofbi->rotation_type == OMAP_DSS_ROT_VRFB)
@@ -1079,6 +1105,7 @@ static struct vm_operations_struct mmap_user_ops = {
 static int omapfb_mmap(struct fb_info *fbi, struct vm_area_struct *vma)
 {
 	struct omapfb_info *ofbi = FB2OFB(fbi);
+	struct fb_var_screeninfo *var = &fbi->var;
 	struct fb_fix_screeninfo *fix = &fbi->fix;
 	unsigned long off;
 	unsigned long start;
@@ -1090,7 +1117,7 @@ static int omapfb_mmap(struct fb_info *fbi, struct vm_area_struct *vma)
 		return -EINVAL;
 	off = vma->vm_pgoff << PAGE_SHIFT;
 
-	start = omapfb_get_region_paddr(ofbi);
+	start = omapfb_get_region_paddr(ofbi, var->rotate);
 	len = fix->smem_len;
 	if (off >= len)
 		return -EINVAL;
-- 
1.6.2.4

Re: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed

[Ville Syrjälä]

On Tue, May 04, 2010 at 03:23:10PM +0200, ext Hiremath, Vaibhav wrote:
> 
> > -----Original Message-----
> > From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> > Sent: Wednesday, April 21, 2010 4:40 PM
> > To: Hiremath, Vaibhav
> > Cc: linux-omap@vger.kernel.org
> > Subject: RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> > 
> > On Wed, 2010-04-21 at 12:45 +0200, ext Hiremath, Vaibhav wrote:
> > > > -----Original Message-----
> > > > From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> > > > owner@vger.kernel.org] On Behalf Of Hiremath, Vaibhav
> > > > Sent: Friday, April 16, 2010 4:28 PM
> > > > To: Tomi Valkeinen
> > > > Cc: linux-omap@vger.kernel.org
> > > > Subject: RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Tomi Valkeinen [mailto:tomi.valkeinen@nokia.com]
> > > > > Sent: Friday, April 16, 2010 3:08 PM
> > > > > To: Hiremath, Vaibhav
> > > > > Cc: linux-omap@vger.kernel.org
> > > > > Subject: Re: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> > > > >
> > > > > On Mon, 2010-03-22 at 14:09 +0100, ext hvaibhav@ti.com wrote:
> > > > > > From: Vaibhav Hiremath <hvaibhav@ti.com>
> > > > > >
> > > > > > In case of 720P with 90/270 degree rotation, the system reports
> > > > > > GFX_FIFO_UNDERFLOW error which usually happens if DSS DMA is not
> > able to
> > > > > fill
> > > > > > the FIFO as per requirement.
> > > > > >
> > > > > > In TRM (section 11.2.6.1.3), where is has been clearly mentioned
> > that,
> > > > > >
> > > > > > "To improve the performance on 90 degree rotation, split the data
> > access
> > > > > on
> > > > > > write side and not read side."
> > > > > >
> > > > > > That means, read should always happen on 0 degree and write should
> > go to
> > > > > > respective rotation view.
> > > > > >
> > > > >
> > > > > With this patch my db test app (from
> > > > > git://gitorious.org/linux-omap-dss2/omapfb-tests.git) shows a lot of
> > > > > tearing when rotation != 0. I tested this on 3430SDP using the LCD.
> > > [Hiremath, Vaibhav] Tomi,
> > >
> > > Yes, just now I tried your db application and I am also seeing tearing
> > effect. All other apps (including the one which I used for testing) works
> > fine for other rotation angles.
> > >
> > > Let me debug further before commenting anything on this, I just thought of
> > updating you on this.
> > 
> > "db" app uses double buffering for updating the display, with maximum
> > update rate. There's also "pan" app, that does a bit similar thing using
> > fb offsets.
> [Hiremath, Vaibhav] Tomi,
> 
> I found the bug which is causing tearing effect, I tested it here with both, mine and your applications and for me it is working fine.
> 
> Can you please check at your end?
> (Sorry for the attachment)

You should really avoid that. I can't quote the patch.

What are those CW<->CCW swaps that you do in the patch?

Also I think the ioremap stuff is a bit broken since AFAICS it will
leave the old angle still mapped when you rotate to another angle.

-- 
Ville Syrjälä
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed

[Hiremath, Vaibhav]

> -----Original Message-----
> From: Ville Syrjälä [mailto:ville.syrjala@nokia.com]
> Sent: Tuesday, May 04, 2010 7:15 PM
> To: Hiremath, Vaibhav
> Cc: Valkeinen Tomi (Nokia-D/Helsinki); linux-omap@vger.kernel.org
> Subject: Re: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> 
> On Tue, May 04, 2010 at 03:23:10PM +0200, ext Hiremath, Vaibhav wrote:
> >
<snip>
> > I found the bug which is causing tearing effect, I tested it here with
> both, mine and your applications and for me it is working fine.
> >
> > Can you please check at your end?
> > (Sorry for the attachment)
> 
> You should really avoid that. I can't quote the patch.
[Hiremath, Vaibhav] I completely understand, actually the intention of this patch is to test so avoided "git send-email".

> 
> What are those CW<->CCW swaps that you do in the patch?
[Hiremath, Vaibhav] Did you observed how the rotation comes on the screen? Does it rotate the image clockwise of anti-clockwise direction?

This is required to get clockwise rotation.

> 
> Also I think the ioremap stuff is a bit broken since AFAICS it will
> leave the old angle still mapped when you rotate to another angle.
> 
[Hiremath, Vaibhav] Why do you say that? Are you referring to changing rotation from sysfs here?

I hope you understand the change here, we are now mapping the write buffer to user space and overlay DMA is configured to 0 degree address map. So when you change the only rotation without writing anything to buffer (mapping is important here, since it will map newly configured rotated view) the display will stay intact.

I have tested with both SYSFS and FBIO_PUTVSCREENINFO ioctl, the only difference in behavior is you have to write it buffer to see rotated image.

Thanks,
Vaibhav

> --
> Ville Syrjälä
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html