lkml.org 
[lkml]   [2013]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: Linux 3.8-rc4
From
On Thu, Jan 31, 2013 at 7:56 AM, Deucher, Alexander
<Alexander.Deucher@amd.com> wrote:
>> -----Original Message-----
>> From: Shuah Khan [mailto:shuahkhan@gmail.com]
>> Sent: Wednesday, January 30, 2013 4:12 PM
>> To: Deucher, Alexander
>> Cc: Linus Torvalds; Linux Kernel Mailing List
>> Subject: Re: Linux 3.8-rc4
>>
>> 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.
>
> I guess we can just add the delay. I've tried all the ways I know of to get proper feedback from the hardware.
>
> Alex
>

Do you want me to send a patch with delay()? Would you like to see the
delay specific to this chipset which is RV620? That said if you think
of other ideas to try instead of delay, I can continue the debug and
testing effort.

-- Shuah


\
 
 \ /
  Last update: 2013-01-31 17:43    [W:1.007 / U:1.284 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site