> -----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? 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
