[Bug 56139] [bisected] kernel 3.7.0-rc1 breaks 6950 (CAYMAN)

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=56139

--- Comment #14 from Alexandre Demers <alexandre.f.demers at gmail.com> ---
(In reply to comment #12)
> (In reply to comment #11)
> > Found what is wrong with the help of a few printk and by comparing to the
> > code being replaced. All the logic is good (going through crtc, disabling
> > them, waiting for vblank) BUT setting "tmp |=
> > EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;" is wrong.
> > 
> > If I do as in the previous code by setting tmp = 0 and then continuing with:
> > radeon_wait_for_vblank(rdev, i);
> > WREG32(EVERGREEN_CRTC_CONTROL + crtc_offsets[i], tmp);
> > everything works fine as before.
> > 
> > What is expected from "tmp |= EVERGREEN_CRTC_DISP_READ_REQUEST_DISABLE;"?
> > From what I read with printk, it is far from a 0 or a 1. Is this normal?
> 
> That's the most important bit in the entire sequence.  It's a bit field in a
> register (bit 24 to be exact).  That bit is the bit that actually disables
> the requests from the display controller in the memory controller.  The
> whole point of this code is to disable all clients of the memory controller
> (mc_stop()) so that we can change the location of vram within the GPU's
> address space.  Once we've moved vram, we can re-enable the clients
> (mc_resume()) so that they point to the new vram location.

Thank you, you confirmed what I had assumed. I had already understood that it
was the most important part in the sequence since it is associated to a "write"
instruction. I don't have the (decimal/binary) values with me right now, but
I'll be able to give you what was read from the register and from the result
returned from the bitwise OR assignment we are pushing in the register. I'll
confirm which bit(s) are changing. I'm sure the assignment was setting one (or
more) bit in the register to "1". Is bit 24 the only one expected to change in
the register? Should it be put to "1" or "0"?

Another question: why were we setting "0" in the register before? By doing so,
we were setting the whole register to "0" (the whole 32 bits), right? If I
remember correctly, from what I saw yesterday with the help of printk, it seems
we are setting at least one bit to "1" in this register, which would be the
opposite of what was being done before and therefore of what was working
correctly with my video card. I'm just trying to understand why we were doing
something in the first place that was working correctly and that was introduce
to fix this problem in the first place, both at boot time for grub (set
gfxpayload=keep) and when suspending/resuming, and we are now doing the
opposite, thus breaking the code for some setups. Is it possible that the
bit/register logic is not the same for all Radeon GPUs? After all, we already
introduced a different path for DCE6.

I'll also try your patch when I'll get home tonight.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121105/c151856a/attachment.html>