1080i60 display issue

Hi,

There could minor tuning required for 1080i format, you could use sysfs timing attribute to do so.

Regards,

Brijesh

Brijesh,

Thank you for the feedback.  I have tried adjusting the sysfs timing attribute without success.  As a sanity check, I have:

74250: display pixel clock

1920: display width
88: horizontal front porch
148: horizontal back porch
44: horizontal sync width

1080: display height
2: vertical front porch
15: vertical back porch
5: vertical sync width
0: progressive output

Where the total number of lines is 1080 + 2 * (2+15+5) + 1 = 1125 because for interlaced modes, the blanking is apparently divided by two and rounded down.  While I don't think that this matches what I see in TI's documentation for the VPSS, this appears to be how it functions based on my observations.  Does this match what you know about the vertical values?

We also have 1920+88+148+44=220 for the horizontal dimension, which appears correct.

When I adjust the vertical blanking numbers with the sysfs timing attribute, it seems like I can adjust where the first and second fields begin and end with respect to the frame, but I can't seem to adjust where active video begins with respect to the frame.

It is also not clear how one might use the sysfs parameters in a way that affects only the first field and not the second field.  Do you have any guidance on this?

Csaba

Hello David,

Could you share the M3 patch for this issue?

Regards,

Brijesh

Hi Brijesh,

RidgeRun's NDA with TI does not allow us to share M3 code on a pubic forum. Please email inquiries@ridgerun.com and we can work out a way to get the patch to you.

-David

The latest drivers and released M3 code should be correct.

Interlaced video should have been correct for along time now.

BR,

Steve

Hi Steve,

     That sounds great, which specific version of the hdvpss dirver is SMPTE 274M compliant? where can it be downloaded?

-David

Brijesh,

Can you please help ensure that David has access to the latest software?

BR,

Steve

David, Steve, Brijesh,

Thank you all of you for your feedback regarding my question.

It is encouraging to know that a solution is available via software change.  I now also know that it is futile for me to attempt to resolve the issue from user space or kernel space, so I will stop beating my head against that.

What is not clear is how one is intended to resolve issues that might be present in the M3 code.  It sounds like this is only available under NDA that is not part of the development kits.

Steve: Would you be allowed to state publicly for the forum what version number is used to identify the most recent M3 code release?  Also, if there were fixes to address interlaced video related issues, what M3 release version number were the most recent relevant changes made in?

Csaba

I don't know specific versions since I am not actually involved in the software releases.

All I know really is that 1080i has been working and validated for quite a while now. I believe all the RDK/SDK releases are available without NDA but as I say, that is not my field.

BR,

Steve

Hi Steve,

  Well the VPSS driver version that we used was 01.00.01.44 which is in the EZSDK overlay and the version in RDK 4.0 is 01.00.01.37 I think. Something interesting is that using the EVM we saw interlaced properly displayed but with discrete sync signals, in case of SMPTE 274M it is embedded sync signals and using a serializer we were able to see what is mentioned by Csaba, so we did the enhancement to get it working, it sounds great if some version includes the fix by default.

-David

Hi David,

Have you tried 1080i with DVR-RDK 4.0? It should be working fine in RDK4.0. I am not sure about HDVPSS.44 release.

Regards,

Brijesh

Hi Brijesh,

   I didn't tried with RDK4.0 since the customer was using EZSDK but in the RDK I didn't find any patch changing the timing signals to be 274M compliant, also since the VPSS driver seems older it doesn't seem that it would have the fix and after a comparison between the timing files on the RDK and the EZSDK I saw that there was not change. Again, I was able to see the mismatch in the board using the serializer and double check it using a Tektronix wakeform monitor.

-David

I can't comment on RDK, but for EZSDK 5_05_02_00, the TI81XX_VPSS_Video_Driver_User_Guide.pdf document references "HDVPSS 01.00.01.37 release".

The linux-2.6.37-psp04.04.00.01/drivers/video/ti81xx/vpss/fvid2.c file has

#define CURRENT_VPS_FIRMWARE_VERSION        (0x01000137)

which I guess is consistent with the documentation, if we interpret 0x01000137 as 01.00.01.37

However, when dm816x_hdvpss.xem3 from EZSDK 5_05_02_00 with file size 20614230 and md5sum 0d2cb156a976d121cc51aedc36f23955 is loaded, we get a message indicating version 01.00.01.45:

VPSS_FVID2: M3 firmware version 0x1000145 is newer,driver may not work properly.

It looks like there is some sort of kernel driver / M3 mismatch in EZSDK 5_05_02_00.

Looking in the arago repository, I see the following commits:

2012-09-21 HDVPSS :- Updated the firmware version number 0x01000143 --> 0x01000144
2012-09-04 TI81xx: vpss: Reduce the sleep time while trying to... still 0x01000143
2012-07-26 TI811x :- Updated the HDVPSS firware version number 0x01000139 --> 0x01000143
2012-05-29 HDVPSS : Firmware: Updated the firmware version 0x01000137 --> 0x01000139
2012-04-16 TI81xx Video Proxy: Same containers are used for Queue... still 0x01000137
2012-01-23 TI81xx Video: Updated for HDVPSS.37 release 0x01000133 --> 0x01000137

Now I am rather confused as to which HDVPSS firmware version is appropriate for us to be using with EZSDK 5_05_02_00 for DM816x.  Brijesh, can you comment on this?

Brijesh, could you please also research in which HDVPSS firmware version the interlaced video output was tested as being correct as Steve indicates?

Csaba

Hi,

I will look into the changes in rdk.

If you are using ezSDK, use the latest hdvpss, i guess it is HDVPSS.44/45. If you are using DVR-RDK, use DVR-RDK4.0/1.

Rgds,

Brijesh

Hi,

  We used EZSDK 5.05.02.00 and if you get the EZSDK overlay with the components needed to rebuild the firmware, it has the HDVPSS driver 01.00.01.44 so that's the one in your EZSDK.

-David

Brijesh,

If we are using EZSDK 5_05_02_00 and the included HDVPSS M3 firmware binary is 1.44/1.45 then does TI recommend that we use the corresponding newer HDVPSS driver (drivers/video/ti81xx/vpss) on the A8 Linux side from the Arago git repository that is expecting v1.44 M3 firmware rather than the Linux HDVPSS driver included with EZSDK 5_05_02_00 that is expecting v1.37 M3 firmware?

Csaba

I have a clue regarding the origin of the v1.45 HDVPSS M3 firmware.

From the EZSDK overlay we have:

~/ti-ezsdk_dm816x-evm_5_05_02_00/component-sources/hdvpss_01_00_01_44/packages/ti/psp/vps/vps.h with #define VPS_VERSION_NUMBER (0x01000145u)

As a reference, from the RDK code base we have:

~/dvrrdk/DVRRDK_04.01.00.02/ti_tools/hdvpss/dvr_rdk_hdvpss/packages/ti/psp/vps/vps.h with #define VPS_VERSION_NUMBER (0x01000137u)

which is at least consistent with the version number provided in the release notes document and is also consistent with the Linux A8 driver.

Hi Csaba,

   On the EZSDK 5.05.02.00 release there was a misalignment between the vps driver on the ARM and the HDVPSS driver in the M3 however, it is recommended to keep using this combination, please see:

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/258126.aspx

-David

I forgot to mention, you can also see a message about it on the bootlog:

MemCfg: DCMM (Dynamically Configurable Memory Map) Version :  2.1.2.1
FIRMWARE: 0 start Successful
VPSS_FVID2: M3 firmware version 0x1000145 is newer,driver may not work properly.
HDMI W1 rev 2.0

http://www.ridgerun.com/demos/evm8168-eval-omx-demo/bootlog-eval-dm8168-evm-omx.txt

But according to TI this can be ignored.
-David

David,

Thank you again for your feedback and the reference to the "VPSS_FVID2: M3 firmware version 0x1000145 is newer,driver may not work properly" forum thread.

In that forum thread, TI Employee Pavel Botev references the Arago git repository changes to the Linux driver side that I too was looking at.  However, after consulting with the rest of his team at TI, Pavel's final comment regarding the issue is ambiguous where he states "the best option is to use older version of HDVPSS to match the versions".

My initial interpretation of Pavel's statement is that with EZSDK 5.05.02.00 Linux the recommendation is to use the v1.37 HDVPSS M3 firmware so that it matches the Linux driver side provided in the EZSDK release.  However, I am not sure how to reconcile this with TI Employee Brijesh Jadav's statement  in this forum thread that "If you are using ezSDK, use the latest hdvpss, i guess it is HDVPSS.44/45".

At the end of the day, it sounds like RidgeRun had to patch the HDVPSS M3 v1.44 aka v1.45 code in order to resolve the 1080i60 issue and that HDVPSS M3 v1.44 is the most recent release provided by Texas Instruments.

As a side note for anyone else interested in this issue, the HDVPSS M3 source code is not provided as part of the EZSDK release that can be downloaded from Texas Instrument's web site.  It is only available under NDA with TI as part of an "EZSDK overlay" or as part of the DVRRDK release under NDA with TI.

Hi Csaba,

          Yes, your understanding is correct, we patched the HDVPSS that comes in the Overlay, i.e, hdvpss_01_00_01_44. At this point I haven't seen any difference or problems using the configuration of versions provided by the EZSDK, the fix here actually was on the M3 side and was not present in older versions of the driver neither.

-David

HI,Csaba,Did you solve this problem?I also have this problem,the 1080i60hz display seems only one field,not include odd field and even field.

Hello,

Csaba said:

In that forum thread, TI Employee Pavel Botev references the Arago git repository changes to the Linux driver side that I too was looking at.  However, after consulting with the rest of his team at TI, Pavel's final comment regarding the issue is ambiguous where he states "the best option is to use older version of HDVPSS to match the versions".

My initial interpretation of Pavel's statement is that with EZSDK 5.05.02.00 Linux the recommendation is to use the v1.37 HDVPSS M3 firmware so that it matches the Linux driver side provided in the EZSDK release.  However, I am not sure how to reconcile this with TI Employee Brijesh Jadav's statement  in this forum thread that "If you are using ezSDK, use the latest hdvpss, i guess it is HDVPSS.44/45".

The latest and current VPSS version is hdvpss_01_00_01_44. You should use 1.00.01.44. The recommendation was 'if there is a problem due to version mismatch is to use older version'.

Since now I have not see any problem with the this version.

Best Regards,

Margarita

Dear sunnyT,

At the present time, the issue that we encountered is still unresolved for our application.

As far as we can tell, the problem is resolvable but requires modifying the HDVPSS M3 firmware.  For our hardware platform, the HDVPSS M3 firmware has been modified by the TI partner that we are working with and we do not have the source code for the modified version of the HDVPSS M3 firmware.

We are working with our TI partner to negotiate the costs of implementing a bug fix.

Csaba