Kernel Upgrade Causes EMC Failure on HDMI Interface

[pauldemet]

We have a system based on the i.MX8M processor that uses the NXP Linux kernel version 5.4. This board passed emissions testing.

We upgraded the kernel to version 5.15 and now the HDMI interface causes us to fail emissions testing. The failing frequency emissions not only got larger but also shifted. 

We have been unable to find any code differences that may cause this to occur.

Does anybody have any clues about the kernel differences?

We would like to experiment with the HDMI clocks but don't know how to adjust the HDMI clock registers. They do not appear to be used at all and are left with the default values. The registers I am referencing are the HDP Lane Configuration registers (lane0_phy_hdp_tx_ctl -lane3_phy_hdp_tx_ctl).

I have seen some similar posts but no firm answers. Help please.

[Zhiming_Liu]

Hi @pauldemet 

Please confirm that you are using i.MX8MQ processer.

Not sure if this issue is caused by firmware update or driver update. You can dump and compare the TX registers between 5.4 and 5.15.

1. One test wat is that you can try older firmware, like firmware in L5.10 and L5.4

2. Another is adjusting TX registers

TX control registers:

Tx De-emphasis setting

Level 0 ( 0.0dB) results in larger voltage swings
Level 1 (-3.5dB)
Level 2 (-6.0dB) results in smaller voltage swings

Tx Voltage Level

Level 0 (400 mV) results in smaller voltage swing
Level 1 (500 mV)
Level 2 (600 mV) results in larger voltage swings

Best Regards

Zhiming

[pauldemet]

Still need some answers.

[pauldemet]

Zhiming Liu,

Thanks for your response.

We are using the i.MX8MQ processor.

How do we dump the TX registers? We have a Lauterbach emulator we have tried to use to read these registers but they appear to be inaccessible. We see '????' response for register values. See image below.

We have done a detailed analysis of the Linux source code for both kernel versions and don't see any differences with the HDMI pixel clock which we think is the culprit.

Couple of questions on your feedback:

1. Where is the firmware you mention? Is there a binary file embedded in the build?

2. We do not see the registers you referenced being manipulated in the Linux source code for either kernel version. They appear to be left with the default reset values. Are we missing something?