Graphics clocks doesn't add up

[B-OatPQURE]

I dumped the DPLL control and configuration registers on a Baytrail platform in VGA mode 3 on HDMI.

The clocks according to your documentation has the following relationship.

REFERENCE----->PLL------>DDI------>TRANSCODER

The output from PLL and input to DDI should be 5 x the TMDS rate.

The output from DDI and input to TRANSCODER should be the TMDS rate / 5.

In the VGA mode 3 set by VBIOS, a multiplier of 4 is used for the frequency 25,175 MHz. Thus the frequency from the PLL will be 4 x 5 x TMDS rate. The output from the DDI port will then be 4 x TMDS rate (4 x TMDS rate / 5).

Thus the TRANSCODER TMDS rate will be 100,700 MHz and the bit rate 1,007 GHz. So it must be compensation for the multiplier or else the dot clock for the mode on the monitor will not match.

So my question is, how is this compensated by the source? What is the reason for bumping up the clock over the 100 MHz level? I have seen that the lowest frequency supported is 25 MHz, but as VBIOS uses 100 MHz for HDMI it must have a reason for that. I guess the VGA port and SDVO might use 25 MHz, but it may not work on HDMI or DP?

Can you verify?

[그래요ITech]

The clock frequencies and multipliers you've described are part of a complex clock generation process for video output on a Baytrail platform. The compensation for the multiplier is typically handled by the source to ensure that the dot clock matches the monitor's requirements for the selected mode.

The reason for increasing the clock frequency above 100 MHz could be related to the requirements of the HDMI specification, which often requires higher frequencies for certain resolutions and refresh rates. The VBIOS likely uses a higher base frequency for HDMI to ensure compatibility across a wide range of monitors and to maintain signal integrity at higher resolutions.

As for the VGA port and SDVO (Serial Digital Video Out), these may indeed use lower frequencies like 25 MHz, as they are typically associated with lower bandwidth requirements compared to HDMI or DisplayPort (DP). However, HDMI and DP are designed to accommodate higher frequencies to support higher resolutions and faster refresh rates.

Cheers,

Max

[B-OatPQURE]

Thank you for your reply!

So the PLL should be programmed to generate a 100.7 MHz clock? Then the multiplier setting of 4 in the DPLxMD generates 25.175 MHz frequency as 100.7 / 4 = 25.175? The divide by 10 in the DPLx_CTRL then generates the required symbol clock (TMDS) of 251.75 MHz for the HDMI monitor?

On CherryView the DP clock recovery always succeed for all 4 lanes using 162 MHz or 270 MHz link rate. The channel equalisation however only succeeds on the first 2 lanes. The status for lane 2-3 is stuck at 0x00, while status for lane 0-1 changes between 0x00, 0x66 and 0x77 (success). It looks like the offset of the DPIO registers responsible for the pre-emphasis and voltage swing level is wrong for lane 2-3. Is it possible to get a correct list of these registers?

Kudos,

B-O

[그래요ITech]

Appreciate that B-OatPQURE

I agree of the PLL programming for generating a 100.7 MHz clock is correct. The multiplier setting of 4 in the DPLxMD does indeed generate a 25.175 MHz frequency, as 100.7 /4 = 25.175. Furthermore, dividing by 10 in the DPLx_CTRL to produce the required TMDS symbol clock of 251.75 MHz for the HDMI monitor is accurate.

...also, CherryView DP clock recovery, it's concerning that channel equalization only succeeds on the first two lanes. The discrepancies you've found in the documentation for the DPIO registers could very well explain the failure in lanes 2-3. It's not uncommon for documentation to lag behind actual implementation, especially in open-source drivers where the community may discover and implement fixes before they are officially documented.

Cheers,

Max

[B-OatPQURE]

Hi Max,

I fixed the DP training, so now the clock recovery and channel equalisation for 4-lanes finish in 3 rounds in 270 MHz link rate. So the code for HDMI and DP links is fine, but I have not been able to see any graphics yet.

I have read all documentation from BayTrail to TigerLake. Some talks about a need to initialise with the display engine with the "display sequence" first. As the block schematics of the display involves pipes, transcoders and DDI ports it's hard to guess what the "display sequence" registers are among all other parts in the display.

As the "display sequence" or other initialisation required before enabling isn't documented along with how to power on the display engine, I have to find out from Linux code. But as Linux drivers covers all the architectures in one driver, including all aspects of settings and being as indirect as usual with Linux, it's a cumbersome process.

The best would be if Intel could document properly and don't leave things out. Some reference code would not hurt either. From the Linux driver code it's hard to find out the sequence of initialisation steps for enabling and disabling the ports. The basic initialisation for powering on and off the display engine is very abstract in the Linux driver.

Best regards,

B-O  

[B-OatPQURE]

I found out that the DP_B, DP_C and DP_D control register is totally wrong in the CherryView documentation! The open source Linux driver uses fields that overlaps or are not present in the documentation.

The fields in the driver is:

PORT_ENABLE                  BIT 31

PIPE_SELECT                     BIT 30

TRAINING_PATTERN        BIT 28-29

TRANS_SELECT                 BIT 24-27                 (BIT 25-27 is voltage swing level in documentation)

LINK_RATE                          BIT 20-23                 (BIT 22-24 is pre-emphasis level in documentation)

DATA_FORMAT                   BIT 18-19                 (BIT 19-21 is port width select and BIT 18 is enhanced framing enable in documentation)

LANE_REVERSAL               BIT 16                        (BIT 15 is lane reversal in documentation) 

BUFFER_IDLE                      BIT 7                          (BIT 7 is scrambling disable and BIT 8 is ASR enable in documentation)

OWNERSHIP                        BIT 6                          (BIT 6 is audio output enable and BIT 5 is HDCP port select in documentation)

4LANES_ENABLE                BIT 4                          (BIT 3-4 is sync polarity in documentation)

PORT_WIDTH                      BIT 1-3                      (BIT 2 is display detected in documentation)

DISPLAY_DETECTION        BIT0                           (BIT 0-1 is reserved (MBZ) in the documentation)

So that may explain why the channel equalisation phase always fail for lane 2-3? The question is if Intel will provide the proper documentation or not? The quality of the documentation is kind of embarrassing in my point of view. The policy of leaving out key parts is questionable and parts that are present but wrong is even worse.

The level of support and documentation at Intel is very bad in my opinion. Perhaps I'm spoiled to have worked with AMD. They have excellent support and documentation. I always got what  asked for.

[H_Mlysgeek]

Hi B-O...

The issues you've encountered with the DP_B, DP_C and DP_D control registers in the CherryView documentation are indeed Troubling, It's possible that the documentation you have is outdated or incorrect.

Regards
Harry

[B-OatPQURE]

Hi Harry,

The open source documentation of the display engine in the CherryView version is shameful! They canceled VBIOS support for the architecture and yet the only documentation about the display engine list the VGA registers. Further they removed all fields in the main registers that holds VGA settings in all the documentation, even though the VBIOS for CherryView use these fields.

Many parts of the documentation for CherryView is totally wrong. One example is that VGA disable bit in the VGA control register will not have any impact on the VGA registers or legacy memory regions 0xB0000-0xAFFFF. When VGA disable bit is set writes to VGA registers are blocked and if I recall correctly the legacy regions will not be visible.

Regarding the 0xB0000-0xAFFFF regions, there is also an undocumented way to turn them on. VBIOS uses an undocumented way of writing to VGA registers while the VGA disable bit is set. They use undocumented I/O registers in IBM original color graphics board that temporarily unlocks the writing to a VGA register. It uses an algorithm based on the VGA register that targets a specific unlock (IBM) register.

Anyway, I always push through even though it takes so much longer time without support, bad documentation and without reference code. As Intel will not provide me with the BMP tool for CherryView and that they dropped VGA support all together, I had no other choice than write my own VGA BIOS.

Best regards,

B-O

[B-OatPQURE]

After further investigation it looks like Intel canceled VBIOS because they messed it up with CherryView. I have tested several versions of the VBIOS for CherryView and none of them is capable of handle any VGA video mode. I tested on a HDMI port and VBIOS was able to set the native video modes. I configured the VBIOS to handle POST VGA video mode 3 and the screen was blanked. No text was shown. Same result in VGA graphic modes. When VBIOS was configured for showing the POST message, nothing was shown on the monitor in VGA video modes. For the native modes, I got some graphics indicating that something from the frame buffer was displayed. The included photo is mode 0x34 (1024x768 and BPP8).

So the question is, did VGA video modes worked in any version of VBIOS? If it worked in some versions, which ones?

Regards,

B-O

Mode 0x34: 1024x768,BPP8