Re: [Intel-gfx] [PATCH 2/3] drm/i915: Attach a fb to the load-detect pipe

2011-04-19 Thread Keith Packard 
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 rewrite most of the load detection code, but doesn't
justify that rewrite in comments (either commit or in-line). You'll need
to break this up so that we can actually see what is changing.

-- 
keith.pack...@intel.com


pgpMiffuFj5GY.pgp
Description: PGP signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Check that the plane points to the pipe's framebuffer before enabling

2011-04-19 Thread Jesse Barnes 
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]:
>   CNTR: c100
>   STRIDE: 0c80
>   SIZE: 03ff04ff
>   POS: 
>   ADDR: 
> 
> [That GTT offset on his system being pinned for the ringbuffer.]
> 
> This is a simple debugging patch to assert that this cannot be so!
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=36246
> Signed-off-by: Chris Wilson 
> Cc: Jesse Barnes 
> ---

I like it.

Reviewed-by: Jesse Barnes 

-- 
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Only enable the plane after setting the fb base (pre-ILK)

2011-04-19 Thread Jesse Barnes 
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 assert_fb_bound_for_plane().
> 
> References: https://bugs.freedesktop.org/show_bug.cgi?id=36246
> Signed-off-by: Chris Wilson 
> Cc: Daniel Vetter 
> Cc: Jesse Barnes 
> ---
>  drivers/gpu/drm/i915/intel_display.c |2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index b9bb20d..f503ad0 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5212,8 +5212,6 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc,
>  
>   I915_WRITE(DSPCNTR(plane), dspcntr);
>   POSTING_READ(DSPCNTR(plane));
> - if (!HAS_PCH_SPLIT(dev))
> - intel_enable_plane(dev_priv, plane, pipe);
>  
>   ret = intel_pipe_set_base(crtc, x, y, old_fb);
>  

As usual, changes like this frighten me.  I think the plane enable
prior to the base set has been in there for a *long* time in various
forms.  I think Carl tried to take it out when trying to debug eDP on
ILK, but we reverted that when it broke things.

But if it works on all your test machines, I guess that's a start; it's
correct in theory at least.

Reviewed-by: Jesse Barnes 

-- 
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/3] drm/i915: Only enable the plane after setting the fb base (pre-ILK)

2011-04-19 Thread Chris Wilson 
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/show_bug.cgi?id=36246
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Cc: Jesse Barnes 
---
 drivers/gpu/drm/i915/intel_display.c |2 --
 1 files changed, 0 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b9bb20d..f503ad0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5212,8 +5212,6 @@ static int intel_crtc_mode_set(struct drm_crtc *crtc,
 
I915_WRITE(DSPCNTR(plane), dspcntr);
POSTING_READ(DSPCNTR(plane));
-   if (!HAS_PCH_SPLIT(dev))
-   intel_enable_plane(dev_priv, plane, pipe);
 
ret = intel_pipe_set_base(crtc, x, y, old_fb);
 
-- 
1.7.4.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/3] drm/i915: Check that the plane points to the pipe's framebuffer before enabling

2011-04-19 Thread Chris Wilson 
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: 
  ADDR: 

[That GTT offset on his system being pinned for the ringbuffer.]

This is a simple debugging patch to assert that this cannot be so!

References: https://bugs.freedesktop.org/show_bug.cgi?id=36246
Signed-off-by: Chris Wilson 
Cc: Jesse Barnes 
---
 drivers/gpu/drm/i915/intel_display.c |   29 +
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 73cec21..b7d63a5 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1560,6 +1560,34 @@ static void intel_disable_pipe(struct drm_i915_private 
*dev_priv,
intel_wait_for_pipe_off(dev_priv->dev, pipe);
 }
 
+/* Check that the display plane points to the pipe's framebuffer. */
+static void assert_fb_bound_to_plane(struct drm_i915_private *dev_priv,
+enum pipe pipe, enum plane plane)
+{
+   struct drm_crtc *crtc;
+   struct intel_framebuffer *intel_fb;
+   u32 val, base, size;
+
+   crtc = intel_get_crtc_for_pipe(dev_priv->dev, pipe);
+   if (WARN(crtc->fb == NULL,
+"no framebuffer attached to pipe %c\n",
+pipe_name(pipe)))
+   return;
+
+   intel_fb = to_intel_framebuffer(crtc->fb);
+   base = intel_fb->obj->gtt_offset;
+   size = intel_fb->obj->base.size;
+
+   if (dev_priv->info->gen >= 4)
+   val = I915_READ(DSPSURF(plane));
+   else
+   val = I915_READ(DSPADDR(plane));
+   WARN(val < base || val >= base + size,
+"mismatching framebuffer for plane %c attached to pipe %c, 
expected %x-%x found %x\n",
+plane_name(plane), pipe_name(pipe),
+base, base + size, val);
+}
+
 /**
  * intel_enable_plane - enable a display plane on a given pipe
  * @dev_priv: i915 private structure
@@ -1576,6 +1604,7 @@ static void intel_enable_plane(struct drm_i915_private 
*dev_priv,
 
/* If the pipe isn't enabled, we can't pump pixels and may hang */
assert_pipe_enabled(dev_priv, pipe);
+   assert_fb_bound_to_plane(dev_priv, pipe, plane);
 
reg = DSPCNTR(plane);
val = I915_READ(reg);
-- 
1.7.4.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/3] drm/i915: Attach a fb to the load-detect pipe

2011-04-19 Thread Chris Wilson 
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 our fbdev.

Reported-by: Knut Petersen 
References: https://bugs.freedesktop.org/show_bug.cgi?id=36246
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/intel_crt.c |   24 ++---
 drivers/gpu/drm/i915/intel_display.c |  182 +++---
 drivers/gpu/drm/i915/intel_drv.h |   25 +++--
 drivers/gpu/drm/i915/intel_tv.c  |   11 +--
 4 files changed, 132 insertions(+), 110 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index d03fc05..2a32405 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
+++ b/drivers/gpu/drm/i915/intel_crt.c
@@ -305,13 +305,11 @@ static bool intel_crt_detect_ddc(struct drm_connector 
*connector)
 }
 
 static enum drm_connector_status
-intel_crt_load_detect(struct drm_crtc *crtc, struct intel_crt *crt)
+intel_crt_load_detect(struct intel_crt *crt)
 {
-   struct drm_encoder *encoder = &crt->base.base;
-   struct drm_device *dev = encoder->dev;
+   struct drm_device *dev = crt->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   uint32_t pipe = intel_crtc->pipe;
+   uint32_t pipe = to_intel_crtc(crt->base.base.crtc)->pipe;
uint32_t save_bclrpat;
uint32_t save_vtotal;
uint32_t vtotal, vactive;
@@ -432,7 +430,6 @@ intel_crt_detect(struct drm_connector *connector, bool 
force)
struct drm_device *dev = connector->dev;
struct intel_crt *crt = intel_attached_crt(connector);
struct drm_crtc *crtc;
-   int dpms_mode;
enum drm_connector_status status;
 
if (I915_HAS_HOTPLUG(dev)) {
@@ -454,17 +451,18 @@ intel_crt_detect(struct drm_connector *connector, bool 
force)
/* for pre-945g platforms use load detect */
crtc = crt->base.base.crtc;
if (crtc && crtc->enabled) {
-   status = intel_crt_load_detect(crtc, crt);
+   status = intel_crt_load_detect(crt);
} else {
-   crtc = intel_get_load_detect_pipe(&crt->base, connector,
- NULL, &dpms_mode);
-   if (crtc) {
+   struct intel_load_detect_pipe tmp;
+
+   if (intel_get_load_detect_pipe(&crt->base,
+  connector, NULL,
+  &tmp)) {
if (intel_crt_detect_ddc(connector))
status = connector_status_connected;
else
-   status = intel_crt_load_detect(crtc, crt);
-   intel_release_load_detect_pipe(&crt->base,
-  connector, dpms_mode);
+   status = intel_crt_load_detect(crt);
+   intel_release_load_detect_pipe(&tmp);
} else
status = connector_status_unknown;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b7d63a5..b9bb20d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5541,115 +5541,133 @@ static struct drm_display_mode load_detect_mode = {
 704, 832, 0, 480, 489, 491, 520, 0, DRM_MODE_FLAG_NHSYNC | 
DRM_MODE_FLAG_NVSYNC),
 };
 
-struct drm_crtc *intel_get_load_detect_pipe(struct intel_encoder 
*intel_encoder,
-   struct drm_connector *connector,
-   struct drm_display_mode *mode,
-   int *dpms_mode)
+bool intel_get_load_detect_pipe(struct intel_encoder *encoder,
+   struct drm_connector *connector,
+   struct drm_display_mode *mode,
+   struct intel_load_detect_pipe *old)
 {
-   struct intel_crtc *intel_crtc;
-   struct drm_crtc *possible_crtc;
-   struct drm_crtc *supported_crtc =NULL;
-   struct drm_encoder *encoder = &intel_encoder->base;
-   struct drm_crtc *crtc = NULL;
-   struct drm_device *dev = encoder->dev;
-   struct drm_encoder_helper_funcs *encoder_funcs = 
encoder->helper_private;
-   struct drm_crtc_helper_funcs *crtc_funcs;
-   int i = -1;
-
-   /*
-* Algorithm gets a little messy:
-*   - if the connector already has an assigned crtc, use it (but make
-* sure it's on first)
-*   - try to find the first unused crtc that can drive this connector,
-* and use that if we find one
-*   - if there

[Intel-gfx] Modesetting fixes for pre-ILK, 915GM especially

2011-04-19 Thread Chris Wilson 
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 pipe, but the intel_crtc_mode_set() enables the plane before
setting up the memory for the plane to read from.

The latter is quite a scary bug. Can anyone remember if there was a
reason for it to be so?
-Chris

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [ANCIENT PATCH] Enable 30-bit depth

2011-04-19 Thread Jesse Barnes 
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 relation to DirectColor mode.

Wouldn't be surprised if you ran into kernel issues as well; the bits
have moved around and various paths had issues with non-24bpp formats.

I'll try mucking with the DDX though and see what I can get working...

-- 
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [ANCIENT PATCH] Enable 30-bit depth

2011-04-19 Thread Andy Lutomirski 
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 changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/intel_driver.c b/src/intel_driver.c
index 1ef16ed..99d32b8 100644
--- a/src/intel_driver.c
+++ b/src/intel_driver.c
@@ -372,10 +372,10 @@ static void intel_check_dri_option(ScrnInfoPtr scrn)
if (!xf86ReturnOptValBool(intel->Options, OPTION_DRI, TRUE))
intel->directRenderingType = DRI_DISABLED;
 
-   if (scrn->depth != 16 && scrn->depth != 24) {
+   if (scrn->depth != 16 && scrn->depth != 24 && scrn->depth != 30) {
xf86DrvMsg(scrn->scrnIndex, X_CONFIG,
   "DRI is disabled because it "
-  "runs only at depths 16 and 24.\n");
+  "runs only at depths 16, 24, and 30.\n");
intel->directRenderingType = DRI_DISABLED;
}
 }
@@ -570,6 +570,7 @@ static Bool I830PreInit(ScrnInfoPtr scrn, int flags)
case 15:
case 16:
case 24:
+   case 30:
break;
default:
xf86DrvMsg(scrn->scrnIndex, X_ERROR,
-- 
1.7.4.2

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 5/5] drm/i915: fix relaxed tiling on gen2: tile height

2011-04-19 Thread Daniel Vetter 
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_gem.c |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6471d51..262fa45 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1504,8 +1504,9 @@ i915_gem_get_unfenced_gtt_alignment(struct 
drm_i915_gem_object *obj)
 * edge of an even tile row (where tile rows are counted as if the bo is
 * placed in a fenced gtt region).
 */
-   if (IS_GEN2(dev) ||
-   (obj->tiling_mode == I915_TILING_Y && HAS_128_BYTE_Y_TILING(dev)))
+   if (IS_GEN2(dev))
+   tile_height = 16;
+   else if (obj->tiling_mode == I915_TILING_Y && 
HAS_128_BYTE_Y_TILING(dev))
tile_height = 32;
else
tile_height = 8;
-- 
1.7.4.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/5] drm/i915: fix relaxed tiling on gen2: y-tiling on i855gm

2011-04-19 Thread Daniel Vetter 
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). Hence move the check
to deny y-tiled access to gem_fault and restrict it with IS_I85X. According to
docs, upload _should_ work to y-tiled textures with the blitter on all gen2
chips.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_gem.c |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index f658f4f..6471d51 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1255,6 +1255,13 @@ int i915_gem_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
goto unlock;
}
 
+   /* i855gm has broken y-tiled fences for cpu access, blitter should work,
+* though. */
+   if (IS_I85X(dev) && obj->tiling_mode == I915_TILING_Y) {
+   ret = -EINVAL;
+   goto unlock;
+   }
+
/* Now bind it into the GTT if needed */
if (!obj->map_and_fenceable) {
ret = i915_gem_object_unbind(obj);
-- 
1.7.4.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/5] drm/i915: check gpu_write_list in move_to_flushing

2011-04-19 Thread Daniel Vetter 
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 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5c900d3..f658f4f 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1749,6 +1749,7 @@ i915_gem_object_move_to_flushing(struct 
drm_i915_gem_object *obj)
drm_i915_private_t *dev_priv = dev->dev_private;
 
WARN_ON(!obj->active);
+   WARN_ON(list_empty(&obj->gpu_write_list));
list_move_tail(&obj->mm_list, &dev_priv->mm.flushing_list);
 
i915_gem_object_move_off_active(obj);
-- 
1.7.4.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/5] drm/i915: downgrade non-lethal BUG_ONs

2011-04-19 Thread Daniel Vetter 
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: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_gem.c|6 +++---
 drivers/gpu/drm/i915/i915_gem_evict.c  |4 ++--
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index ae40272..1ef0b91 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1748,7 +1748,7 @@ i915_gem_object_move_to_flushing(struct 
drm_i915_gem_object *obj)
struct drm_device *dev = obj->base.dev;
drm_i915_private_t *dev_priv = dev->dev_private;
 
-   BUG_ON(!obj->active);
+   WARN_ON(!obj->active);
list_move_tail(&obj->mm_list, &dev_priv->mm.flushing_list);
 
i915_gem_object_move_off_active(obj);
@@ -1765,8 +1765,8 @@ i915_gem_object_move_to_inactive(struct 
drm_i915_gem_object *obj)
else
list_move_tail(&obj->mm_list, &dev_priv->mm.inactive_list);
 
-   BUG_ON(!list_empty(&obj->gpu_write_list));
-   BUG_ON(!obj->active);
+   WARN_ON(!list_empty(&obj->gpu_write_list));
+   WARN_ON(!obj->active);
obj->ring = NULL;
 
i915_gem_object_move_off_active(obj);
diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c 
b/drivers/gpu/drm/i915/i915_gem_evict.c
index da05a26..db62fae 100644
--- a/drivers/gpu/drm/i915/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/i915_gem_evict.c
@@ -136,7 +136,7 @@ i915_gem_evict_something(struct drm_device *dev, int 
min_size,
   exec_list);
 
ret = drm_mm_scan_remove_block(obj->gtt_space);
-   BUG_ON(ret);
+   WARN_ON(ret);
 
list_del_init(&obj->exec_list);
drm_gem_object_unreference(&obj->base);
@@ -199,7 +199,7 @@ i915_gem_evict_everything(struct drm_device *dev, bool 
purgeable_only)
if (ret)
return ret;
 
-   BUG_ON(!list_empty(&dev_priv->mm.flushing_list));
+   WARN_ON(!list_empty(&dev_priv->mm.flushing_list));
 
return i915_gem_evict_inactive(dev, purgeable_only);
 }
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
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1093,7 +1093,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
&objects, eb,
exec,

args->buffer_count);
-   BUG_ON(!mutex_is_locked(&dev->struct_mutex));
+   WARN_ON(!mutex_is_locked(&dev->struct_mutex));
}
if (ret)
goto err;
@@ -1122,7 +1122,7 @@ i915_gem_do_execbuffer(struct drm_device *dev, void *data,
if (ret)
goto err;
 
-   BUG_ON(ring->sync_seqno[i]);
+   WARN_ON(ring->sync_seqno[i]);
}
}
 
-- 
1.7.4.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/5] drm/i915: not finding a fence is a non-recoverable condition

2011-04-19 Thread Daniel Vetter 
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) error code.

This has the added benefit that out-of-gtt can be distinguish from
broken fence accounting by simply looking at the ioctl return code.

Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/i915/i915_gem.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1ef0b91..5c900d3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2735,7 +2735,7 @@ i915_gem_object_get_fence(struct drm_i915_gem_object *obj,
 
reg = i915_find_fence_reg(dev, pipelined);
if (reg == NULL)
-   return -ENOSPC;
+   return -EDEADLK;
 
if ((old = reg->obj)) {
drm_gem_object_reference(&old->base);
-- 
1.7.4.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 0/5] various small patches for -next

2011-04-19 Thread Daniel Vetter 
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 a fence is a non-recoverable condition
  drm/i915: check gpu_write_list in move_to_flushing
  drm/i915: fix relaxed tiling on gen2: y-tiling on i855gm
  drm/i915: fix relaxed tiling on gen2: tile height

 drivers/gpu/drm/i915/i915_gem.c|   21 +++--
 drivers/gpu/drm/i915/i915_gem_evict.c  |4 ++--
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |4 ++--
 3 files changed, 19 insertions(+), 10 deletions(-)

-- 
1.7.4.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 6/7] drm/i915: use pipe bpp in DP link bandwidth calculations

2011-04-19 Thread Jesse Barnes 
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 used to calculate the PLL values here, not bw requirements.

-- 
Jesse Barnes, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 5/7] drm/i915: split out plane update code

2011-04-19 Thread Jesse Barnes 
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  |2 +
 drivers/gpu/drm/i915/intel_display.c |  107 +++---
 2 files changed, 100 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7ee0ac8..04fe37e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -208,6 +208,8 @@ struct drm_i915_display_funcs {
 struct drm_display_mode *adjusted_mode,
 int x, int y,
 struct drm_framebuffer *old_fb);
+   int (*update_plane)(struct drm_crtc *crtc, struct drm_framebuffer *fb,
+   int x, int y);
 
/* clock updates for mode set */
/* cursor updates */
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e81e418..b727d7f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1839,10 +1839,8 @@ err_interruptible:
return ret;
 }
 
-/* Assume fb object is pinned & idle & fenced and just update base pointers */
-static int
-intel_pipe_set_base_atomic(struct drm_crtc *crtc, struct drm_framebuffer *fb,
-  int x, int y, enum mode_set_atomic state)
+static int i9xx_update_plane(struct drm_crtc *crtc, struct drm_framebuffer *fb,
+int x, int y)
 {
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
@@ -1885,7 +1883,7 @@ intel_pipe_set_base_atomic(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
dspcntr |= DISPPLANE_32BPP_NO_ALPHA;
break;
default:
-   DRM_ERROR("Unknown color depth\n");
+   DRM_ERROR("Unknown color depth %d\n", fb->bits_per_pixel);
return -EINVAL;
}
if (INTEL_INFO(dev)->gen >= 4) {
@@ -1895,10 +1893,6 @@ intel_pipe_set_base_atomic(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
dspcntr &= ~DISPPLANE_TILED;
}
 
-   if (HAS_PCH_SPLIT(dev))
-   /* must disable */
-   dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
-
I915_WRITE(reg, dspcntr);
 
Start = obj->gtt_offset;
@@ -1915,6 +1909,99 @@ intel_pipe_set_base_atomic(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
I915_WRITE(DSPADDR(plane), Start + Offset);
POSTING_READ(reg);
 
+   return 0;
+}
+
+static int ironlake_update_plane(struct drm_crtc *crtc,
+struct drm_framebuffer *fb, int x, int y)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+   struct intel_framebuffer *intel_fb;
+   struct drm_i915_gem_object *obj;
+   int plane = intel_crtc->plane;
+   unsigned long Start, Offset;
+   u32 dspcntr;
+   u32 reg;
+
+   switch (plane) {
+   case 0:
+   case 1:
+   break;
+   default:
+   DRM_ERROR("Can't update plane %d in SAREA\n", plane);
+   return -EINVAL;
+   }
+
+   intel_fb = to_intel_framebuffer(fb);
+   obj = intel_fb->obj;
+
+   reg = DSPCNTR(plane);
+   dspcntr = I915_READ(reg);
+   /* Mask out pixel format bits in case we change it */
+   dspcntr &= ~DISPPLANE_PIXFORMAT_MASK;
+   switch (fb->bits_per_pixel) {
+   case 8:
+   dspcntr |= DISPPLANE_8BPP;
+   break;
+   case 16:
+   if (fb->depth != 16)
+   return -EINVAL;
+
+   dspcntr |= DISPPLANE_16BPP;
+   break;
+   case 24:
+   case 32:
+   if (fb->depth == 24)
+   dspcntr |= DISPPLANE_32BPP_NO_ALPHA;
+   else if (fb->depth == 30)
+   dspcntr |= DISPPLANE_32BPP_30BIT_NO_ALPHA;
+   else
+   return -EINVAL;
+   break;
+   default:
+   DRM_ERROR("Unknown color depth %d\n", fb->bits_per_pixel);
+   return -EINVAL;
+   }
+
+   if (obj->tiling_mode != I915_TILING_NONE)
+   dspcntr |= DISPPLANE_TILED;
+   else
+   dspcntr &= ~DISPPLANE_TILED;
+
+   /* must disable */
+   dspcntr |= DISPPLANE_TRICKLE_FEED_DISABLE;
+
+   I915_WRITE(reg, dspcntr);
+
+   Start = obj->gtt_offset;
+   Offset = y * fb->pitch + x * (fb->bits_per_pixel / 8);
+
+   DRM_DEBUG_KMS("Writing base %08lX %08lX %d %d %d\n",
+ Start, Offset, x, y, fb->pitch);
+   I915_WRITE(DSPSTRIDE(plan

[Intel-gfx] [PATCH 6/7] drm/i915: use pipe bpp in DP link bandwidth calculations

2011-04-19 Thread Jesse Barnes 
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/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 0daefca..bce9edb 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -684,7 +684,7 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
struct drm_encoder *encoder;
struct drm_i915_private *dev_priv = dev->dev_private;
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
-   int lane_count = 4, bpp = 24;
+   int lane_count = 4;
struct intel_dp_m_n m_n;
int pipe = intel_crtc->pipe;
 
@@ -703,7 +703,6 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
break;
} else if (is_edp(intel_dp)) {
lane_count = dev_priv->edp.lanes;
-   bpp = dev_priv->edp.bpp;
break;
}
}
@@ -713,7 +712,7 @@ intel_dp_set_m_n(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
 * the number of bytes_per_pixel post-LUT, which we always
 * set up for 8-bits of R/G/B, or 3 bytes total.
 */
-   intel_dp_compute_m_n(bpp, lane_count,
+   intel_dp_compute_m_n(intel_crtc->bpp, lane_count,
 mode->clock, adjusted_mode->clock, &m_n);
 
if (HAS_PCH_SPLIT(dev)) {
-- 
1.7.4.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 4/7] drm/i915: split out Ironlake pipe bpp picking code

2011-04-19 Thread Jesse Barnes 
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 DisplayPort output on another pipe means using 8bpc and
no dithering.

So split out and enhance the code to handle the various cases, returning
an appropriate pipe bpp as well as whether dithering should be enabled.

Save the resulting pipe bpp in the intel_crtc struct for use by encoders
in calculating bandwidth requirements (defaults to 24bpp on pre-ILK).

Signed-off-by: Jesse Barnes 
---
 drivers/gpu/drm/i915/intel_display.c |  181 ++
 drivers/gpu/drm/i915/intel_drv.h |1 +
 2 files changed, 140 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8ef0c39..e81e418 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4232,6 +4232,120 @@ static inline bool intel_panel_use_ssc(struct 
drm_i915_private *dev_priv)
return dev_priv->lvds_use_ssc && i915_panel_use_ssc;
 }
 
+/**
+ * intel_choose_pipe_bpp - figure out what color depth the pipe should send
+ * @crtc: CRTC structure
+ *
+ * A pipe may be connected to one or more outputs.  Based on the depth of the
+ * attached framebuffer, choose a good color depth to use on the pipe.
+ *
+ * If possible, match the pipe depth to the fb depth.  In some cases, this
+ * isn't ideal, because the connected output supports a lesser or restricted
+ * set of depths.  Resolve that here:
+ *LVDS typically supports only 6bpc, so clamp down in that case
+ *HDMI supports only 8bpc or 12bpc, so clamp to 8bpc with dither for 10bpc
+ *Displays may support a restricted set as well, check EDID and clamp as
+ *  appropriate.
+ *
+ * RETURNS:
+ * Dithering requirement (i.e. false if display bpc and pipe bpc match,
+ * true if they don't match).
+ */
+static bool intel_choose_pipe_bpp(struct drm_crtc *crtc, unsigned int 
*pipe_bpp)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_encoder *encoder;
+   struct drm_connector *connector;
+   unsigned int display_bpc = UINT_MAX, fb_bpc, bpc;
+
+   fb_bpc = crtc->fb->depth / 3;
+
+   /* Walk the encoders & connectors on this crtc, get min bpc */
+   list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
+   struct intel_encoder *intel_encoder = to_intel_encoder(encoder);
+
+   if (encoder->crtc != crtc)
+   continue;
+
+   if (intel_encoder->type == INTEL_OUTPUT_LVDS) {
+   unsigned int lvds_bpc;
+
+   if ((I915_READ(PCH_LVDS) & LVDS_A3_POWER_MASK) ==
+   LVDS_A3_POWER_UP)
+   lvds_bpc = 8;
+   else
+   lvds_bpc = 6;
+
+   if (lvds_bpc < display_bpc)
+   display_bpc = lvds_bpc;
+   continue;
+   }
+
+   if (intel_encoder->type == INTEL_OUTPUT_EDP) {
+   /* Use VBT settings if we have an eDP panel */
+   unsigned int edp_bpc = dev_priv->edp.bpp / 3;
+
+   if (edp_bpc < display_bpc)
+   display_bpc = edp_bpc;
+   continue;
+   }
+
+   /* Not one of the known troublemakers, check the EDID */
+   list_for_each_entry(connector, &dev->mode_config.connector_list,
+   head) {
+   if (connector->encoder != encoder)
+   continue;
+
+   if (connector->display_info.bpc < display_bpc)
+   display_bpc = connector->display_info.bpc;
+   }
+
+   /*
+* HDMI is either 12 or 8, so if the display let 10bpc sneak
+* through, clamp it down.  (Note: >12bpc will be caught below.)
+*/
+   if (intel_encoder->type == INTEL_OUTPUT_HDMI) {
+   if (display_bpc > 8 && display_bpc < 12)
+   display_bpc = 12;
+   else
+   display_bpc = 8;
+   }
+   }
+
+   /*
+* We could just drive the pipe at the highest bpc all the time and
+* enable dithering as needed, but that costs bandwidth.  So choose
+* the minimum value that expresses the full color range of the fb but
+* also stays within the max display bpc discovered above.
+*/
+
+   switch (crtc->fb->depth) {
+   case 8:
+   case 15:
+   case 16

[Intel-gfx] [PATCH 7/7] drm/i915: use pipe bpp when setting HDMI bpc

2011-04-19 Thread Jesse Barnes 
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/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index a6871d8..5cf7b23 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -132,6 +132,11 @@ static void intel_hdmi_mode_set(struct drm_encoder 
*encoder,
if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
sdvox |= SDVO_HSYNC_ACTIVE_HIGH;
 
+   if (intel_crtc->bpp > 24)
+   sdvox |= COLOR_FORMAT_12bpc;
+   else
+   sdvox |= COLOR_FORMAT_8bpc;
+
/* Required on CPT */
if (intel_hdmi->has_hdmi_sink && HAS_PCH_CPT(dev))
sdvox |= HDMI_MODE_SELECT;
-- 
1.7.4.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 3/7] drm/i915: set bpc for DP transcoder

2011-04-19 Thread Jesse Barnes 
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/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 69649b2..8ef0c39 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2504,6 +2504,7 @@ static void ironlake_pch_enable(struct drm_crtc *crtc)
/* For PCH DP, enable TRANS_DP_CTL */
if (HAS_PCH_CPT(dev) &&
intel_pipe_has_type(crtc, INTEL_OUTPUT_DISPLAYPORT)) {
+   u32 bpc = (I915_READ(PIPECONF(pipe)) & PIPE_BPC_MASK) >> 5;
reg = TRANS_DP_CTL(pipe);
temp = I915_READ(reg);
temp &= ~(TRANS_DP_PORT_SEL_MASK |
@@ -2511,7 +2512,7 @@ static void ironlake_pch_enable(struct drm_crtc *crtc)
  TRANS_DP_BPC_MASK);
temp |= (TRANS_DP_OUTPUT_ENABLE |
 TRANS_DP_ENH_FRAMING);
-   temp |= TRANS_DP_8BPC;
+   temp |= bpc << 9; /* same format but at 11:9 */
 
if (crtc->mode.flags & DRM_MODE_FLAG_PHSYNC)
temp |= TRANS_DP_HSYNC_ACTIVE_HIGH;
-- 
1.7.4.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/7] drm/i915: color range only works on pre-ILK

2011-04-19 Thread Jesse Barnes 
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 f289b86..a6871d8 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -125,7 +125,8 @@ static void intel_hdmi_mode_set(struct drm_encoder *encoder,
u32 sdvox;
 
sdvox = SDVO_ENCODING_HDMI | SDVO_BORDER_ENABLE;
-   sdvox |= intel_hdmi->color_range;
+   if (!HAS_PCH_SPLIT(dev))
+   sdvox |= intel_hdmi->color_range;
if (adjusted_mode->flags & DRM_MODE_FLAG_PVSYNC)
sdvox |= SDVO_VSYNC_ACTIVE_HIGH;
if (adjusted_mode->flags & DRM_MODE_FLAG_PHSYNC)
-- 
1.7.4.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 2/7] drm/i915: don't set transcoder bpc on CougarPoint

2011-04-19 Thread Jesse Barnes 
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/intel_display.c
index 09b20b1..69649b2 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1157,12 +1157,15 @@ static void intel_enable_transcoder(struct 
drm_i915_private *dev_priv,
 
reg = TRANSCONF(pipe);
val = I915_READ(reg);
-   /*
-* make the BPC in transcoder be consistent with
-* that in pipeconf reg.
-*/
-   val &= ~PIPE_BPC_MASK;
-   val |= I915_READ(PIPECONF(pipe)) & PIPE_BPC_MASK;
+
+   if (HAS_PCH_IBX(dev_priv->dev)) {
+   /*
+* make the BPC in transcoder be consistent with
+* that in pipeconf reg.
+*/
+   val &= ~PIPE_BPC_MASK;
+   val |= I915_READ(PIPECONF(pipe)) & PIPE_BPC_MASK;
+   }
I915_WRITE(reg, val | TRANS_ENABLE);
if (wait_for(I915_READ(reg) & TRANS_STATE_ENABLE, 100))
DRM_ERROR("failed to enable transcoder %d\n", pipe);
-- 
1.7.4.1

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [RFC] Deep color support

2011-04-19 Thread Jesse Barnes 
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 how things are split out and lots of review for
implications on various chipsets.

Thanks,
Jesse

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/3] drm/i915: reference counted forcewake

2011-04-19 Thread Keith Packard 
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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] suggestions for Web site (was: Intel 2011Q1 release)

2011-04-19 Thread Lan, Hai 
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: [Intel-gfx] suggestions for Web site (was: Intel 2011Q1 release)
> 
> 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 updated.
> >
> > Hai Lan
> >
> > > -Original Message-
> > > From: intel-gfx-bounces+hai.lan=intel@lists.freedesktop.org
> > > [mailto:intel-gfx-bounces+hai.lan=intel@lists.freedesktop.org] On
> > > Behalf Of Paul Menzel
> > > Sent: Friday, April 15, 2011 6:40 PM
> > > To: intel-gfx@lists.freedesktop.org
> > > Subject: [Intel-gfx] suggestions for Web site (was: Intel 2011Q1 release)
> > >
> > > Dear Gordon,
> > >
> > >
> > > Am Freitag, den 15.04.2011, 08:25 +0800 schrieb Jin, Gordon:
> > >
> > > > We'd like to announce Intel 2011Q1 graphics package, with bug fixes as
> > > usual, and improved support for Sandy Bridge.
> > >
> > > […]
> > >
> > > > Please also let us know your suggestions for how the website could be
> > > improved.
> > >
> > > 1. 
> > > a) Under »components« I found it confusing that clicking on the link a
> > > download is started especially because of the word release. Maybe put
> there
> > > two links. The first one could link to the announcement and the second,
> for
> > > example named »download«, to the tarball.
> > > b) Under »support discontinued« I find it confusing that it still says
> »XvMC is
> > > disabled on 915G/GM for KMS: bug#23012.«, since that has been the
> way
> > > since over a year?. I suggest to either drop it or add »since
> > > 2010Q1(?) release«.
> > >
> > > 2. 
> > > a) Use full stops at the end of sentences.
> > > b) In the table it is not clear for me, if the hardware does not support 
> > > that
> > > feature or it has just not been yet implemented in the software
> stack/driver.
> > > It would be great to clarify this by for example »not supported by
> hardware«
> > > and »not implemented«.
> > >
> > >
> > >
> > > Thanks,
> > >
> > > Paul
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> --
> Sérgio M. B.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] suggestions for Web site (was: Intel 2011Q1 release)

2011-04-19 Thread Sergio Monteiro Basto 
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 
> updated.
> 
> Hai Lan
> 
> > -Original Message-
> > From: intel-gfx-bounces+hai.lan=intel@lists.freedesktop.org
> > [mailto:intel-gfx-bounces+hai.lan=intel@lists.freedesktop.org] On
> > Behalf Of Paul Menzel
> > Sent: Friday, April 15, 2011 6:40 PM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [Intel-gfx] suggestions for Web site (was: Intel 2011Q1 release)
> > 
> > Dear Gordon,
> > 
> > 
> > Am Freitag, den 15.04.2011, 08:25 +0800 schrieb Jin, Gordon:
> > 
> > > We'd like to announce Intel 2011Q1 graphics package, with bug fixes as
> > usual, and improved support for Sandy Bridge.
> > 
> > […]
> > 
> > > Please also let us know your suggestions for how the website could be
> > improved.
> > 
> > 1. 
> > a) Under »components« I found it confusing that clicking on the link a
> > download is started especially because of the word release. Maybe put there
> > two links. The first one could link to the announcement and the second, for
> > example named »download«, to the tarball.
> > b) Under »support discontinued« I find it confusing that it still says 
> > »XvMC is
> > disabled on 915G/GM for KMS: bug#23012.«, since that has been the way
> > since over a year?. I suggest to either drop it or add »since
> > 2010Q1(?) release«.
> > 
> > 2. 
> > a) Use full stops at the end of sentences.
> > b) In the table it is not clear for me, if the hardware does not support 
> > that
> > feature or it has just not been yet implemented in the software 
> > stack/driver.
> > It would be great to clarify this by for example »not supported by hardware«
> > and »not implemented«.
> > 
> > 
> > 
> > Thanks,
> > 
> > Paul
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Sérgio M. B.


smime.p7s
Description: S/MIME cryptographic signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx