[GLK] Monitor suffers no signal by power off then on to monitor when HDMI output is 4K@60Hz

Test Environment

• Ubuntu 18.04 with kernel drm-tip (1/6/2021, v5.11-rc2) or v5.10.
• Symptom: Suffers screen blank in 4K@60Hz resolution by power-off monitor then power-on it. There is no this issue when HDMI's resolution is set with 1080p@60Hz for the same test steps.

It seems to not have fully modeset on 4K pipe (pipe-A for HDMI-A-1 from log) then lack edid's update & probing of connector's modes further... GLK-kern-02172021.log

changed the description

added feature: display/HDMI label

added platform: GLK label

made the issue visible to everyone

I tested again by drm-tip 2/17/2021 and also saw HDMI scrambling enabled for pipe-A during HDMI's detecting (after monitor power-on),

…
Feb 18 11:05:36 intel-DUT kernel: [  129.684934] i915 0000:00:02.0: [drm:verify_single_dpll_state.isra.102 [i915]] PORT PLL A
Feb 18 11:05:36 intel-DUT kernel: [  129.685084] i915 0000:00:02.0: [drm:verify_single_dpll_state.isra.102 [i915]] PORT PLL B
Feb 18 11:05:36 intel-DUT kernel: [  129.685233] i915 0000:00:02.0: [drm:verify_single_dpll_state.isra.102 [i915]] PORT PLL C
Feb 18 11:05:36 intel-DUT kernel: [  129.685422] i915 0000:00:02.0: [drm:intel_enable_shared_dpll [i915]] enable PORT PLL B (active 1, on? 0) for crtc 67
Feb 18 11:05:36 intel-DUT kernel: [  129.685572] i915 0000:00:02.0: [drm:intel_enable_shared_dpll [i915]] enabling PORT PLL B
Feb 18 11:05:36 intel-DUT kernel: [  129.685829] i915 0000:00:02.0: [drm:intel_dp_dual_mode_set_tmds_output [i915]] Enabling DP dual mode adaptor TMDS output
Feb 18 11:05:36 intel-DUT kernel: [  129.687111] i915 0000:00:02.0: [drm:intel_power_well_enable [i915]] enabling DDI B IO power well
Feb 18 11:05:36 intel-DUT kernel: [  129.687332] i915 0000:00:02.0: [drm:intel_enable_pipe [i915]] enabling pipe A
Feb 18 11:05:36 intel-DUT kernel: [  129.687515] i915 0000:00:02.0: [drm:intel_hdmi_handle_sink_scrambling [i915]] [CONNECTOR:143:HDMI-A-1] scrambling=yes, TMDS bit clock ratio=1/40
Feb 18 11:05:36 intel-DUT kernel: [  129.691779] i915 0000:00:02.0: [drm:intel_fbc_enable [i915]] reserved 33177600 bytes of contiguous stolen space for FBC, threshold: 1
Feb 18 11:05:36 intel-DUT kernel: [  129.691943] i915 0000:00:02.0: [drm:intel_fbc_enable [i915]] Enabling FBC on pipe A
Feb 18 11:05:36 intel-DUT kernel: [  129.708798] i915 0000:00:02.0: [drm:verify_connector_state [i915]] [CONNECTOR:143:HDMI-A-1]
Feb 18 11:05:36 intel-DUT kernel: [  129.709088] i915 0000:00:02.0: [drm:intel_atomic_commit_tail [i915]] [CRTC:67:pipe A]
Feb 18 11:05:36 intel-DUT kernel: [  129.709531] i915 0000:00:02.0: [drm:verify_single_dpll_state.isra.102 [i915]] PORT PLL B
…

GLK-drm-tip.02172021kern.log

I made some workaround to treat this issue as handling of type-c with disconnection then doing modeset. https://lists.freedesktop.org/archives/intel-gfx/2021-February/261287.html

It's a bit hard to see from the log when things are happening. Can you insert some markers there to help see this. Could be done with something like:

1. echo "XXX turning off the monitor" > /dev/kmsg
2. turn off the monitor and maybe wait ~10s
3. echo "XXX turning on the monitor" > /dev/kmsg
4. turn on the monitor and wait a bit again
5. collect dmesg

Since it only happens with 4k I suspect it has something to do with the scrambling/bit clock ratio stuff. Can you try poking around in the SCDC registers a bit? IIRC would be something along the lines of:

1. modprobe i2c-dev
2. locate the correct i2c bus number with eg. echo /sys/class/drm/card0-HDMI-A-1/i2c*
   should give eg. /sys/class/drm/card0-HDMI-A-1/i2c-5 where the '5' is the bus number
3. Find out the current status from SCDC:
   i2cget <bus number> 0x54 0x20
   i2cget <bus number> 0x54 0x21
   i2cget <bus number> 0x54 0x40
4. could try to reset the scrambler stuff with something like
   i2cset <bus number> 0x54 0x20 0x0
   i2cset <bus number> 0x54 0x20 0x3

Hi @vsyrjala, Thanks for your help and guiding. Please refer this log file (GLK-issue_by_drm-tip-02172021.log)

Related status from SCDC when suffering issue

root@intel-DUT:~# ls -l /sys/class/drm/card0-HDMI-A-1/i2c*
lrwxrwxrwx 1 root root 0 Feb 22 13:49 /sys/class/drm/card0-HDMI-A-1/i2c-1 -> ../../../i2c-1
root@intel-DUT:~# i2cget 1 0x54 0x20
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will read from device file /dev/i2c-1, chip address 0x54, data address
0x20, using read byte data.
Continue? [Y/n] y
0x03
root@intel-DUT:~# i2cget 1 0x54 0x21
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will read from device file /dev/i2c-1, chip address 0x54, data address
0x21, using read byte data.
Continue? [Y/n] y
0x00
root@intel-DUT:~# i2cget 1 0x54 0x40
WARNING! This program can confuse your I2C bus, cause data loss and worse!
I will read from device file /dev/i2c-1, chip address 0x54, data address
0x40, using read byte data.
Continue? [Y/n] y
0x00

BTW I wrote register to reset the scrambler stuff with following commands but no effective result were observed.

root@intel-DUT:~#    i2cset 1 0x54 0x20 0x0
WARNING! This program can confuse your I2C bus, cause data loss and worse!
DANGEROUS! Writing to a serial EEPROM on a memory DIMM
may render your memory USELESS and make your system UNBOOTABLE!
I will write to device file /dev/i2c-1, chip address 0x54, data address
0x20, data 0x00, mode byte.
Continue? [y/N] y
root@intel-DUT:~#    i2cset 1 0x54 0x20 0x3
WARNING! This program can confuse your I2C bus, cause data loss and worse!
DANGEROUS! Writing to a serial EEPROM on a memory DIMM
may render your memory USELESS and make your system UNBOOTABLE!
I will write to device file /dev/i2c-1, chip address 0x54, data address
0x20, data 0x03, mode byte.
Continue? [y/N] y
root@intel-DUT:~#