Your message dated Mon, 31 Dec 2018 15:59:23 +0000 with message-id <05145eac3ac793204c8411f85faee96b874bc333.camel@decadent.org.uk> and subject line Re: Bug#838344: Acknowledgement (linux-image-4.6.0-1-amd64: allow a patch that makes elder radeon cards UltraHD ready) has caused the Debian Bug report #838344, regarding linux-image-4.6.0-1-amd64: allow a patch that makes elder radeon cards UltraHD ready to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) -- 838344: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838344 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
--- Begin Message ---
- To: submit@bugs.debian.org
- Subject: Re: linux-image-4.6.0-1-amd64: allow a patch that makes elder radeon cards UltraHD ready
- From: Elmar Stellnberger <estellnb@elstel.org>
- Date: Tue, 20 Sep 2016 09:29:14 +0200
- Message-id: <f5962548-42e1-a4f8-14aa-92671e6c5b2c@elstel.org>
- In-reply-to: <dab79540-3355-e28e-e81c-711432f9c03e@elstel.org>
- References: <dab79540-3355-e28e-e81c-711432f9c03e@elstel.org>
Package: src:linux Version: 4.6.4-1 Severity: wishlist Tags: patch Here come the patches. Am 2016-09-20 um 09:16 schrieb Elmar Stellnberger:Package: src:linux Version: 4.6.4-1 Severity: wishlist Tags: patch In March 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. 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 Debian Stretch: * 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 already available at least with the radeon R5 230 card 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 rarely be possible to damage a card; 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 article is no more completely new and it will be updated soon.). P.S.: The attached patches are for application at the 4.8.0-rcX kernels; however the same patch has also proven to work well for 4.6.x/Debian. If you do not want to update 4.6.0-1 then I`d apply for inclusion of this patch with the adoption of 4.8.0. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.0-rc6+ (SMP w/4 CPU cores) Locale: LANG=de_AT.utf8, LC_CTYPE=de_AT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-image-4.6.0-1-amd64 depends on: ii initramfs-tools [linux-initramfs-tool] 0.125 ii kmod 22-1.1 ii linux-base 4.4 Versions of packages linux-image-4.6.0-1-amd64 recommends: ii firmware-linux-free 3.4 pn irqbalance <none> Versions of packages linux-image-4.6.0-1-amd64 suggests: pn debian-kernel-handbook <none> ii grub-pc 2.02~beta2-36 pn linux-doc-4.6 <none> Versions of packages linux-image-4.6.0-1-amd64 is related to: ii firmware-amd-graphics 20160110-1 ii firmware-atheros 20160110-1 ii firmware-bnx2 20160110-1 ii firmware-bnx2x 20160110-1 ii firmware-brcm80211 20160110-1 ii firmware-cavium 20160110-1 ii firmware-intel-sound 20160110-1 ii firmware-intelwimax 20160110-1 ii firmware-ipw2x00 20160110-1 ii firmware-ivtv 20160110-1 ii firmware-iwlwifi 20160110-1 ii firmware-libertas 20160110-1 pn firmware-linux-nonfree <none> ii firmware-misc-nonfree 20160110-1 ii firmware-myricom 20160110-1 ii firmware-netxen 20160110-1 ii firmware-qlogic 20160110-1 ii firmware-realtek 20160110-1 ii firmware-samsung 20160110-1 ii firmware-siano 20160110-1 ii firmware-ti-connectivity 20160110-1 pn xen-hypervisor <none>>From 17245f2ba90fe9242041dd0626a570a8becce5c1 Mon Sep 17 00:00:00 2001 From: Elmar Stellnberger <estellnb@elstel.org> Date: Mon, 22 Aug 2016 10:27:53 +0200 Subject: [PATCH] radeon.hdmimhz parameter introduced * proven to work for a radeon XFX R5 230 card with radeon.hdmimhz=297 3840x2160@30 is offered automatically and can be set successfully with an AOC u2868pqu as well as an iiyama X4071UHSU monitor; no heat issues in the long term (cooler moderately warm after running half a day) * radeon_encoders.c: radeon_dig_monitor_is_duallink must always return false otherwise screen stays black for the settings described above --- drivers/gpu/drm/radeon/radeon.h | 1 + drivers/gpu/drm/radeon/radeon_connectors.c | 16 ++++++++++------ drivers/gpu/drm/radeon/radeon_drv.c | 4 ++++ drivers/gpu/drm/radeon/radeon_encoders.c | 3 +++ 4 files changed, 18 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 5633ee3..5451a43 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -113,6 +113,7 @@ extern int radeon_bapm; extern int radeon_backlight; extern int radeon_auxch; extern int radeon_mst; +extern int radeon_hdmimhz; extern int radeon_uvd; extern int radeon_vce; diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c index b79f3b0..88736ac 100644 --- a/drivers/gpu/drm/radeon/radeon_connectors.c +++ b/drivers/gpu/drm/radeon/radeon_connectors.c @@ -1476,6 +1476,7 @@ static int radeon_dvi_mode_valid(struct drm_connector *connector, struct drm_device *dev = connector->dev; struct radeon_device *rdev = dev->dev_private; struct radeon_connector *radeon_connector = to_radeon_connector(connector); + int mode_valid = MODE_OK; /* XXX check mode bandwidth */ @@ -1483,7 +1484,7 @@ static int radeon_dvi_mode_valid(struct drm_connector *connector, if (radeon_connector->use_digital && (rdev->family == CHIP_RV100) && (mode->clock > 135000)) - return MODE_CLOCK_HIGH; + return MODE_CLOCK_HIGH; // never override since this is a known issue if (radeon_connector->use_digital && (mode->clock > 165000)) { if ((radeon_connector->connector_object_id == CONNECTOR_OBJECT_ID_DUAL_LINK_DVI_I) || @@ -1493,19 +1494,22 @@ static int radeon_dvi_mode_valid(struct drm_connector *connector, else if (ASIC_IS_DCE6(rdev) && drm_detect_hdmi_monitor(radeon_connector_edid(connector))) { /* HDMI 1.3+ supports max clock of 340 Mhz */ if (mode->clock > 340000) - return MODE_CLOCK_HIGH; + mode_valid = MODE_CLOCK_HIGH; else return MODE_OK; } else { - return MODE_CLOCK_HIGH; + mode_valid = MODE_CLOCK_HIGH; } } + if ( radeon_hdmimhz > 0 && ( mode->clock <= radeon_hdmimhz * 1000 ) ) + mode_valid = MODE_OK; + /* check against the max pixel clock */ - if ((mode->clock / 10) > rdev->clock.max_pixel_clock) - return MODE_CLOCK_HIGH; + if ( mode_valid == MODE_OK && (mode->clock / 10) > rdev->clock.max_pixel_clock ) + mode_valid = MODE_CLOCK_HIGH; - return MODE_OK; + return mode_valid; } static const struct drm_connector_helper_funcs radeon_dvi_connector_helper_funcs = { diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c index c01a7c6..85cf798 100644 --- a/drivers/gpu/drm/radeon/radeon_drv.c +++ b/drivers/gpu/drm/radeon/radeon_drv.c @@ -202,6 +202,7 @@ int radeon_bapm = -1; int radeon_backlight = -1; int radeon_auxch = -1; int radeon_mst = 0; +int radeon_hdmimhz = 0; int radeon_uvd = 1; int radeon_vce = 1; @@ -295,6 +296,9 @@ module_param_named(auxch, radeon_auxch, int, 0444); MODULE_PARM_DESC(mst, "DisplayPort MST experimental support (1 = enable, 0 = disable)"); module_param_named(mst, radeon_mst, int, 0444); +MODULE_PARM_DESC(hdmimhz, "Force a maximum HDMI pixel clock (in MHz); try 165/225/297/330 to overclock your TMDS for gaining a higher resolution."); +module_param_named(hdmimhz, radeon_hdmimhz, int, 0444); + MODULE_PARM_DESC(uvd, "uvd enable/disable uvd support (1 = enable, 0 = disable)"); module_param_named(uvd, radeon_uvd, int, 0444); diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c b/drivers/gpu/drm/radeon/radeon_encoders.c index c6ee802..0d06e12 100644 --- a/drivers/gpu/drm/radeon/radeon_encoders.c +++ b/drivers/gpu/drm/radeon/radeon_encoders.c @@ -372,6 +372,9 @@ bool radeon_dig_monitor_is_duallink(struct drm_encoder *encoder, struct radeon_connector *radeon_connector; struct radeon_connector_atom_dig *dig_connector; + if(radeon_hdmimhz > 0) + return false; + connector = radeon_get_connector_for_encoder(encoder); /* if we don't have an active device yet, just use one of * the connectors tied to the encoder. -- 2.9.3>From 0a550210ec0483a4da70bac3e42444d8df770a15 Mon Sep 17 00:00:00 2001 From: Elmar Stellnberger <estellnb@elstel.org> Date: Mon, 22 Aug 2016 11:18:27 +0200 Subject: [PATCH] radeon.duallink parameter introduced * has only effect when radeon.hdmimhz != 0; it allows for duallink if the driver decides so * may be useful when connecting over a dual-link-DVI * as expected it was detremential with the R5 230 card for 3840x2160@30 over HDMI 1.4 --- drivers/gpu/drm/radeon/radeon.h | 1 + drivers/gpu/drm/radeon/radeon_drv.c | 4 ++++ drivers/gpu/drm/radeon/radeon_encoders.c | 2 +- 3 files changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h index 5451a43..3210bf5 100644 --- a/drivers/gpu/drm/radeon/radeon.h +++ b/drivers/gpu/drm/radeon/radeon.h @@ -114,6 +114,7 @@ extern int radeon_backlight; extern int radeon_auxch; extern int radeon_mst; extern int radeon_hdmimhz; +extern int radeon_duallink; extern int radeon_uvd; extern int radeon_vce; diff --git a/drivers/gpu/drm/radeon/radeon_drv.c b/drivers/gpu/drm/radeon/radeon_drv.c index 85cf798..8a3d182 100644 --- a/drivers/gpu/drm/radeon/radeon_drv.c +++ b/drivers/gpu/drm/radeon/radeon_drv.c @@ -203,6 +203,7 @@ int radeon_backlight = -1; int radeon_auxch = -1; int radeon_mst = 0; int radeon_hdmimhz = 0; +int radeon_duallink = 0; int radeon_uvd = 1; int radeon_vce = 1; @@ -299,6 +300,9 @@ module_param_named(mst, radeon_mst, int, 0444); MODULE_PARM_DESC(hdmimhz, "Force a maximum HDMI pixel clock (in MHz); try 165/225/297/330 to overclock your TMDS for gaining a higher resolution."); module_param_named(hdmimhz, radeon_hdmimhz, int, 0444); +MODULE_PARM_DESC(duallink, "Allow for the dual link feature when overclocking with radeon.hdmimhz."); +module_param_named(duallink, radeon_duallink, int, 0444); + MODULE_PARM_DESC(uvd, "uvd enable/disable uvd support (1 = enable, 0 = disable)"); module_param_named(uvd, radeon_uvd, int, 0444); diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c b/drivers/gpu/drm/radeon/radeon_encoders.c index 0d06e12..1451fa3 100644 --- a/drivers/gpu/drm/radeon/radeon_encoders.c +++ b/drivers/gpu/drm/radeon/radeon_encoders.c @@ -372,7 +372,7 @@ bool radeon_dig_monitor_is_duallink(struct drm_encoder *encoder, struct radeon_connector *radeon_connector; struct radeon_connector_atom_dig *dig_connector; - if(radeon_hdmimhz > 0) + if( radeon_hdmimhz > 0 && !radeon_duallink ) return false; connector = radeon_get_connector_for_encoder(encoder); -- 2.9.3
--- End Message ---
--- Begin Message ---
- To: 838344-done@bugs.debian.org
- Subject: Re: Bug#838344: Acknowledgement (linux-image-4.6.0-1-amd64: allow a patch that makes elder radeon cards UltraHD ready)
- From: Ben Hutchings <ben@decadent.org.uk>
- Date: Mon, 31 Dec 2018 15:59:23 +0000
- Message-id: <05145eac3ac793204c8411f85faee96b874bc333.camel@decadent.org.uk>
- In-reply-to: <[🔎] 78bc34e8-ccb9-9837-179a-acc5db30df1c@elstel.org>
- References: <f5962548-42e1-a4f8-14aa-92671e6c5b2c@elstel.org> <[🔎] 78bc34e8-ccb9-9837-179a-acc5db30df1c@elstel.org>
On Mon, 2018-12-31 at 15:58 +0100, Elmar Stellnberger wrote: > It is now about two years ago that I have developed a patch to set > the TMDS frequency for Radeon cards. A similar patch for Nouveau and for > the Windows ATI driver does already exist. The patch has been proven to > work well in the long term at least with the Radeon R5 230 and the > Radeon HD 6570. Other people have given positive reports as well (Radeon > HD 6970, Radeon HD 6770, see: > https://bugs.freedesktop.org/show_bug.cgi?id=93885#c24) though not as > extensively as John Reinhard with the HD 6570. > Many cards do not show heat issues at all when overclocking the TMDS. > - and even if a card did Nouveau developers have told me that it would > hardly be possible to damage a card with this. The reason why Radeon > developers did not want to assimilate it seems to be business interest > as they have told me frankly. 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 Debian? We try to avoid carrying patches that upstream doesn't want, as they often require ongoing effort to rebase on new upstream versions. This feature doesn't seem important enough to make an exception. Sorry. Ben. -- Ben Hutchings Power corrupts. Absolute power is kind of neat. - John LehmanAttachment: signature.asc
Description: This is a digitally signed message part
--- End Message ---