Bug 105302 - [DC] - Maximum pixel clock of dual-link DVI too low for some modes
Summary: [DC] - Maximum pixel clock of dual-link DVI too low for some modes
Status: RESOLVED MOVED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/AMDgpu (show other bugs)
Version: DRI git
Hardware: x86-64 (AMD64) Linux (All)
: medium enhancement
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-01 05:34 UTC by Andrew Sheldon
Modified: 2019-11-19 08:31 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Andrew Sheldon 2018-03-01 05:34:04 UTC
I have a monitor that supports 2560x1440 >60hz (up to around 110hz) through the DVI-D interface but requires pixel clocks greater than the current dual-link limit of 330khz, with amdgpu.dc=1. Setting TMDS_MAX_PIXEL_CLOCK to 250000 in signal_types.h works around the problem. 

amdgpu.dc=0 doesn't appear to have this limit (or the value is higher) so the problem does not exist there.

I'm using ~ag5df's drm-next-4.17-wip branch.

There appears to be a discussion about setting a higher pixel clock limit in this bug: https://bugs.freedesktop.org/show_bug.cgi?id=93885 but focused on HDMI and not DVI-D, and regarding the older radeon driver.
Comment 1 Alex Deucher 2018-03-01 14:49:40 UTC
The non-DC code should really have limited this too.  It's probably a bug there.  As to what the actual limit is, hopefully Harry can comment on that.
Comment 2 Harry Wentland 2018-03-01 19:41:14 UTC
I don't have the spec right now but wikipedia has a nice run-down of the DVI bounding box: https://en.wikipedia.org/wiki/Digital_Visual_Interface#Digital

Basically 2560x1600 @ 60Hz is the highest allowed for dual-link, which is just a tad above your 2560x1440 @ 60Hz. 110Hz at full resolution would definitely not be supported by DVI.

What monitor are you using? Is it intended to support 110Hz at full resolution on DVI? Could it be that this full monitor capabilities are only supported through DP?
Comment 3 Andrew Sheldon 2018-03-01 23:42:49 UTC
(In reply to Harry Wentland from comment #2)
> I don't have the spec right now but wikipedia has a nice run-down of the DVI
> bounding box: https://en.wikipedia.org/wiki/Digital_Visual_Interface#Digital
> 
> Basically 2560x1600 @ 60Hz is the highest allowed for dual-link, which is
> just a tad above your 2560x1440 @ 60Hz. 110Hz at full resolution would
> definitely not be supported by DVI.
> 
> What monitor are you using? Is it intended to support 110Hz at full
> resolution on DVI? Could it be that this full monitor capabilities are only
> supported through DP?

It's a cheap Korean monitor that only supports DVI-D (Qnix qx2710 single input version), and unofficially supports greater than 60hz. You're right, it's above DVI-D spec but it would be nice to have an option to use higher pixel clocks nevertheless. The Nvidia binary drivers have the option for ignoring the pixel clock check so there is at least one example of this being supported in the wild.
Comment 4 Harry Wentland 2018-03-02 15:03:50 UTC
This sounds like a feature request, rather than a bug.
Comment 5 Alex Deucher 2018-03-02 15:39:13 UTC
I'd rather not support running things out of spec in the driver.  The source is open.  If you want to adjust the code allow something like that you can.
Comment 6 Andrew Sheldon 2018-03-08 09:06:39 UTC
(In reply to Alex Deucher from comment #5)
> I'd rather not support running things out of spec in the driver.  The source
> is open.  If you want to adjust the code allow something like that you can.

Fair enough, it's simple enough to patch the source for a higher limit.
Comment 7 Martin Peres 2019-11-19 08:31:47 UTC
-- 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/drm/amd/issues/319.


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.