Hi Linus,
Intel, radeon, exynos fixes.
Intel: fixes a few Ivybridge hangs, along with fixing RC6 on SNB (still not on, but at least allows for distros to patch it on easily). radeon: oops reading some files in debugfs that weren't meant to appear, a fix that touches a lot of files, so looks worse than it is, it fixes an oops if a GPU reset fails and userspace keeps submitting more data, along with a minor BIOS fix for newer boards.
exynos: a group of fixes for exynos, they've sent me a few more but these were all I got through, and its no hw vanilla kernel users see a lot off yet.
Dave.
The following changes since commit b7f5b7dec3d539a84734f2bcb7e53fbb1532a40b:
drm/radeon/kms: fix MSI re-arm on rv370+ (2012-02-14 13:36:23 +0000)
are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-fixes
Alex Deucher (1): drm/radeon/kms/atom: dpms bios scratch reg updates
Dave Airlie (1): Merge branch 'drm-intel-fixes' of git://git.kernel.org/.../jbarnes/drm-intel into drm-fixes
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
Inki Dae (4): drm/exynos: added possible_clones setup function. drm/exynos: fixed page flip issue. drm/exynos: removed exynos_drm_fbdev_recreate function. drm/exynos: added postclose to release resource.
Jerome Glisse (1): drm/radeon/kms: properly set accel working flag and bailout when false
Joonyoung Shim (2): drm/exynos: changed priority of mixer layers. drm/exynos: removed pageflip_event_list init code when closed.
Kenneth Graunke (1): drm/i915: gen7: Disable the RHWO optimization as it can cause GPU hangs.
Masanari Iida (1): drm/exynos: Fix typo in exynos_mixer.c
Michel Dänzer (1): drm/radeon: Only create additional ring debugfs files on Cayman or newer.
drivers/gpu/drm/exynos/exynos_drm_core.c | 3 + drivers/gpu/drm/exynos/exynos_drm_crtc.c | 6 +- drivers/gpu/drm/exynos/exynos_drm_drv.c | 26 +++++++--- drivers/gpu/drm/exynos/exynos_drm_encoder.c | 34 +++++++++++++ drivers/gpu/drm/exynos/exynos_drm_encoder.h | 1 + drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 70 ++------------------------- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 7 ++- drivers/gpu/drm/exynos/exynos_mixer.c | 19 +++++--- drivers/gpu/drm/i915/i915_reg.h | 15 ++++++ drivers/gpu/drm/i915/intel_display.c | 24 ++++++++- drivers/gpu/drm/radeon/evergreen.c | 1 + drivers/gpu/drm/radeon/ni.c | 1 + drivers/gpu/drm/radeon/r100.c | 8 +++- drivers/gpu/drm/radeon/r300.c | 8 +++- drivers/gpu/drm/radeon/r420.c | 8 +++- drivers/gpu/drm/radeon/r520.c | 8 +++- drivers/gpu/drm/radeon/r600.c | 1 + drivers/gpu/drm/radeon/radeon_atombios.c | 3 + drivers/gpu/drm/radeon/radeon_cs.c | 4 ++ drivers/gpu/drm/radeon/radeon_ring.c | 7 ++- drivers/gpu/drm/radeon/rs400.c | 8 +++- drivers/gpu/drm/radeon/rs600.c | 8 +++- drivers/gpu/drm/radeon/rs690.c | 8 +++- drivers/gpu/drm/radeon/rv515.c | 8 +++- drivers/gpu/drm/radeon/rv770.c | 1 + 25 files changed, 190 insertions(+), 97 deletions(-)
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?
HTH
Torsten
As noticed by Torsten Kaiser, the operator precedence can play tricks with us here.
CC: Dave Airlie airlied@redhat.com CC: Jesse Barnes jbarnes@virtuousgeek.org Signed-off-by: Eugeni Dodonov eugeni.dodonov@intel.com --- drivers/gpu/drm/i915/intel_display.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index e654f32..4871ba0 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8194,7 +8194,7 @@ void gen6_enable_rps(struct drm_i915_private *dev_priv)
if (intel_enable_rc6(dev_priv->dev)) rc6_mask = GEN6_RC_CTL_RC6_ENABLE | - (IS_GEN7(dev_priv->dev)) ? GEN6_RC_CTL_RC6p_ENABLE : 0; + ((IS_GEN7(dev_priv->dev)) ? GEN6_RC_CTL_RC6p_ENABLE : 0);
I915_WRITE(GEN6_RC_CONTROL, rc6_mask |
On Thu, 23 Feb 2012 23:57:06 -0200 Eugeni Dodonov eugeni.dodonov@intel.com wrote:
As noticed by Torsten Kaiser, the operator precedence can play tricks with us here.
CC: Dave Airlie airlied@redhat.com CC: Jesse Barnes jbarnes@virtuousgeek.org Signed-off-by: Eugeni Dodonov eugeni.dodonov@intel.com
drivers/gpu/drm/i915/intel_display.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index e654f32..4871ba0 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -8194,7 +8194,7 @@ void gen6_enable_rps(struct drm_i915_private *dev_priv)
if (intel_enable_rc6(dev_priv->dev)) rc6_mask = GEN6_RC_CTL_RC6_ENABLE |
(IS_GEN7(dev_priv->dev)) ? GEN6_RC_CTL_RC6p_ENABLE : 0;
((IS_GEN7(dev_priv->dev)) ? GEN6_RC_CTL_RC6p_ENABLE : 0);I915_WRITE(GEN6_RC_CONTROL, rc6_mask |
ugg yeah, with the old code we'd never end up enabling rc6 at all. Pushed.
Thanks,
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.
Fix just sent to Dave anyway.
On Mon, Feb 27, 2012 at 13:09, Jesse Barnes jbarnes@virtuousgeek.orgwrote:
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.
On Mon, 27 Feb 2012 13:33:53 -0300 Eugeni Dodonov eugeni@dodonov.net wrote:
On Mon, Feb 27, 2012 at 13:09, Jesse Barnes jbarnes@virtuousgeek.orgwrote:
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.
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.
dri-devel@lists.freedesktop.org
-
Dave Airlie -
Eugeni Dodonov -
Eugeni Dodonov -
Jesse Barnes -
Torsten Kaiser