Hi everbody
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi everbody
Hi Kadir,
Do you see issue even with linux bootup logo? Is pixel clock configured for the rate specified in LCD data sheet? Can you please have debug message to print the interrupt status in the interrupt handler to see if you are hitting any sync or underflow errors?
Thanks,
Prakash
Hi
We cannot see the effect on bootup logo because we need an animation not a static image on screen.
Pixel rate is adjusted according to datasheet but if we look at it carefully, we can see the effect. And if i reduce the rate of PCLK, the tearing effect is seen more.
I opened the debug messages for interrupts but no overflow and sync interrupt errors occured.
If it is necessary, i can send you source file and some pictures or video which shows the tearing effect on our lcd.
Thanks
Can you please confirm if lcd data and vsync/hsync lines are connected to panel properly? Do you see linux logo in proper color? I see panel supports 18bpp, driver is capable of configuring for 8/16/24bpps.
Can you please try with attached pan_display application which does displaying 2 moving white rectangles(top and bottom) on black background and let me know if you see issue with this? This application also reports fps(which should be ~60fps).
You may also want merge below recent patch(video:da8xx-fb: calculate pixel clock period for the panel) if your application based on pixel clock period.
Thanks,
Prakash
Hi
I was trying to run Pan_2Rect app but i got some errors in mmap and ioctls (that's why i respond you late). However, i compassed the errors with some changes. For mmap, i made MAX_BUFFER equal to 1 (only 1 frame buffer) and closed the IOCTLs at the end of the main loop. Of course, after closing them, app didn't run properly but run. I saw the rectangles (moving only in horizontal direction and not cleaning the past) and also the tearing effect.
The two ioctls FBIOPAN_DISPLAY and FBIO_WAITFORVSYNC at the end of the main loop is not implemented in our driver. Can there be any relationship between these ioctls and tearing effect ?
I sent you our driver source code (we install this driver as module)
thanks.
Whenever application fills up a buffer, it calls PAN_DISPLAY to indicate driver about the updated new frame and waits for it to be displayed by doing FBIO_WAITFORVSYNC before updating the next frame. If you donot have FBIO_WAITFORVSYNC implemented in your driver, then if application updates the buffer which is being DMAed then you will see tearing effect.
Thanks,
Prakash
Hi
I guess we are close to solve this problem. I added fb_wait_for_vysnc functions to the driver (copied from http://gitorious.org/linux-davinci/linux-davinci/blobs/master/drivers/video/da8xx-fb.c) and called it in ioctl handle function but i got some erros in kernel level about NULL pointer reference.
How can i add correct ioctl PAN_DISPLAY and WAITFORVSYNC functions to my driver ?
Thanks
Hi,
Can you please let me know Why cant you use existing da8xx-fb driver and add support for your panel? Current driver supports Sharp_LCD035Q3DG01 and Sharp_LK043T1DG01 panels.
Thanks,
Prakash
Hi
We have added support for our lcd panel(SEIKO 24QVF2H) to driver (line: 242). We need to supply our fb driver as module to provide some requirements of our customer(for static bootup logo if we put it in kernel, scrren is cleaned early ).
Thanks
Does it mean with static build you are able get bootup logo? Have you made required changes in your board file(board-da850-evm.c) to support your panel?
What do you mean by screen is cleaned early? Do you have any GUI or xwindows coming up after bootup? If so can you please disable it?
Can you please share boot log?
Thanks,
Prakash
Hi Prakash
I think you misunderstood somethings. At first, our kernel version is 2.6.33, Lcd panel support is added to our board file and fb driver. Because of some reasons, we need to make our fb driver as module (it is not about the tearing effect problem).
On bootup(in UBL), there is an image, which our customer want to see, and then our grafic application which is written in Qt4 starts. At first everything is ok on screen but If anybody looks at the screen deeply, tearing effect is seenable especially on middle of the screen. If i reduce the frequency of lcd module, tearing effect appears more.
Neither lcd device nor grafic apps causes this issue. The problem is on our fb driver, i think forgotten ioctls can cause this effect.
Thanks for dealing.
I sent you our bootup log.
Hi Kadir,
Just to confirm if configuration for your panel are proper
Thanks,
Prakash
Hi Prakash,
Sorry for replying very late, i was dealing with other issues. At first, I tried static built-in da8xx frame buffer module (lack of PAN_DISPLAY and FBIO_WAITFORVSYNC ioctls) and then installed the module but the result was same, still tearing effect occurs. As i said before our bootup image is a static image so tearing effect is not observed but it think there should be no tearing before frame buffer module installation.
Secondly, i didn't dump the registers in UBL. How can i do this ? But the value of lcdc registers in kernel after driver is loaded seems to be normal (valid to datasheet).
Our frame buffer driver still lacks of PAN_DISPLAY and FBIO_WAITFORVSYNC ioctls and related functions. Maybe i need to add them and try again ?
Thanks,
Kadir
Hi
I added WAITFORVSYNC and FBIO_PANDISPLAY ioctls to frambffer driver but nothing changed. Tearing effect also occured in your app pan2_rect.
I am sure that I have seen exactly same issue before, but I am not able to recall what fix/root-cause we found at that time. Spend almost 10-20 mins to remember, but couldn't able to recall.
Let me check with Team here, may be some pointer or discussion somebody can bring and I recall it....
Have you tried it on multiple board? Is it consistent on other boards as well?
Thanks,
Vaibhav
Yes, we see tearing effect on all our boards.
We think it is not hardware related, it looks like a software problem.
When i first saw Prakash's tearing effect patch, i had a strong feeling that it would solve our problem. But the result was disappointing.
Maybe we are doing something wrong...
Regards
Alper