On Wed, 20 Apr 2011 17:21:03 -0700, Eric Anholt e...@anholt.net wrote:
On Sun, 17 Apr 2011 17:37:32 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
The 965G (Broadwater) and 965GM (Crestline) chipsets had many errata in
handling pages allocation above 4GiB. So we should be careful never
On Wed, 20 Apr 2011 16:53:17 -0700, Ben Widawsky b...@bwidawsk.net wrote:
Signed-off-by: Ben Widawsky b...@bwidawsk.net
Just to annoy you, this needs to be split up into the various categories
of fixes. Because...
static void ironlake_crtc_dpms(struct drm_crtc *crtc, int mode)
@@ -3067,9
On Wed, 20 Apr 2011 16:53:18 -0700, Ben Widawsky b...@bwidawsk.net wrote:
The render P-state handling code requires reading from a GT register.
This means that FORCEWAKE must be written to, a resource which is shared
and should be protected by struct_mutex.
Signed-off-by: Ben Widawsky
On Wed, 20 Apr 2011 16:53:14 -0700, Ben Widawsky b...@bwidawsk.net wrote:
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
I've had the opportunity to test this now on my 915GM. Lo and behold,
the very first thing it did was report a PGTBL_ER. Some head scratching
later, it became clear that we were never actually disabling the pipe
after load detection, leaving the plane pointing off into never-never
land.
-Chris
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
As we now never attempt to steal a crtc for load detection, we either
set a mode on a new pipe, or change the dpms mode on an existing pipe.
Never both, so we can simplify the code slightly.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c |8
Whilst this may appear to be a big batch, it is actually only a few bug
fixes from the last couple of weeks broken down into small steps.
1,2: Seem to be well tested now and fix the condition where the pipes
are still active and reading from memory as we rewrite the GTT. This
impacts both boot
From: Zhao Yakui yakui.z...@intel.com
... otherwise the TV type will be misdetected and cause spurious
connections.
This was originally applied as fb8b5a39b6310379d7b54c0c7113703a8eaf4a57
(drm/i915: Configure the TV sense state correctly on GM45 to make TV
detection reliable)
Eric: Shortly
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
... 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
Reviewed-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c |7 ++-
1 files changed, 2 insertions(+),
As we only allow the use of a disabled CRTC, we don't need to handle the
case where we are reusing an already enabled pipe.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Reviewed-by: Keith Packard kei...@keithp.com
---
drivers/gpu/drm/i915/intel_display.c | 28
Check the return value from drm_crtc_set_mode(), report the failure
via a debug message and propagate the error back to the caller. This
prevents us from blissfully continuing to do the load detection on a
disabled pipe. Fortunately actual failure for modesetting is very rare,
and reported
Reported-by: Alan Cox a...@linux.intel.com
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
Cc: sta...@kernel.org
---
drivers/gpu/drm/i915/intel_display.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
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.
As we now never attempt to steal a crtc for load detection, we either
set a mode on a new pipe, or change the dpms mode on an existing pipe.
Never both, so we can simplify the code slightly.
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_display.c |8
From: Dave Airlie airl...@redhat.com
i915 calls the panic handler function on last close to reset the modes,
however this is a really bad idea for multi-gpu machines, esp shareable
gpus machines. So add a new entry point for the driver to just restore
its own fbcon mode.
v2: move code into fb
When enabling the plane, it is helpful to have already pointed that
plane to valid memory or else we may incur the wrath of a PGTBL_ER.
This code preserved the behaviour from the bad old days for unknown
reasons...
Found by assert_fb_bound_for_plane().
References:
Knut Petersen reported a GPU hang when he left x11perf running
overnight. The error state quite clearly indicates that plane A was
enabled without being fully setup:
PGTBL_ER: 0x0010
Display A: Invalid GTT PTE
Plane [0]:
CNTR: c100
STRIDE: 0c80
SIZE: 03ff04ff
POS:
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 them inside the common encoder structure.
Signed-off-by: Chris Wilson
As we failed to update the dpms_mode after modeset, where it is presumed
to have been changed to DRM_MODE_DPMS_ON by the upper layers the dpms state
on the crtc became inconsistent with its actual active state. This
notably confused code and left the pipe active when it was meant to be
disabled,
If the outputs are active and continuing to access the GATT when we
teardown the PTEs, then there is a potential for us to hang the GPU.
The hang tends to be a PGTBL_ER with either an invalid host access or
an invalid display plane fetch.
v2: Reorder IRQ initialisation to defer until after GEM is
... and so remove the confusion as to whether to use the returned crtc
or intel_encoder-base.crtc with the subsequent load-detection. Even
though they were the same, the two instances of load-detection code
disagreed over which was the more correct.
Signed-off-by: Chris Wilson
On Thu, 21 Apr 2011 22:18:15 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Whilst this may appear to be a big batch, it is actually only a few bug
fixes from the last couple of weeks broken down into small steps.
Do you think any of these are needed in .39?
--
keith.pack...@intel.com
On Fri, Apr 22, 2011 at 7:56 AM, Keith Packard kei...@keithp.com wrote:
On Thu, 21 Apr 2011 22:18:15 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Whilst this may appear to be a big batch, it is actually only a few bug
fixes from the last couple of weeks broken down into small steps.
On Thu, 21 Apr 2011 22:18:22 +0100
Chris Wilson ch...@chris-wilson.co.uk wrote:
When enabling the plane, it is helpful to have already pointed that
plane to valid memory or else we may incur the wrath of a PGTBL_ER.
This code preserved the behaviour from the bad old days for unknown
On Wed, 20 Apr 2011, Mike Isely wrote:
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
On Thu, 21 Apr 2011 17:30:21 -0500 (CDT), Mike Isely is...@isely.net wrote:
It looks like the driver did notice the specified mode and used it -
because the display's refresh rate did get adjusted and the overall
resolution is correct. However the display timings are slightly off,
the
On Thu, 21 Apr 2011 14:56:21 -0700, Keith Packard kei...@keithp.com wrote:
On Thu, 21 Apr 2011 22:18:15 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
Whilst this may appear to be a big batch, it is actually only a few bug
fixes from the last couple of weeks broken down into small
On Thu, 21 Apr 2011, Chris Wilson wrote:
On Thu, 21 Apr 2011 17:30:21 -0500 (CDT), Mike Isely is...@isely.net wrote:
It looks like the driver did notice the specified mode and used it -
because the display's refresh rate did get adjusted and the overall
resolution is correct. However
On Thu, 21 Apr 2011 22:18:20 +0100, Chris Wilson ch...@chris-wilson.co.uk
wrote:
From: Zhao Yakui yakui.z...@intel.com
... otherwise the TV type will be misdetected and cause spurious
connections.
This was originally applied as fb8b5a39b6310379d7b54c0c7113703a8eaf4a57
(drm/i915:
On Thu, 21 Apr 2011 16:36:08 -0700, Eric Anholt e...@anholt.net wrote:
Maybe it actually makes things work (both for not-detecting no TV, and
detecting a real TV). But I also didn't like the because HW
requirement, instead of some specific explanation (some reason why we
need low sense level
32 matches
Mail list logo
