Since kernel 3.15 I cannot get a stable video output on HDMI. The screen flickers and blinks, and my dmesg is full of these: sound hdaudioC1D0: HDMI ATI/AMD: no speaker allocation for ELD The video card in question is: Advanced Micro Devices, Inc. [AMD/ATI] RS880 [Radeon HD 4200] Downgrading to 3.14 seems to remove the issue.
Does booting with radeon.audio=0 on the kernel command line in grub fix the issue? You can also disable audio on the fly xrandr. E.g., xrandr --output HDMI-0 --set audio off
I haven't tried myself, but according to publicly available forums it would help. However, I need hdmi audio working, so I can't use this as a workaround.
Can you try it to be sure to at least narrow down what the problem might be?
ok i tried it and surprisingly it does not help. I have flicker, but i don't get the ELD messages. Note I also use video=HDMI-A-1:640x480 for the kernel to get a usable resolution in the text console.
(In reply to kb from comment #0) > > Downgrading to 3.14 seems to remove the issue. Can you bisect to find out what change caused this regression?
I'll have to setup the enviro, it'll take some time. But yeah, I'll do it.
32167016076f714f0e35e287fbead7de0f1fb179 is the first bad commit commit 32167016076f714f0e35e287fbead7de0f1fb179 Author: Christian König <christian.koenig@amd.com> Date: Fri Mar 28 18:55:10 2014 +0100 drm/radeon: rework finding display PLL numbers v2 This completely reworks how the PLL parameters are generated and should result in better matching dot clock frequencies. Probably needs quite a bit of testing. bugs: https://bugs.freedesktop.org/show_bug.cgi?id=76564 v2: more cleanup and comments. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> :040000 040000 1a91914271fc3761ec6961fa0cc4bded879bd05c c0ab21500dcb8d2876f4744e4465c9aa7203a113 M drivers
Also, I've noticed that when X boots, the "good" kernels give this sequence: 1) TV blanks with "No signal" message briefly 2) Desktop shows normally And the "bad" kernels give: 1) TV blanks with "Mode not supported" message for a longer time 2) Desktop shows, blinking and/or flickering
Please provide the output of "xrandr --verbose" and of dmesg when booted with "drm.debug=0xe" on the kernel command line. Thanks, Christian.
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 VGA-0 disconnected (normal left inverted right x axis y axis) Identifier: 0x51 Timestamp: 20519 Subpixel: no subpixels Clones: CRTCs: 0 1 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: load detection: 1 range: (0, 1) HDMI-0 connected 1920x1080+0+0 (0x54) normal (normal left inverted right x axis y axis) 160mm x 90mm Identifier: 0x52 Timestamp: 20519 Subpixel: horizontal rgb Gamma: 1.0:1.0:1.0 Brightness: 1.0 Clones: CRTC: 0 CRTCs: 0 1 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: EDID: 00ffffffffffff004c2d090501000000 30120103801009780aee91a3544c9926 0f5054bdef80714f8100814081809500 950fb3000101023a801871382d40582c 4500a05a0000001e662150b051001b30 40703600a05a0000001e000000fd0018 4b1a5117000a202020202020000000fc 0053414d53554e470a2020202020016f 020327f14b901f041305140312202122 2309070783010000e2000fe305030167 030c003000b82d011d007251d01e206e 285500a05a0000001e011d00bc52d01e 20b8285540a05a0000001e011d801871 1c1620582c2500a05a0000009e011d80 d0721c1620102c2580a05a0000009e00 000000000000000000000000000000fd dither: off supported: off, on audio: auto supported: off, on, auto underscan vborder: 0 range: (0, 128) underscan hborder: 0 range: (0, 128) underscan: off supported: off, on, auto coherent: 1 range: (0, 1) 1920x1080 (0x54) 148.500MHz +HSync +VSync *current +preferred h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.50KHz v: height 1080 start 1084 end 1089 total 1125 clock 60.00Hz 1920x1080 (0x55) 148.500MHz +HSync +VSync h: width 1920 start 2448 end 2492 total 2640 skew 0 clock 56.25KHz v: height 1080 start 1084 end 1089 total 1125 clock 50.00Hz 1920x1080 (0x56) 148.352MHz +HSync +VSync h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.43KHz v: height 1080 start 1084 end 1089 total 1125 clock 59.94Hz 1920x1080i (0x57) 74.250MHz +HSync +VSync Interlace h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 33.75KHz v: height 1080 start 1084 end 1094 total 1125 clock 60.00Hz 1920x1080i (0x58) 74.250MHz +HSync +VSync Interlace h: width 1920 start 2448 end 2492 total 2640 skew 0 clock 28.12KHz v: height 1080 start 1084 end 1094 total 1125 clock 50.00Hz 1920x1080 (0x59) 74.250MHz +HSync +VSync h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 33.75KHz v: height 1080 start 1084 end 1089 total 1125 clock 30.00Hz 1920x1080 (0x5a) 74.250MHz +HSync +VSync h: width 1920 start 2448 end 2492 total 2640 skew 0 clock 28.12KHz v: height 1080 start 1084 end 1089 total 1125 clock 25.00Hz 1920x1080 (0x5b) 74.250MHz +HSync +VSync h: width 1920 start 2558 end 2602 total 2750 skew 0 clock 27.00KHz v: height 1080 start 1084 end 1089 total 1125 clock 24.00Hz 1920x1080i (0x5c) 74.176MHz +HSync +VSync Interlace h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 33.72KHz v: height 1080 start 1084 end 1094 total 1125 clock 59.94Hz 1920x1080 (0x5d) 74.176MHz +HSync +VSync h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 33.72KHz v: height 1080 start 1084 end 1089 total 1125 clock 29.97Hz 1920x1080 (0x5e) 74.176MHz +HSync +VSync h: width 1920 start 2558 end 2602 total 2750 skew 0 clock 26.97KHz v: height 1080 start 1084 end 1089 total 1125 clock 23.98Hz 1680x1050 (0x5f) 119.000MHz +HSync -VSync h: width 1680 start 1728 end 1760 total 1840 skew 0 clock 64.67KHz v: height 1050 start 1053 end 1059 total 1080 clock 59.88Hz 1280x1024 (0x60) 135.000MHz +HSync +VSync h: width 1280 start 1296 end 1440 total 1688 skew 0 clock 79.98KHz v: height 1024 start 1025 end 1028 total 1066 clock 75.02Hz 1280x1024 (0x61) 108.000MHz +HSync +VSync h: width 1280 start 1328 end 1440 total 1688 skew 0 clock 63.98KHz v: height 1024 start 1025 end 1028 total 1066 clock 60.02Hz 1440x900 (0x62) 136.750MHz -HSync +VSync h: width 1440 start 1536 end 1688 total 1936 skew 0 clock 70.64KHz v: height 900 start 903 end 909 total 942 clock 74.98Hz 1440x900 (0x63) 88.750MHz +HSync -VSync h: width 1440 start 1488 end 1520 total 1600 skew 0 clock 55.47KHz v: height 900 start 903 end 909 total 926 clock 59.90Hz 1280x960 (0x64) 108.000MHz +HSync +VSync h: width 1280 start 1376 end 1488 total 1800 skew 0 clock 60.00KHz v: height 960 start 961 end 964 total 1000 clock 60.00Hz 1360x768 (0x65) 85.500MHz +HSync +VSync h: width 1360 start 1424 end 1536 total 1792 skew 0 clock 47.71KHz v: height 768 start 771 end 777 total 795 clock 60.02Hz 1280x800 (0x66) 71.000MHz +HSync -VSync h: width 1280 start 1328 end 1360 total 1440 skew 0 clock 49.31KHz v: height 800 start 803 end 809 total 823 clock 59.91Hz 1152x864 (0x67) 108.000MHz +HSync +VSync h: width 1152 start 1216 end 1344 total 1600 skew 0 clock 67.50KHz v: height 864 start 865 end 868 total 900 clock 75.00Hz 1280x720 (0x68) 74.250MHz +HSync +VSync h: width 1280 start 1390 end 1430 total 1650 skew 0 clock 45.00KHz v: height 720 start 725 end 730 total 750 clock 60.00Hz 1280x720 (0x69) 74.250MHz +HSync +VSync h: width 1280 start 1720 end 1760 total 1980 skew 0 clock 37.50KHz v: height 720 start 725 end 730 total 750 clock 50.00Hz 1280x720 (0x6a) 74.176MHz +HSync +VSync h: width 1280 start 1390 end 1430 total 1650 skew 0 clock 44.96KHz v: height 720 start 725 end 730 total 750 clock 59.94Hz 1024x768 (0x6b) 78.800MHz +HSync +VSync h: width 1024 start 1040 end 1136 total 1312 skew 0 clock 60.06KHz v: height 768 start 769 end 772 total 800 clock 75.08Hz 1024x768 (0x6c) 75.000MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1328 skew 0 clock 56.48KHz v: height 768 start 771 end 777 total 806 clock 70.07Hz 1024x768 (0x6d) 65.000MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew 0 clock 48.36KHz v: height 768 start 771 end 777 total 806 clock 60.00Hz 832x624 (0x6e) 57.284MHz -HSync -VSync h: width 832 start 864 end 928 total 1152 skew 0 clock 49.73KHz v: height 624 start 625 end 628 total 667 clock 74.55Hz 800x600 (0x6f) 50.000MHz +HSync +VSync h: width 800 start 856 end 976 total 1040 skew 0 clock 48.08KHz v: height 600 start 637 end 643 total 666 clock 72.19Hz 800x600 (0x70) 49.500MHz +HSync +VSync h: width 800 start 816 end 896 total 1056 skew 0 clock 46.88KHz v: height 600 start 601 end 604 total 625 clock 75.00Hz 800x600 (0x71) 40.000MHz +HSync +VSync h: width 800 start 840 end 968 total 1056 skew 0 clock 37.88KHz v: height 600 start 601 end 605 total 628 clock 60.32Hz 720x576 (0x72) 27.000MHz -HSync -VSync h: width 720 start 732 end 796 total 864 skew 0 clock 31.25KHz v: height 576 start 581 end 586 total 625 clock 50.00Hz 720x480 (0x73) 27.027MHz -HSync -VSync h: width 720 start 736 end 798 total 858 skew 0 clock 31.50KHz v: height 480 start 489 end 495 total 525 clock 60.00Hz 720x480 (0x74) 27.000MHz -HSync -VSync h: width 720 start 736 end 798 total 858 skew 0 clock 31.47KHz v: height 480 start 489 end 495 total 525 clock 59.94Hz 640x480 (0x75) 31.500MHz -HSync -VSync h: width 640 start 656 end 720 total 840 skew 0 clock 37.50KHz v: height 480 start 481 end 484 total 500 clock 75.00Hz 640x480 (0x76) 31.500MHz -HSync -VSync h: width 640 start 664 end 704 total 832 skew 0 clock 37.86KHz v: height 480 start 489 end 491 total 520 clock 72.81Hz 640x480 (0x77) 30.240MHz -HSync -VSync h: width 640 start 704 end 768 total 864 skew 0 clock 35.00KHz v: height 480 start 483 end 486 total 525 clock 66.67Hz 640x480 (0x78) 25.200MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew 0 clock 31.50KHz v: height 480 start 490 end 492 total 525 clock 60.00Hz 640x480 (0x79) 25.175MHz -HSync -VSync h: width 640 start 656 end 752 total 800 skew 0 clock 31.47KHz v: height 480 start 490 end 492 total 525 clock 59.94Hz 720x400 (0x7a) 28.320MHz -HSync +VSync h: width 720 start 738 end 846 total 900 skew 0 clock 31.47KHz v: height 400 start 412 end 414 total 449 clock 70.08Hz
Created attachment 154681 [details] dmesg with drm.debug=0xe on BAD kernel
note xrandr is on good kernel, dmesg in on bad
(In reply to kb from comment #12) > note xrandr is on good kernel, dmesg in on bad Those outputs should work fine. Going to make a patch for this, but this might take a while.
Created attachment 155721 [details] Add more debugging output. Please apply the attached patch and provide new dmesg created with drm.debug=0xE It should now show a bit more debugging output about your hardware.
Created attachment 156061 [details] dmesg 2nd run
I applied the patch but don't see any of the extra msgs in the dmesg. Maybe it's because i'm running it on the BAD kernel? Can you make a patch against 3.14 (this one doesn't apply cleanly on 3.14)?
Created attachment 156071 [details] dmesg round 2 with correct kernel
OK, false alarm. I had a wrong kernel. Correct output attached.
Created attachment 156211 [details] Possible fix Please try the attached patch. It's based on top of Alex drm-fixes-3.18 branch, but should apply to older ones as well. The problem seems to be that with a reference frequency of 14.32Mhz and a reference divider of 14 we get 1.0228Mhz which is very close to the minimum input frequency of 1Mhz.
Hi, unfortunately supplied patch does not fix the issue. Do you need some more debug output?
(In reply to kb from comment #20) > Hi, unfortunately supplied patch does not fix the issue. Do you need some > more debug output? dmesg output generated with drm.debug=0xE on the kernel command line would be nice. But I'm running out of idea what else this could be.
I've also added this line DRM_DEBUG_KMS("in patched branch: %u\n", ref_div_max); add the end of your patch, i.e. after ref_div_max = min(ref_div_max, pll->reference_freq / in_min); just to make sure the new code gets hit. I see this in dmesg [ 23.002707] [drm:radeon_compute_pll_avivo] in patched branch: 13 and I'm attaching the full output as well. Hope it gives you some more ideas.
Created attachment 158001 [details] dmesg #3
Any ideas on this? It's really annoying as I need to keep away from upgrading kernel past 3.14. :( Do you think change of graphics card would resolve the issue?
(In reply to kb from comment #24) > Any ideas on this? It's really annoying as I need to keep away from > upgrading kernel past 3.14. :( Unfortunately not, cause I don't have any idea what's causing this. You could try to artificially limit ref_div_max or fb_div_max until you get a stable signal once more. Maybe this will yield some more light on the root cause of the issue. > Do you think change of graphics card would resolve the issue? Well, most likely yes. But the new kernel seems to work better for some people, but has regressed for you. So I would really like to create a solution that works for everybody.
(In reply to Christian König from comment #25) > You could try to artificially limit ref_div_max or fb_div_max until you get > a stable signal once more. Maybe this will yield some more light on the root > cause of the issue. Can you give me some details - how to do this? > > Do you think change of graphics card would resolve the issue? > > Well, most likely yes. > > But the new kernel seems to work better for some people, but has regressed > for you. So I would really like to create a solution that works for > everybody. Right now I switched to catalyst which seems to work and allows me to use new kernel. But since apparently my card is "legacy" I had to downgrade to xorg server 1.12 :-|
Created attachment 159331 [details] Testing patch. (In reply to kb from comment #26) > (In reply to Christian König from comment #25) > > You could try to artificially limit ref_div_max or fb_div_max until you get > > a stable signal once more. Maybe this will yield some more light on the > root > > cause of the issue. > > Can you give me some details - how to do this? Attached is a testing patch which adds an artificially upper limit to 400.0 for the feedback divider (normal range 17.0-2048.0) and an upper limit of 13 for the reference divider (normal range 2-15). I suggest you start playing with the feedback divider values until you can figure out the limits for your hardware. E.g. try 400 as in my patch first, if that works raise it to 800 if that doesn't work go down to 600 again etc.. > > > > Do you think change of graphics card would resolve the issue? > > > > Well, most likely yes. > > > > But the new kernel seems to work better for some people, but has regressed > > for you. So I would really like to create a solution that works for > > everybody. > > Right now I switched to catalyst which seems to work and allows me to use > new kernel. But since apparently my card is "legacy" I had to downgrade to > xorg server 1.12 :-| Yeah, that's the problem I've got as well. The hardware isn't supported any more so the whole documentation is not available.
I think your patch has a typo on line 1002 should be ref_div_max not fb_div_max. Anyway I played with the numbers and I found a config that works for me. See below for all the different combos. Right now I'm running with ref_div_max capped to 2 and going to test it in prolonged use. Any further ideas about this? fb/ref => outcome 4000/13 => mode not supported (message on TV screen) 2000/13 => MNS 1000/13 => MNS 500/13 => MNS 4000/1023 => MNS 2000/1023 => MNS 1000/1023 => MNS 20470/1023 => (nominal value without any capping) flicker 10000/1023 => flicker 8000/1023 => different type of flicker, then blank screen 6000/1023 => MNS 20470/13 => flicker 20470/11 => flicker 20470/10 => flicker 20470/9 => very seldom flicker 20470/7 => stable! 20470/2 => stable!
Hi, I've also verified that commit 32167016076f714f0e35e287fbead7de0f1fb179 breaks my system: 01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS880 [Radeon HD 4250] (prog-if 00 [VGA controller]) The attached patch works fine for me. Without the patch, I can no longer use the DVI connector of my (onboard) graphics card, only VGA works.
Additional info: With the (unmodified) patch applied, I get a message "Nonpreset Mode" displayed on my monitor when I turn it on. So I think the patch is not 100% correct ...
Christian, do you have any further ideas? Can perhaps the ref_div_max be settable via sysfs so that I can cap it on boot?
Created attachment 163891 [details] Possible fix Unfortunately I don't have any more ideas either. There must be some undocumented limitation on RS880 and maybe older chips that don't seem to exists any more on newer ones. Unfortunately my last RS880 based system blow up about a month ago, so I can't test this any more. Please test the attached patch, it just artificial limits the reference divider to 7 on RS880 and older chips. If that works I'm going to submit the patch upstream.
Hello Christian It took me a while to regather my bugzilla login info, so I'm not sure whether you pushed this fix into kernel-git already or still are awaiting feedback, anyway ... I'm quoting my testing results I wrote in the debian bugtracker (#770790): That small patch in attachment #163891 [details] does indeed fix the screen flickering for me. I built three versions of radeon.ko against 3.16.7-ckt2 from debian/testing: 1) vanilla version: reproducible flickering, it's even easier to reproduce by quickly dragging a medium sized window around in circles 2) superseded version: (attachment #159331 [details]): no flickering, might contain a typo on line 1002, but I did not fix that one and it ran flawless for days 3) current version: (#attachment 163891 [details]): no flickering So to sum up: this small fix in #163891 is a blessing, I vote for pushing this if it hasn't happened already.
Already upstream: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=72edd83cc9e5819ed1ee771519143d7594e059f0
I had similar problems until I used 3.18.7. I couldn´t even boot beyond radeon load. The whole kernel crashed and my Monitor showed no usable signal. I had to blacklist and load it manually with option radeon.dpm=0, after turning on my Monitor . With kernel 3.18.6 I could use the radeon option radeon.aspm=0, but still had to turn on my Monitor before radeon module load. Now with this kernel I only need radeon.aspm=0 and no blacklist option, either the Monitor is turned on before or after radeon module load. Also GPU speedup with Video output works fine. Thx alot!! Here´s my card info lspci -s 01:00.0 -vv 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Cedar [Radeon HD 5000/6000/7350/8350 Series] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited / Sapphire Technology Device e157 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 33 Region 0: Memory at e0000000 (64-bit, prefetchable) [size=256M] Region 2: Memory at f7cc0000 (64-bit, non-prefetchable) [size=128K] Region 4: I/O ports at d000 [size=256] Expansion ROM at f7ca0000 [disabled] [size=128K] Capabilities: [50] Power Management version 3 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00 DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset- DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported- RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend- LnkCap: Port #0, Speed 5GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us ClockPM- Surprise- LLActRep- BwNot- LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+ ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt- LnkSta: Speed 5GT/s, Width x2, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt- DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR-, OBFF Not Supported DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis- Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS- Compliance De-emphasis: -6dB LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest- Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+ Address: 00000000fee00000 Data: 40e2 Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?> Capabilities: [150 v1] Advanced Error Reporting UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol- UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol- CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+ AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn- Kernel driver in use: radeon
Oh I forgot, In the kernel changelog it also hits bug 91861. And it isn´t in 3.19 because there I still have those problem.
(In reply to Joerg Esser from comment #35) > I had similar problems until I used 3.18.7. > I couldn´t even boot beyond radeon load. The whole kernel crashed and my > Monitor showed no usable signal. I had to blacklist and load it manually > with option radeon.dpm=0, after turning on my Monitor . With kernel 3.18.6 I > could use the radeon option radeon.aspm=0, but still had to turn on my > Monitor before radeon module load. > > Now with this kernel I only need radeon.aspm=0 and no blacklist option, > either the Monitor is turned on before or after radeon module load. Also GPU > speedup with Video output works fine. Please file a different bug. This bug and the patch only affect old asics like the RS880. Something else must have fixed the issue for you.
I landed here via: https://bugs.freedesktop.org/show_bug.cgi?id=87682 With the same issue mentioned by user Lockheed and the exact same chip (RS780M). Last comment in that post (from Alex Deucher) referred to this bugreport. On my RS780M I have exactly the same artefacts on my LVDS on any kernel version higher than 3.13 ( https://www.youtube.com/watch?v=nx2-Fvihzxg ) strangely enough the VGA out is not affected. Kernels tested up to 4.4.0 Would you like me to add some more info or would you like me to file a separate bug ?