RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
-Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@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-ow...@vger.kernel.org [mailto:linux-omap- ow...@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.valkei...@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 hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@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 0001-OMAP-DSS2-GFX-FIFO-UNDERFLOW-issue-fixed.patch Description: 0001-OMAP-DSS2-GFX-FIFO-UNDERFLOW-issue-fixed.patch
Re: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
On Tue, May 04, 2010 at 03:23:10PM +0200, ext Hiremath, Vaibhav wrote: -Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@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-ow...@vger.kernel.org [mailto:linux-omap- ow...@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.valkei...@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 hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@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.valkei...@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 hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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-ow...@vger.kernel.org [mailto:linux-omap- ow...@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.valkei...@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 hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
-Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@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-ow...@vger.kernel.org [mailto:linux-omap- ow...@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.valkei...@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 hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
-Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@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-ow...@vger.kernel.org [mailto:linux-omap- ow...@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.valkei...@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 hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
On Mon, 2010-03-22 at 14:09 +0100, ext hvaib...@ti.com wrote:
From: Vaibhav Hiremath hvaib...@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 hvaib...@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,
+
RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
-Original Message-
From: Tomi Valkeinen [mailto:tomi.valkei...@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 hvaib...@ti.com wrote:
From: Vaibhav Hiremath hvaib...@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 hvaib...@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
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.valkei...@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 hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
-Original Message- From: Tomi Valkeinen [mailto:tomi.valkei...@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.valkei...@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 hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
On Mon, 2010-03-22 at 14:09 +0100, ext hvaib...@ti.com wrote: From: Vaibhav Hiremath hvaib...@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 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
-Original Message-
From: Hiremath, Vaibhav
Sent: Monday, March 22, 2010 6:40 PM
To: linux-omap@vger.kernel.org
Cc: tomi.valkei...@nokia.com; Hiremath, Vaibhav
Subject: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
From: Vaibhav Hiremath hvaib...@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 hvaib...@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
[PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
From: Vaibhav Hiremath hvaib...@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 hvaib...@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 =
