Bug 82781

Created attachment 147291 [details]
add some debugging output

I'd rather try and fix this properly.  Is it only a problem with specific monitors?  If so which ones?  Please attach your xorg log and dmesg output.  Please apply the attached patch and attach your dmesg output with it applied when the problematic monitor is attached and you see the flickering.

Created attachment 147301 [details]
dmesg output

Ok i've attached the dmesg output.

Back with the 5570 i've corrected my sync timings after your suggestions.
I can also attach my EDID info in case the values that were fine with the
5570 somehow are not acceptable anymore. They should be pretty vanilla
vesa modes now (Windows Generic Monitor is the same here).

Created attachment 147311 [details]
Xorg log file

Created attachment 147321 [details]
EDID info

EDID info for the monitor

The Monitor is an EIZO F930 connected over BNC (so no real EDID from the device itself)

The values should be pretty standard VESA, and have been running stable with various cards for the past years (probably 10 or more)

Created attachment 147331 [details]
possible fix

As you can see from your log, the vblank time for the mode you've selected is right at the mclk switching limit:
[    5.943137] vblank_time 450, switch_limit 450
so I guess in your case, there are times when it doesn't quite complete in time.  A minor adjustment to the comparison should fix it.

Since you seem to be using a custom edid, you can also adjust the modelines to increase (to give the GPU more time to switch the mclk) or decrease (to disable mclk switching) the vblank_time. I suspect the vblank period is not reliable on you monitor and since it's currently set to exactly the switching limit  the margin for error is very small.  The switch may not have finished completely during the vblank period if the vblank period happens to be shorter in some cases.  That's why you see the flickering.  Tweaking your modeline to increase the vblank period should avoid that.

Yes, that patch would indeed fix it in my case.

I was pretty sure i took standard VESA modes and the fact that Windows Generic Monitor (no overrides or "hacks" there) values also using the same timings tells
me that they re rather "normal" modes.

i'm going to take your fix and live with it because i prefer when all my screen
modes remain exactly the same between OS switches.

But for curiosity reasons. Do you have a suggestion for mode sources with higher
vblank pauses which are still considered "standard" and not totaly uniq and custom? Or might it be possible my 85 Hz value simply has this 450 as standard.

Anyway, thanks for your help.

I've applied your patch, booted and still see the mclk changing.

I know i'm doing something wrong but i cannot see what.

I've checke the source .. and "vblank_time <= switch_limit" is there.
Also 450 and 450 gets printed so the test must match. "make modules" tells me everything is built and the timestamp on radeon.ko is recent so it's installed.

(In reply to Christian Birchinger from comment #7)
> Yes, that patch would indeed fix it in my case.
> 
> I was pretty sure i took standard VESA modes and the fact that Windows
> Generic Monitor (no overrides or "hacks" there) values also using the same
> timings tells
> me that they re rather "normal" modes.
> 
> i'm going to take your fix and live with it because i prefer when all my
> screen
> modes remain exactly the same between OS switches.
> 
> But for curiosity reasons. Do you have a suggestion for mode sources with
> higher
> vblank pauses which are still considered "standard" and not totaly uniq and
> custom? Or might it be possible my 85 Hz value simply has this 450 as
> standard.
>

There's nothing wrong with the modes or non-standard about a mode with a 450 us vblank time.  The issue is it takes 450 us for the mclk to change.  It just so happens that when the vblank period is the same as the switch limit so there is very little margin for error.

As for tweaking your modeline, you can try adjusting the htotal or vblank_end parameters.  CRT multi-sync monitors are pretty flexible when it comes to timing.

You can use gtf of cvt to generate vesa compatible modelines.  e.g.,
$ gtf 1600 1200 85

  # 1600x1200 @ 85.00 Hz (GTF) hsync: 107.10 kHz; pclk: 234.76 MHz
  Modeline "1600x1200_85.00"  234.76  1600 1720 1896 2192  1200 1201 1204 1260  -HSync +Vsync

$ cvt 1600 1200 85
# 1600x1200 84.95 Hz (CVT 1.92M3) hsync: 107.21 kHz; pclk: 235.00 MHz
Modeline "1600x1200_85.00"  235.00  1600 1728 1896 2192  1200 1203 1207 1262 -hsync +vsync

your mode:
[    30.543] (II) RADEON(0): Modeline "1600x1200"x85.0  229.50  1600 1664 1856 2160  1200 1201 1204 1250 +hsync +vsync (106.2 kHz eP)

gtf was the vesa formula used for CRTs and cvt is the newer formula designed for DFPs.  I'm not sure how your modes were generated, but they don't seem to follow either gtf or cvt.  Both the gtf (540 us vblank period) and cvt (558 us vblank period) modes should work fine as there is pleny of margin.

I don't know why but the only way i can stop it from chaning mclk is doing this:

si_dpm.c

/*
  if ((rdev->pm.dpm.new_active_crtc_count > 1) ||
      ni_dpm_vblank_too_short(rdev))
*/
    disable_mclk_switching = true;

I know ni_dpm_vblank_too_short must report true because "450 <= 450".
I'm totaly clueless why only hardcoding "true" keeps mclk at max 160000
also any printk i add after this wont get printed out.

Simply doing this also works:

ni_dpm.c:

bool ni_dpm_vblank_too_short(struct radeon_device *rdev)
{
  struct rv7xx_power_info *pi = rv770_get_pi(rdev);
  u32 vblank_time = r600_dpm_get_vblank_time(rdev);
  /* we never hit the non-gddr5 limit so disable it */
  u32 switch_limit = pi->mem_gddr5 ? 450 : 0;

  return true;

Adding a hardcoded true also disables mclk changes. which only leads
to one conclusion:

  if (vblank_time <= switch_limit)
    return true;
  else
    return false;

Somehow the values are not always 450 but i cannot see such a case
in the printk debug.

I'm not sure what's going on.  Maybe a gcc bug?  Can you try a modeline with a longer vblank period?  E.g.,

xrandr --newmode 1600x1200_gtf  234.76  1600 1720 1896 2192  1200 1201 1204 1260  -HSync +Vsync
xrandr --addmode DVI-0 1600x1200_gtf
xrandr --output DVI-0 --mode 1600x1200_gtf

or
xrandr --newmode 1600x1200_cvt 235.00  1600 1728 1896 2192  1200 1203 1207 1262 -hsync +vsync
xrandr --addmode DVI-0 1600x1200_cvt
xrandr --output DVI-0 --mode 1600x1200_cvt

The GTF one is unusable. I see a totaly desyncd image and lines are only flickering around.

The CVT one works, altough with huge black borders. However, it still flickers every 20-60 seconds. So longer vblank periods don't seem to fix my issue.