This is a note to let you know that I've just added the patch titled
drm/i915: use hsw rps tuning values everywhere on gen6+
to the 3.5-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
drm-i915-use-hsw-rps-tuning-values-everywhere-on-gen6.patch
and it can be found in the queue-3.5 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <[email protected]> know about it.
>From 1ee9ae3244c4789f3184c5123f3b2d7e405b3f4c Mon Sep 17 00:00:00 2001
From: Daniel Vetter <[email protected]>
Date: Wed, 15 Aug 2012 10:41:45 +0200
Subject: drm/i915: use hsw rps tuning values everywhere on gen6+
From: Daniel Vetter <[email protected]>
commit 1ee9ae3244c4789f3184c5123f3b2d7e405b3f4c upstream.
James Bottomley reported [1] a massive power regression, due to the
enabling of semaphores by default in 3.5. A workaround for him is to
again disable semaphores. And indeed, his system has a very hard time
to enter rc6 with semaphores enabled.
Ben Widawsky run around with a kill-a-watt a lot and noticed:
- There are indeed a few rare systems that seem to have a hard time
entering rc6 when desktop-idle.
- One machine, The Indestructible Toshiba regressed in this behaviour
between 3.5 and 3.6 in a merge commit! So rc6 behaviour with the
current setting seems to be highly timing dependent and not robust
at all.
- The behaviour James reported wrt semaphores seems to be a freak
timing thing that only happens on his specific machine, confirming
that enabling semaphores shouldn't reduce rc6 residency.
Now furthermore the Google ChromeOS guys reported [2] a while ago that
at least on some machines a simply a blinking cursor can keep the gpu
turbo at the highest frequency. This is because the current rps limits
used on snb/ivb are highly asymmetric.
On the theory that gpu turbo and rc6 tuning values are related, we've
tried whether the much saner looking (since much less asymmetric) rps
tuning values used for hsw would also help entering rc6 more robustly.
And it seems to mostly work, and we don't really have the resources to
through-roughly tune things in any better way: The values from the
ChromeOS ppl seem to fare a bit worse for James' machine, so I guess
we better stick with something vpg (the gpu hw/windows group)
provided, hoping that they've done their jobs.
Reference[1]:
http://lists.freedesktop.org/archives/dri-devel/2012-July/025675.html
Reference[2]:
http://lists.freedesktop.org/archives/intel-gfx/2012-July/018692.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53393
Tested-by: Ben Widawsky <[email protected]>
Signed-off-by: Daniel Vetter <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
drivers/gpu/drm/i915/intel_pm.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2431,10 +2431,10 @@ void gen6_enable_rps(struct drm_i915_pri
I915_WRITE(GEN6_RP_INTERRUPT_LIMITS,
dev_priv->max_delay << 24 |
dev_priv->min_delay << 16);
- I915_WRITE(GEN6_RP_UP_THRESHOLD, 10000);
- I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 1000000);
- I915_WRITE(GEN6_RP_UP_EI, 100000);
- I915_WRITE(GEN6_RP_DOWN_EI, 5000000);
+ I915_WRITE(GEN6_RP_UP_THRESHOLD, 59400);
+ I915_WRITE(GEN6_RP_DOWN_THRESHOLD, 245000);
+ I915_WRITE(GEN6_RP_UP_EI, 66000);
+ I915_WRITE(GEN6_RP_DOWN_EI, 350000);
I915_WRITE(GEN6_RP_IDLE_HYSTERSIS, 10);
I915_WRITE(GEN6_RP_CONTROL,
GEN6_RP_MEDIA_TURBO |
Patches currently in stable-queue which might be from [email protected] are
queue-3.5/drm-i915-extract-connector-update-from-intel_ddc_get_modes-for-reuse.patch
queue-3.5/drm-i915-use-hsw-rps-tuning-values-everywhere-on-gen6.patch
queue-3.5/drm-i915-fall-back-to-bit-banging-if-gmbus-fails-in-crt-edid-reads.patch
--
To unsubscribe from this list: send the line "unsubscribe stable" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
