On Mon, Feb 27, 2012 at 13:09, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:

On Thu, 23 Feb 2012 21:19:20 +0100
Torsten Kaiser <just.for.lkml@googlemail.com> wrote:

> On Wed, Feb 22, 2012 at 8:56 PM, Dave Airlie <airlied@linux.ie> wrote:
> > Eugeni Dodonov (4):
> > drm/i915: gen7: implement rczunit workaround
> > drm/i915: gen7: Implement an L3 caching workaround.
> > drm/i915: gen7: work around a system hang on IVB
> > drm/i915: do not enable RC6p on Sandy Bridge
>
> That last patch about RC6p looks wrong.
>
> It does:
> GEN6_RC_CTL_RC6_ENABLE |
> (IS_GEN7(dev_priv->dev)) ? GEN6_RC_CTL_RC6p_ENABLE : 0;
> But I think this was meant:
> GEN6_RC_CTL_RC6_ENABLE |
> ((IS_GEN7(dev_priv->dev)) ? GEN6_RC_CTL_RC6p_ENABLE : 0);
>
> Or did I get the operator precedence wrong?

You're right, no cookie for Eugeni. :) This would have prevented RC6
from ever getting enabled though, which should have the same effect as
the patch intended, though at the cost of higher power consumption.

Actually, no, it got RC6p enabled - so it got to have all the power savings of RC6 plus some additional ones in the range of 0.1W, but it also resulted in the very same problem as before, when both RC6 and RC6p were enabled.

So, from what we've seen with https://wiki.ubuntu.com/Kernel/PowerManagementRC6, the graphics corruptions do only happen when RC6p is enabled (either together with RC6, or individually, on its own). If we have only RC6, all the issues are gone so far.

So this bad patch had its use after all - it served to finally isolate and prove that the i915_enable_rc6-related issues are caused directly by RC6p.