Hi there,
I'm running into a problem with the display system on the AM3517 (kernel 2.6.37 from PSP 04.02.00.07 with many patches applied). I'm using the AM3517 along with the graphics layer and one of the two video layers. I'm hoping someone might have some more experience than I do on this, because I feel like I've hit a brick wall.
Quick introduction: I'm outputting a 1024x768 signal on a DVI/HDMI port. The graphics layer is the same size and displays a UI. I'm using the SGX for acceleration. The framebuffer is configured for 32 bit ARGB. I'm not using VRFB or any special rotation stuff on this layer at all.
I'm also capturing 30 fps 720x480 NTSC video decoded with a TVP5146. I'm using a V4L2 program (with the userptr mechanism) to capture it from the VPFE and display it on the video 1 layer (with the omap_vout module). I'm using the scaling capability to display the video 1 layer at 1024x768 to fill the screen. It shows up underneath the graphics layer in sections where the graphics layer is transparent.
This setup has been working great with no problems at all for almost two years (aside from the annoying fact that NTSC video is interlaced, but that's a different issue). Recently I needed to implement the ability to horizontally flip the video (across the vertical axis). The omap_vout driver is capable of doing this with the V4L2_CID_VFLIP control, which appears to use the VRFB capability. After I applied this patch to enable rotation to work with the userptr mechanism, it actually worked and the video was correctly flipped.
However, ever since I've done this, the system (especially the video output) is very unstable. Occasionally the entire DVI video signal drops out for about a second. Sometimes the entire system freezes hard and ends up with a green screen. I also sometimes see the following error:
omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX
Of course, this error causes the graphics layer to turn itself off, and the video layer carries on happily.
Does anyone have any suggestions for what might be wrong? Am I asking the DSS to do too much now that I'm using VRFB as well? Is this a problem that has been patched since 2.6.37? I've backported many helpful patches but I may have missed something important.
More details:
~ # cat /sys/devices/platform/omapdss/display1/timings
72000,1024/24/160/136,768/3/29/6
(The next-lowest pixel clock I can do is about 61.7 MHz, which causes issues with some monitors, so lowering that clock is not acceptable, and I don't have the ability to use the DSI PLL on this board to get the preferred 65 MHz pixel clock)
fbset output:
mode "1024x768-66"
# D: 72.005 MHz, H: 53.575 kHz, V: 66.470 Hz
geometry 1024 768 1024 768 32
timings 13888 160 24 29 3 136 6
accel false
rgba 8/16,8/8,8/0,8/24
endmode
I'm running the AM3517 at 600 MHz. I'm adding the vid1_static_vrfb_alloc=1 parameter to the omap-vout modprobe command.
Any ideas or suggestions would be appreciated. Thanks!
Doug