* [Intel-gfx] Tracing a "drm_mode_prune_invalid"
@ 2021-05-12 16:31 Adam Chasen
2021-05-12 20:04 ` Ville Syrjälä
0 siblings, 1 reply; 9+ messages in thread
From: Adam Chasen @ 2021-05-12 16:31 UTC (permalink / raw)
To: intel-gfx
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
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_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_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
kernel: [drm:drm_helper_probe_single_connector_modes [drm_kms_helper]] [CONNECTOR:106:HDMI-A-1]
```
./edid-decode /sys/devices/pci0000:00/0000:00:02.0/drm/card0/card0-DP-1/edid
```
edid-decode (hex):
00 ff ff ff ff ff ff 00 22 f0 90 26 01 01 01 01
16 14 01 03 80 40 28 78 2a 8f 95 ad 4f 32 b2 25
0f 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 b0 68 00 a0 a0 40 2e 60 30 20
36 00 81 90 21 00 00 1a bc 1b 00 a0 50 20 17 30
30 20 36 00 81 90 21 00 00 1a 00 00 00 fc 00 48
50 20 4c 50 33 30 36 35 0a 20 20 20 00 00 00 ff
00 43 4e 34 30 32 32 30 51 39 43 0a 20 20 00 77
----------------
Block 0, Base EDID:
...
Detailed Timing Descriptors:
DTD 1: 2560x1600 59.860 Hz 8:5 98.529 kHz 268.000 MHz (641 mm x 400 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 6 Vback 37 Vpol N
DTD 2: 1280x800 59.910 Hz 8:5 49.306 kHz 71.000 MHz (641 mm x 400 mm)
Hfront 48 Hsync 32 Hback 80 Hpol P
Vfront 3 Vsync 6 Vback 14 Vpol N
Display Product Name: 'HP LP3065'
...
```
/sys/kernel/debug/dri/0/i915_display_info
```
CRTC info
---------
[CRTC:51:pipe A]:
uapi: enable=yes, active=yes, mode="1280x800": 60 71000 1280 1328 1360 1440 800 803 809 823 0x40 0x9
hw: active=yes, adjusted_mode="1280x800": 60 71000 1280 1328 1360 1440 800 803 809 823 0x40 0x9
pipe src size=1280x800, dither=no, bpp=24
num_scalers=2, scaler_users=0 scaler_id=-1, scalers[0]: use=no, mode=0, scalers[1]: use=no, mode=0
[ENCODER:94:DDI C/PHY C]: connectors:
[CONNECTOR:95:DP-1]
[PLANE:31:plane 1A]: type=PRI
uapi: [FB:133] XR24 little-endian (0x34325258),0x100000000000001,1280x800, visible=visible, src=1280.000000x800.000000+0.000000+0.000000, dst=1280x800+0+0, rotation=0 (0x00000001)
hw: [FB:133] XR24 little-endian (0x34325258),0x100000000000001,1280x800, visible=yes, src=1280.000000x800.000000+0.000000+0.000000, dst=1280x800+0+0, rotation=0 (0x00000001)
[PLANE:39:plane 2A]: type=OVL
uapi: [FB:0] n/a,0x0,0x0, visible=hidden, src=0.000000x0.000000+0.000000+0.000000, dst=0x0+0+0, rotation=0 (0x00000001)
[PLANE:47:cursor A]: type=CUR
uapi: [FB:0] n/a,0x0,0x0, visible=hidden, src=0.000000x0.000000+0.000000+0.000000, dst=0x0+0+0, rotation=0 (0x00000001)
underrun reporting: cpu=yes pch=yes
...
Connector info
--------------
[CONNECTOR:95:DP-1]: status: connected
physical dimensions: 640x400mm
subpixel order: Unknown
CEA rev: 0
DPCD rev: 11
audio support: no
DP branch device present: yes
Type: DVI
ID: m2DVIa
HW: 0.1
SW: 2.0
HDCP version: HDCP1.4
modes:
"1280x800": 60 71000 1280 1328 1360 1440 800 803 809 823 0x40 0x9
[CONNECTOR:106:HDMI-A-1]: status: disconnected
...
```
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Intel-gfx] Tracing a "drm_mode_prune_invalid"
2021-05-12 16:31 [Intel-gfx] Tracing a "drm_mode_prune_invalid" Adam Chasen
@ 2021-05-12 20:04 ` Ville Syrjälä
2021-05-12 21:07 ` Adam Chasen
0 siblings, 1 reply; 9+ messages in thread
From: Ville Syrjälä @ 2021-05-12 20:04 UTC (permalink / raw)
To: Adam Chasen; +Cc: intel-gfx
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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Intel-gfx] Tracing a "drm_mode_prune_invalid"
2021-05-12 20:04 ` Ville Syrjälä
@ 2021-05-12 21:07 ` Adam Chasen
2021-05-28 18:15 ` Adam Chasen
0 siblings, 1 reply; 9+ messages in thread
From: Adam Chasen @ 2021-05-12 21:07 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Intel-gfx] Tracing a "drm_mode_prune_invalid"
2021-05-12 21:07 ` Adam Chasen
@ 2021-05-28 18:15 ` Adam Chasen
2021-05-31 14:15 ` Ville Syrjälä
0 siblings, 1 reply; 9+ messages in thread
From: Adam Chasen @ 2021-05-28 18:15 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Intel-gfx] Tracing a "drm_mode_prune_invalid"
2021-05-28 18:15 ` Adam Chasen
@ 2021-05-31 14:15 ` Ville Syrjälä
2021-05-31 14:28 ` Adam Chasen
0 siblings, 1 reply; 9+ messages in thread
From: Ville Syrjälä @ 2021-05-31 14:15 UTC (permalink / raw)
To: Adam Chasen; +Cc: intel-gfx
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@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Intel-gfx] Tracing a "drm_mode_prune_invalid"
2021-05-31 14:15 ` Ville Syrjälä
@ 2021-05-31 14:28 ` Adam Chasen
2021-06-04 16:57 ` Adam Chasen
0 siblings, 1 reply; 9+ messages in thread
From: Adam Chasen @ 2021-05-31 14:28 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
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@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >
>
> --
> Ville Syrjälä
> Intel
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Intel-gfx] Tracing a "drm_mode_prune_invalid"
2021-05-31 14:28 ` Adam Chasen
@ 2021-06-04 16:57 ` Adam Chasen
2021-06-04 17:13 ` Ville Syrjälä
0 siblings, 1 reply; 9+ messages in thread
From: Adam Chasen @ 2021-06-04 16:57 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
Thanks for staying with me! Still hoping I can get back to using KMS/Wayland combination with my setup.
I understand the current recommendation is to push the mode setting to the wayland compositor per Ville here: https://gitlab.freedesktop.org/drm/intel/-/issues/393#note_337616
Alas, I am using Mutter (similar to issue #393) which (historically) doesn't support mode setting (yet?).
There is mention of drm_dp_downstream_max_clock() in an i915 comment, which looks like could be a reference to drm_dp_downstream_max_tmds_clock().
It seems there is a hard coded 165MHz max for DP_DWN_STRM_PORT_TYPE_TMDS or (note the comment in the below code):
case DP_DS_PORT_TYPE_DVI:
if ((dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE) == 0)
return 165000;
/* FIXME what to do about DVI dual link? */
return port_cap[1] * 2500;
Still wondering about the "one byte" format is for configuration, but I presume it is setting DP_DETAILED_CAP_INFO_AVAILABLE to 0 which triggers this.
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)?
Is there a recommended approach for a "disable filter", or "manual modeset"? There are others who seem interested in overriding the filtering logic (e.g. "do what I say even though it isn't clear it will work"). https://gitlab.freedesktop.org/drm/intel/-/issues/393#note_829142
-Adam
-- Related --
I found these following a thread on the 165MHz clock limit in the context of DP dual mode HDMI dongles with a patch experimenting with turning off the limit: https://bugs.freedesktop.org/show_bug.cgi?id=112018#c2 (now https://gitlab.freedesktop.org/drm/intel/-/issues/511) There is even a hack for what appears to be a similar limitation
(using Dual mode DP): https://github.com/hansmi/fake-dp-dual-mode
Researching answers for previous questions:
"one byte" cap:
/*
* 0x80-0x8f describe downstream port capabilities, but there are two layouts
* based on whether DP_DETAILED_CAP_INFO_AVAILABLE was set. If it was not,
* each port's descriptor is one byte wide. If it was set, each port's is
* four bytes wide, starting with the one byte from the base info. As of
* DP interop v1.1a only VGA defines additional detail.
*/
And from a commit:
* Fixup logic for calculating the downstream port length to account for
the fact that downstream port caps can be either 1 byte or 4 bytes
long. We can actually skip fixing the max_clock/max_bpc helpers here
since they all check for DP_DETAILED_CAP_INFO_AVAILABLE anyway.
DPCD = DisplayPort Configuration Data
DFP appears to be a structure to hold configuration data as part of intel_attached_dp(connector):
/* Downstream facing port caps */
struct {
int min_tmds_clock, max_tmds_clock;
int max_dotclock;
u8 max_bpc;
bool ycbcr_444_to_420;
} dfp;
On Mon, May 31, 2021, at 10:28 AM, Adam Chasen wrote:
> 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@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > >
> >
> > --
> > Ville Syrjälä
> > Intel
> >
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Intel-gfx] Tracing a "drm_mode_prune_invalid"
2021-06-04 16:57 ` Adam Chasen
@ 2021-06-04 17:13 ` Ville Syrjälä
2021-08-26 14:59 ` Adam Chasen
0 siblings, 1 reply; 9+ messages in thread
From: Ville Syrjälä @ 2021-06-04 17:13 UTC (permalink / raw)
To: Adam Chasen; +Cc: intel-gfx
On Fri, Jun 04, 2021 at 12:57:25PM -0400, Adam Chasen wrote:
> Thanks for staying with me! Still hoping I can get back to using KMS/Wayland combination with my setup.
>
> I understand the current recommendation is to push the mode setting to the wayland compositor per Ville here: https://gitlab.freedesktop.org/drm/intel/-/issues/393#note_337616
>
> Alas, I am using Mutter (similar to issue #393) which (historically) doesn't support mode setting (yet?).
>
> There is mention of drm_dp_downstream_max_clock() in an i915 comment, which looks like could be a reference to drm_dp_downstream_max_tmds_clock().
>
> It seems there is a hard coded 165MHz max for DP_DWN_STRM_PORT_TYPE_TMDS or (note the comment in the below code):
>
> case DP_DS_PORT_TYPE_DVI:
> if ((dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE) == 0)
> return 165000;
> /* FIXME what to do about DVI dual link? */
> return port_cap[1] * 2500;
>
> Still wondering about the "one byte" format is for configuration, but I presume it is setting DP_DETAILED_CAP_INFO_AVAILABLE to 0 which triggers this.
>
> 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)?
EDID can't help us since it would only tell us whether the display
supports dual-link or not. The dongle may still be single link only.
>
> Is there a recommended approach for a "disable filter", or "manual modeset"? There are others who seem interested in overriding the filtering logic (e.g. "do what I say even though it isn't clear it will work"). https://gitlab.freedesktop.org/drm/intel/-/issues/393#note_829142
Userspace is free to force any it wants. But I guess mutter+wayland
doesn't support that for some reason.
I've occasionally pondered about adding some kind of connector property
for this, but not sure wht it should look like. And it would still
require userspace support to set it. Another idea would be to extend the
video= cmdline with some kind of knob that lets you override these
limits. But again it's a bit hard to come up with a decent solution since
there are various different clock limits involved (TMDS clock for HDMI
vs. link rate for DP, dotclock for everyting). And just saying "ignore
all limits" is not a very flexible solution since there may be some
limit you do want to enforce, just not as low as what we would
auto-detect.
>
> -Adam
>
> -- Related --
>
> I found these following a thread on the 165MHz clock limit in the context of DP dual mode HDMI dongles with a patch experimenting with turning off the limit: https://bugs.freedesktop.org/show_bug.cgi?id=112018#c2 (now https://gitlab.freedesktop.org/drm/intel/-/issues/511) There is even a hack for what appears to be a similar limitation
> (using Dual mode DP): https://github.com/hansmi/fake-dp-dual-mode
>
> Researching answers for previous questions:
>
> "one byte" cap:
> /*
> * 0x80-0x8f describe downstream port capabilities, but there are two layouts
> * based on whether DP_DETAILED_CAP_INFO_AVAILABLE was set. If it was not,
> * each port's descriptor is one byte wide. If it was set, each port's is
> * four bytes wide, starting with the one byte from the base info. As of
> * DP interop v1.1a only VGA defines additional detail.
> */
>
> And from a commit:
> * Fixup logic for calculating the downstream port length to account for
> the fact that downstream port caps can be either 1 byte or 4 bytes
> long. We can actually skip fixing the max_clock/max_bpc helpers here
> since they all check for DP_DETAILED_CAP_INFO_AVAILABLE anyway.
>
> DPCD = DisplayPort Configuration Data
> DFP appears to be a structure to hold configuration data as part of intel_attached_dp(connector):
> /* Downstream facing port caps */
> struct {
> int min_tmds_clock, max_tmds_clock;
> int max_dotclock;
> u8 max_bpc;
> bool ycbcr_444_to_420;
> } dfp;
>
> On Mon, May 31, 2021, at 10:28 AM, Adam Chasen wrote:
> > 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@lists.freedesktop.org
> > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > > >
> > >
> > > --
> > > Ville Syrjälä
> > > Intel
> > >
> > _______________________________________________
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
--
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Intel-gfx] Tracing a "drm_mode_prune_invalid"
2021-06-04 17:13 ` Ville Syrjälä
@ 2021-08-26 14:59 ` Adam Chasen
0 siblings, 0 replies; 9+ messages in thread
From: Adam Chasen @ 2021-08-26 14:59 UTC (permalink / raw)
To: Ville Syrjälä; +Cc: intel-gfx
Ville,
It appears we are receiving some minimal information about the DP to dual-link DVI adapter which may be used to indicate dual-link support. Any chance we can use this information to augment the EDID to not filter out the higher clocks?
> EDID can't help us since it would only tell us whether the display
> supports dual-link or not. The dongle may still be single link only.
[CONNECTOR:95:DP-1]: status: connected
...
DP branch device present: yes
Type: DVI
ID: ***m2DVIa***
HW: 0.1
SW: 2.0
...
I very well may be barking up the wrong tree with the following:
The "DP-1" reports a "branch device" with an "ID" of m2DVIa which is mentioned in another (amd) video driver:
> +/*DP to Dual link DVI converter*/
> +static const uint8_t DP_DVI_CONVERTER_ID_4[] = "m2DVIa";
> +static const uint8_t DP_DVI_CONVERTER_ID_5[] = "3393N2";
from https://lore.kernel.org/patchwork/patch/1338037/
This is used here which appears to do something with I2C: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/display/dc/core/dc_link_ddc.c#L309
There are mention of a small number of "external converter chips" which are used in the above conditional: https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/amd/display/include/ddc_service_types.h#L30
Thanks,
Adam
On Fri, Jun 4, 2021, at 1:13 PM, Ville Syrjälä wrote:
> On Fri, Jun 04, 2021 at 12:57:25PM -0400, Adam Chasen wrote:
> > Thanks for staying with me! Still hoping I can get back to using KMS/Wayland combination with my setup.
> >
> > I understand the current recommendation is to push the mode setting to the wayland compositor per Ville here: https://gitlab.freedesktop.org/drm/intel/-/issues/393#note_337616
> >
> > Alas, I am using Mutter (similar to issue #393) which (historically) doesn't support mode setting (yet?).
> >
> > There is mention of drm_dp_downstream_max_clock() in an i915 comment, which looks like could be a reference to drm_dp_downstream_max_tmds_clock().
> >
> > It seems there is a hard coded 165MHz max for DP_DWN_STRM_PORT_TYPE_TMDS or (note the comment in the below code):
> >
> > case DP_DS_PORT_TYPE_DVI:
> > if ((dpcd[DP_DOWNSTREAMPORT_PRESENT] & DP_DETAILED_CAP_INFO_AVAILABLE) == 0)
> > return 165000;
> > /* FIXME what to do about DVI dual link? */
> > return port_cap[1] * 2500;
> >
> > Still wondering about the "one byte" format is for configuration, but I presume it is setting DP_DETAILED_CAP_INFO_AVAILABLE to 0 which triggers this.
> >
> > 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)?
>
> EDID can't help us since it would only tell us whether the display
> supports dual-link or not. The dongle may still be single link only.
>
> >
> > Is there a recommended approach for a "disable filter", or "manual modeset"? There are others who seem interested in overriding the filtering logic (e.g. "do what I say even though it isn't clear it will work"). https://gitlab.freedesktop.org/drm/intel/-/issues/393#note_829142
>
> Userspace is free to force any it wants. But I guess mutter+wayland
> doesn't support that for some reason.
>
> I've occasionally pondered about adding some kind of connector property
> for this, but not sure wht it should look like. And it would still
> require userspace support to set it. Another idea would be to extend the
> video= cmdline with some kind of knob that lets you override these
> limits. But again it's a bit hard to come up with a decent solution since
> there are various different clock limits involved (TMDS clock for HDMI
> vs. link rate for DP, dotclock for everyting). And just saying "ignore
> all limits" is not a very flexible solution since there may be some
> limit you do want to enforce, just not as low as what we would
> auto-detect.
>
> >
> > -Adam
> >
> > -- Related --
> >
> > I found these following a thread on the 165MHz clock limit in the context of DP dual mode HDMI dongles with a patch experimenting with turning off the limit: https://bugs.freedesktop.org/show_bug.cgi?id=112018#c2 (now https://gitlab.freedesktop.org/drm/intel/-/issues/511) There is even a hack for what appears to be a similar limitation
> > (using Dual mode DP): https://github.com/hansmi/fake-dp-dual-mode
> >
> > Researching answers for previous questions:
> >
> > "one byte" cap:
> > /*
> > * 0x80-0x8f describe downstream port capabilities, but there are two layouts
> > * based on whether DP_DETAILED_CAP_INFO_AVAILABLE was set. If it was not,
> > * each port's descriptor is one byte wide. If it was set, each port's is
> > * four bytes wide, starting with the one byte from the base info. As of
> > * DP interop v1.1a only VGA defines additional detail.
> > */
> >
> > And from a commit:
> > * Fixup logic for calculating the downstream port length to account for
> > the fact that downstream port caps can be either 1 byte or 4 bytes
> > long. We can actually skip fixing the max_clock/max_bpc helpers here
> > since they all check for DP_DETAILED_CAP_INFO_AVAILABLE anyway.
> >
> > DPCD = DisplayPort Configuration Data
> > DFP appears to be a structure to hold configuration data as part of intel_attached_dp(connector):
> > /* Downstream facing port caps */
> > struct {
> > int min_tmds_clock, max_tmds_clock;
> > int max_dotclock;
> > u8 max_bpc;
> > bool ycbcr_444_to_420;
> > } dfp;
> >
> > On Mon, May 31, 2021, at 10:28 AM, Adam Chasen wrote:
> > > 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@lists.freedesktop.org
> > > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > > > >
> > > >
> > > > --
> > > > Ville Syrjälä
> > > > Intel
> > > >
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > >
>
> --
> Ville Syrjälä
> Intel
>
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-08-26 15:00 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-05-12 16:31 [Intel-gfx] Tracing a "drm_mode_prune_invalid" Adam Chasen
2021-05-12 20:04 ` Ville Syrjälä
2021-05-12 21:07 ` Adam Chasen
2021-05-28 18:15 ` Adam Chasen
2021-05-31 14:15 ` Ville Syrjälä
2021-05-31 14:28 ` Adam Chasen
2021-06-04 16:57 ` Adam Chasen
2021-06-04 17:13 ` Ville Syrjälä
2021-08-26 14:59 ` Adam Chasen
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.