One of the original chores for intel_get_load_detect_pipe() was to steal
a CRTC from an active output for the transient purpose of load detection.
Understandably this code was removed some time ago, but its legacy remains.
In order to fix a real bug, where we failed to attach a fb, I first had to
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
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 0d8d5e2..61fa02f 100644
---
As we only allow the use of a disabled CRTC, we don't need to handle the
case we are reusing an already enabled pipe.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c | 28 ++--
1 files changed, 10 insertions(+), 18
... and the no longer relevant comment. The code ceased stealing a pipe
for load detection a long time ago.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git
On Tue, 19 Apr 2011 14:26:04 -0700, Keith Packard kei...@keithp.com wrote:
On Tue, 19 Apr 2011 21:32:02 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
We need to ensure that we feed valid memory into the display plane
attached to the pipe when switching the pipe on. Otherwise, the
On Wed, Apr 20, 2011 at 09:18:03AM +0100, Chris Wilson wrote:
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 316603e..8cac87c 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++
On Wed, 20 Apr 2011 07:27:24 -0700, Ben Widawsky b...@bwidawsk.net wrote:
On Wed, Apr 20, 2011 at 09:18:03AM +0100, Chris Wilson wrote:
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 316603e..8cac87c 100644
---
On Thu, Apr 07, 2011 at 02:32:58PM -0700, Jesse Barnes wrote:
Rather than branching in ironlake_pch_enable, add a new train_fdi
function to the display function pointer struct and use it instead.
Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org
---
drivers/gpu/drm/i915/i915_drv.h
On Wed, 20 Apr 2011 07:45:08 -0700
Ben Widawsky b...@bwidawsk.net wrote:
@@ -7270,6 +7267,7 @@ static void intel_init_display(struct drm_device *dev)
Disable CxSR\n);
dev_priv-display.update_wm = NULL;
Given that the hardware may be left in a random condition by the BIOS,
it is conceivable that we then attempt to clear the DP_PIPEB_SELECT bit
without us ever enabling/attaching the DP encoder to a pipe. Thus
causing a NULL deference when we attempt to wait for a vblank on that
crtc.
On Wed, 20 Apr 2011 16:42:08 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Given that the hardware may be left in a random condition by the BIOS,
it is conceivable that we then attempt to clear the DP_PIPEB_SELECT bit
without us ever enabling/attaching the DP encoder to a pipe. Thus
On Wed, 20 Apr 2011 10:22:17 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
+
+ if (!drm_crtc_helper_set_mode(crtc, mode, 0, 0, crtc-fb)) {
+ DRM_DEBUG_KMS(failed to set mode on load-detect
pipe\n);
+ return false;
+ }
On Wed, 20 Apr 2011 10:22:18 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Keep all the state required for undoing and restoring the previous pipe
configuration together in a single struct passed from
intel_get_load_detect_pipe() to intel_release_load_detect_pipe() rather
than stuffing
On Wed, 20 Apr 2011 10:22:20 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Keith Packard kei...@keithp.com
(this might be separately tested to see if it might fix some TV load
detection issues?)
--
On Wed, 20 Apr 2011 10:36:29 -0700, Keith Packard kei...@keithp.com wrote:
On Wed, 20 Apr 2011 16:42:08 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Given that the hardware may be left in a random condition by the BIOS,
it is conceivable that we then attempt to clear the
On Wed, 20 Apr 2011 11:43:38 -0700, Keith Packard kei...@keithp.com wrote:
On Wed, 20 Apr 2011 10:22:22 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
For bonus amusement value, we perform the first load detect before even
establishing our fbdev.
It seems like we need to be able
Andrew, do you have anything hacked together for this yet?
Nope. I gave up because I couldn't even get the mode to set. :)
Ok well you should be able to now. :) Using the patchset I posted
earlier along with the two attached patches, the testdisplay program in
intel-gpu-tools will set a
On Wed, Apr 20, 2011 at 3:38 PM, Jesse Barnes jbar...@virtuousgeek.org wrote:
Andrew, do you have anything hacked together for this yet?
Nope. I gave up because I couldn't even get the mode to set. :)
Ok well you should be able to now. :) Using the patchset I posted
earlier along with the
Chris:
I've tested this patch and it doesn't help us here. Even if I add
lvds_fixed_mode=whatever, the display still comes up with the messed
up configuration from the motherboard's completely ignorant BIOS. It
appears that lvds_fixed_mode is being ignored by the driver.
I think there's
On Wed, 20 Apr 2011 14:48:36 -0500 (CDT), Mike Isely is...@isely.net wrote:
Chris:
I've tested this patch and it doesn't help us here. Even if I add
lvds_fixed_mode=whatever, the display still comes up with the messed
up configuration from the motherboard's completely ignorant BIOS. It
On Wed, 20 Apr 2011, Chris Wilson wrote:
On Wed, 20 Apr 2011 14:48:36 -0500 (CDT), Mike Isely is...@isely.net wrote:
Chris:
I've tested this patch and it doesn't help us here. Even if I add
lvds_fixed_mode=whatever, the display still comes up with the messed
up configuration
We need to ensure that we feed valid memory into the display plane
attached to the pipe when switching the pipe on. Otherwise, the display
engine may read through an invalid PTE and so throw an PGTBL_ER
exception.
As we need to perform load detection before even the first object is
allocated for
On Wed, 20 Apr 2011 20:38:54 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
On Wed, 20 Apr 2011 11:23:01 -0700, Keith Packard kei...@keithp.com wrote:
On Wed, 20 Apr 2011 10:22:20 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Signed-off-by: Chris Wilson
On Wed, 20 Apr 2011 19:55:10 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
I'll spin up a patch for a temporary buffer and see what you think.
Ok. I'd love to be able to use that code path all of the time, but I
don't like the thought of the cost of a temporary allocation every time
you
We need to ensure that we feed valid memory into the display plane
attached to the pipe when switching the pipe on. Otherwise, the display
engine may read through an invalid PTE and so throw an PGTBL_ER
exception.
As we need to perform load detection before even the first object is
allocated for
Moved the macros around to properly do reads and writes for the given
GPU. This is to address special requirements for gen6 (SNB) reads and
writes.
Registers in the range 0-0x4 on gen6 platforms require special
handling. Instead of relying on the callers to pick the registers
correctly, move
forcewake is controlled by the open and close of the debugfs file. This
assures that buggy applications cannot cause the GT to stay on forever.
Signed-off-by: Ben Widawsky b...@bwidawsk.net
---
drivers/gpu/drm/i915/i915_debugfs.c | 80 +++
1 files changed, 80
Once you're done laughing that I got up to v5 (I think I skipped a v3,
and v1 was the IOCTls, so it's really more like a v3) for patches meant
to simply allow register reads and wites...
Back to struct_mutex since it turned out to be my mistake regarding the
IIR problem. The only issue in the
28 matches
Mail list logo
