From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?ISO-8859-1?Q?Christian_K=F6nig?= Subject: Re: radeon testing Date: Tue, 21 Aug 2012 16:17:27 +0200 Message-ID: <50339877.2060202@vodafone.de> References: <20120820123045.GA6212@growl> <20120820193057.GA5176@growl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from outgoing.email.vodafone.de (outgoing.email.vodafone.de [139.7.28.128]) by gabe.freedesktop.org (Postfix) with ESMTP id 8B9589EB1A for ; Tue, 21 Aug 2012 07:17:31 -0700 (PDT) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Alex Deucher Cc: Mailing list - DRI developers List-Id: dri-devel@lists.freedesktop.org On 21.08.2012 15:51, Alex Deucher wrote: > On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti wrote: >> On Mon, Aug 20, 2012 at 10:24:01AM -0400, Alex Deucher wrote: >>>> I just tested the rebased acpi_patches branch: ACPI part works fine, but >>>> I see a big slow down during radeon driver initialization when the >>>> screen goes black for a couple of seconds (with 3.5.0 + acpi patches the >>>> screen just flickers during boot). With initcall_debug I see: >>>> >>>> [ 2.355300] calling radeon_init+0x0/0x1000 [radeon] @ 552 >>>> ... >>>> [ 5.530310] initcall radeon_init+0x0/0x1000 [radeon] returned 0 after 3102147 usecs >>>> >>>> For reference 3.5 takes ~1 sec. With drm.debug=2 the log (attached) is not very >>>> informative, I'll try and get more info... >>> Can you bisect? >> I've put in some printk, this is the result: >> >> [ 2.403138] evergreen_mc_program >> [ 2.403196] evergreen_mc_stop >> ... >> [ 4.268491] evergreen_mc_resume done >> [ 4.268548] evergreen_mc_program done >> >> This is the patch: >> >> --- a/drivers/gpu/drm/radeon/evergreen.c >> +++ b/drivers/gpu/drm/radeon/evergreen.c >> @@ -1349,6 +1349,8 @@ void evergreen_mc_program(struct radeon_device *rdev) >> u32 tmp; >> int i, j; >> >> + printk(KERN_INFO "%s\n", __func__); >> + >> /* Initialize HDP */ >> for (i = 0, j = 0; i < 32; i++, j += 0x18) { >> WREG32((0x2c14 + j), 0x00000000); >> @@ -1359,10 +1361,14 @@ void evergreen_mc_program(struct radeon_device *rdev) >> } >> WREG32(HDP_REG_COHERENCY_FLUSH_CNTL, 0); >> >> + printk(KERN_INFO "evergreen_mc_stop\n"); >> evergreen_mc_stop(rdev, &save); >> +// printk(KERN_INFO "evergreen_mc_wait_for_idle\n"); >> if (evergreen_mc_wait_for_idle(rdev)) { >> dev_warn(rdev->dev, "Wait for MC idle timedout !\n"); >> } >> +// printk(KERN_INFO "evergreen_mc_wait_for_idle done\n"); >> + >> /* Lockout access through VGA aperture*/ >> WREG32(VGA_HDP_CONTROL, VGA_MEMORY_DISABLE); >> /* Update configuration */ >> @@ -1411,10 +1417,13 @@ void evergreen_mc_program(struct radeon_device *rdev) >> WREG32(MC_VM_AGP_TOP, 0x0FFFFFFF); >> WREG32(MC_VM_AGP_BOT, 0x0FFFFFFF); >> } >> +// printk(KERN_INFO "evergreen_mc_wait_for_idle\n"); >> if (evergreen_mc_wait_for_idle(rdev)) { >> dev_warn(rdev->dev, "Wait for MC idle timedout !\n"); >> } >> +// printk(KERN_INFO "evergreen_mc_resume\n"); >> evergreen_mc_resume(rdev, &save); >> + printk(KERN_INFO "evergreen_mc_resume done\n"); >> /* we need to own VRAM, so turn off the VGA renderer here >> * to stop it overwriting our objects */ >> rv515_vga_render_disable(rdev); >> >> >> Any printk between evergreen_mc_stop and evergreen_mc_resume locks up >> the machine. The likely culprit is commit 023e188e: > yeah, vram is locked out at that point. I guess we probably need to > block anyone from trying to access it. IIRC we have a rw-semaphore that you can writelock to prevent anything from accessing vram. But if you try to access VRAM from within the critical section (by using a printk that tries to write something to the console) you probably end up deadlocking the kernel. Christian. > >> commit 023e188ec102330eb05ad264f675e869637478eb >> Author: Alex Deucher >> Date: Wed Aug 15 17:18:42 2012 -0400 >> >> drm/radeon: properly handle mc_stop/mc_resume on evergreen+ >> >> - Stop the displays from accessing the FB >> - Block CPU access >> - Turn off MC client access >> >> This should fix issues some users have seen, especially >> with UEFI, when changing the MC FB location that result >> in hangs or display corruption. >> >> >> >> I haven't tried backing out the commit yet, but looking at the diff I >> see that you call radeon_wait_for_vblank and radeon_get_vblank_counter, >> but evergreen_mc_program is called way before IRQ is set up. Is the >> vblank counter running? Looks like we just hitting the timeout here... >> > We aren't waiting for an interrupt, just polling the current crtc > status until it enters the vblank region. The status and counters > should be working as we only wait on displays that are enabled. I'll > double check the code however. Thanks for testing. > > Alex > >> >> >> >> Luca > _______________________________________________ > dri-devel mailing list > dri-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel >