[git pull] drm fixes

[git pull] drm fixes

[Dave Airlie]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 3513 bytes --]


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(-)

Re: [git pull] drm fixes

[Torsten Kaiser]

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

[PATCH 1/1] drm/i915: fix operator precedence when enabling RC6p

[Eugeni Dodonov]

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 |
-- 
1.7.8.4

Re: [PATCH 1/1] drm/i915: fix operator precedence when enabling RC6p

[Jesse Barnes]

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]

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,
-- 
Jesse Barnes, Intel Open Source Technology Center

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [git pull] drm fixes

[Jesse Barnes]

[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]

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.

-- 
Jesse Barnes, Intel Open Source Technology Center

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [git pull] drm fixes

[Jesse Barnes]

[-- Attachment #1: Type: text/plain, Size: 2159 bytes --]

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.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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]