[Bug 105534] amdgpu cannot set 2560x1440@60 mode even though monitor,gpu and motherboard support it
https://bugs.freedesktop.org/show_bug.cgi?id=105534
Bug ID: 105534 Summary: amdgpu cannot set 2560x1440@60 mode even though monitor,gpu and motherboard support it Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: philipmorant@gmail.com
Hardware: Raven Ridge 2200G Asrock A320M-HDV. Manual states max resolution for DVI 1920x1200@60 which is single link, however the board's DVI socket is clearly dual link. Monex WQHD which is known to work @ 2560x1440@60 with reduced blanking since it works on Intel Haswell with the i915 drivers. This monitor has only one input, which is dual link DVI. See below for edid-decode output. Dual channel DVI-D cable. This is a dual monitor setup. The other monitor is 1920x1080 over VGA/D-SUB.
Software: ubuntu bionic beaver with linux kernel 4.16.0-rc5+ and ppa:oibaf/graphics-drivers /lib/firmware/amdgpu/raven_gpu_info.bin is present (316 bytes). No customisation of xorg configuration files.
Possibly related bug reports: https://bugs.freedesktop.org/show_bug.cgi?id=102820 https://bugs.freedesktop.org/show_bug.cgi?id=104412
$ xrandr --newmode "2560x1440_60R" 241.50 2560 2608 2640 2720 1440 1443 1448 1481 +hsync -vsync $ xrandr --addmode HDMI-A-2 "2560x1440_60R" $ xrandr --output HDMI-A-2 --mode "2560x1440_60R" --verbose crtc 1: 2560x1440_60R 59.95 +0+0 "HDMI-A-2" xrandr: Configure crtc 1 failed crtc 0: disable crtc 1: disable crtc 2: disable crtc 3: disable screen 0: revert crtc 0: revert crtc 1: revert crtc 2: revert crtc 3: revert $ xrandr Screen 0: minimum 320 x 200, current 4480 x 1440, maximum 16384 x 16384 DisplayPort-0 connected primary 1920x1080+2560+360 (normal left inverted right x axis y axis) 478mm x 269mm 1920x1080 60.00*+ 1680x1050 59.95 1280x1024 75.02 1440x900 74.98 59.89 1280x960 60.00 1280x800 59.81 1152x864 75.00 1280x720 60.00 1152x720 59.97 1024x768 75.03 70.07 60.00 832x624 74.55 800x600 72.19 75.00 60.32 56.25 640x480 75.00 72.81 66.67 59.94 720x400 70.08 HDMI-A-0 disconnected (normal left inverted right x axis y axis) HDMI-A-1 disconnected (normal left inverted right x axis y axis) HDMI-A-2 connected (normal left inverted right x axis y axis) 2560x1440_60R 59.95
I've been running with drm.debug=0xf and searching log files but am unable to find any helpful error message.
$ edid-decode /sys/class/drm/card0-HDMI-A-3/edid Extracted contents: header: 00 ff ff ff ff ff ff 00 serial number: 12 ed fa 00 00 00 00 00 28 15 version: 01 03 basic params: a5 3c 22 78 22 chroma info: 6f b1 a7 55 4c 9e 25 0c 50 54 established: 00 00 00 standard: 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 descriptor 1: 56 5e 00 a0 a0 a0 29 50 30 20 35 00 55 50 21 00 00 1a descriptor 2: 00 00 00 fc 00 51 48 44 32 37 30 0a 20 20 20 20 20 20 descriptor 3: 00 00 00 fc 00 0a 20 20 20 20 20 20 20 20 20 20 20 20 descriptor 4: 00 00 00 fc 00 0a 20 20 20 20 20 20 20 20 20 20 20 20 extensions: 00 checksum: 8a
Manufacturer: DWM Model fa Serial Number 0 Made week 40 of 2011 EDID version: 1.3 Digital display DFP 1.x compatible TMDS Maximum image size: 60 cm x 34 cm Gamma: 2.20 DPMS levels: Off Supported color formats: RGB 4:4:4 First detailed timing is preferred timing Established timings supported: Standard timings supported: Detailed mode: Clock 241.500 MHz, 597 mm x 336 mm 2560 2608 2640 2720 hborder 0 1440 1443 1448 1481 vborder 0 +hsync -vsync Monitor name: QHD270 Checksum: 0x8a (valid) EDID block does NOT conform to EDID 1.3! Digital display field contains garbage: 24 Missing monitor ranges
https://bugs.freedesktop.org/show_bug.cgi?id=105534
Alex Deucher alexdeucher@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTABUG Status|NEW |RESOLVED
--- Comment #1 from Alex Deucher alexdeucher@gmail.com --- Please attach your dmesg output. Note that Raven does not support dual-link DVI. There is only a single digital encoder connected to each connector on the motherboards. You need two encoders (one for each link) per connector to run dual link DVI. You need to use native DP or HDMI for high res modes.
https://bugs.freedesktop.org/show_bug.cgi?id=105534
--- Comment #2 from philipmorant@gmail.com --- Will this work with an HDMI to DVI-D cable then ?
https://bugs.freedesktop.org/show_bug.cgi?id=105534
--- Comment #3 from Christian König ckoenig.leichtzumerken@gmail.com --- (In reply to philipmorant from comment #2)
Will this work with an HDMI to DVI-D cable then ?
No, DVI only supports up to 1920×1200 @ 60Hz with a single link.
It doesn't matter if the output is HDMI or DVI as long as your monitor only supports DVI input.
What you can use is either an active DP to dual DVI converter (probably rather expensive if such a thing even exists) or native DP/HDMI (if the monitor has connectors for that).
https://bugs.freedesktop.org/show_bug.cgi?id=105534
--- Comment #4 from philipmorant@gmail.com --- Thanks for replies. My monitor is DVI DL only.
My old Haswell i5 4670 with HD4600 graphics was also single link DVI only (https://communities.intel.com/thread/44135), and it worked at 60Hz. Could somebody please explain why haswell can do it but raven can't ?
Otherwise I find myself assuming that the hardware is capable of DL DVI, just that the manufacturers aren't validating for it, ergo fixable in software.
I understand if AMD object to coding for something that hasn't been validated (I'd do the same myself). Would it be possible alternatively to provide hints in log output or code comments or on a wiki somewhere, such that people in my position can hack the source themselves ?
Secondly, even accepting the single link limitation, shouldn't it be possible to run at 33 refresh rate ? I tried at 30 and got nothing.
Thirdly, why does amdgpu refer to the connection as HDMI-A-3 ? There's no HDMI in the setup at all.
https://bugs.freedesktop.org/show_bug.cgi?id=105534
--- Comment #5 from Alex Deucher alexdeucher@gmail.com --- (In reply to Christian König from comment #3)
What you can use is either an active DP to dual DVI converter (probably rather expensive if such a thing even exists) or native DP/HDMI (if the monitor has connectors for that).
They are actually relatively common for just these sorts of scenarios. Not sure about cost however.
(In reply to philipmorant from comment #4)
Thanks for replies. My monitor is DVI DL only.
My old Haswell i5 4670 with HD4600 graphics was also single link DVI only (https://communities.intel.com/thread/44135), and it worked at 60Hz. Could somebody please explain why haswell can do it but raven can't ?
I'm not sure how the intel hw is designed. I can't comment on exactly what is happening. I suspect what is happening is that the intel driver is not validating the link requirements and treating the DVI port like HDMI and sending the high bandwidth mode over a single TMDS link. The monitor just happens to accept it.
Otherwise I find myself assuming that the hardware is capable of DL DVI, just that the manufacturers aren't validating for it, ergo fixable in software.
No. DL DVI requires two digital transmitters, one for each TMDS link. We only wire a single transmitter to each physical connector. For DL DVI, you need two transmitters connected to the physical connector.
I understand if AMD object to coding for something that hasn't been validated (I'd do the same myself). Would it be possible alternatively to provide hints in log output or code comments or on a wiki somewhere, such that people in my position can hack the source themselves ?
You could try hacking the driver to treat the monitor as HDMI even through it's DL DVI. Maybe your monitor will accept the timing over a single TMDS link.
Secondly, even accepting the single link limitation, shouldn't it be possible to run at 33 refresh rate ? I tried at 30 and got nothing.
It depends on the hardware and the panel in the monitor. The monitor hardware may not like 30 Hz refresh rates.
Thirdly, why does amdgpu refer to the connection as HDMI-A-3 ? There's no HDMI in the setup at all.
The display connectors are read from a table in the bios and are determined by the OEM that designs the board. It our case the OEM seems to have set it up as 3 HDMI connectors and a DP connector. What physical connectors are actually on the board?
https://bugs.freedesktop.org/show_bug.cgi?id=105534
--- Comment #6 from Ville Syrjala ville.syrjala@linux.intel.com --- (In reply to Alex Deucher from comment #5)
(In reply to Christian König from comment #3)
What you can use is either an active DP to dual DVI converter (probably rather expensive if such a thing even exists) or native DP/HDMI (if the monitor has connectors for that).
They are actually relatively common for just these sorts of scenarios. Not sure about cost however.
(In reply to philipmorant from comment #4)
Thanks for replies. My monitor is DVI DL only.
My old Haswell i5 4670 with HD4600 graphics was also single link DVI only (https://communities.intel.com/thread/44135), and it worked at 60Hz. Could somebody please explain why haswell can do it but raven can't ?
I'm not sure how the intel hw is designed. I can't comment on exactly what is happening. I suspect what is happening is that the intel driver is not validating the link requirements and treating the DVI port like HDMI and sending the high bandwidth mode over a single TMDS link. The monitor just happens to accept it.
FYI in i915 we validate everything when enumerating the modes, but during a modeset we allow the user mode to exceed the DP++ dongle and sink limitations for just these sort of cases (source limitations we enforce always). The user has manually added the out-of-spec mode so presumably they know what they're doing...
Also we can't reliably tell what kind of connector is present on the board so we treat DVI and HDMI the same. DP++ we treat a little special because we can't actually read out the state of the CONFIG1 pin so we can't tell whether a type1 DVI DP++ dongle is present or not. So if we can't read out the dongle registers and the connector *looks* like a DP++ in the video BIOS tables we assume the dongle to be present. But again the user can still override this by forcing an out-of-spec mode.
https://bugs.freedesktop.org/show_bug.cgi?id=105534
--- Comment #7 from philipmorant@gmail.com --- There are 3 physical motherboard sockets: HDMI, DVI DL, and D-SUB. xrandr reports the D-SUB as DisplayPort-0.
In kernel versions before 4.10 I used to have to hack the i915 code as follows (in intel_hdmi.c):
@@ -849,7 +849,7 @@ static int hdmi_portclock_limit(struct intel_hdmi *hdmi, bool respect_dvi_limit) { struct drm_device *dev = intel_hdmi_to_dev(hdmi);
- if ((respect_dvi_limit && !hdmi->has_hdmi_sink) || IS_G4X(dev)) + if (IS_G4X(dev)) return 165000; else if (IS_HASWELL(dev) || INTEL_INFO(dev)->gen >= 8) return 300000;
After 4.10 came out the hack became unnecessary.
https://bugs.freedesktop.org/show_bug.cgi?id=105534
--- Comment #8 from Harry Wentland harry.wentland@amd.com --- (In reply to philipmorant from comment #4)
I understand if AMD object to coding for something that hasn't been validated (I'd do the same myself). Would it be possible alternatively to provide hints in log output or code comments or on a wiki somewhere, such that people in my position can hack the source themselves ?
The easiest way to hack this is probably to double TMDS_MAX_PIXEL_CLOCK in amd/display/include/signal_types.h from 165000 to 330000.
https://bugs.freedesktop.org/show_bug.cgi?id=105534
--- Comment #9 from philipmorant@gmail.com --- Created attachment 138199 --> https://bugs.freedesktop.org/attachment.cgi?id=138199&action=edit syslog for xrandr --addmode with drm.debug-0xe and TDMS_MAX_PIXEL_CLOCK 330000
https://bugs.freedesktop.org/show_bug.cgi?id=105534
--- Comment #10 from philipmorant@gmail.com --- Created attachment 138200 --> https://bugs.freedesktop.org/attachment.cgi?id=138200&action=edit syslog for xrandr --output with drm.debug-0xe and TDMS_MAX_PIXEL_CLOCK 330000
https://bugs.freedesktop.org/show_bug.cgi?id=105534
--- Comment #11 from philipmorant@gmail.com --- #TDMS_MAX_PIXEL_CLOCK 330000 makes no difference. See syslog files attached above.
https://bugs.freedesktop.org/show_bug.cgi?id=105534
--- Comment #12 from philipmorant@gmail.com --- static int amdgpu_connector_dvi_mode_valid(struct drm_connector *connector, struct drm_display_mode *mode) has a hard-coded 165000 and looks likely. I'll try hacking that to bits.
https://bugs.freedesktop.org/show_bug.cgi?id=105534
--- Comment #13 from philipmorant@gmail.com --- No, that's not it either. Apparently it's not going through amdgpu_connector_dvi_mode_valid(). My trace output (using DRM_ERROR()) does not appear in syslog.
https://bugs.freedesktop.org/show_bug.cgi?id=105534
--- Comment #14 from Alex Deucher alexdeucher@gmail.com --- (In reply to philipmorant from comment #13)
No, that's not it either. Apparently it's not going through amdgpu_connector_dvi_mode_valid(). My trace output (using DRM_ERROR()) does not appear in syslog.
That's the legacy pre-DC code.
dri-devel@lists.freedesktop.org
-
bugzilla-daemon＠freedesktop.org