Messages in this thread | | | Date | Wed, 30 Jan 2013 14:12:05 -0700 | Subject | Re: Linux 3.8-rc4 | From | Shuah Khan <> |
| |
On Wed, Jan 30, 2013 at 8:53 AM, Deucher, Alexander <Alexander.Deucher@amd.com> wrote: >> -----Original Message----- >> From: Shuah Khan [mailto:shuahkhan@gmail.com] >> Sent: Wednesday, January 30, 2013 10:35 AM >> To: Deucher, Alexander >> Cc: Linus Torvalds; Linux Kernel Mailing List >> Subject: Re: Linux 3.8-rc4 >> >> On Wed, Jan 30, 2013 at 6:31 AM, Deucher, Alexander >> <Alexander.Deucher@amd.com> wrote: >> >> >> >> >> ok. I did more debugging in rv515_mc_stop() and here is what's >> >> happening. It has two display controllers and one of them is enabled >> >> and the other is in disabled state when AVIVO_D1CRTC_CONTROL is >> >> checked. The current code doesn't blank the disabled crtc. However, it >> >> needs to be blanked to avoid DMAR faults it appears. I think that is >> >> what the original code prior to >> >> 6253e4c75d96006c06b9ac8f417eba873de2497b commit was doing: >> >> >> >> - WREG32(R_0060E8_D1CRTC_UPDATE_LOCK, 1); >> >> - WREG32(R_0068E8_D2CRTC_UPDATE_LOCK, 1); >> >> - WREG32(R_006080_D1CRTC_CONTROL, 0); >> >> - WREG32(R_006880_D2CRTC_CONTROL, 0); >> >> - WREG32(R_0060E8_D1CRTC_UPDATE_LOCK, 0); >> >> - WREG32(R_0068E8_D2CRTC_UPDATE_LOCK, 0); >> >> - WREG32(R_000330_D1VGA_CONTROL, 0); >> >> - WREG32(R_000338_D2VGA_CONTROL, 0); >> >> >> >> Anyways, here is the diff for the change (by no means a patch) I made >> >> that fixed the problem: >> > >> > Unfortunately, that just fixes the problem by causing an additional delay >> since the wait_for_vblank() and get_frame_count() loops will timeout since >> the secondary display is disabled. The previous code disabled the displays >> completely while the new code just disables the memory request interface >> so that the display timing stays on to avoid additional flicker at startup or GPU >> reset. For some reason on your system there seems to be a delay in getting >> the memory request interface to stop. >> > >> > Alex >> >> Right. That makes sense and yes the annoying flicker went away. :) Can >> you think of something that can address systems that would need more >> time to get the memory request interface to stop such as mine? > > Does adding an additional radeon_mc_wait_for_idle(rdev) call at the end of rv515_mc_stop() help? Can you find out what the minimum delay required for your system is? > > Alex
Adding radeon_mc_wait_for_idle(rdev) call at the end of rv515_mc_stop() - didn't help.
I tried with adding udelay() with delay values of 1,10, and 50, and 100 at the end of rv515_mc_stop(). 100 is the minimum that fixed the DMAR faults.
-- Shuah
| |