• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 33 subscribers
  • Views 1001 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

DS90UB949A-Q1: EDID with Pixel Clock <165 MHz fails

Matěj Bartík
Prodigy 10 points
Part Number: DS90UB949A-Q1


Hello, 

we are developing a product with DS90UB949A, which should support pixel clock up to 210 MHz, however we are struggling to go beyond 165 MHz.

We have a display with 948 deserializer (max PCLK 190 MHz) and a mating car control unit with 949A, which gives video signal with PCLK=178,42 MHz. Therefore; the display is capable of recieving such signal and 949A is capable of generating such signal, but we don't which configuration/operating mode is used.

We captured timing with an analyzer to created an EDID structure with matching parameters.

We discovered, that any EDID structure with PCLK greater than ~165 MHz won't work with the display and this behavior is the same our custom PCB and the EVM as well. In case the PCK is greater than 165 MHz, the 949A doesn't propagate the custom EDID to GPU drivers (949A reports VGA resolution or isn't recognized at all depending on the GPU/driver vendor). We made an EDID with 55 FPS which works fine. However, attempts with 56 FPS or greater have been failing.

EDID:

0x00, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x53, 0x0E, 0x49, 0x09, 0x01, 0x00, 0x00, 0x00,
0x1C, 0x21, 0x01, 0x03, 0x80, 0x34, 0x20, 0x78, 0x0A, 0xEC, 0x18, 0xA3, 0x54, 0x46, 0x98, 0x25,
0x0F, 0x48, 0x4C, 0x00, 0x00, 0x00, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0x01,
0x01, 0x01, 0x01, 0x01, 0x01, 0x01, 0xE3, 0x3F, 0xC0, 0x60, 0x80, 0xEC, 0x0D, 0x40, 0x1C, 0x1C,
0x62, 0x00, 0x00, 0x20, 0x21, 0x00, 0x00, 0x18, 0x00, 0x00, 0x00, 0xFC, 0x00, 0x57, 0x56, 0x5F,
0x31, 0x35, 0x5F, 0x30, 0x5F, 0x48, 0x34, 0x31, 0x0A, 0x20, 0x00, 0x00, 0x00, 0xFE, 0x00, 0x54,
0x45, 0x53, 0x54, 0x45, 0x32, 0x30, 0x32, 0x33, 0x30, 0x37, 0x31, 0x37, 0x00, 0x00, 0x00, 0x10,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC0,

  • 0
    Prodigy 10 points

    I'm going to answer my own question :-)

    I found out the problem is the EDID 1.3 structure, which has pixel clock limit of 165 MHz, therefore drivers are interpreting such value as invalid (but it's valid to all EDID editors I tested).

    So the solution is to change EDID format to 1.4, than everything works.

  • 0 in reply to Matěj Bartík
    TI__Mastermind 22946 points

    Hi Matej,

    Glad to hear you got the answer. Note that DS90Ux949/929 can be configured when EDID information must be allowable by the HDMI v1.4b and DVI 1.0 standards. Please let me know if you have any question further.

    Best,

    Josh

  • 0 in reply to Josh Baik
    Prodigy 10 points

    Dear Josh,

    That's not correct. EDID 1.3 structure is allowed and seems to be  the default option for HDMI 1.4b: https://www.quantumdata.com/pdf/EDID_WP.pdf

    The DS90UB949A default pre-programmed EDID is 1.3 structure as well. That is contrary to your claim.

    Therefore the DS90UB949A datasheet needs to be corrected because I used a valid EDID 1.3 structure which is compliant with HDMI 1.4b, and DS90UB949A doesn't work.

    Because the DS90UB949A default EDID is 1.3, using it as a template for other resolutions creates an issue; the DS90UB949A will be discovered as HDMI1.2/DVI Single-Link device because the "Video interface" type field was introduced in EDID 1.4 (and then it is possible to specify the DS90UB949A interface as DVI/HDMI/DP, etc.); therefore a GPU driver makes a test if PCLK is greater than 165 MHz and automatically fails to identify the DS90UB949A.

    So I suggest making an errata/datasheet update that clarifies the EDID 1.4 must be used for PCLK greater than 165 MHz (and is recommended for other PCLKs because it can correctly define an input interface as HDMI).

    Best regards,

    Matej

  • 0 in reply to Matěj Bartík
    TI__Mastermind 22946 points

    Hi Matej,

    The maximum PCLK of EDID 1.3 structure is 655.35MHz as 2 bytes timing descriptor is used for pixel clock as below. You can refer to VESA EDID 1.3 Standard. (Link) Please let me know if I miss any information.

      

    Best,

    Josh

  • 0 in reply to Josh Baik
    Prodigy 10 points

    Hi Josh,

    That is the problem. You can create a valid EDID 1.3 structure with PCLK between 165 and 655.35 MHz, but no PC will recognize it because it is EDID 1.3!

    Intel/nVidia/AMD drivers (tested on tens of configurations of drivers/GPUs) won't recognize a DS90UB949A! The reason is the DVI specs and EDID 1.3 itself. DS90UB949A with EDID 1.3 report itself as a "Digital" interface" with a "Single-link" option (where is the limit of 165 MHz). If a GPU driver reads PCLK greater than 165 Mhz, the GPU driver interprets it as an error value.

    Imagine you created a valid EDID 1.3 structure and uploaded it into a DS90UB949A, and it won't work despite everything being compliant!

    Therefore, TI should make an application note for DS90UB949A to point out it is necessary to use EDID 1.4 structure instead. EDID 1.4 has an option to describe the type of an input interface and identification process in a driver won't fail. Following the instructions in the current DS90UB949A datasheet will not work for video signals with PCLK greater then 165 MHz.

    Best regards,
    Matej

  • +1 in reply to Matěj Bartík
    TI__Mastermind 22946 points

    Hi Matej,

    Thank you for the point out. I guess it is not an issue from DS90UB949A, might be from the HDMI TX side or specification as we don't have any issue before regarding the limit of pixel clock for DS90UB949A. I will discuss this internally with the team about this and then it would be considered updating the datasheet or making the app note if we need. Thank you for the clarification of your experience.

    Best,

    Josh

  • 0 in reply to Josh Baik
    Prodigy 10 points

    Hi Josh,

    It has nothing to do with the DS90UB949A hardware design or HDMI TX sides (our tests included GPUs with HDMI 2.0). The only issue is the combination of EDID 1.3 usage recommended by the datasheet, high PCLK, and how GPU drivers discover a video sink device. This won't be an issue in an embedded system where a GPU generates a video signal with forced parameters/timings and the system doesn't rely on a GPU driver autodetection procedure (because such behavior doesn't require an EDID to be present).

    The probable reasons why this behavior wasn't noticed (as an automotive insider):

    • Car units are designed as an embedded system with forced video parameters,
    • I have met only one infotainment display using PCLK greater than 165 MHz (most of them are 1080p max, but people are demanding bigger screens while we need to use already existing car platforms).

    Best regards,

    Matej Bartik