On Thu, 21 Apr 2011 17:06:30 -0700, Keith Packard wrote:
> On Fri, 22 Apr 2011 08:01:46 +1000, Dave Airlie wrote:
>
> > My one is definitely, I've got a few people who can't use machines
> > without it, I was going to push it myself, but I'm being nice ;-)
>
> I'll review all of them for .39 th
On Thu, 21 Apr 2011 16:36:08 -0700, Eric Anholt 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 on the cha
On Thu, 21 Apr 2011 22:18:20 +0100, Chris Wilson
wrote:
> From: Zhao Yakui
>
> ... 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
On Fri, 22 Apr 2011 08:01:46 +1000, Dave Airlie wrote:
> My one is definitely, I've got a few people who can't use machines
> without it, I was going to push it myself, but I'm being nice ;-)
I'll review all of them for .39 then; it wasn't clear from the original
mail whether that was the desire
On Thu, 21 Apr 2011, Chris Wilson wrote:
> On Thu, 21 Apr 2011 17:30:21 -0500 (CDT), Mike Isely 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
On Thu, 21 Apr 2011 14:56:21 -0700, Keith Packard wrote:
> On Thu, 21 Apr 2011 22:18:15 +0100, Chris Wilson
> 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 ar
On Thu, 21 Apr 2011 17:30:21 -0500 (CDT), Mike Isely 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 image is stret
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
> > wrote:
> > >
> > > Chris:
> > >
> > > I've tested this patch and it doesn't help us here. Even if I add
> > > lvds_fixed_mode=, the display still
On Thu, 21 Apr 2011 22:18:22 +0100
Chris Wilson 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
> reasons...
>
> Found by asser
On Thu, 21 Apr 2011 22:18:16 +0100
Chris Wilson wrote:
> Required so that we don't obliterate the queue if initialising the
> rings after the global IRQ handler is installed.
>
> [Jesse, you recently looked at refactoring the IRQ installation
> routines, does moving the initialisation of ring bu
On Fri, Apr 22, 2011 at 7:56 AM, Keith Packard wrote:
> On Thu, 21 Apr 2011 22:18:15 +0100, Chris Wilson
> 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 need
On Thu, 21 Apr 2011 22:18:15 +0100, Chris Wilson
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
pgpAZG9Gv4Qio.pgp
Desc
... 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
---
drivers/gpu/d
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
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, le
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
Reviewed-by: Ke
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:
Signed-off-by: Chris Wilson
Reviewed-by: Keith Packard
---
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 cfd58a2..132f83d 100644
--- a/drivers/gpu/d
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: https://bugs.freedesktop.org/sho
From: Dave Airlie
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 helper, fix panic cod
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
---
drivers/gpu/drm/i915/intel_display.c |8 +++-
1 files changed, 3
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.
Reported-and-
Reported-by: Alan Cox
Signed-off-by: Chris Wilson
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
b/drivers/gpu/drm/i915/intel_display.c
index 2183c4d..16f38e4 100644
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 failures
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
Reviewed-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c | 28 ++--
1 files changed, 10 insertions(+), 18
Required so that we don't obliterate the queue if initialising the
rings after the global IRQ handler is installed.
[Jesse, you recently looked at refactoring the IRQ installation
routines, does moving the initialisation of ring buffer data structures away
from that routine make sense in your gran
... and the no longer relevant comment. The code ceased stealing a pipe
for load detection a long time ago.
Signed-off-by: Chris Wilson
Reviewed-by: Keith Packard
---
drivers/gpu/drm/i915/intel_display.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/
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 t
From: Zhao Yakui
... 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 after applying this patch
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 and
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.
Reported-and-
On Tue, 19 Apr 2011 22:45:59 +0200, Daniel Vetter
wrote:
> The first 3 are stuff that I've found useful while hunting down gem_stress
> fallout.
>
> The latter 2 wrap up the gen2 tiling on the kernel side.
>
> Please review and consider merging for -next.
I've picked up the last 4 patches. The
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, le
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
---
drivers/gpu/drm/i915/intel_display.c |8 +++-
1 files changed, 3
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 t
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
___
36 matches
Mail list logo
