Re: radeon testing

[Luca Tettamanti <kronos.it@gmail.com>]

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