<html>
<head>
<base href="https://bugs.freedesktop.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED --- - Latest radeon dri driver on HD6950 with GRUB set "GRUB_GFXPAYLOAD_LINUX=keep" put the display in a flickering state"
href="https://bugs.freedesktop.org/show_bug.cgi?id=43655#c23">Comment # 23</a>
on <a class="bz_bug_link
bz_status_REOPENED "
title="REOPENED --- - Latest radeon dri driver on HD6950 with GRUB set "GRUB_GFXPAYLOAD_LINUX=keep" put the display in a flickering state"
href="https://bugs.freedesktop.org/show_bug.cgi?id=43655">bug 43655</a>
from <span class="vcard"><a class="email" href="mailto:alexandre.f.demers@gmail.com" title="Alexandre Demers <alexandre.f.demers@gmail.com>"> <span class="fn">Alexandre Demers</span></a>
</span></b>
<pre>(In reply to <a href="show_bug.cgi?id=43655#c22">comment #22</a>)
<span class="quote">> The current code should do the right thing with respect to disabling display
> access to vram when we reconfigure the memory controller. The current code
> disables memory reads but leaves the display controllers enabled while we
> change the MC setup. Turning off the crtcs as the patch you mentioned does
> has two problems:
> 1. it breaks some systems which the current method fixes
> 2. it defeats the purpose of GRUB_GFXPAYLOAD_LINUX=keep which is to avoid
> turning off the displays for flickerless boot up. If you turn off the crtcs
> you have to re-init the entire display pipeline.
> The problem seems to be that disabling the crtc memory reads seems to take
> longer than expected on some systems which leads to invalid reads while the
> MC is being reprogrammed. One possible solution may be to leave the MC as
> configured by the vbios and try and put the gart aperture either before or
> after the location of varm in the GPU's address space.</span >
I understand what you are explaining. Meanwhile, I'm bisecting to find out
where it was broken again since commit 81ee8fb6b52ec69eeed37fe7943446af1dccecc5
does indeed what it is supposed to do (no problem when using
GRUB_GFXPAYLOAD_LINUX=keep). So, somewhere between commit
81ee8fb6b52ec69eeed37fe7943446af1dccecc5 and 3.9.0-rcx, something went wrong.
I'll keep in touch.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>