Jay, I met this problem before, and resolved it finally.
You may need to make sure of the behaviour of your display hardware firstly. Does your display hardware switch buffer on per vsync base or per scan line base? When will your hardware generate interrupt? If your hardware is on per vsync base, and generate ISR after finish one frame DMA, you should set base address in pan_display, and wait. Function isr just clear the wait event. Regards, Jill On Mar 31, 12:39 pm, Manish Sharma <[email protected]> wrote: > Hi Jay, > > I missed one thing in the psuedo code. > > pan_display() > { > 1. gets the yoffset(0/480) and updates the display base address in a > global variable > 2. enables the interuppt on vertical sync > 3. waits for event > > } > > isr() > { > 1. clears the interrupt > 2. gets the base address from global variable and updates the actual > display register > 3. Mask the interrupt > 4. sends the wakeup event to the pan_display > > } > > The step 3 in ISR is to mask the interrupt. > > >> And looks like your vsync is triggered at constant rate. > > If we mask the interrupt then it will not be triggered at constant rate. > With this code the interrupt will be enabled whenever there is a call for > pan_display(). And in ISR we will update the CLCD base address depending on > the offset recved from application. > > Thanks and regards, > MS > On Tue, Mar 31, 2009 at 9:17 AM, Manish Sharma > <[email protected]>wrote: > > > Thanks Jay, > > > Yes you are right I am using ARM based board and vsync is edge triggered. > > > >> You will probably need to enable irq at request_vsync(). (I think it is > > better than put it in pan_display()) > > > Can you please give some more details regarding the request_vsync()? > > > Regards, > > MS > > > On Mon, Mar 30, 2009 at 12:36 PM, <[email protected]> wrote: > > >> I am guessing you are working on ARM and the vsync is edge triggered. > > >> And looks like your vsync is triggered at constant rate. > > >> The basic rule is, you can not send data across next vsync, you will get > >> tearing otherwise. > > >> You will probably need to enable irq at request_vsync(). (I think it is > >> better than put it in pan_display()) > > >> In ISR(), it is the same as what you did. > > >> Then comes a problem, kernel will re-trigger the interrupt in resend.c > >> right after you enable_irq. > > >> That is not you want at this case. (It is not really hardware vsync > >> interrupt then) > > >> You can: > > >> 1. Disable CONFIG_HARDIRQS_SW_RESEND or > > >> 2. registerd vsync interrupt as level trigger or > > >> 3. add a retrigger handler in gpio.c > > >> And, the interrupt status is **sticky**. You may need to clear it before > >> enable_irq. > > >> Hi Arve, > > >> Do you have better solution? > > >> cheers, > > >> jay > > >> *From:* [email protected] [mailto: > >> [email protected]] *On Behalf Of *Manish Sharma > >> *Sent:* Sunday, March 29, 2009 11:17 AM > >> *To:* [email protected]; [email protected] > >> *Subject:* [android-kernel] Tearing issue with OpenGL > > >> Hi All, > > >> I am getting tearing issue with ApiDemos->Graphics->OpenGL applications. > >> Has anyone checked these applications on there platform? > > >> I have VGA display and the psuedo fb implementation is as follows: > > >> pan_display() > > >> { > > >> 1. gets the yoffset(0/480) and updates the display base address in a > >> global variable > > >> 2. enables the interuppt on vertical sync > > >> 3. waits for event > > >> } > > >> isr() > > >> { > > >> 1. clears the interrupt > > >> 2. gets the base address from global variable and updates the actual > >> display register > > >> 3. sends the wakeup event to the pan_display > > >> } > > >> My understanding is pan_display will be called by EGLsurface context and > >> isr is in interrupt context. > > >> The functionality of EGLsurface is to update the active FB for display and > >> use the inactive FB for processing. > > >> Means only EGL is updating the FB. Is this correct? > > >> With the above sync between pan_display and isr using wait event tearing > >> should not occur. But still we are getting...:( > > >> Your observations and inputs are most welcome. > > >> My setup is from master branch with 2.6.25 android kernel for my platform. > > >> Thanks and Regards, > > >> MS > > >> >> CONFIDENTIALITY NOTE : The information in this e-mail is confidential > >> and privileged; it is intended for use solely by the individual or entity > >> named as the recipient hereof. Disclosure, copying, distribution, or use of > >> the contents of this e-mail by persons other than the intended recipient is > >> strictly prohibited and may violate applicable laws. If you have received > >> this e-mail in error, please delete the original message and notify us by > >> return email or collect call immediately. Thank you. HTC Corporation --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [email protected] website: http://groups.google.com/group/android-kernel -~----------~----~----~----~------~----~------~--~---
