Re: Tracing a "drm_mode_prune_invalid"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?

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
> 
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux