TV out GFX + VID1 and FIFOUNDERFLOW

jlmartin

Other Parts Discussed in Thread: OMAP3530

Hi,

I'm trying to use OMAP3530 overlay1 (VID1) and overlay0 (GFX) for PAL resolution with the TV out (venc). The facts are:

- GFX overlay displays graphics OK when enabled.

- When VID1 overlay is enabled (via sysfs), video overlay is shown for some seconds, and then VID1_FIFO_UNDERFLOW is produced and overlay is disabled (showing back GFX overlay).

- Doing the same as the previous point, but selecting LCD manager as output, GFX and VID1 overlays work nicely, and no FIFO UNDERFLOW is produced in any case (with same video resolution).

- Disabling GFX overlay and enabling only VID1 produces also VID1_FIFO_UNDERFLOW when TV out selected.

- BPP is 32 for GFX, and 16 for VID1

- Linux version used: linux-omap-2.6-b15127d (3.0.0)

After reviewing OMAP3530 Technical Reference my hypothesis are:

- some kind of L3 bus bandwith limitation due to different pixel encoding for PAL TV (unlikely: if LCD output is used, error is not produced).

- some DISPC / VENC register misconfiguration in the kernel when activating TV out.

Any idea?

Regards!

over 13 years ago

0 Vaibhav Hiremath over 13 years ago

TI__Expert 8180 points

By the time I digest your description and issue, can you try one test-case?

Enable TV out by default and run both video and GFX directly, without changing anything through sysfs???

Thanks,

Vaibhav

0 jlmartin over 13 years ago in reply to Vaibhav Hiremath

Prodigy 50 points

Thank you for the response.

The test-case you mention produces the same result described when changing sysfs (GFX appears ok, and VID1 produces FIFO_UNDERFLOW after 2 - 10 seconds).

Thinking further on this I see that data flow should be something similar to what is depicted here:

SDRAM <--L3 clk domain--> VID1_FIFO <---clk domain (2) --> VENC

What is clk domain (2)? Could be that frequency of the clock reading VID1_FIFO is too high and draining the FIFO?

0 Vaibhav Hiremath over 13 years ago in reply to jlmartin

TI__Expert 8180 points

Don't use sysfs for configuration, use bootargs to configure default display.

Thanks,

Vaibhav

0 jlmartin over 13 years ago in reply to Vaibhav Hiremath

Prodigy 50 points

Yes, this is exactly what I was doing.

Bootargs I'm using:

mem=62M mpurate=650 console=ttyO2,115200n8 vram=12M omapdss.def_disp="tv" omapfb.mode=tv:pal root=/dev/nfs nfsroot=192.168.2.123:/srv/nfs/poky/poky-image-ditel/igep0020b ip=192.168.2.124:192.168.2.123:192.168.2.123:255.255.255.0::eth0:

dmesg: http://pastebin.com/WzLMknM3

Thanks.

0 Beatriz Soriano Saura over 13 years ago in reply to jlmartin

TI__Prodigy 190 points

Vaibhav, do you have any news about this? Thanks, Beatriz,

0 Vaibhav Hiremath over 13 years ago in reply to Beatriz Soriano Saura

TI__Expert 8180 points

Hi,

Sorry for delayed response, was quite busy so could not able to follow e2e.

If I understand your description correctly, you are facing FIFO underflow issue only when the display in put on TV, right?

I am not sure whether is is possible for you to change the kernel version but just for sake of testing this issue, can you try PSP release which is based on 2.6.37 kernel - http://arago-project.org/git/projects/?p=linux-omap3.git;a=shortlog;h=refs/heads/OMAPPSP_04.02.00.07

Certainly you are exceeding L3/L4 bandwidth and that's where you are ending into FIFO underflow error condition. I am quite not sure why it should happen only with TV out. Can you try below tes-cases -

- What is LCD resolution? Can you change the resolution to higher resolution? something like, 720x480.

- Once we prove that issue is not happening due to VENC configuration, we need to optimize for L3/L4 bandwidth. Some options

- Overlay optimization

- Avoid rotation

- In case of rotation, optimize of 90/270 degree - http://arago-project.org/git/projects/?p=linux-omap3.git;a=commit;h=42daddb1b8fca7594868852f663fe0504032b7e6

Thanks,

Vaibhav

0 PaulM over 13 years ago in reply to Vaibhav Hiremath

TI__Mastermind 28035 points

Are you running into this issue on an EVM such that we can repeat it here?

Are there any other high bandwidth tasks running in parallel?

Thanks

Paul

0 Steve Clynes over 13 years ago in reply to Vaibhav Hiremath

TI__Mastermind 43875 points

Vaibhav,

If there is no scaling or anti-flicker filtering enabled then the DSS bandwidth requirements will only be about 75MB/s with a 16 bit YUV video buffer and a 24/32 bit graphics buffer.

If scaling or anti-flicker is enabled then this will be doubled to 150MB/s

Would we really expect this to consume all the bandwidth?

BR,

Steve

0 Vaibhav Hiremath over 13 years ago in reply to Steve Clynes

TI__Expert 8180 points

Steve,

I do not expect to consume so much bandwidth here, and also I have tested this use-case here at my end and I remember it worked for me.

Thanks,

Vaibhav

0 Matthias Brugger over 13 years ago in reply to jlmartin

Prodigy 10 points

We run in a similar problem with the OMAP3530 based on 2.6.37 kernel.

The problem was, that we didn't use the "performance" default cpu-freq govenor. This way the MPU at start-up isn't at it's highest rate and therefore the clockrates in DSS are not set right.

As I can see from your dmesg, your MPU frequency is at 500 MHz instead of 720 MHz. Please check your kernel configuration on that.

Best regards,

Matthias

Processors

Processors forum

TV out GFX + VID1 and FIFOUNDERFLOW