Hi Sean, In our case display base register is not shadow register but still I will try doing base address update in pan_display.
Thanks, MS On Wed, Apr 1, 2009 at 6:08 PM, Sean McNeil <[email protected]> wrote: > > The code below assumes that the change in the display base address > happens immediately. If you have an architecture that provides shadow > registers, then you want to set them in pan_display and not in the isr > and just wait for the VSYNC. > > Manish 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 Apr 1, 1:33 pm, Manish <[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 Mar 30, 8:10 pm, "[email protected]" <[email protected]> wrote: > >> > >> > >> > >> > >>> Hi, > >>> I am assuming you are working on ARM, and the vsync is edge triggered. > >>> Looks like your vsync is trigged at a constant rate. > >>> > >>> In kernel, it will re-trigger the interrupt in resend.c right after > >>> enable_irq. > >>> So, you may encountertearingbecause of this. (At this case, it is > >>> not real hardware vsync) > >>> > >>> You can, > >>> 1. disable CONFIG_HARDIRQS_SW_RESEND or > >>> 2. register it as level trigger or > >>> 3. register a retrigger in gpio.c > >>> > >>> The interrupt status is *sticky*, you may need to clear its status > >>> before enable_irq. > >>> > >>> Hi Arve, > >>> Do you have better solution? > >>> > >>> On 3月29日, 上午11時17分, Manish Sharma <[email protected]> wrote: > >>> > >>>> Hi All, > >>>> > >>>> I am gettingtearingissue 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 > eventtearing > >>>> 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- Hide quoted text - > >>>> > >>> - Show quoted text -- Hide quoted text - > >>> > >> - Show quoted text - > >> > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [email protected] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
