Bug 73067 - RV770 - screen flicker with radeon.dpm=1
Summary: RV770 - screen flicker with radeon.dpm=1
Status: RESOLVED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Radeon (show other bugs)
Version: unspecified
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-27 13:31 UTC by Vasco Almeida
Modified: 2014-02-17 17:35 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
lspci -vv (2.33 KB, text/plain)
2013-12-27 13:31 UTC, Vasco Almeida
no flags Details
dmesg output (72.70 KB, text/plain)
2013-12-27 13:34 UTC, Vasco Almeida
no flags Details
glxinfo (56.44 KB, text/plain)
2013-12-27 13:37 UTC, Vasco Almeida
no flags Details
debugging patch (481 bytes, patch)
2013-12-27 15:22 UTC, Alex Deucher
no flags Details | Splinter Review
xrandr --verbose (4.66 KB, text/plain)
2013-12-27 20:15 UTC, Vasco Almeida
no flags Details
Xorg.log (82.66 KB, text/plain)
2013-12-27 20:16 UTC, Vasco Almeida
no flags Details
dmesg with patch (73.84 KB, text/plain)
2013-12-28 11:22 UTC, Vasco Almeida
no flags Details
add quirk (1.11 KB, patch)
2014-01-07 18:53 UTC, Alex Deucher
no flags Details | Splinter Review

Description Vasco Almeida 2013-12-27 13:31:42 UTC
Created attachment 91222 [details]
lspci -vv

linux-sabayon-3.12.5
https://github.com/Sabayon/kernel
I installed the lastest available kernel version on sabayon-weekly repository.
sha1sum /lib/firmware/radeon/RV770_smc.bin
43e2fc7b9faa57e78401e1b1c609f71374cc8109  /lib/firmware/radeon/RV770_smc.bin

Whem booted with radeon.dpm=1 as a kernel parameter on grub, screen flicks: jumps down some pixels and go to normal position every ~4 seconds very fast.
Whem /sys/class/drm/card0/device/power_dpm_force_performance_level is changed to "high" or "low" flicker stops. Whem is changed back to "auto" flicker happens again, no mather what value is power_dpm_state.

Whem booted without radeon.dpm=1 parameter there isn't flicker.
Comment 1 Vasco Almeida 2013-12-27 13:34:39 UTC
Created attachment 91223 [details]
dmesg output
Comment 2 Vasco Almeida 2013-12-27 13:37:51 UTC
Created attachment 91224 [details]
glxinfo
Comment 3 Alex Deucher 2013-12-27 15:20:56 UTC
Please attach your xorg log and the output of xrandr --verbose.
Comment 4 Alex Deucher 2013-12-27 15:22:43 UTC
Created attachment 91227 [details] [review]
debugging patch

Please attach your dmesg output with the attached patch applied to your kernel.
Comment 5 Vasco Almeida 2013-12-27 20:15:23 UTC
Created attachment 91232 [details]
xrandr --verbose
Comment 6 Vasco Almeida 2013-12-27 20:16:44 UTC
Created attachment 91233 [details]
Xorg.log
Comment 7 Vasco Almeida 2013-12-28 11:22:47 UTC
Created attachment 91254 [details]
dmesg with patch

This is dmesg outpout with the patch attached above.
Comment 8 Alex Deucher 2014-01-07 18:53:49 UTC
Created attachment 91611 [details] [review]
add quirk

Does the attached patch fix the issue?
Comment 9 Vasco Almeida 2014-01-16 17:12:33 UTC
Yes, the attached patch fixed the flicker. Screen does not flick whichever value is power_dpm_state or power_dpm_force_performance_level.

Before the patch, the flicker happened when switching from
power level 2    sclk: 66500 mclk: 95000 vddc: 1082
to
power level 1    sclk: 50000 mclk: 70000 vddc: 1046

In the way level 1 -> level 2 there is not screen flicker.
Comment 10 Alex Deucher 2014-01-16 17:15:49 UTC
(In reply to comment #9)
> Yes, the attached patch fixed the flicker. Screen does not flick whichever
> value is power_dpm_state or power_dpm_force_performance_level.
> 
> Before the patch, the flicker happened when switching from
> power level 2    sclk: 66500 mclk: 95000 vddc: 1082
> to
> power level 1    sclk: 50000 mclk: 70000 vddc: 1046
> 
> In the way level 1 -> level 2 there is not screen flicker.

The flicker is caused by the mclk transition.  It some cases it seems to take longer than the vblank period which is why you are seeing the flicker.
Comment 11 Vasco Almeida 2014-01-16 18:07:45 UTC
I found that my screen was flicking once in ~4 seconds because of conky. With conky off, flicks happen but happen a lot less, like 1 in ~20 - this period depends on what I'm doing. But testing with glxspheres, screen flicker happens each ~4 seconds again. Probably this isn't important.

Can you give some hints about the solution? Do you think this can be fixed? Or this driver won't support mclk transition on this board?
Comment 12 Alex Deucher 2014-01-16 19:06:02 UTC
(In reply to comment #11)
> I found that my screen was flicking once in ~4 seconds because of conky.
> With conky off, flicks happen but happen a lot less, like 1 in ~20 - this
> period depends on what I'm doing. But testing with glxspheres, screen
> flicker happens each ~4 seconds again. Probably this isn't important.
> 

It happens whenever there is an mclk transition based on GPU load.

> Can you give some hints about the solution? Do you think this can be fixed?
> Or this driver won't support mclk transition on this board?

I'm not sure how reliable mclk switching was on rv770 boards in general.  Most rv770 boards I've seen have the same mclk for all performance levels.  You might try adjusting the value of CG_DISPLAY_GAP_CNTL in rv770_program_display_gap().  Maybe try R600_PM_DISPLAY_GAP_VBLANK_OR_WM or R600_PM_DISPLAY_GAP_WATERMARK rather than R600_PM_DISPLAY_GAP_VBLANK for DISP1_GAP_MCHG, but I don't think it will make a difference.
Comment 13 Benjamin Bellec 2014-02-16 13:03:02 UTC
Alex, I saw you disabled RV770 mclk switching to kernel 3.13.3 and 3.12.11. Thank you, it's now much more comfortable (tested with Fedora 19 kernel 3.12.11).

Anyway, do you plan to add your patch to kernel 3.10 too? It's a long-term release and will be used by RHEL7.
Comment 14 Benjamin Bellec 2014-02-17 08:03:03 UTC
(In reply to comment #13)
> Anyway, do you plan to add your patch to kernel 3.10 too? It's a long-term
> release and will be used by RHEL7.

Shame on me. DPM landed in kernel 3.11.


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.