Ville, Thanks for the additional detail! I looked up HPD and understand it is hot plug detection, but I didn't find much for "one byte caps format". I assume this is short hand for "capability format". Is the "one byte" format a limitation from the monitor, the dongle, the motherboard, or the chipset? What are some examples of other "capability formats"? Is there a recommended approach to setting the port to support Dual-Link based on EDID response (or is it too late by the time we get the EDID)? If there is no obvious automatic solution, do you have an example of a "manual override" (i.e. module argument) for another situation I can use as a guide? Still curious what DPCD DFP stands for. Thanks, Adam On Mon, May 31, 2021, at 10:15 AM, Ville Syrjälä wrote: > On Fri, May 28, 2021 at 02:15:46PM -0400, Adam Chasen wrote: > > Any further advice on tracing what is triggering what appears to be the limitation of the clock? My guess is it is imposing a DVI Single-Link speed (165000) limitation on the dual-link DVI adapter. > > > > > TMDS clock 25000-165000 > > > > I am able to override in xorg with xrandr to 268500 > > > > Per Ville's request: > > DPCD DFP: 0a > > > > What is the DPCD DFP? > > It indicates the port is DVI with HPD capability. But unfortunately it's > using the one byte caps format which doesn't let us differentiate > between single link and dual link DVI. So we take the more cautious > apporach and assume it's single link. > > > > > Thanks, > > Adam > > > > On Wed, May 12, 2021, at 5:07 PM, Adam Chasen wrote: > > > 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 > > > > > > > _______________________________________________ > > > Intel-gfx mailing list > > > Intel-gfx@xxxxxxxxxxxxxxxxxxxxx > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > > -- > Ville Syrjälä > Intel > _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
