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 <[email protected]> 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 <[email protected]>
CC: Jesse Barnes <[email protected]>
Signed-off-by: Eugeni Dodonov <[email protected]>
---
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
On Thu, 23 Feb 2012 23:57:06 -0200
Eugeni Dodonov <[email protected]> wrote:
> As noticed by Torsten Kaiser, the operator precedence can play tricks with
> us here.
>
> CC: Dave Airlie <[email protected]>
> CC: Jesse Barnes <[email protected]>
> Signed-off-by: Eugeni Dodonov <[email protected]>
> ---
> 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
On Thu, 23 Feb 2012 21:19:20 +0100
Torsten Kaiser <[email protected]> wrote:
> On Wed, Feb 22, 2012 at 8:56 PM, Dave Airlie <[email protected]> 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
On Mon, 27 Feb 2012 13:33:53 -0300
Eugeni Dodonov <[email protected]> wrote:
> On Mon, Feb 27, 2012 at 13:09, Jesse Barnes <[email protected]>wrote:
>
> > On Thu, 23 Feb 2012 21:19:20 +0100
> > Torsten Kaiser <[email protected]> wrote:
> >
> > > On Wed, Feb 22, 2012 at 8:56 PM, Dave Airlie <[email protected]> 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