Differences between 8168 ES1.1 and ES2.1 CPU revision?

Here's the file containing the usecase. It's 130 lines of C code.

WHat is the error msg.Pls share the console logs.Is displayDriver create failing ?

Attached are the console logs for the expected behaviour.

More to come

This is me having to kill the application because it's not doing anything.

And here's the patch to showcase where the additional printf statements are coming from.

So it looks like the DISPLAY Start is waiting for something called a DLM callback, but it never happens.

Have you modified the display controller tree compared to baseline DVR RDK 3.5. In the functional case which VENCs are tied ?

The only modifications to the display controller are the ones you and Shiju helped me with here: http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/249459.aspx?pi239031349=1

I.e. some changes necessary to support ISR queuing of the displayed frames.

Otherwise, I did not manually request any VENCs to be tied, so to answer your question: they're tied in whatever way the default is.

EDIT: Looks like the default is to tie HDCOMP and DVO2. This is the line I'm looking at:

ti_vdis.c: pContext->tiedDevicesMask = VDIS_VENC_HDCOMP | VDIS_VENC_DVO2;

Also, my bad for not posting the correct log. The "null_display_start_successful.txt" log is from the RevJ board. It's just that the usecase starts up and tears down well the first time around, but subsequent starts hang.

I've attached the log from the Rev G board where I can start and tear down an infinite number of times.

Philipp Schrader said:

Also, my bad for not posting the correct log. The "null_display_start_successful.txt" log is from the RevJ board. It's just that the usecase starts up and tears down well the first time around, but subsequent starts hang.

To clarify on this:

When I run the usecase on the Rev G board I can start it and tear it down a very large number of times.

When I run the usecase on the Rev J board I can start it and tear it down once. When I start it the second time, it hangs waiting for this DLM callback.

Alright, I think I've narrowed down the problem to the display path.

If I make use the following code, the setup and teardown work as expected:

System_LinkChInfo *info = &nullSrcPrm.inputInfo.chInfo[0];
info->dataFormat = SYSTEM_DF_YUV422I_YUYV;
info->memType = SYSTEM_MT_NONTILEDMEM;
info->startX = 0;
info->startY = 0;
info->width = 1920;
info->height = 1080;
info->pitch[0] = 1920 * 2;
info->pitch[1] = info->pitch[0];
info->pitch[2] = 0;
info->scanFormat = SYSTEM_SF_PROGRESSIVE;
System_linkCreate(gVcapModuleContext.nullSrcId, &nullSrcPrm, sizeof(nullSrcPrm));

// Initialize the display
DisplayLink_CreateParams_Init(&displayPrm);
displayPrm.inQueParams[0].prevLinkId    = gVcapModuleContext.nullSrcId;
displayPrm.inQueParams[0].prevLinkQueId = 0;
displayPrm.displayRes = gVdisModuleContext.vdisConfig.deviceParams[VDIS_DEV_HDMI].resolution;
displayPrm.displayId = DISPLAY_LINK_DISPLAY_BP0;
System_linkCreate(gVdisModuleContext.displayId[0], &displayPrm, sizeof(displayPrm));

So there is something about using SC1 (with 420 frames) instead of BP0 (with 422 frames) that doesn't work right with the CPU rev 2.1.

Are you aware of any such limitations, Badri?

I tried on Udowrks DVR board and I am able to start and stop your nulldisplay usecase multiple time. The board uses a PG2.1 silicon so this is not an issue with the silicon version. There were some bug fixes in DVR RDK 4.0 which would program the scaler coefficients and abort any busy lists befre starting the display. Pls try with DVR RDK 4.0 if you see similar behavior. I doubt this is the issue though since you are not seeing the issue on PG1.1 silicon.If you have a Udworks DVR board pls try on that.

Unfortunately, I do not have a UDworks DVR, but I can try RDK 4.0 easily enough.

I will try that and get back to you. I _may_ be able to get ahold of a UDWorks DVR board.

Thanks Badri!

Badri Narayanan said:

I tried on Udowrks DVR board and I am able to start and stop your nulldisplay usecase multiple time. The board uses a PG2.1 silicon so this is not an issue with the silicon version.

Just to be clear, did you try this with RDK 4.0 or with RDK 3.5?

I just tried this on the RDK 4.0 and I was able to start and stop my nulldisplay usecase on both EVMs (i.e. revision G and J).

I tried on DVR RDK 4.0 .

Badri Narayanan said:

There were some bug fixes in DVR RDK 4.0 which would program the scaler coefficients and abort any busy lists befre starting the display.

Hi Badri,

At this point I can say that the startup issue does not appear with RDK 4.0, but does appear with RDK 3.5. Would you be able to narrow down my search for this by telling me what folders the scaler coefficients and busy lists abort fixes are in?

I would like to see if I can take just those changes into our RDK 3.5 build.

Thanks,
Phil

Alrighty, I ended up copying the entire "ti_tools/hdvpss/dvr_rdk_hdvpss/" directory from RDK 4.0 to our RDK 3.5 code along with some changes in "dvr_rdk/mcfw" to adjust the REMOTE_DEBUG_LOG_BUF_SIZE appropriately.

Now the display link on the Rev J EVMs comes up properly (i.e. no more hangs) and plays video.

Thank you very much for your help Badri!