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 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...
</i don't know what i'm talking about>
Luca