Re: [Intel-gfx] [PATCH 21/21] drm/i915: Introduce vmap (mapping of user pages into video memory) ioctl
Thanks for excellent comments... Skipping to the end for a quick response: On Mon, 18 Apr 2011 16:58:17 +0200, Daniel Vetter dan...@ffwll.ch wrote: I have hopes that we might be able to subsume that use-case into the single-shot use-case by beefing up pwrite/read with a blt variant that does the right thing for 2d/tiled buffers (and also handles stride mismatches). That feels a bit more generally useful, which is why I lean a bit towards it. On the other hand we might turn vmap on it's head and create an shm id out of a bo for X to use (if X shm turns out to be the only user for such a thing). This is where I started: a new 2D pread/pwrite ioctl that used the BLT if it so desired. This was flawed in my use cases by the synchronous nature of the API I used. When I thought about introducing async versions, I realised that it became so much simpler if I moved the entirety of the serialisation into userspace and vmap was born. And then I realised that a vmap bo could be used in places other than simple BLT uploads and downloads. Meanwhile, I'm intrigued by the idea of integrating SHM and bo... The use case is a bit narrow though, latter protocol designs already use the bo as the natural transport. Anyway, it looks like my next task is see if vmap is a workable interface for Mesa as well. I'd much prefer spending another couple of months addressing your comments and widening the use cases, so I can drop this patch for this merge window. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ 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
ILK+ provides this feature in the transcoder and pipe configuration instead. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org --- 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 3/7] drm/i915: set bpc for DP transcoder
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 jbar...@virtuousgeek.org
---
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 7/7] drm/i915: use pipe bpp when setting HDMI bpc
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 jbar...@virtuousgeek.org --- 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 1/5] drm/i915: downgrade non-lethal BUG_ONs
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 daniel.vet...@ffwll.ch --- 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 3/5] drm/i915: check gpu_write_list in move_to_flushing
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 daniel.vet...@ffwll.ch --- 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] [ANCIENT PATCH] Enable 30-bit depth
Signed-off-by: Andy Lutomirski l...@mit.edu
---
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
Re: [Intel-gfx] [ANCIENT PATCH] Enable 30-bit depth
On Tue, 19 Apr 2011 15:50:01 -0400 Andy Lutomirski l...@mit.edu wrote: Signed-off-by: Andy Lutomirski l...@mit.edu --- 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] [PATCH 2/3] drm/i915: Attach a fb to the load-detect pipe
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 knut_peter...@t-online.de
References: https://bugs.freedesktop.org/show_bug.cgi?id=36246
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
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
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Check that the plane points to the pipe's framebuffer before enabling
On Tue, 19 Apr 2011 21:32:01 +0100 Chris Wilson ch...@chris-wilson.co.uk 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 ch...@chris-wilson.co.uk Cc: Jesse Barnes jbar...@virtuousgeek.org --- I like it. Reviewed-by: Jesse Barnes jbar...@virtuousgeek.org -- 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 2/3] drm/i915: Attach a fb to the load-detect pipe
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 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
