drm/i915: Correct sandybrige overclocking
authorBen Widawsky <ben@bwidawsk.net>
Wed, 20 Mar 2013 03:19:56 +0000 (20:19 -0700)
committerDaniel Vetter <daniel.vetter@ffwll.ch>
Sat, 23 Mar 2013 11:18:04 +0000 (12:18 +0100)
commita2b3fc0133083d2ab1edac9c3485eb80d1378dbb
tree3d834dc654014b430725b2cf8c748143887a3b1d
parent219f4fdbed5570f1d2e8da0af1c298dd3622060e
drm/i915: Correct sandybrige overclocking

Change the gen6+ max delay if the pcode read was successful (not the
inverse).

The previous code was all sorts of wrong and has existed since I broke
it:
commit 42c0526c930523425ff6edc95b7235ce7ab9308d
Author: Ben Widawsky <ben@bwidawsk.net>
Date:   Wed Sep 26 10:34:00 2012 -0700

    drm/i915: Extract PCU communication

I added some parentheses for clarity, and I also corrected the debug
message message to use the mask (wrong before I came along) and added a
print to show the value we're changing from.

Looking over the code, I'm not actually sure what we're trying to do. I
introduced the bug simply by extracting the function not implementing
anything new. We already set max_delay based on the capabilities
register (which is what we use elsewhere to determine min and max).
This would potentially increase it, I suppose? Jesse, I can't find the
document which explains the definitions of the pcode commands, maybe you
have it around.

Based on Jesse's response, this could potentially be for -fixes, or
stable, or maybe lead to us dropping it entirely. As the current code is
is, things won't completely break because of the aforementioned
capabilities register, and in my experimentation, enabling this has no
effect, it goes from 1100->1100.

I found this while reviewing Jesse's VLV patches.

Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Bikeshed-away the redudant parens spotted by Chris Wilson.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drivers/gpu/drm/i915/intel_pm.c