RE: [PATCH] OMAP: DSS2: GFX FIFO UNDERFLOW issue fixed
> -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@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: > > > > 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 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 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 > > > > > > > > > > > > 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: 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 > > > > > > > > > > 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
> -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 > > > > > > > > > > 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
> -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 > > > > > > > > > > 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
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 > > > > > > > > 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: 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 > > > > > > 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 > > > > > -- > 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
> -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
> >
> > 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
> > ---
> > 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 =
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
>
> 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
> ---
> 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
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 > > > > > > > > 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-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 > > > > > > 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: 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 > > > > 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 > -- 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 > > 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
>
> 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
> ---
> 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,
