Bug 1662754

Summary: allow a patch that makes elder radeon cards UltraHD ready
Product: [Fedora] Fedora Reporter: Elmar Stellnberger <estellnb>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: airlied, bskeggs, ewk, hdegoede, ichavero, itamar, jarodwilson, jglisse, john.j5live, jonathan, josef, kernel-maint, labbott, linville, mchehab, mjg59, steved
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-01-02 16:58:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
radeon.hdmimhz patch
none
optional: radeon.duallink patch none

Description Elmar Stellnberger 2019-01-01 16:26:23 UTC 
Created attachment 1517748 [details]
radeon.hdmimhz patch

In March 2016 I had developed a kernel patch that allows to set the TMDS frequency for Radeon cards by a new kernel parameter called radeon.hdmimhz if the automatically set frequency stays either behind of what has been advertised for the card or by what is achievable through overclocking. A similar parameter for Nvidia/Nouveau cards is already available somewhat longer. There exists a patched ATI driver even for Windows. However up to now the patch has not been accepted into the mainline kernel simply because Radeon developers are not encouraged to enable this feature for elder cards by the policy of their sponsors. Here are some of my considerations which you may take into account when deciding about the acceptance of the patch for Fedora:
   * the patch is very simple, just a few lines of code
   * behaviour of the kernel is not influenced by the patch except when the user gives a non-zero value for radeon.hdmimhz
   * the patch has already wheathered time; the surrounding code has more or less remained unchanged since March
   * long time usage experience is available at least with the Radeon R5 230 and the Radeon HD 6770 cards (no heast issues) as well as different monitors; my personal experience with the patch is very good
   * the patch provides a huge advantage at least for all people who still use Core 2 based systems:
     - elder Radeon cards can be made UHD ready
     - the R5 230 card supported by the patch may be the only one of its type that has a single slot height - and it has been sold to me as DVI-UltraHD ready; however this feature can not be exploited without the kernel patch
     - newer Radeon cards are often incompatible with elder Core 2 systems
   * at least Nouveau developers say that by overclocking your TMDS it would hardly be possible to damage a card even if it shows heat issues; a way of proceeding considered safe can be read in the linked article https://www.elstel.org/software/hunt-for-4K-UHD-2160p.html.en. The patch can also be found on this website; see also: https://bugs.freedesktop.org/show_bug.cgi?id=93885#c24. Mageia was the first distribution to accept this patch. The patch is safe and has been proven useful (since then many people with positive experience have linked to my site) - so why do we not include it for Fedora?
Comment 1 Elmar Stellnberger 2019-01-01 16:27:06 UTC 
Created attachment 1517749 [details]
optional: radeon.duallink patch
Comment 2 Laura Abbott 2019-01-02 16:58:33 UTC 
Fedora has a policy of not carrying out of tree patches except in limited circumstances. The issue is once we take a patch like this in, we are stuck carrying it indefinitely or it counts as a regression. Even if the context hasn't changed since March, that's not a guarantee it won't change if someone decides to do a drm wide cleanup (which has happened in the past). Carrying a patch like this also makes it harder to report upstream directly. Because Fedora carries so few patches, any regression almost always comes from the upstream sources and not from Fedora patches. Carrying this patch introduces another data point of in tree vs. out of tree code which can make bug reporting more difficult.

I think the best course of action is to get it accepted into the mainline tree, until that happens I don't think it's appropriate for Fedora to carry.