http://bugs.freedesktop.org/show_bug.cgi?id=25718
--- Comment #14 from Rafał Miłecki <[email protected]> 2009-12-21 23:04:54 PST --- Aidan: did you make some more tests, can you say that dynpm=1 really makes this issue happen earlier than with dynpm=0? If so, can you try removing radeon_set_engine_clock calls from radeon_pm.c and use dynpm=1? Does this makes KMS stable just like with dynpm=0? Did you actually experience that issue again with dynpm=0? Or did this happen just once (15min of Nexuiz)? diff --git a/drivers/gpu/drm/radeon/radeon_pm.c b/drivers/gpu/drm/radeon/radeon_pm.c index a9c61f4..4aa1061 100644 --- a/drivers/gpu/drm/radeon/radeon_pm.c +++ b/drivers/gpu/drm/radeon/radeon_pm.c @@ -156,17 +156,12 @@ static void radeon_pm_set_clocks_locked(struct radeon_device *rdev) /*radeon_fence_wait_last(rdev);*/ switch (rdev->pm.planned_action) { case PM_ACTION_UPCLOCK: - radeon_set_engine_clock(rdev, rdev->clock.default_sclk); rdev->pm.downclocked = false; break; case PM_ACTION_DOWNCLOCK: - radeon_set_engine_clock(rdev, - rdev->pm.min_mode_engine_clock); rdev->pm.downclocked = true; break; case PM_ACTION_MINIMUM: - radeon_set_engine_clock(rdev, - rdev->pm.min_gpu_engine_clock); break; case PM_ACTION_NONE: DRM_ERROR("%s: PM_ACTION_NONE\n", __func__); -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. ------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- _______________________________________________ Dri-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dri-devel
