[Intel-gfx] Tracing a "drm_mode_prune_invalid"

Wed May 12 21:07:49 UTC 2021

Ville,
DPCD DFP: 0a

What is the DPCD DFP?

Additional info, this is the first time there has been an issue with this adapter not working (i.e. it must have been operating above 165MHz), but it is possible other drivers have "ignored" things and just followed the EDID.

Thanks!
Adam

kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:95:DP-1] 
kernel: i915 0000:00:02.0: [drm:intel_dp_detect [i915]] [CONNECTOR:95:DP-1]
kernel: [drm:drm_dp_read_dpcd_caps [drm_kms_helper]] AUX C/DDI C/PHY C: DPCD: 11 0a 84 01 00 05 00 81 00 00 00 00 00 00 00
kernel: [drm:drm_dp_read_desc [drm_kms_helper]] AUX C/DDI C/PHY C: DP branch: OUI 00-80-e1 dev-ID m2DVIa HW-rev 0.1 SW-rev 2.0 quirks 0x0000
kernel: [drm:drm_dp_read_downstream_info [drm_kms_helper]] AUX C/DDI C/PHY C: DPCD DFP: 0a
kernel: i915 0000:00:02.0: [drm:intel_dp_detect [i915]] [ENCODER:94:DDI C/PHY C] MST support: port: yes, sink: no, modparam: yes
kernel: i915 0000:00:02.0: [drm:intel_dp_print_rates [i915]] source rates: 162000, 216000, 270000, 324000, 432000, 540000
kernel: i915 0000:00:02.0: [drm:intel_dp_print_rates [i915]] sink rates: 162000, 270000
kernel: i915 0000:00:02.0: [drm:intel_dp_print_rates [i915]] common rates: 162000, 270000
kernel: [drm:drm_dp_i2c_do_msg [drm_kms_helper]] AUX C/DDI C/PHY C: native defer
kernel: [drm:drm_dp_i2c_do_msg [drm_kms_helper]] AUX C/DDI C/PHY C: native defer
kernel: [drm:drm_dp_i2c_do_msg [drm_kms_helper]] AUX C/DDI C/PHY C: native defer
kernel: [drm:drm_dp_i2c_do_msg [drm_kms_helper]] AUX C/DDI C/PHY C: native defer
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
kernel: i915 0000:00:02.0: [drm:intel_dp_set_edid [i915]] [CONNECTOR:95:DP-1] YCbCr 4:2:0 allowed? no, YCbCr 4:4:4->4:2:0 conversion? no 
kernel: [drm:drm_dp_get_edid_quirks [drm_kms_helper]] DP sink: EDID mfg 22-f0 prod-ID 90-26 quirks: 0x0000
kernel: [drm:drm_add_edid_modes [drm]] ELD: no CEA Extension found
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: [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
kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:95:DP-1] probed modes :
kernel: [drm:drm_mode_debug_printmodeline [drm]] Modeline "1280x800": 60 71000 1280 1328 1360 1440 800 803 809 823 0x40 0x9

# for aux in /dev/drm_dp_aux* ; do dd if=$aux bs=1 count=16 skip=$((0x80)) 2>/dev/null | hexdump -C ; done
00000000  0a 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000010

# for aux in /dev/drm_dp_aux* ; do dd if=$aux bs=1 2>/dev/null | hexdump -C ; done
00000000  11 0a 84 01 00 05 00 81  00 00 00 00 00 00 00 00  |................|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000080  0a 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000100  0a 84 00 08 08 08 08 00  01 00 00 00 00 00 00 00  |................|
00000110  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  01 00 77 77 81 00 44 44  00 00 00 00 00 00 00 00  |..ww..DD........|
00000210  00 80 00 80 00 80 00 80  00 00 00 00 00 00 00 00  |................|
00000220  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000240  00 00 00 00 00 00 20 00  00 00 00 00 00 00 00 00  |...... .........|
00000250  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000300  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 80  |................|
00000310  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400  47 53 53 00 00 01 01 00  01 00 00 90 02 00 00 90  |GSS.............|
00000410  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000500  00 80 e1 6d 32 44 56 49  61 01 02 00 00 cf 00 00  |...m2DVIa.......|
00000510  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000600  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000610  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*

On Wed, May 12, 2021, at 4:04 PM, Ville Syrjälä wrote:
> 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
> 