[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 #19 from Alexandre Demers <alexandre.f.demers at gmail.com> ---
(In reply to comment #15)
> (In reply to comment #14)
> > (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"?
> > 
> 
> Setting bit 24 to 1 disables memory requests from the display controller. 
> Setting bit 24 to 0, enables memory requests from the display controller.
> 
> > 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.
> 
> Bit 0 for CRTC_CONTROL turns on/off the entire crtc.  If bit 0 is 0 the crtc
> is disabled.  If bit 0 is 1, the crtc is enabled.  If the crtc is disabled
> (bit 0 = 0) bit 24 is irrelevant.  There are separate bits to enable the
> crtc and disable memory requests since there are cases (like this one) where
> we want to keep the crtc timing running so that the monitor stays synced,
> but disable reads from memory so we can reconfigure the memory controller. 
> If we disable the crtc entirely, the monitor would lose sync and you would
> get additional flicker during boot up.  Ideally, eventually we'd like to
> just hand over control from the firmware without touching the display
> hardware so the user gets a flicker free boot experience.
> 
> DCE4 and 5 have the same logic and bit layout for these registers.  The
> logic is different on DCE6 chips.  On DCE6, the the memory controller
> request bit is now tied in with the crtc blanking bit.  When the crtc is
> blanked, memory requests are also disabled.

If I followed you correctly, setting bit 24 to "1" disables memory but keeps
the CRTC state as it is (hopefully in sync with the monitor). However, what I
see when grub2 kicks in with the "gfxpayload=keep" is an unsynced monitor.
Sometimes the display will be black, other times it will only appear in the
first couple of vertical lines, in others it will be vertically synced but
shifted to the right at half or at two third of the screen. In other words,
this really seems to be a sync problem. Should I try to combine patch 69113 and
patch 69370 with the others?

-- 
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/20121106/136a79da/attachment.html>