On 21.08.2012 15:51, Alex Deucher wrote:
On Mon, Aug 20, 2012 at 3:30 PM, Luca Tettamanti kronos.it@gmail.com 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 alexander.deucher@amd.com 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 don't know what i'm talking about>
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
</i don't know what i'm talking about>
Luca
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel