kernel/drivers/gpu/drm/i915/intel_display.c, branch linux-3.3.y

drm/i915: don't clobber the pipe param in sanitize_modesetting

2012-06-01T07:15:51Z

commit a9dcf84b14ef4e9a609910367576995e6f32f3dc upstream. ... we need it later on in the function to clean up pipe <-> plane associations. This regression has been introduced in commit f47166d2b0001fcb752b40c5a2d4db986dfbea68 Author: Chris Wilson Date: Thu Mar 22 15:00:50 2012 +0000 drm/i915: Sanitize BIOS debugging bits from PIPECONF Spotted by staring at debug output of an (as it turns out) totally unrelated bug. v2: I've totally failed to do the s/pipe/i/ correctly, spotted by Chris Wilson. Reviewed-by: Chris Wilson Reviewed-by: Eugeni Dodonov Signed-Off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: [GEN7] Use HW scheduler for fixed function shaders

2012-06-01T07:15:50Z

commit a1e969e0332de7a430e62822cee8f2ec8d83cd7c upstream. This originally started as a patch from Bernard as a way of simply setting the VS scheduler. After submitting the RFC patch, we decided to also modify the DS scheduler. To be most explicit, I've made the patch explicitly set all scheduler modes, and included the defines for other modes (in case someone feels frisky later). The rest of the story gets a bit weird. The first version of the patch showed an almost unbelievable performance improvement. Since rebasing my branch it appears the performance improvement has gone, unfortunately. But setting these bits seem to be the right thing to do given that the docs describe corruption that can occur with the default settings. In summary, I am seeing no more perf improvements (or regressions) in my limited testing, but we believe this should be set to prevent rendering corruption, therefore cc stable. v1: Clear bit 4 also (Ken + Eugeni) Do a full clear + set of the bits we want (Me). Cc: Bernard Kilarski Reviewed-by (RFC): Kenneth Graunke Signed-off-by: Ben Widawsky Reviewed-by: Eugeni Dodonov Reviewed-by: Kenneth Graunke Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: Sanitize BIOS debugging bits from PIPECONF

2012-04-13T16:13:53Z

commit f47166d2b0001fcb752b40c5a2d4db986dfbea68 upstream. Quoting the BSpec from time immemorial: PIPEACONF, bits 28:27: Frame Start Delay (Debug) Used to delay the frame start signal that is sent to the display planes. Care must be taken to insure that there are enough lines during VBLANK to support this setting. An instance of the BIOS leaving these bits set was found in the wild, where it caused our modesetting to go all squiffy and skewiff. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=47271 Reported-and-tested-by: Eva Wang Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=43012 Reported-and-tested-by: Carl Richell Signed-off-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman

drm/i915: support 32 bit BGR formats in sprite planes

2012-03-07T18:52:13Z

intel_framebuffer_init does some basic sanity checking of the pixel format, but is used by the plane code in addition to the primary crtc. So it needs to contain any formats used in either place. Add the XBGR8888 format to the checklist so the plane code can use it. Signed-off-by: Jesse Barnes Signed-off-by: Keith Packard

drm/i915: Prevent a machine hang by checking crtc->active before loading lut

2012-02-24T17:36:25Z

Before loading the lut (gamma), check the active state of intel_crtc, otherwise at least on gen2 hang ensue. This is reproducible in Xorg via: xset dpms force off then xgamma -rgamma 2.0 # freeze. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=44505 Signed-off-by: Alban Browaeys Signed-off-by: Chris Wilson Reviewed-by: Jesse Barnes Cc: stable@kernel.org Signed-off-by: Jesse Barnes

drm/i915: fix operator precedence when enabling RC6p

2012-02-24T17:34:10Z

As noticed by Torsten Kaiser, the operator precedence can play tricks with us here. CC: Dave Airlie Signed-off-by: Eugeni Dodonov Signed-off-by: Jesse Barnes

drm/i915: fix a sprite watermark computation to avoid divide by zero if xpos<0

2012-02-23T16:56:40Z

When setting overlay position with x<0, it will divide 0 and make drm driver crash. Signed-off-by: Hai Lan Signed-off-by: Jesse Barnes

drm/i915: fix mode set on load pipe. (v2)

2012-02-23T16:06:31Z

Booted my i965 machine and it started printing the unsupported pixel format of 0 message (once I added content to it). Oh looksie here, we pass 0. fix. v2: compile it. Buzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45966 Reviewed-by: Daniel Vetter Reviewed-by: Chris Wilson Signed-off-by: Dave Airlie Signed-off-by: Jesse Barnes

Merge branch 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel into drm-fixes

2012-02-22T08:02:17Z

* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/drm-intel: drm/i915: do not enable RC6p on Sandy Bridge drm/i915: gen7: Disable the RHWO optimization as it can cause GPU hangs. drm/i915: gen7: work around a system hang on IVB drm/i915: gen7: Implement an L3 caching workaround. drm/i915: gen7: implement rczunit workaround

drm/i915: do not enable RC6p on Sandy Bridge

2012-02-16T01:43:41Z

With base on latest findings, RC6p seems to be respondible for RC6-related issues on Sandy Bridge platform. To work-around those issues, the previous solution was to completely disable RC6 on Sandy Bridge for the past few releases, even if plain RC6 was not giving any issues. What this patch does is preventing RC6p from being enabled on Sandy Bridge even if users enable RC6 via a kernel parameter. So it won't change the defaults in any way, but will ensure that if users do enable RC6 manually it won't break their machines by enabling this extra state. Proper fix for this (enabling specific RC6 states according to the GPU generation) were proposed for the -next kernel, but we are too late in the release process now to pick such changes. Acked-by: Keith Packard Signed-off-by: Eugeni Dodonov Signed-off-by: Jesse Barnes