Comment # 14
on bug 56139
from Alexandre Demers
(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.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
