[Intel-gfx] Tracing a "drm_mode_prune_invalid"

[Ville Syrjälä]

On Wed, May 12, 2021 at 12:31:14PM -0400, Adam Chasen wrote:
> Hoping I can (help) craft a patch to address what appears to be an issue with overaggressive mode pruning. I am having trouble with rejection of a Dual-DVI compatible mode out of the DisplayPort  specific to i915 in Fedora 33. It seems that drm_mode_validate_pipeline is the wall I hit when digging for why this mode is pruned. Requesting additional troubleshooting guidance.
> 
> ```
> kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline "2560x1600": 60 268000 2560 2608 2640 2720 1600 1603 1609 1646 0x48 0x9
> kernel: [drm:drm_mode_prune_invalid [drm]] Not using 2560x1600 mode: CLOCK_HIGH
> ```
> 
> This is an HP LP3065 Dual-DVI monitor connected via DisplayPort with a BizLink "active" adapter (recommended by HP and DELL for their Dual-DVI monitors).
> 
> The adapter appears to be "transparent" to the system (unlike some adapters reporting similar issues). I2C probes and EDIDs all appear to be direct from the monitor. Though, there is a mention of a m2DVIa "branch device" in the `i915_display_info` output.
> 
> The pruned mode works with X-Org with manually setting the mode via `xrandr` on Xorg (my current fallback setup): 
> `xrandr --newmode "2560x1600R" 268.50 2560 2608 2640 2720 1600 1603 1609 1646 +hsync -vsync`
> 
> My setup is a bit different than some older reported "dual mode" issues (i.e. passive adapters), so I do not believe it is the "faulty dual mode detection" (i.e. https://github.com/hansmi/fake-dp-dual-mode). I was thinking it could be related by some "state" of the port detection limiting output to 165MHz clock.
> 
> Thanks,
> Adam
> 
> with `echo 0x6 > /sys/module/drm/parameters/debug`
> 
> ```
> kernel: [drm:drm_add_display_info [drm]] Supported Monitor Refresh rate range is 0 Hz - 0 Hz
> kernel: [drm:drm_add_display_info [drm]] non_desktop set to 0
> kernel: i915 0000:00:02.0: [drm:intel_dp_set_edid [i915]] [CONNECTOR:95:DP-1] DFP max bpc 8, max dotclock 0, TMDS clock 25000-165000

That one seems to be saying that it's the adapter itself that's
telling us it can't handle >165MHz. What does the "DPCD DFP: ..." line say?

Alternatively you can do something like
 for aux in /dev/drm_dp_aux* ; do dd if=$aux bs=1 count=16 skip=$((0x80)) 2>/dev/null | hexdump -C ; done
to get the raw dump..

-- 
Ville Syrjälä
Intel