Created attachment 116968 [details] dmesg of full boot + setting external display to mode with 297 MHz clock Starting from stock linux 4.1.0 source, libdrm 2.4.61, xf86-video-nouveau-1.0.11, xorg-server 1.17.1. The hardware is a Quatro 2000M in a Lenovo W520 laptop setup as an offload sink and output source for an integrated intel display. The external display is a Seiki SE39UY04 connected by HDMI to display port passive adapter. We attempted to use a 3840x2160@30 mode which has a pixel clock of 297 MHz. This is known to work fine in both the nvidia blob and the windows driver, so the hardware has no issues driving this clock in a single TDMS link. First the connector detection code will reject this mode from the default list because the maximum TDMS speed is based on pre-HDMI 1.3 spec. Second even if that is worked around the mode is higher than 165 MHz, so the display port connection will enter dual link mode, which must be stopped in this case. We attempted to allow the mode to pass through to see if it might just work. There were two changes: drivers/gpu/drm/nouveau/nouvau_connector.c modified get_tmds_link_bandwidth() to return 340000 (HDMI 1.3 spec) drivers/gpu/drm/nouveau/nvkm/engine/disp/nv50.c commented out line 1547-1548 to not use dual link mode. The result is a failure. The screen flickers and does not show anything. A full dmesg log with nouveau.debug=trace is attached. I am a C programmer but I have no familiarity with any part of the nouveau or DRM parts of the world. Very willing to help, just don't know where to proceed.
Look for the series starting with [PATCH 0/2] drm/nouveau: add support for 2560x1440@56 over HDMI sent to nouveau and dri-devel on Aug 8. It limits things to 225mhz though. We did some poking around with various VBIOS's, I think I found the place where the max freq is stored, but would be curious to see yours (can be grabbed from /sys/kernel/debug/dri/0/vbios.rom).
Created attachment 119057 [details] Video Bios
(In reply to Andrew Boettcher from comment #2) > Created attachment 119057 [details] > Video Bios Blast! According to my theory you'd only have 225MHz on this card. You're sure about 297MHz working? FTR my theory is that the bit 'T' table contains this info, which with your vbios is: BIT table 'T' version 1 at 0x02d8 length 0x0002 Unknown BIT table 'T' version 1 0x02d8: 41 b5 0000b540 71 20 0d 04 00 00 50 32 74 40 e8 80 e4 57 5b fd |q ....P2t@...W[.| 0x4074 = 16500 (single-link dvi) 0x80e8 = 33000 (dual-link dvi) 0x57e4 = 22500 -- my theory for max hdmi link speed
(In reply to Ilia Mirkin from comment #3) > Blast! According to my theory you'd only have 225MHz on this card. You're > sure about 297MHz working? I have a passive HDMI connector and I can get a 297 mhz mode from the binary blob as well as in windows over that connector. So they are either doing something special behind the scenes or that table is not the whole truth.
With the below pair of patches, you should be able to set any max pixel clock you like. http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=8d5fe3328855063bb41acb00b1049138acce8e2e http://cgit.freedesktop.org/~darktama/nouveau/commit/?id=f787ef9b44102ed01d4255a653d0261bb6365ba3 These should apply relatively easily onto a 4.3 or even older kernel. Boot with nouveau.hdmimhz=297.
I am reporting the patches worked great! Indeed I am now viewing this bug with a screen in 297 MHz over a passive DP to HDMI connector. Before we missed the second part where the dual link mode was activated. This is great, thanks! I guess the next step is to figure out how to detect the real limit, which I believe is 300 MHz on this chip.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-nouveau/issues/200.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.