From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luca Tettamanti Subject: Re: radeon testing Date: Mon, 20 Aug 2012 21:30:57 +0200 Message-ID: <20120820193057.GA5176@growl> References: <20120820123045.GA6212@growl> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wg0-f43.google.com (mail-wg0-f43.google.com [74.125.82.43]) by gabe.freedesktop.org (Postfix) with ESMTP id D441D9E764 for ; Mon, 20 Aug 2012 12:31:09 -0700 (PDT) Received: by wgbdr1 with SMTP id dr1so4902093wgb.12 for ; Mon, 20 Aug 2012 12:31:09 -0700 (PDT) Content-Disposition: inline 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 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: 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... Luca