On Tue, 19 Apr 2011 21:32:02 +0100, Chris Wilson
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 display
> engine may read through an invalid PTE and so throw an PGTBL_ER
> exception.
This seems to rew
On Tue, 19 Apr 2011 21:32:01 +0100
Chris Wilson wrote:
> 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]
On Tue, 19 Apr 2011 21:32:03 +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
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
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:
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.
For bonus amusement value, we perform the first load detect before even
establishing
I revised the diagnostic patch (assert_fb_bound_for_plane) so that the
function comment actually matches what the function does and ran it on a
couple of machines whilst bug hunting. It scored 2 direct hits. Not only
does intel_get_load_detect_pipe() not attach a framebuffer when enabling
an unused
On Tue, 19 Apr 2011 15:50:01 -0400
Andy Lutomirski wrote:
> Signed-off-by: Andy Lutomirski
> ---
>
> This patch is over a year old, caused problems, and probably doesn't even
> apply anymore. It worked at least a little bit, though. There's a lot more
> that needs doing, especially in relat
Signed-off-by: Andy Lutomirski
---
This patch is over a year old, caused problems, and probably doesn't even apply
anymore. It worked at least a little bit, though. There's a lot more that
needs doing, especially in relation to DirectColor mode.
src/intel_driver.c |5 +++--
1 files chan
A tile on gen2 has a size of 2kb, stride of 128 bytes and 16 rows.
Userspace was broken and assumed 8 rows. Chris Wilson noted that the
kernel unfortunately can't reliable check that because libdrm rounds
up the size to the next bucket.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915
Experiments showed that y-tiled access from the cpu doesn't work on my gen2
machine.
Checking this in create_mmap_offset does not work due to libdrm bo reuse.
Chris Wilson also clarified (by checking internal docs) that only i855GM has
broken y-tiled fences for cpu access (guess what hw I own). H
The corresponding WARN_ON with opposite sign already exists in
move_to_inactive, hence add it here for symmetry.
I've actually hit this while hunting down bugs in various
pipelined fencing patches.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/i915_gem.c |1 +
1 files changed, 1 ins
If it's a simple gem accounting error that won't lead to immediate harm
(like a NULL-deref) or is a simple violation of a required invariant
that the caller should always check/ensure, downgrade the BUG_ON to
a WARN_ON and hope the system survives long enough to grab the dmesg.
Signed-off-by: Dani
This happens in two cases:
- userspace got its fence accounting wrong or
- the kernel got its fence accounting wrong.
In both cases there's absolutely no point in calling evict_everything,
that will not magically bring back the missing fence. So return a
different (hopefully somewhat sensible) err
Hi all,
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.
Thanks, Daniel
Daniel Vetter (5):
drm/i915: downgrade non-lethal BUG_ONs
drm/i915: not finding
On Tue, 19 Apr 2011 12:12:40 -0700
Jesse Barnes wrote:
> The pipe may be driving various bpp values depending on the display
> configuration, so take that into account when calculating link bandwidth
> requirements.
>
Oops, mixed up this changelog with another piece. The bpp is actually
being
Updating the planes is device specific, so create a new display callback
and use it in pipe_set_base. (In fact we could go even further, valid
display plane bits have changed with each generation, as has tiled
buffer handling.)
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.h
The pipe may be driving various bpp values depending on the display
configuration, so take that into account when calculating link bandwidth
requirements.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_dp.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/
Figuring out which pipe bpp to use is a bit painful. It depends on both
the encoder and display configuration attached to a pipe. For instance,
to drive a 24bpp framebuffer out to an 18bpp panel, we need to use 6bpc
on the pipe but also enable dithering. But driving that same
framebuffer to a Di
The Intel HDMI encoder can support 8bpc or 12bpc. Set the appropriate
value based on the pipe bpp when configuring the output.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_hdmi.c |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/i915/inte
This may not be the default value, so pull the bpc out of the pipe reg
and write it to the DP transcoder so proper dithering and signaling
occurs.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drive
ILK+ provides this feature in the transcoder and pipe configuration instead.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_hdmi.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index f
BPC is specified in FDI RX on CPT and above, rather than in the transcoder.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/intel_display.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/int
This collection of patches sits on top of my two DRM EDID patches to fetch
display color format support. They fix a few bugs in our depth handling
code, and allow for deep color configurations to be enabled in the core
display code (still working on good tests for this).
Looking for comments on h
On Mon, 18 Apr 2011 10:31:43 -0700, Ben Widawsky wrote:
> gen6_gt_force_wake_get()
> while(foo)
> i915_read32_awake()
> gen6_gt_force_wake_put()
Uh. Anything looping on registers might not want to hold the lock...
--
keith.pack...@intel.com
pgpgKFMx6v8mp.pgp
Description: PGP signature
Yes, I think so if there is no discrete graphics card in your machine.
Hai Lan
> -Original Message-
> From: Sergio Monteiro Basto [mailto:ser...@sergiomb.no-ip.org]
> Sent: Tuesday, April 19, 2011 10:44 PM
> To: Lan, Hai
> Cc: Paul Menzel; intel-gfx@lists.freedesktop.org
> Subject: Re: [
Hi,
my dell Latitude E6410
with an arrandale http://en.wikipedia.org/wiki/Arrandale
seems to be a Intel® HD Graphics , is eligible for use vaapi ?
On Tue, 2011-04-19 at 09:56 +0800, Lan, Hai wrote:
> Dear Paul,
> Thanks for your suggestion. http://intellinuxgraphics.org/vaapi.html has been
27 matches
Mail list logo
