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 <manishsharm...@gmail.com> 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, "arden....@gmail.com" <arden....@gmail.com> 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 <manishsharm...@gmail.com> 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: android-porting+unsubscr...@googlegroups.com
website: http://groups.google.com/group/android-porting
-~----------~----~----~----~------~----~------~--~---
