From patchwork Mon Aug 20 19:30:57 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luca Tettamanti X-Patchwork-Id: 1350761 Return-Path: X-Original-To: patchwork-dri-devel@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) by patchwork1.kernel.org (Postfix) with ESMTP id E7E003FC33 for ; Mon, 20 Aug 2012 19:31:21 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id D7B709E9DE for ; Mon, 20 Aug 2012 12:31:21 -0700 (PDT) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=l46AV0+hLAP7JFsis9CAeGmm2KLjwzOvAl3DEWDrC/0=; b=Q2EjrsFORe+IiEb8T9FwPwdaQc7eIS/xLCXeHdulquT9fZs9cnQjcZR8aM3Sz+JeN3 mNi61TcoY1kKKE9Xx3tlDM1NYBCvq3/NOftl7ExFbGsP+bZJ6yTNHBPXHaTjUGZNmQbU j0sE9khtuelrKw35OkvdEAzKmCJAB5f7IcQKGnuO/DjylAqyO8QX3gnnDAesWNgI8o0G DWzxgmRCVWEi00yTibhyLNWe3beN0cekxW5B4dAzjUFIZC7G5+E0E+L2xtMAJkJyq9sw YWtl/lTkdPWELZRFGlZPvbn4/7JNKUQG7sB5pC27fqFG1iggKEvYfAu+mOsH1+gjhJSg g0cQ== Received: by 10.180.109.166 with SMTP id ht6mr31575191wib.11.1345491068973; Mon, 20 Aug 2012 12:31:08 -0700 (PDT) Received: from growl (dynamic-adsl-78-14-225-27.clienti.tiscali.it. [78.14.225.27]) by mx.google.com with ESMTPS id eu4sm29542773wib.2.2012.08.20.12.31.07 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 20 Aug 2012 12:31:08 -0700 (PDT) Date: Mon, 20 Aug 2012 21:30:57 +0200 From: Luca Tettamanti To: Alex Deucher Subject: Re: radeon testing Message-ID: <20120820193057.GA5176@growl> References: <20120820123045.GA6212@growl> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Mailing list - DRI developers X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+patchwork-dri-devel=patchwork.kernel.org@lists.freedesktop.org Errors-To: dri-devel-bounces+patchwork-dri-devel=patchwork.kernel.org@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: 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 --- 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);