On Mon, 27 Feb 2012 13:33:53 -0300 Eugeni Dodonov wrote: > On Mon, Feb 27, 2012 at 13:09, Jesse Barnes wrote: > > > On Thu, 23 Feb 2012 21:19:20 +0100 > > Torsten Kaiser wrote: > > > > > On Wed, Feb 22, 2012 at 8:56 PM, Dave Airlie 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. Oh you're right; I had the bit positions mixed up... I thought the higher level bit toggled all RC6 functionality, but that's kept separate from this. -- Jesse Barnes, Intel Open Source Technology Center