On Wed, Jan 30, 2013 at 6:31 AM, Deucher, Alexander <alexander.deuc...@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? -- Shuah -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
