[Bug 41121] Apple Thunderbolt display is not initialized when plugged into iMac 12,2 (Radeon 6870)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41121

Brad Campbell  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #9 from Brad Campbell  2011-10-04 21:57:12 
PDT ---
Fixed. Cheers Alex!

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=1fd2a850ecad717113cb36fa9d6e4304cd19b89d

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH 26/26] vmwgfx: Minor cleanups

[Thomas Hellstrom]

As suggested by Konrad Rzeszutek Wilk

Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c |6 +++---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |   17 +
 2 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index a98ee19..ddb5abd 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -569,9 +569,9 @@ static int vmw_driver_load(struct drm_device *dev, unsigned 
long chipset)
vmw_overlay_init(dev_priv);

/* 3D Depends on Screen Objects being used. */
-   DRM_INFO("%s", vmw_fifo_have_3d(dev_priv) ?
-"Detected device 3D availability.\n" :
-"Detected no device 3D availability.\n");
+   DRM_INFO("Detected %sdevice 3D availability.\n",
+vmw_fifo_have_3d(dev_priv) ?
+"" : "no ");

/* We might be done with the fifo now */
if (dev_priv->enable_fb) {
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 0921cce..fc62c87 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1317,18 +1317,19 @@ int vmw_du_update_layout(struct vmw_private *dev_priv, 
unsigned num,
struct drm_device *dev = dev_priv->dev;
struct vmw_display_unit *du;
struct drm_connector *con;
-   int i;

mutex_lock(>mode_config.mutex);

 #if 0
-   DRM_INFO("%s: new layout ", __func__);
-   for (i = 0; i < (int)num; i++)
-   DRM_INFO("(%i, %i %ux%u) ", rects[i].x, rects[i].y,
-rects[i].w, rects[i].h);
-   DRM_INFO("\n");
-#else
-   (void)i;
+   {
+   unsigned int i;
+
+   DRM_INFO("%s: new layout ", __func__);
+   for (i = 0; i < num; i++)
+   DRM_INFO("(%i, %i %ux%u) ", rects[i].x, rects[i].y,
+rects[i].w, rects[i].h);
+   DRM_INFO("\n");
+   }
 #endif

list_for_each_entry(con, >mode_config.connector_list, head) {
-- 
1.7.4.4

[PATCH 25/26] vmwgfx: Bump driver minor to advertise support for new ioctls.

[Thomas Hellstrom]

Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index ee564f0..8cce73e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -40,9 +40,9 @@
 #include "ttm/ttm_module.h"
 #include "vmwgfx_fence.h"

-#define VMWGFX_DRIVER_DATE "20110901"
+#define VMWGFX_DRIVER_DATE "20110927"
 #define VMWGFX_DRIVER_MAJOR 2
-#define VMWGFX_DRIVER_MINOR 0
+#define VMWGFX_DRIVER_MINOR 1
 #define VMWGFX_DRIVER_PATCHLEVEL 0
 #define VMWGFX_FILE_PAGE_OFFSET 0x0010
 #define VMWGFX_FIFO_STATIC_SIZE (1024*1024)
-- 
1.7.4.4

[PATCH 24/26] vmwgfx: Be more strict with fb depths when using screen objects

[Thomas Hellstrom]

From: Jakob Bornecrantz 

Signed-off-by: Jakob Bornecrantz 
Reviewed-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |   27 +++
 1 files changed, 27 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index b4b9aa9..0921cce 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -776,6 +776,33 @@ static int vmw_kms_new_framebuffer_dmabuf(struct 
vmw_private *dev_priv,
return -EINVAL;
}

+   /* Limited framebuffer color depth support for screen objects */
+   if (dev_priv->sou_priv) {
+   switch (mode_cmd->depth) {
+   case 32:
+   case 24:
+   /* Only support 32 bpp for 32 and 24 depth fbs */
+   if (mode_cmd->bpp == 32)
+   break;
+
+   DRM_ERROR("Invalid color depth/bbp: %d %d\n",
+ mode_cmd->depth, mode_cmd->bpp);
+   return -EINVAL;
+   case 16:
+   case 15:
+   /* Only support 16 bpp for 16 and 15 depth fbs */
+   if (mode_cmd->bpp == 16)
+   break;
+
+   DRM_ERROR("Invalid color depth/bbp: %d %d\n",
+ mode_cmd->depth, mode_cmd->bpp);
+   return -EINVAL;
+   default:
+   DRM_ERROR("Invalid color depth: %d\n", mode_cmd->depth);
+   return -EINVAL;
+   }
+   }
+
vfbd = kzalloc(sizeof(*vfbd), GFP_KERNEL);
if (!vfbd) {
ret = -ENOMEM;
-- 
1.7.4.4

[PATCH 23/26] vmwgfx: Handle device surface memory limit

[Thomas Hellstrom]

Make surfaces swappable. Make sure we honor the maximum amount of surface
memory the device accepts. This is done by potentially reading back surface
contents not used by the current command submission and storing it
locally in buffer objects.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Jakob Bornecrantz 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c   |   14 +
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |   22 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |   26 +
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c  |   19 +
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |  836 +++---
 5 files changed, 835 insertions(+), 82 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
index 98a5d7e..5a72ed9 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
@@ -60,6 +60,11 @@ static uint32_t vram_gmr_placement_flags[] = {
VMW_PL_FLAG_GMR | TTM_PL_FLAG_CACHED
 };

+static uint32_t gmr_vram_placement_flags[] = {
+   VMW_PL_FLAG_GMR | TTM_PL_FLAG_CACHED,
+   TTM_PL_FLAG_VRAM | TTM_PL_FLAG_CACHED
+};
+
 struct ttm_placement vmw_vram_gmr_placement = {
.fpfn = 0,
.lpfn = 0,
@@ -125,6 +130,15 @@ struct ttm_placement vmw_evictable_placement = {
.busy_placement = _placement_flags
 };

+struct ttm_placement vmw_srf_placement = {
+   .fpfn = 0,
+   .lpfn = 0,
+   .num_placement = 1,
+   .num_busy_placement = 2,
+   .placement = _placement_flags,
+   .busy_placement = gmr_vram_placement_flags
+};
+
 struct vmw_ttm_backend {
struct ttm_backend backend;
struct page **pages;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 7b88104..a98ee19 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -402,6 +402,8 @@ static int vmw_driver_load(struct drm_device *dev, unsigned 
long chipset)
init_waitqueue_head(_priv->fifo_queue);
dev_priv->fence_queue_waiters = 0;
atomic_set(_priv->fifo_queue_waiters, 0);
+   INIT_LIST_HEAD(_priv->surface_lru);
+   dev_priv->used_memory_size = 0;

dev_priv->io_start = pci_resource_start(dev->pdev, 0);
dev_priv->vram_start = pci_resource_start(dev->pdev, 1);
@@ -422,6 +424,10 @@ static int vmw_driver_load(struct drm_device *dev, 
unsigned long chipset)

dev_priv->capabilities = vmw_read(dev_priv, SVGA_REG_CAPABILITIES);

+   dev_priv->vram_size = vmw_read(dev_priv, SVGA_REG_VRAM_SIZE);
+   dev_priv->mmio_size = vmw_read(dev_priv, SVGA_REG_MEM_SIZE);
+   dev_priv->fb_max_width = vmw_read(dev_priv, SVGA_REG_MAX_WIDTH);
+   dev_priv->fb_max_height = vmw_read(dev_priv, SVGA_REG_MAX_HEIGHT);
if (dev_priv->capabilities & SVGA_CAP_GMR) {
dev_priv->max_gmr_descriptors =
vmw_read(dev_priv,
@@ -434,13 +440,15 @@ static int vmw_driver_load(struct drm_device *dev, 
unsigned long chipset)
vmw_read(dev_priv, SVGA_REG_GMRS_MAX_PAGES);
dev_priv->memory_size =
vmw_read(dev_priv, SVGA_REG_MEMORY_SIZE);
+   dev_priv->memory_size -= dev_priv->vram_size;
+   } else {
+   /*
+* An arbitrary limit of 512MiB on surface
+* memory. But all HWV8 hardware supports GMR2.
+*/
+   dev_priv->memory_size = 512*1024*1024;
}

-   dev_priv->vram_size = vmw_read(dev_priv, SVGA_REG_VRAM_SIZE);
-   dev_priv->mmio_size = vmw_read(dev_priv, SVGA_REG_MEM_SIZE);
-   dev_priv->fb_max_width = vmw_read(dev_priv, SVGA_REG_MAX_WIDTH);
-   dev_priv->fb_max_height = vmw_read(dev_priv, SVGA_REG_MAX_HEIGHT);
-
mutex_unlock(_priv->hw_mutex);

vmw_print_capabilities(dev_priv->capabilities);
@@ -454,8 +462,8 @@ static int vmw_driver_load(struct drm_device *dev, unsigned 
long chipset)
if (dev_priv->capabilities & SVGA_CAP_GMR2) {
DRM_INFO("Max number of GMR pages is %u\n",
 (unsigned)dev_priv->max_gmr_pages);
-   DRM_INFO("Max dedicated hypervisor graphics memory is %u\n",
-(unsigned)dev_priv->memory_size);
+   DRM_INFO("Max dedicated hypervisor surface memory is %u kiB\n",
+(unsigned)dev_priv->memory_size / 1024);
}
DRM_INFO("VRAM at 0x%08x size is %u kiB\n",
 dev_priv->vram_start, dev_priv->vram_size / 1024);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 75e6d10..ee564f0 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -79,6 +79,7 @@ struct vmw_resource {
int id;
enum ttm_object_type res_type;
bool avail;
+   void (*remove_from_lists) (struct vmw_resource *res);
void (*hw_destroy) (struct vmw_resource 

[PATCH 22/26] vmwgfx: Make sure we always have a user-space handle to use for objects that are backing kms framebuffers.

[Thomas Hellstrom]

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Jakob Bornecrantz 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |   56 --
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h |2 +
 2 files changed, 41 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 41916b5..b4b9aa9 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -345,11 +345,13 @@ void vmw_framebuffer_surface_destroy(struct 
drm_framebuffer *framebuffer)
drm_master_put(>master);
drm_framebuffer_cleanup(framebuffer);
vmw_surface_unreference(>surface);
+   ttm_base_object_unref(>base.user_obj);

kfree(vfbs);
 }

 static int do_surface_dirty_sou(struct vmw_private *dev_priv,
+   struct drm_file *file_priv,
struct vmw_framebuffer *framebuffer,
struct vmw_surface *surf,
unsigned flags, unsigned color,
@@ -359,7 +361,7 @@ static int do_surface_dirty_sou(struct vmw_private 
*dev_priv,
int left = clips->x2, right = clips->x1;
int top = clips->y2, bottom = clips->y1;
size_t fifo_size;
-   int i;
+   int i, ret;

struct {
SVGA3dCmdHeader header;
@@ -368,18 +370,16 @@ static int do_surface_dirty_sou(struct vmw_private 
*dev_priv,


fifo_size = sizeof(*cmd);
-   cmd = vmw_fifo_reserve(dev_priv, fifo_size);
+   cmd = kzalloc(fifo_size, GFP_KERNEL);
if (unlikely(cmd == NULL)) {
-   DRM_ERROR("Fifo reserve failed.\n");
+   DRM_ERROR("Temporary fifo memory alloc failed.\n");
return -ENOMEM;
}

-   memset(cmd, 0, fifo_size);
-
cmd->header.id = cpu_to_le32(SVGA_3D_CMD_BLIT_SURFACE_TO_SCREEN);
cmd->header.size = cpu_to_le32(sizeof(cmd->body));

-   cmd->body.srcImage.sid = cpu_to_le32(surf->res.id);
+   cmd->body.srcImage.sid = cpu_to_le32(framebuffer->user_handle);
cmd->body.destScreenId = SVGA_ID_INVALID; /* virtual coords */

for (i = 0; i < num_clips; i++, clips += inc) {
@@ -399,9 +399,11 @@ static int do_surface_dirty_sou(struct vmw_private 
*dev_priv,
cmd->body.destRect.top = top;
cmd->body.destRect.bottom = bottom;

-   vmw_fifo_commit(dev_priv, fifo_size);
+   ret = vmw_execbuf_process(file_priv, dev_priv, NULL, cmd, fifo_size,
+ 0, NULL);
+   kfree(cmd);

-   return 0;
+   return ret;
 }

 int vmw_framebuffer_surface_dirty(struct drm_framebuffer *framebuffer,
@@ -440,7 +442,7 @@ int vmw_framebuffer_surface_dirty(struct drm_framebuffer 
*framebuffer,
inc = 2; /* skip source rects */
}

-   ret = do_surface_dirty_sou(dev_priv, >base, surf,
+   ret = do_surface_dirty_sou(dev_priv, file_priv, >base, surf,
   flags, color,
   clips, num_clips, inc);

@@ -535,6 +537,7 @@ static int vmw_kms_new_framebuffer_surface(struct 
vmw_private *dev_priv,
vfbs->base.base.width = mode_cmd->width;
vfbs->base.base.height = mode_cmd->height;
vfbs->surface = surface;
+   vfbs->base.user_handle = mode_cmd->handle;
vfbs->master = drm_master_get(file_priv->master);

mutex_lock(>fb_surf_mutex);
@@ -563,7 +566,6 @@ out_err1:
 struct vmw_framebuffer_dmabuf {
struct vmw_framebuffer base;
struct vmw_dma_buffer *buffer;
-   uint32_t handle;
 };

 void vmw_framebuffer_dmabuf_destroy(struct drm_framebuffer *framebuffer)
@@ -573,6 +575,7 @@ void vmw_framebuffer_dmabuf_destroy(struct drm_framebuffer 
*framebuffer)

drm_framebuffer_cleanup(framebuffer);
vmw_dmabuf_unreference(>buffer);
+   ttm_base_object_unref(>base.user_obj);

kfree(vfbd);
 }
@@ -620,8 +623,6 @@ static int do_dmabuf_dirty_sou(struct drm_file *file_priv,
   struct drm_clip_rect *clips,
   unsigned num_clips, int increment)
 {
-   struct vmw_framebuffer_dmabuf *vfbd =
-   vmw_framebuffer_to_vfbd(>base);
size_t fifo_size;
int i, ret;

@@ -647,7 +648,7 @@ static int do_dmabuf_dirty_sou(struct drm_file *file_priv,
cmd->body.format.colorDepth = framebuffer->base.depth;
cmd->body.format.reserved = 0;
cmd->body.bytesPerLine = framebuffer->base.pitch;
-   cmd->body.ptr.gmrId = vfbd->handle;
+   cmd->body.ptr.gmrId = framebuffer->user_handle;
cmd->body.ptr.offset = 0;

blits = (void *)[1];
@@ -802,7 +803,7 @@ static int vmw_kms_new_framebuffer_dmabuf(struct 
vmw_private *dev_priv,
}
vfbd->base.dmabuf = true;
vfbd->buffer = dmabuf;
-   vfbd->handle = mode_cmd->handle;
+   vfbd->base.user_handle = mode_cmd->handle;
*out = >base;

return 0;
@@ -828,6 

[PATCH 21/26] vmwgfx: Optimize the command submission resource list

[Thomas Hellstrom]

Use a list for resources referenced during command submission, instead of
an array.
As long as we don't implement parallell command submission this works fine
and simplifies things a bit.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Jakob Bornecrantz 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |5 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c  |   50 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |1 +
 3 files changed, 26 insertions(+), 30 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index d8d6a86..75e6d10 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -81,7 +81,7 @@ struct vmw_resource {
bool avail;
void (*hw_destroy) (struct vmw_resource *res);
void (*res_free) (struct vmw_resource *res);
-   bool on_validate_list;
+   struct list_head validate_head;
struct list_head query_head; /* Protected by the cmdbuf mutex */
/* TODO is a generic snooper needed? */
 #if 0
@@ -155,8 +155,7 @@ struct vmw_sw_context{
uint32_t cur_val_buf;
uint32_t *cmd_bounce;
uint32_t cmd_bounce_size;
-   struct vmw_resource *resources[VMWGFX_MAX_VALIDATIONS];
-   uint32_t num_ref_resources;
+   struct list_head resource_list;
uint32_t fence_flags;
struct list_head query_list;
struct ttm_buffer_object *cur_query_bo;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index efa1d1c..dfd7fca 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -44,27 +44,16 @@ static int vmw_cmd_ok(struct vmw_private *dev_priv,
return 0;
 }

-static int vmw_resource_to_validate_list(struct vmw_sw_context *sw_context,
-struct vmw_resource **p_res)
+static void vmw_resource_to_validate_list(struct vmw_sw_context *sw_context,
+ struct vmw_resource **p_res)
 {
-   int ret = 0;
struct vmw_resource *res = *p_res;

-   if (!res->on_validate_list) {
-   if (sw_context->num_ref_resources >= VMWGFX_MAX_VALIDATIONS) {
-   DRM_ERROR("Too many resources referenced in "
- "command stream.\n");
-   ret = -ENOMEM;
-   goto out;
-   }
-   sw_context->resources[sw_context->num_ref_resources++] = res;
-   res->on_validate_list = true;
-   return 0;
-   }
-
-out:
-   vmw_resource_unreference(p_res);
-   return ret;
+   if (list_empty(>validate_head)) {
+   list_add_tail(>validate_head, _context->resource_list);
+   *p_res = NULL;
+   } else
+   vmw_resource_unreference(p_res);
 }

 /**
@@ -142,7 +131,9 @@ static int vmw_cmd_cid_check(struct vmw_private *dev_priv,
sw_context->last_cid = cmd->cid;
sw_context->cid_valid = true;
sw_context->cur_ctx = ctx;
-   return vmw_resource_to_validate_list(sw_context, );
+   vmw_resource_to_validate_list(sw_context, );
+
+   return 0;
 }

 static int vmw_cmd_sid_check(struct vmw_private *dev_priv,
@@ -179,7 +170,9 @@ static int vmw_cmd_sid_check(struct vmw_private *dev_priv,
*sid = sw_context->sid_translation;

res = >res;
-   return vmw_resource_to_validate_list(sw_context, );
+   vmw_resource_to_validate_list(sw_context, );
+
+   return 0;
 }


@@ -388,7 +381,7 @@ static void vmw_query_bo_switch_commit(struct vmw_private 
*dev_priv,
 query_head) {
list_del_init(>query_head);

-   BUG_ON(!ctx->on_validate_list);
+   BUG_ON(list_empty(>validate_head));

ret = vmw_fifo_emit_dummy_query(dev_priv, ctx->id);

@@ -582,7 +575,9 @@ static int vmw_cmd_dma(struct vmw_private *dev_priv,
vmw_dmabuf_unreference(_bo);

res = >res;
-   return vmw_resource_to_validate_list(sw_context, );
+   vmw_resource_to_validate_list(sw_context, );
+
+   return 0;

 out_no_reloc:
vmw_dmabuf_unreference(_bo);
@@ -870,7 +865,7 @@ static void vmw_apply_relocations(struct vmw_sw_context 
*sw_context)
 static void vmw_clear_validations(struct vmw_sw_context *sw_context)
 {
struct ttm_validate_buffer *entry, *next;
-   uint32_t i = sw_context->num_ref_resources;
+   struct vmw_resource *res, *res_next;

/*
 * Drop references to DMA buffers held during command submission.
@@ -887,9 +882,10 @@ static void vmw_clear_validations(struct vmw_sw_context 
*sw_context)
/*
 * Drop references to resources held during command submission.
 */
-   while (i-- > 0) {
-   sw_context->resources[i]->on_validate_list = false;
-   vmw_resource_unreference(_context->resources[i]);
+  

[PATCH 20/26] vmwgfx: Fix up query processing

[Thomas Hellstrom]

Previously, query results could be placed in any buffer object, but since
we didn't allow pinned buffer objects, query results could be written when
that buffer was evicted, corrupting data in other buffers.

Now, require that buffers holding query results are no more than two pages
large, and allow one single pinned such buffer. When the command submission
code encounters query result structures in other buffers, the queries in the
pinned buffer will be finished using a query barrier for the last hardware
context using the buffer. Also if the command submission code detects
that a new hardware context is used for queries, all queries of the previous
hardware context is also flushed. Currently we use waiting for a no-op
occlusion query as a query barrier for a specific context.

The query buffer is also flushed and unpinned on context destructions,
master drops and before scanout bo placement.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Jakob Bornecrantz 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c   |   44 
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |   86 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |   24 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c  |  375 --
 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c |   57 +
 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |8 +-
 6 files changed, 572 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c
index 7f744a8..3fa884d 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c
@@ -42,6 +42,7 @@
  * May only be called by the current master since it assumes that the
  * master lock is the current master's lock.
  * This function takes the master's lock in write mode.
+ * Flushes and unpins the query bo to avoid failures.
  *
  * Returns
  *  -ERESTARTSYS if interrupted by a signal.
@@ -59,6 +60,8 @@ int vmw_dmabuf_to_placement(struct vmw_private *dev_priv,
if (unlikely(ret != 0))
return ret;

+   vmw_execbuf_release_pinned_bo(dev_priv, false, 0);
+
ret = ttm_bo_reserve(bo, interruptible, false, false, 0);
if (unlikely(ret != 0))
goto err;
@@ -78,6 +81,7 @@ err:
  * May only be called by the current master since it assumes that the
  * master lock is the current master's lock.
  * This function takes the master's lock in write mode.
+ * Flushes and unpins the query bo if @pin == true to avoid failures.
  *
  * @dev_priv:  Driver private.
  * @buf:  DMA buffer to move.
@@ -100,6 +104,9 @@ int vmw_dmabuf_to_vram_or_gmr(struct vmw_private *dev_priv,
if (unlikely(ret != 0))
return ret;

+   if (pin)
+   vmw_execbuf_release_pinned_bo(dev_priv, false, 0);
+
ret = ttm_bo_reserve(bo, interruptible, false, false, 0);
if (unlikely(ret != 0))
goto err;
@@ -177,6 +184,7 @@ int vmw_dmabuf_to_vram(struct vmw_private *dev_priv,
  * May only be called by the current master since it assumes that the
  * master lock is the current master's lock.
  * This function takes the master's lock in write mode.
+ * Flushes and unpins the query bo if @pin == true to avoid failures.
  *
  * @dev_priv:  Driver private.
  * @buf:  DMA buffer to move.
@@ -205,6 +213,9 @@ int vmw_dmabuf_to_start_of_vram(struct vmw_private 
*dev_priv,
if (unlikely(ret != 0))
return ret;

+   if (pin)
+   vmw_execbuf_release_pinned_bo(dev_priv, false, 0);
+
ret = ttm_bo_reserve(bo, interruptible, false, false, 0);
if (unlikely(ret != 0))
goto err_unlock;
@@ -276,3 +287,36 @@ void vmw_bo_get_guest_ptr(const struct ttm_buffer_object 
*bo,
ptr->offset = 0;
}
 }
+
+
+/**
+ * vmw_bo_pin - Pin or unpin a buffer object without moving it.
+ *
+ * @bo: The buffer object. Must be reserved, and present either in VRAM
+ * or GMR memory.
+ * @pin: Whether to pin or unpin.
+ *
+ */
+void vmw_bo_pin(struct ttm_buffer_object *bo, bool pin)
+{
+   uint32_t pl_flags;
+   struct ttm_placement placement;
+   uint32_t old_mem_type = bo->mem.mem_type;
+   int ret;
+
+   BUG_ON(!atomic_read(>reserved));
+   BUG_ON(old_mem_type != TTM_PL_VRAM &&
+  old_mem_type != VMW_PL_FLAG_GMR);
+
+   pl_flags = TTM_PL_FLAG_VRAM | VMW_PL_FLAG_GMR | TTM_PL_FLAG_CACHED;
+   if (pin)
+   pl_flags |= TTM_PL_FLAG_NO_EVICT;
+
+   memset(, 0, sizeof(placement));
+   placement.num_placement = 1;
+   placement.placement = _flags;
+
+   ret = ttm_bo_validate(bo, , false, true, true);
+
+   BUG_ON(ret != 0 || bo->mem.mem_type != old_mem_type);
+}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index ace4402..7b88104 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -213,6 +213,72 @@ static void vmw_print_capabilities(uint32_t 

[PATCH 19/26] vmwgfx: Allow reference and unreference of NULL fence objects.

[Thomas Hellstrom]

The execbuf utils may call reference on NULL fence objects.

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Jakob Bornecrantz 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c |9 -
 1 files changed, 8 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
index 5065a14..5f60be7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c
@@ -177,6 +177,9 @@ out_unlock:

 struct vmw_fence_obj *vmw_fence_obj_reference(struct vmw_fence_obj *fence)
 {
+   if (unlikely(fence == NULL))
+   return NULL;
+
kref_get(>kref);
return fence;
 }
@@ -191,8 +194,12 @@ struct vmw_fence_obj *vmw_fence_obj_reference(struct 
vmw_fence_obj *fence)
 void vmw_fence_obj_unreference(struct vmw_fence_obj **fence_p)
 {
struct vmw_fence_obj *fence = *fence_p;
-   struct vmw_fence_manager *fman = fence->fman;
+   struct vmw_fence_manager *fman;
+
+   if (unlikely(fence == NULL))
+   return;

+   fman = fence->fman;
*fence_p = NULL;
spin_lock_irq(>lock);
BUG_ON(atomic_read(>kref.refcount) == 0);
-- 
1.7.4.4

[PATCH 18/26] vmwgfx: minor dmabuf utilities cleanup

[Thomas Hellstrom]

Add / fix some function comments.
Don't move out an fbdev framebuffer when unused. Just unpin.
Only have a single function that computes a SVGAGuestPtr from the buffer's
current placement, and make it more versatile by accepting a
struct ttm_buffer_object

Signed-off-by: Thomas Hellstrom 
Reviewed-by: Jakob Bornecrantz 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c  |   86 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |9 +---
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c  |3 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c |   10 ++--
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c|2 +-
 5 files changed, 45 insertions(+), 65 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c
index 5668ad9..7f744a8 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c
@@ -32,10 +32,16 @@


 /**
- * Validate a buffer to placement.
+ * vmw_dmabuf_to_placement - Validate a buffer to placement.
  *
- * May only be called by the current master as this function takes the
- * its lock in write mode.
+ * @dev_priv:  Driver private.
+ * @buf:  DMA buffer to move.
+ * @pin:  Pin buffer if true.
+ * @interruptible:  Use interruptible wait.
+ *
+ * May only be called by the current master since it assumes that the
+ * master lock is the current master's lock.
+ * This function takes the master's lock in write mode.
  *
  * Returns
  *  -ERESTARTSYS if interrupted by a signal.
@@ -67,10 +73,11 @@ err:
 }

 /**
- * Move a buffer to vram or gmr.
+ * vmw_dmabuf_to_vram_or_gmr - Move a buffer to vram or gmr.
  *
- * May only be called by the current master as this function takes the
- * its lock in write mode.
+ * May only be called by the current master since it assumes that the
+ * master lock is the current master's lock.
+ * This function takes the master's lock in write mode.
  *
  * @dev_priv:  Driver private.
  * @buf:  DMA buffer to move.
@@ -134,10 +141,11 @@ err:
 }

 /**
- * Move a buffer to vram.
+ * vmw_dmabuf_to_vram - Move a buffer to vram.
  *
- * May only be called by the current master as this function takes the
- * its lock in write mode.
+ * May only be called by the current master since it assumes that the
+ * master lock is the current master's lock.
+ * This function takes the master's lock in write mode.
  *
  * @dev_priv:  Driver private.
  * @buf:  DMA buffer to move.
@@ -164,10 +172,11 @@ int vmw_dmabuf_to_vram(struct vmw_private *dev_priv,
 }

 /**
- * Move a buffer to start of vram.
+ * vmw_dmabuf_to_start_of_vram - Move a buffer to start of vram.
  *
- * May only be called by the current master as this function takes the
- * its lock in write mode.
+ * May only be called by the current master since it assumes that the
+ * master lock is the current master's lock.
+ * This function takes the master's lock in write mode.
  *
  * @dev_priv:  Driver private.
  * @buf:  DMA buffer to move.
@@ -219,11 +228,13 @@ err_unlock:
return ret;
 }

+
 /**
- * Unpin the buffer given buffer, does not move the buffer.
+ * vmw_dmabuf_upin - Unpin the buffer given buffer, does not move the buffer.
  *
- * May only be called by the current master as this function takes the
- * its lock in write mode.
+ * May only be called by the current master since it assumes that the
+ * master lock is the current master's lock.
+ * This function takes the master's lock in write mode.
  *
  * @dev_priv:  Driver private.
  * @buf:  DMA buffer to unpin.
@@ -246,47 +257,22 @@ int vmw_dmabuf_unpin(struct vmw_private *dev_priv,
   interruptible);
 }

+
 /**
- * Move a buffer to system memory, does not pin the buffer.
- *
- * May only be called by the current master as this function takes the
- * its lock in write mode.
- *
- * @dev_priv:  Driver private.
- * @buf:  DMA buffer to move.
- * @interruptible:  Use interruptible wait.
+ * vmw_bo_get_guest_ptr - Get the guest ptr representing the current placement
+ * of a buffer.
  *
- * Returns
- * -ERESTARTSYS if interrupted by a signal.
+ * @bo: Pointer to a struct ttm_buffer_object. Must be pinned or reserved.
+ * @ptr: SVGAGuestPtr returning the result.
  */
-int vmw_dmabuf_to_system(struct vmw_private *dev_priv,
-struct vmw_dma_buffer *buf,
-bool interruptible)
-{
-   return vmw_dmabuf_to_placement(dev_priv, buf,
-  _sys_placement,
-  interruptible);
-}
-
-void vmw_dmabuf_get_id_offset(struct vmw_dma_buffer *buf,
- uint32_t *gmrId, uint32_t *offset)
-{
-   if (buf->base.mem.mem_type == TTM_PL_VRAM) {
-   *gmrId = SVGA_GMR_FRAMEBUFFER;
-   *offset = buf->base.offset;
-   } else {
-   *gmrId = buf->base.mem.start;
-   *offset = 0;
-   }
-}
-
-void vmw_dmabuf_get_guest_ptr(struct vmw_dma_buffer *buf, SVGAGuestPtr *ptr)
+void 

[PATCH 16/26] vmwgfx: Add present and readback ioctls

[Thomas Hellstrom]

From: Jakob Bornecrantz 

Signed-off-by: Jakob Bornecrantz 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   |   13 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h   |   19 
 drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c |  172 +
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c   |  170 
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h   |3 +
 include/drm/vmwgfx_drm.h  |   63 
 6 files changed, 440 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 73757c3..ace4402 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -94,6 +94,12 @@
 #define DRM_IOCTL_VMW_FENCE_UNREF  \
DRM_IOW(DRM_COMMAND_BASE + DRM_VMW_FENCE_UNREF, \
 struct drm_vmw_fence_arg)
+#define DRM_IOCTL_VMW_PRESENT  \
+   DRM_IOW(DRM_COMMAND_BASE + DRM_VMW_PRESENT, \
+struct drm_vmw_present_arg)
+#define DRM_IOCTL_VMW_PRESENT_READBACK \
+   DRM_IOW(DRM_COMMAND_BASE + DRM_VMW_PRESENT_READBACK,\
+struct drm_vmw_present_readback_arg)

 /**
  * The core DRM version of this macro doesn't account for
@@ -146,6 +152,13 @@ static struct drm_ioctl_desc vmw_ioctls[] = {
  DRM_AUTH | DRM_UNLOCKED),
VMW_IOCTL_DEF(VMW_GET_3D_CAP, vmw_get_cap_3d_ioctl,
  DRM_AUTH | DRM_UNLOCKED),
+
+   /* these allow direct access to the framebuffers mark as master only */
+   VMW_IOCTL_DEF(VMW_PRESENT, vmw_present_ioctl,
+ DRM_MASTER | DRM_AUTH | DRM_UNLOCKED),
+   VMW_IOCTL_DEF(VMW_PRESENT_READBACK,
+ vmw_present_readback_ioctl,
+ DRM_MASTER | DRM_AUTH | DRM_UNLOCKED),
 };

 static struct pci_device_id vmw_pci_id_list[] = {
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 2124fbc..fc0e3bc 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -97,6 +97,8 @@ struct vmw_cursor_snooper {
uint32_t *image;
 };

+struct vmw_framebuffer;
+
 struct vmw_surface {
struct vmw_resource res;
uint32_t flags;
@@ -430,6 +432,10 @@ extern int vmw_getparam_ioctl(struct drm_device *dev, void 
*data,
  struct drm_file *file_priv);
 extern int vmw_get_cap_3d_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
+extern int vmw_present_ioctl(struct drm_device *dev, void *data,
+struct drm_file *file_priv);
+extern int vmw_present_readback_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv);

 /**
  * Fifo utilities - vmwgfx_fifo.c
@@ -554,6 +560,19 @@ bool vmw_kms_validate_mode_vram(struct vmw_private 
*dev_priv,
uint32_t pitch,
uint32_t height);
 u32 vmw_get_vblank_counter(struct drm_device *dev, int crtc);
+int vmw_kms_present(struct vmw_private *dev_priv,
+   struct drm_file *file_priv,
+   struct vmw_framebuffer *vfb,
+   struct vmw_surface *surface,
+   uint32_t sid, int32_t destX, int32_t destY,
+   struct drm_vmw_rect *clips,
+   uint32_t num_clips);
+int vmw_kms_readback(struct vmw_private *dev_priv,
+struct drm_file *file_priv,
+struct vmw_framebuffer *vfb,
+struct drm_vmw_fence_rep __user *user_fence_rep,
+struct drm_vmw_rect *clips,
+uint32_t num_clips);

 /**
  * Overlay control - vmwgfx_overlay.c
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
index 5ecf966..c0284a4 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
@@ -27,6 +27,7 @@

 #include "vmwgfx_drv.h"
 #include "vmwgfx_drm.h"
+#include "vmwgfx_kms.h"

 int vmw_getparam_ioctl(struct drm_device *dev, void *data,
   struct drm_file *file_priv)
@@ -110,3 +111,174 @@ int vmw_get_cap_3d_ioctl(struct drm_device *dev, void 
*data,

return ret;
 }
+
+int vmw_present_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+   struct ttm_object_file *tfile = vmw_fpriv(file_priv)->tfile;
+   struct vmw_private *dev_priv = vmw_priv(dev);
+   struct drm_vmw_present_arg *arg =
+   (struct drm_vmw_present_arg *)data;
+   struct vmw_surface *surface;
+   struct vmw_master *vmaster = vmw_master(file_priv->master);
+   struct drm_vmw_rect __user *clips_ptr;
+   struct drm_vmw_rect *clips = NULL;
+   struct drm_mode_object *obj;
+ 

[PATCH 15/26] vmwgfx: Place overlays in GMR area if we can

[Thomas Hellstrom]

From: Jakob Bornecrantz 

When we hae screen objects we are allowed to place the overlay source
in the GMR area, do this as this will save precious VRAM.

Signed-off-by: Jakob Bornecrantz 
Reviewed-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c |  134 +--
 1 files changed, 75 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
index 7a7abcd..29481e1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c
@@ -97,68 +97,80 @@ static int vmw_overlay_send_put(struct vmw_private 
*dev_priv,
struct drm_vmw_control_stream_arg *arg,
bool interruptible)
 {
+   struct vmw_escape_video_flush *flush;
+   size_t fifo_size;
+   uint32_t gmrId, offset;
+   bool have_so = dev_priv->sou_priv ? true : false;
+   int i, num_items;
+
struct {
struct vmw_escape_header escape;
struct {
-   struct {
-   uint32_t cmdType;
-   uint32_t streamId;
-   } header;
-   struct {
-   uint32_t registerId;
-   uint32_t value;
-   } items[SVGA_VIDEO_PITCH_3 + 1];
-   } body;
-   struct vmw_escape_video_flush flush;
+   uint32_t cmdType;
+   uint32_t streamId;
+   } header;
} *cmds;
-   uint32_t offset;
-   int i, ret;
+   struct {
+   uint32_t registerId;
+   uint32_t value;
+   } *items;

-   for (;;) {
-   cmds = vmw_fifo_reserve(dev_priv, sizeof(*cmds));
-   if (cmds)
-   break;
+   /* defines are a index needs + 1 */
+   if (have_so)
+   num_items = SVGA_VIDEO_DST_SCREEN_ID + 1;
+   else
+   num_items = SVGA_VIDEO_PITCH_3 + 1;

-   ret = vmw_fallback_wait(dev_priv, false, true, 0,
-   interruptible, 3*HZ);
-   if (interruptible && ret == -ERESTARTSYS)
-   return ret;
-   else
-   BUG_ON(ret != 0);
+   fifo_size = sizeof(*cmds) + sizeof(*flush) + sizeof(*items) * num_items;
+
+   cmds = vmw_fifo_reserve(dev_priv, fifo_size);
+   /* hardware has hung, can't do anything here */
+   if (!cmds)
+   return -ENOMEM;
+
+   items = (typeof(items))[1];
+   flush = (struct vmw_escape_video_flush *)[num_items];
+
+   /* the size is header + number of items */
+   fill_escape(>escape, sizeof(*items) * (num_items + 1));
+
+   cmds->header.cmdType = SVGA_ESCAPE_VMWARE_VIDEO_SET_REGS;
+   cmds->header.streamId = arg->stream_id;
+
+   /* the IDs are neatly numbered */
+   for (i = 0; i < num_items; i++)
+   items[i].registerId = i;
+
+   vmw_dmabuf_get_id_offset(buf, , );
+   offset += arg->offset;
+
+   items[SVGA_VIDEO_ENABLED].value = true;
+   items[SVGA_VIDEO_FLAGS].value   = arg->flags;
+   items[SVGA_VIDEO_DATA_OFFSET].value = offset;
+   items[SVGA_VIDEO_FORMAT].value  = arg->format;
+   items[SVGA_VIDEO_COLORKEY].value= arg->color_key;
+   items[SVGA_VIDEO_SIZE].value= arg->size;
+   items[SVGA_VIDEO_WIDTH].value   = arg->width;
+   items[SVGA_VIDEO_HEIGHT].value  = arg->height;
+   items[SVGA_VIDEO_SRC_X].value   = arg->src.x;
+   items[SVGA_VIDEO_SRC_Y].value   = arg->src.y;
+   items[SVGA_VIDEO_SRC_WIDTH].value   = arg->src.w;
+   items[SVGA_VIDEO_SRC_HEIGHT].value  = arg->src.h;
+   items[SVGA_VIDEO_DST_X].value   = arg->dst.x;
+   items[SVGA_VIDEO_DST_Y].value   = arg->dst.y;
+   items[SVGA_VIDEO_DST_WIDTH].value   = arg->dst.w;
+   items[SVGA_VIDEO_DST_HEIGHT].value  = arg->dst.h;
+   items[SVGA_VIDEO_PITCH_1].value = arg->pitch[0];
+   items[SVGA_VIDEO_PITCH_2].value = arg->pitch[1];
+   items[SVGA_VIDEO_PITCH_3].value = arg->pitch[2];
+   if (have_so) {
+   items[SVGA_VIDEO_DATA_GMRID].value= gmrId;
+   items[SVGA_VIDEO_DST_SCREEN_ID].value = SVGA_ID_INVALID;
}

-   fill_escape(>escape, sizeof(cmds->body));
-   cmds->body.header.cmdType = SVGA_ESCAPE_VMWARE_VIDEO_SET_REGS;
-   cmds->body.header.streamId = arg->stream_id;
-
-   for (i = 0; i <= SVGA_VIDEO_PITCH_3; i++)
-   cmds->body.items[i].registerId = i;
-
-   offset = buf->base.offset + arg->offset;
-
-   cmds->body.items[SVGA_VIDEO_ENABLED].value = true;
-   cmds->body.items[SVGA_VIDEO_FLAGS].value   = arg->flags;
-   cmds->body.items[SVGA_VIDEO_DATA_OFFSET].value = offset;

[PATCH 14/26] vmwgfx: Drop 3D Legacy Display Unit support

[Thomas Hellstrom]

From: Jakob Bornecrantz 

Since 3D requires HWv8 and screen objects is always available on those
hosts we only need the screen objects path for surfaces.

Signed-off-by: Jakob Bornecrantz 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |   10 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c |4 +
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |  225 ++
 3 files changed, 20 insertions(+), 219 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index d1e1325..73757c3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -457,9 +457,6 @@ static int vmw_driver_load(struct drm_device *dev, unsigned 
long chipset)
if (unlikely(ret != 0))
goto out_no_fifo;
vmw_kms_save_vga(dev_priv);
-   DRM_INFO("%s", vmw_fifo_have_3d(dev_priv) ?
-"Detected device 3D availability.\n" :
-"Detected no device 3D availability.\n");

/* Start kms and overlay systems, needs fifo. */
ret = vmw_kms_init(dev_priv);
@@ -467,6 +464,11 @@ static int vmw_driver_load(struct drm_device *dev, 
unsigned long chipset)
goto out_no_kms;
vmw_overlay_init(dev_priv);

+   /* 3D Depends on Screen Objects being used. */
+   DRM_INFO("%s", vmw_fifo_have_3d(dev_priv) ?
+"Detected device 3D availability.\n" :
+"Detected no device 3D availability.\n");
+
/* We might be done with the fifo now */
if (dev_priv->enable_fb) {
vmw_fb_init(dev_priv);
@@ -779,8 +781,6 @@ static void vmw_master_drop(struct drm_device *dev,

vmw_fp->locked_master = drm_master_get(file_priv->master);
ret = ttm_vt_lock(>lock, false, vmw_fp->tfile);
-   vmw_kms_idle_workqueues(vmaster);
-
if (unlikely((ret != 0))) {
DRM_ERROR("Unable to lock TTM at VT switch.\n");
drm_master_put(_fp->locked_master);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
index 4b32419..d7ed33e7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
@@ -48,6 +48,10 @@ bool vmw_fifo_have_3d(struct vmw_private *dev_priv)
if (hwversion < SVGA3D_HWVERSION_WS8_B1)
return false;

+   /* Non-Screen Object path does not support surfaces */
+   if (!dev_priv->sou_priv)
+   return false;
+
return true;
 }

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 346e232..8628bc7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -31,9 +31,6 @@
 /* Might need a hrtimer here? */
 #define VMWGFX_PRESENT_RATE ((HZ / 60 > 0) ? HZ / 60 : 1)

-static int vmw_surface_dmabuf_pin(struct vmw_framebuffer *vfb);
-static int vmw_surface_dmabuf_unpin(struct vmw_framebuffer *vfb);
-
 void vmw_display_unit_cleanup(struct vmw_display_unit *du)
 {
if (du->cursor_surface)
@@ -330,41 +327,10 @@ struct vmw_framebuffer_surface {
struct vmw_framebuffer base;
struct vmw_surface *surface;
struct vmw_dma_buffer *buffer;
-   struct delayed_work d_work;
-   struct mutex work_lock;
-   bool present_fs;
struct list_head head;
struct drm_master *master;
 };

-/**
- * vmw_kms_idle_workqueues - Flush workqueues on this master
- *
- * @vmaster - Pointer identifying the master, for the surfaces of which
- * we idle the dirty work queues.
- *
- * This function should be called with the ttm lock held in exclusive mode
- * to idle all dirty work queues before the fifo is taken down.
- *
- * The work task may actually requeue itself, but after the flush returns we're
- * sure that there's nothing to present, since the ttm lock is held in
- * exclusive mode, so the fifo will never get used.
- */
-
-void vmw_kms_idle_workqueues(struct vmw_master *vmaster)
-{
-   struct vmw_framebuffer_surface *entry;
-
-   mutex_lock(>fb_surf_mutex);
-   list_for_each_entry(entry, >fb_surf, head) {
-   if (cancel_delayed_work_sync(>d_work))
-   (void) entry->d_work.work.func(>d_work.work);
-
-   (void) cancel_delayed_work_sync(>d_work);
-   }
-   mutex_unlock(>fb_surf_mutex);
-}
-
 void vmw_framebuffer_surface_destroy(struct drm_framebuffer *framebuffer)
 {
struct vmw_framebuffer_surface *vfbs =
@@ -376,7 +342,6 @@ void vmw_framebuffer_surface_destroy(struct drm_framebuffer 
*framebuffer)
list_del(>head);
mutex_unlock(>fb_surf_mutex);

-   cancel_delayed_work_sync(>d_work);
drm_master_put(>master);
drm_framebuffer_cleanup(framebuffer);
vmw_surface_unreference(>surface);
@@ -384,101 +349,6 @@ void vmw_framebuffer_surface_destroy(struct 
drm_framebuffer *framebuffer)
kfree(vfbs);
 }

-static void 

[PATCH 13/26] vmwgfx: Require HWV8 for 3d support

[Thomas Hellstrom]

On lower versions, the way we mix 2D and 3D may be too slow.

Signed-off-by: Thomas Hellstrom 
Signed-off-by: Jakob Bornecrantz 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
index 881f67a..4b32419 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
@@ -45,7 +45,7 @@ bool vmw_fifo_have_3d(struct vmw_private *dev_priv)
if (hwversion == 0)
return false;

-   if (hwversion < SVGA3D_HWVERSION_WS65_B1)
+   if (hwversion < SVGA3D_HWVERSION_WS8_B1)
return false;

return true;
-- 
1.7.4.4

[PATCH 12/26] vmwgfx: Add screen object support

[Thomas Hellstrom]

From: Jakob Bornecrantz 

Signed-off-by: Jakob Bornecrantz 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/Makefile  |2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c  |   34 ++-
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h  |1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c  |  165 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h  |   10 +
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c  |5 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c |  566 ++
 7 files changed, 752 insertions(+), 31 deletions(-)
 create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c

diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index e13a118..586869c 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -5,6 +5,6 @@ vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o 
vmwgfx_drv.o \
vmwgfx_fb.o vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_buffer.o \
vmwgfx_fifo.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
vmwgfx_overlay.o vmwgfx_marker.o vmwgfx_gmrid_manager.o \
-   vmwgfx_fence.o vmwgfx_dmabuf.o
+   vmwgfx_fence.o vmwgfx_dmabuf.o vmwgfx_scrn.o

 obj-$(CONFIG_DRM_VMWGFX) := vmwgfx.o
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index d4829cb..d1e1325 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -451,22 +451,28 @@ static int vmw_driver_load(struct drm_device *dev, 
unsigned long chipset)
dev_priv->fman = vmw_fence_manager_init(dev_priv);
if (unlikely(dev_priv->fman == NULL))
goto out_no_fman;
+
+   /* Need to start the fifo to check if we can do screen objects */
+   ret = vmw_3d_resource_inc(dev_priv, true);
+   if (unlikely(ret != 0))
+   goto out_no_fifo;
+   vmw_kms_save_vga(dev_priv);
+   DRM_INFO("%s", vmw_fifo_have_3d(dev_priv) ?
+"Detected device 3D availability.\n" :
+"Detected no device 3D availability.\n");
+
+   /* Start kms and overlay systems, needs fifo. */
ret = vmw_kms_init(dev_priv);
if (unlikely(ret != 0))
goto out_no_kms;
vmw_overlay_init(dev_priv);
+
+   /* We might be done with the fifo now */
if (dev_priv->enable_fb) {
-   ret = vmw_3d_resource_inc(dev_priv, false);
-   if (unlikely(ret != 0))
-   goto out_no_fifo;
-   vmw_kms_save_vga(dev_priv);
vmw_fb_init(dev_priv);
-   DRM_INFO("%s", vmw_fifo_have_3d(dev_priv) ?
-"Detected device 3D availability.\n" :
-"Detected no device 3D availability.\n");
} else {
-   DRM_INFO("Delayed 3D detection since we're not "
-"running the device in SVGA mode yet.\n");
+   vmw_kms_restore_vga(dev_priv);
+   vmw_3d_resource_dec(dev_priv, true);
}

if (dev_priv->capabilities & SVGA_CAP_IRQMASK) {
@@ -483,15 +489,17 @@ static int vmw_driver_load(struct drm_device *dev, 
unsigned long chipset)
return 0;

 out_no_irq:
-   if (dev_priv->enable_fb) {
+   if (dev_priv->enable_fb)
vmw_fb_close(dev_priv);
+   vmw_overlay_close(dev_priv);
+   vmw_kms_close(dev_priv);
+out_no_kms:
+   /* We still have a 3D resource reference held */
+   if (dev_priv->enable_fb) {
vmw_kms_restore_vga(dev_priv);
vmw_3d_resource_dec(dev_priv, false);
}
 out_no_fifo:
-   vmw_overlay_close(dev_priv);
-   vmw_kms_close(dev_priv);
-out_no_kms:
vmw_fence_manager_takedown(dev_priv->fman);
 out_no_fman:
if (dev_priv->stealth)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 5acf1f2..2124fbc 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -217,6 +217,7 @@ struct vmw_private {

void *fb_info;
struct vmw_legacy_display *ldu_priv;
+   struct vmw_screen_object_display *sou_priv;
struct vmw_overlay *overlay_priv;

/*
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index b3d5120..346e232 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -27,6 +27,7 @@

 #include "vmwgfx_kms.h"

+
 /* Might need a hrtimer here? */
 #define VMWGFX_PRESENT_RATE ((HZ / 60 > 0) ? HZ / 60 : 1)

@@ -474,6 +475,62 @@ static int do_surface_dirty_ldu(struct vmw_private 
*dev_priv,

vmw_fifo_commit(dev_priv, sizeof(*cmd) + (num_clips - 1) *
sizeof(cmd->cr));
+
+   return 0;
+}
+
+static int do_surface_dirty_sou(struct vmw_private *dev_priv,
+   struct vmw_framebuffer *framebuffer,
+   struct vmw_surface *surf,
+  

[PATCH 11/26] vmwgfx: Add dmabuf helper functions for pinning

[Thomas Hellstrom]

From: Jakob Bornecrantz 

Signed-off-by: Jakob Bornecrantz 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/Makefile |2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c  |   33 
 drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c  |  292 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |   32 +++-
 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c  |   57 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |4 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c |   66 ++-
 7 files changed, 379 insertions(+), 107 deletions(-)
 create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c

diff --git a/drivers/gpu/drm/vmwgfx/Makefile b/drivers/gpu/drm/vmwgfx/Makefile
index 7d8e9d5..e13a118 100644
--- a/drivers/gpu/drm/vmwgfx/Makefile
+++ b/drivers/gpu/drm/vmwgfx/Makefile
@@ -5,6 +5,6 @@ vmwgfx-y := vmwgfx_execbuf.o vmwgfx_gmr.o vmwgfx_kms.o 
vmwgfx_drv.o \
vmwgfx_fb.o vmwgfx_ioctl.o vmwgfx_resource.o vmwgfx_buffer.o \
vmwgfx_fifo.o vmwgfx_irq.o vmwgfx_ldu.o vmwgfx_ttm_glue.o \
vmwgfx_overlay.o vmwgfx_marker.o vmwgfx_gmrid_manager.o \
-   vmwgfx_fence.o
+   vmwgfx_fence.o vmwgfx_dmabuf.o

 obj-$(CONFIG_DRM_VMWGFX) := vmwgfx.o
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
index 5d665ce..98a5d7e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
@@ -42,6 +42,10 @@ static uint32_t sys_placement_flags = TTM_PL_FLAG_SYSTEM |
 static uint32_t gmr_placement_flags = VMW_PL_FLAG_GMR |
TTM_PL_FLAG_CACHED;

+static uint32_t gmr_ne_placement_flags = VMW_PL_FLAG_GMR |
+   TTM_PL_FLAG_CACHED |
+   TTM_PL_FLAG_NO_EVICT;
+
 struct ttm_placement vmw_vram_placement = {
.fpfn = 0,
.lpfn = 0,
@@ -65,6 +69,20 @@ struct ttm_placement vmw_vram_gmr_placement = {
.busy_placement = _placement_flags
 };

+static uint32_t vram_gmr_ne_placement_flags[] = {
+   TTM_PL_FLAG_VRAM | TTM_PL_FLAG_CACHED | TTM_PL_FLAG_NO_EVICT,
+   VMW_PL_FLAG_GMR | TTM_PL_FLAG_CACHED | TTM_PL_FLAG_NO_EVICT
+};
+
+struct ttm_placement vmw_vram_gmr_ne_placement = {
+   .fpfn = 0,
+   .lpfn = 0,
+   .num_placement = 2,
+   .placement = vram_gmr_ne_placement_flags,
+   .num_busy_placement = 1,
+   .busy_placement = _ne_placement_flags
+};
+
 struct ttm_placement vmw_vram_sys_placement = {
.fpfn = 0,
.lpfn = 0,
@@ -92,6 +110,21 @@ struct ttm_placement vmw_sys_placement = {
.busy_placement = _placement_flags
 };

+static uint32_t evictable_placement_flags[] = {
+   TTM_PL_FLAG_SYSTEM | TTM_PL_FLAG_CACHED,
+   TTM_PL_FLAG_VRAM | TTM_PL_FLAG_CACHED,
+   VMW_PL_FLAG_GMR | TTM_PL_FLAG_CACHED
+};
+
+struct ttm_placement vmw_evictable_placement = {
+   .fpfn = 0,
+   .lpfn = 0,
+   .num_placement = 3,
+   .placement = evictable_placement_flags,
+   .num_busy_placement = 1,
+   .busy_placement = _placement_flags
+};
+
 struct vmw_ttm_backend {
struct ttm_backend backend;
struct page **pages;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c
new file mode 100644
index 000..5668ad9
--- /dev/null
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_dmabuf.c
@@ -0,0 +1,292 @@
+/**
+ *
+ * Copyright ? 2011 VMware, Inc., Palo Alto, CA., USA
+ * All Rights Reserved.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the
+ * "Software"), to deal in the Software without restriction, including
+ * without limitation the rights to use, copy, modify, merge, publish,
+ * distribute, sub license, and/or sell copies of the Software, and to
+ * permit persons to whom the Software is furnished to do so, subject to
+ * the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the
+ * next paragraph) shall be included in all copies or substantial portions
+ * of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
+ * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
+ * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
+ * USE OR OTHER DEALINGS IN THE SOFTWARE.
+ *
+ **/
+
+#include "ttm/ttm_placement.h"
+
+#include "drmP.h"
+#include "vmwgfx_drv.h"
+
+
+/**
+ * Validate a buffer to placement.
+ *
+ * May only be called by the current master as this function takes the
+ * its lock in write mode.
+ *
+ * Returns
+ *  -ERESTARTSYS if interrupted by a 

[PATCH 10/26] vmwgfx: Refactor common display unit functions to shared file

[Thomas Hellstrom]

From: Jakob Bornecrantz 

More preparation for Screen Object support.

Signed-off-by: Jakob Bornecrantz 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  238 +++
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h |   31 -
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |  268 ++-
 3 files changed, 282 insertions(+), 255 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 1dbb67e..c34866a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1152,3 +1152,241 @@ u32 vmw_get_vblank_counter(struct drm_device *dev, int 
crtc)
 {
return 0;
 }
+
+
+/*
+ * Small shared kms functions.
+ */
+
+int vmw_du_update_layout(struct vmw_private *dev_priv, unsigned num,
+struct drm_vmw_rect *rects)
+{
+   struct drm_device *dev = dev_priv->dev;
+   struct vmw_display_unit *du;
+   struct drm_connector *con;
+   int i;
+
+   mutex_lock(>mode_config.mutex);
+
+#if 0
+   DRM_INFO("%s: new layout ", __func__);
+   for (i = 0; i < (int)num; i++)
+   DRM_INFO("(%i, %i %ux%u) ", rects[i].x, rects[i].y,
+rects[i].w, rects[i].h);
+   DRM_INFO("\n");
+#else
+   (void)i;
+#endif
+
+   list_for_each_entry(con, >mode_config.connector_list, head) {
+   du = vmw_connector_to_du(con);
+   if (num > du->unit) {
+   du->pref_width = rects[du->unit].w;
+   du->pref_height = rects[du->unit].h;
+   du->pref_active = true;
+   } else {
+   du->pref_width = 800;
+   du->pref_height = 600;
+   du->pref_active = false;
+   }
+   con->status = vmw_du_connector_detect(con, true);
+   }
+
+   mutex_unlock(>mode_config.mutex);
+
+   return 0;
+}
+
+void vmw_du_crtc_save(struct drm_crtc *crtc)
+{
+}
+
+void vmw_du_crtc_restore(struct drm_crtc *crtc)
+{
+}
+
+void vmw_du_crtc_gamma_set(struct drm_crtc *crtc,
+  u16 *r, u16 *g, u16 *b,
+  uint32_t start, uint32_t size)
+{
+   struct vmw_private *dev_priv = vmw_priv(crtc->dev);
+   int i;
+
+   for (i = 0; i < size; i++) {
+   DRM_DEBUG("%d r/g/b = 0x%04x / 0x%04x / 0x%04x\n", i,
+ r[i], g[i], b[i]);
+   vmw_write(dev_priv, SVGA_PALETTE_BASE + i * 3 + 0, r[i] >> 8);
+   vmw_write(dev_priv, SVGA_PALETTE_BASE + i * 3 + 1, g[i] >> 8);
+   vmw_write(dev_priv, SVGA_PALETTE_BASE + i * 3 + 2, b[i] >> 8);
+   }
+}
+
+void vmw_du_connector_dpms(struct drm_connector *connector, int mode)
+{
+}
+
+void vmw_du_connector_save(struct drm_connector *connector)
+{
+}
+
+void vmw_du_connector_restore(struct drm_connector *connector)
+{
+}
+
+enum drm_connector_status
+vmw_du_connector_detect(struct drm_connector *connector, bool force)
+{
+   uint32_t num_displays;
+   struct drm_device *dev = connector->dev;
+   struct vmw_private *dev_priv = vmw_priv(dev);
+
+   mutex_lock(_priv->hw_mutex);
+   num_displays = vmw_read(dev_priv, SVGA_REG_NUM_DISPLAYS);
+   mutex_unlock(_priv->hw_mutex);
+
+   return ((vmw_connector_to_du(connector)->unit < num_displays) ?
+   connector_status_connected : connector_status_disconnected);
+}
+
+static struct drm_display_mode vmw_kms_connector_builtin[] = {
+   /* 640x480 at 60Hz */
+   { DRM_MODE("640x480", DRM_MODE_TYPE_DRIVER, 25175, 640, 656,
+  752, 800, 0, 480, 489, 492, 525, 0,
+  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) },
+   /* 800x600 at 60Hz */
+   { DRM_MODE("800x600", DRM_MODE_TYPE_DRIVER, 4, 800, 840,
+  968, 1056, 0, 600, 601, 605, 628, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 1024x768 at 60Hz */
+   { DRM_MODE("1024x768", DRM_MODE_TYPE_DRIVER, 65000, 1024, 1048,
+  1184, 1344, 0, 768, 771, 777, 806, 0,
+  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC) },
+   /* 1152x864 at 75Hz */
+   { DRM_MODE("1152x864", DRM_MODE_TYPE_DRIVER, 108000, 1152, 1216,
+  1344, 1600, 0, 864, 865, 868, 900, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 1280x768 at 60Hz */
+   { DRM_MODE("1280x768", DRM_MODE_TYPE_DRIVER, 79500, 1280, 1344,
+  1472, 1664, 0, 768, 771, 778, 798, 0,
+  DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_PVSYNC) },
+   /* 1280x800 at 60Hz */
+   { DRM_MODE("1280x800", DRM_MODE_TYPE_DRIVER, 83500, 1280, 1352,
+  1480, 1680, 0, 800, 803, 809, 831, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+   /* 1280x960 at 60Hz */
+   { DRM_MODE("1280x960", 

[PATCH 09/26] vmwgfx: Expand the command checker to cover screen object commands

[Thomas Hellstrom]

From: Jakob Bornecrantz 

Signed-off-by: Jakob Bornecrantz 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |   77 +--
 1 files changed, 72 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 542c852..c98c347 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -450,6 +450,73 @@ static int vmw_cmd_tex_state(struct vmw_private *dev_priv,
return 0;
 }

+static int vmw_cmd_check_define_gmrfb(struct vmw_private *dev_priv,
+ struct vmw_sw_context *sw_context,
+ void *buf)
+{
+   struct vmw_dma_buffer *vmw_bo;
+   int ret;
+
+   struct {
+   uint32_t header;
+   SVGAFifoCmdDefineGMRFB body;
+   } *cmd = buf;
+
+   ret = vmw_translate_guest_ptr(dev_priv, sw_context,
+ >body.ptr,
+ _bo);
+   if (unlikely(ret != 0))
+   return ret;
+
+   vmw_dmabuf_unreference(_bo);
+
+   return ret;
+}
+
+static int vmw_cmd_check_not_3d(struct vmw_private *dev_priv,
+   struct vmw_sw_context *sw_context,
+   void *buf, uint32_t *size)
+{
+   uint32_t size_remaining = *size;
+   bool need_kernel = true;
+   uint32_t cmd_id;
+
+   cmd_id = le32_to_cpu(((uint32_t *)buf)[0]);
+   switch (cmd_id) {
+   case SVGA_CMD_UPDATE:
+   *size = sizeof(uint32_t) + sizeof(SVGAFifoCmdUpdate);
+   need_kernel = false;
+   break;
+   case SVGA_CMD_DEFINE_GMRFB:
+   *size = sizeof(uint32_t) + sizeof(SVGAFifoCmdDefineGMRFB);
+   break;
+   case SVGA_CMD_BLIT_GMRFB_TO_SCREEN:
+   *size = sizeof(uint32_t) + sizeof(SVGAFifoCmdBlitGMRFBToScreen);
+   break;
+   case SVGA_CMD_BLIT_SCREEN_TO_GMRFB:
+   *size = sizeof(uint32_t) + sizeof(SVGAFifoCmdBlitGMRFBToScreen);
+   break;
+   default:
+   DRM_ERROR("Unsupported SVGA command: %u.\n", cmd_id);
+   return -EINVAL;
+   }
+
+   if (*size > size_remaining) {
+   DRM_ERROR("Invalid SVGA command (size mismatch):"
+ " %u.\n", cmd_id);
+   return -EINVAL;
+   }
+
+   if (unlikely(need_kernel && !sw_context->kernel)) {
+   DRM_ERROR("Kernel only SVGA command: %u.\n", cmd_id);
+   return -EPERM;
+   }
+
+   if (cmd_id == SVGA_CMD_DEFINE_GMRFB)
+   return vmw_cmd_check_define_gmrfb(dev_priv, sw_context, buf);
+
+   return 0;
+}

 typedef int (*vmw_cmd_func) (struct vmw_private *,
 struct vmw_sw_context *,
@@ -502,11 +569,11 @@ static int vmw_cmd_check(struct vmw_private *dev_priv,
SVGA3dCmdHeader *header = (SVGA3dCmdHeader *) buf;
int ret;

-   cmd_id = ((uint32_t *)buf)[0];
-   if (cmd_id == SVGA_CMD_UPDATE) {
-   *size = 5 << 2;
-   return 0;
-   }
+   cmd_id = le32_to_cpu(((uint32_t *)buf)[0]);
+   /* Handle any none 3D commands */
+   if (unlikely(cmd_id < SVGA_CMD_MAX))
+   return vmw_cmd_check_not_3d(dev_priv, sw_context, buf, size);
+

cmd_id = le32_to_cpu(header->id);
*size = le32_to_cpu(header->size) + sizeof(SVGA3dCmdHeader);
-- 
1.7.4.4

[PATCH 08/26] vmwgfx: Break out dirty submission code

[Thomas Hellstrom]

From: Jakob Bornecrantz 

In preperation for screen objects, still leaves the delayed workqueue
for surface updates in place.

Signed-off-by: Jakob Bornecrantz 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  144 ++-
 1 files changed, 90 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 7ee8b8e..1dbb67e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -433,6 +433,49 @@ out_unlock:
mutex_unlock(>work_lock);
 }

+static int do_surface_dirty_ldu(struct vmw_private *dev_priv,
+   struct vmw_framebuffer *framebuffer,
+   struct vmw_surface *surf,
+   unsigned flags, unsigned color,
+   struct drm_clip_rect *clips,
+   unsigned num_clips, int inc)
+{
+   SVGA3dCopyRect *cr;
+   int i;
+
+   struct {
+   SVGA3dCmdHeader header;
+   SVGA3dCmdPresent body;
+   SVGA3dCopyRect cr;
+   } *cmd;
+
+   cmd = vmw_fifo_reserve(dev_priv, sizeof(*cmd) + (num_clips - 1) *
+  sizeof(cmd->cr));
+   if (unlikely(cmd == NULL)) {
+   DRM_ERROR("Fifo reserve failed.\n");
+   return -ENOMEM;
+   }
+
+   memset(cmd, 0, sizeof(*cmd));
+
+   cmd->header.id = cpu_to_le32(SVGA_3D_CMD_PRESENT);
+   cmd->header.size = cpu_to_le32(sizeof(cmd->body) + num_clips *
+  sizeof(cmd->cr));
+   cmd->body.sid = cpu_to_le32(surf->res.id);
+
+   for (i = 0, cr = >cr; i < num_clips; i++, cr++, clips += inc) {
+   cr->x = cpu_to_le16(clips->x1);
+   cr->y = cpu_to_le16(clips->y1);
+   cr->srcx = cr->x;
+   cr->srcy = cr->y;
+   cr->w = cpu_to_le16(clips->x2 - clips->x1);
+   cr->h = cpu_to_le16(clips->y2 - clips->y1);
+   }
+
+   vmw_fifo_commit(dev_priv, sizeof(*cmd) + (num_clips - 1) *
+   sizeof(cmd->cr));
+   return 0;
+}

 int vmw_framebuffer_surface_dirty(struct drm_framebuffer *framebuffer,
  struct drm_file *file_priv,
@@ -446,15 +489,7 @@ int vmw_framebuffer_surface_dirty(struct drm_framebuffer 
*framebuffer,
vmw_framebuffer_to_vfbs(framebuffer);
struct vmw_surface *surf = vfbs->surface;
struct drm_clip_rect norect;
-   SVGA3dCopyRect *cr;
-   int i, inc = 1;
-   int ret;
-
-   struct {
-   SVGA3dCmdHeader header;
-   SVGA3dCmdPresent body;
-   SVGA3dCopyRect cr;
-   } *cmd;
+   int ret, inc = 1;

if (unlikely(vfbs->master != file_priv->master))
return -EINVAL;
@@ -493,29 +528,10 @@ int vmw_framebuffer_surface_dirty(struct drm_framebuffer 
*framebuffer,
inc = 2; /* skip source rects */
}

-   cmd = vmw_fifo_reserve(dev_priv, sizeof(*cmd) + (num_clips - 1) * 
sizeof(cmd->cr));
-   if (unlikely(cmd == NULL)) {
-   DRM_ERROR("Fifo reserve failed.\n");
-   ttm_read_unlock(>lock);
-   return -ENOMEM;
-   }
-
-   memset(cmd, 0, sizeof(*cmd));
+   ret = do_surface_dirty_ldu(dev_priv, >base, surf,
+  flags, color,
+  clips, num_clips, inc);

-   cmd->header.id = cpu_to_le32(SVGA_3D_CMD_PRESENT);
-   cmd->header.size = cpu_to_le32(sizeof(cmd->body) + num_clips * 
sizeof(cmd->cr));
-   cmd->body.sid = cpu_to_le32(surf->res.id);
-
-   for (i = 0, cr = >cr; i < num_clips; i++, cr++, clips += inc) {
-   cr->x = cpu_to_le16(clips->x1);
-   cr->y = cpu_to_le16(clips->y1);
-   cr->srcx = cr->x;
-   cr->srcy = cr->y;
-   cr->w = cpu_to_le16(clips->x2 - clips->x1);
-   cr->h = cpu_to_le16(clips->y2 - clips->y1);
-   }
-
-   vmw_fifo_commit(dev_priv, sizeof(*cmd) + (num_clips - 1) * 
sizeof(cmd->cr));
ttm_read_unlock(>lock);
return 0;
 }
@@ -648,6 +664,41 @@ void vmw_framebuffer_dmabuf_destroy(struct drm_framebuffer 
*framebuffer)
kfree(vfbd);
 }

+static int do_dmabuf_dirty_ldu(struct vmw_private *dev_priv,
+  struct vmw_framebuffer *framebuffer,
+  struct vmw_dma_buffer *buffer,
+  unsigned flags, unsigned color,
+  struct drm_clip_rect *clips,
+  unsigned num_clips, int increment)
+{
+   size_t fifo_size;
+   int i;
+
+   struct {
+   uint32_t header;
+   SVGAFifoCmdUpdate body;
+   } *cmd;
+
+   fifo_size = sizeof(*cmd) * num_clips;
+   cmd = 

[PATCH 07/26] vmwgfx: Break out execbuf command processing

[Thomas Hellstrom]

This will make it easier to execute commands operating on user-space
resources but generated by the kernel.

JB: Added tracking if the sw_context was called from the kernel or userspace.

Signed-off-by: Thomas Hellstrom 
Signed-off-by: Jakob Bornecrantz 
Reviewed-by: Jakob Bornecrantz 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |9 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |  136 ++-
 2 files changed, 89 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 564a815..edd1e83 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -139,6 +139,7 @@ struct vmw_sw_context{
struct ida bo_list;
uint32_t last_cid;
bool cid_valid;
+   bool kernel; /**< is the called made from the kernel */
uint32_t last_sid;
uint32_t sid_translation;
bool sid_valid;
@@ -449,6 +450,14 @@ extern int vmw_dma_quiescent(struct drm_device *dev);

 extern int vmw_execbuf_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file_priv);
+extern int vmw_execbuf_process(struct drm_file *file_priv,
+  struct vmw_private *dev_priv,
+  void __user *user_commands,
+  void *kernel_commands,
+  uint32_t command_size,
+  uint64_t throttle_us,
+  struct drm_vmw_fence_rep __user
+  *user_fence_rep);

 /**
  * IRQs and wating - vmwgfx_irq.c
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index cc8c08b..542c852 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -531,9 +531,9 @@ out_err:

 static int vmw_cmd_check_all(struct vmw_private *dev_priv,
 struct vmw_sw_context *sw_context,
+void *buf,
 uint32_t size)
 {
-   void *buf = sw_context->cmd_bounce;
int32_t cur_size = size;
int ret;

@@ -724,58 +724,44 @@ int vmw_execbuf_fence_commands(struct drm_file *file_priv,
return 0;
 }

-int vmw_execbuf_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv)
+int vmw_execbuf_process(struct drm_file *file_priv,
+   struct vmw_private *dev_priv,
+   void __user *user_commands,
+   void *kernel_commands,
+   uint32_t command_size,
+   uint64_t throttle_us,
+   struct drm_vmw_fence_rep __user *user_fence_rep)
 {
-   struct vmw_private *dev_priv = vmw_priv(dev);
-   struct drm_vmw_execbuf_arg *arg = (struct drm_vmw_execbuf_arg *)data;
-   struct drm_vmw_fence_rep fence_rep;
-   struct drm_vmw_fence_rep __user *user_fence_rep;
-   int ret;
-   void *user_cmd;
-   void *cmd;
struct vmw_sw_context *sw_context = _priv->ctx;
-   struct vmw_master *vmaster = vmw_master(file_priv->master);
+   struct drm_vmw_fence_rep fence_rep;
struct vmw_fence_obj *fence;
uint32_t handle;
+   void *cmd;
+   int ret;

-   /*
-* This will allow us to extend the ioctl argument while
-* maintaining backwards compatibility:
-* We take different code paths depending on the value of
-* arg->version.
-*/
-
-   if (unlikely(arg->version != DRM_VMW_EXECBUF_VERSION)) {
-   DRM_ERROR("Incorrect execbuf version.\n");
-   DRM_ERROR("You're running outdated experimental "
- "vmwgfx user-space drivers.");
-   return -EINVAL;
-   }
-
-   ret = ttm_read_lock(>lock, true);
+   ret = mutex_lock_interruptible(_priv->cmdbuf_mutex);
if (unlikely(ret != 0))
-   return ret;
+   return -ERESTARTSYS;

-   ret = mutex_lock_interruptible(_priv->cmdbuf_mutex);
-   if (unlikely(ret != 0)) {
-   ret = -ERESTARTSYS;
-   goto out_no_cmd_mutex;
-   }
+   if (kernel_commands == NULL) {
+   sw_context->kernel = false;

-   ret = vmw_resize_cmd_bounce(sw_context, arg->command_size);
-   if (unlikely(ret != 0))
-   goto out_unlock;
+   ret = vmw_resize_cmd_bounce(sw_context, command_size);
+   if (unlikely(ret != 0))
+   goto out_unlock;

-   user_cmd = (void __user *)(unsigned long)arg->commands;
-   ret = copy_from_user(sw_context->cmd_bounce,
-user_cmd, arg->command_size);

-   if (unlikely(ret != 0)) {
-   ret = -EFAULT;
-   DRM_ERROR("Failed copying commands.\n");
-   goto out_unlock;
-   }
+   ret = 

[PATCH 06/26] vmwgfx: Some comments and BUG_ON

[Thomas Hellstrom]

From: Jakob Bornecrantz 

Signed-off-by: Jakob Bornecrantz 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index fa26e64..cc8c08b 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -681,6 +681,9 @@ static int vmw_resize_cmd_bounce(struct vmw_sw_context 
*sw_context,
  * Creates a fence object and submits a command stream marker.
  * If this fails for some reason, We sync the fifo and return NULL.
  * It is then safe to fence buffers with a NULL pointer.
+ *
+ * If @p_handle is not NULL @file_priv must also not be NULL. Creates
+ * a userspace handle if @p_handle is not NULL, otherwise not.
  */

 int vmw_execbuf_fence_commands(struct drm_file *file_priv,
@@ -692,6 +695,8 @@ int vmw_execbuf_fence_commands(struct drm_file *file_priv,
int ret;
bool synced = false;

+   /* p_handle implies file_priv. */
+   BUG_ON(p_handle != NULL && file_priv == NULL);

ret = vmw_fifo_send_fence(dev_priv, );
if (unlikely(ret != 0)) {
-- 
1.7.4.4

[PATCH 05/26] vmwgfx: Make sure the reserved area is at the start of vram

[Thomas Hellstrom]

From: Jakob Bornecrantz 

Signed-off-by: Jakob Bornecrantz 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index c14eb76..7ee8b8e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -717,6 +717,9 @@ static int vmw_surface_dmabuf_pin(struct vmw_framebuffer 
*vfb)
vmw_framebuffer_to_vfbs(>base);
unsigned long size = vfbs->base.base.pitch * vfbs->base.base.height;
int ret;
+   struct ttm_placement ne_placement = vmw_vram_ne_placement;
+
+   ne_placement.lpfn = (size + (PAGE_SIZE - 1)) / PAGE_SIZE;

vfbs->buffer = kzalloc(sizeof(*vfbs->buffer), GFP_KERNEL);
if (unlikely(vfbs->buffer == NULL))
-- 
1.7.4.4

[PATCH 04/26] vmwgfx: Add comments for buffer pinning code

[Thomas Hellstrom]

From: Jakob Bornecrantz 

Signed-off-by: Jakob Bornecrantz 
Reviewed-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 1a4c84c..c14eb76 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -706,6 +706,10 @@ static struct drm_framebuffer_funcs 
vmw_framebuffer_dmabuf_funcs = {
.create_handle = vmw_framebuffer_create_handle,
 };

+/**
+ * We need to reserve the start of vram because the host might
+ * scribble to it at mode changes, so we need to reserve it.
+ */
 static int vmw_surface_dmabuf_pin(struct vmw_framebuffer *vfb)
 {
struct vmw_private *dev_priv = vmw_priv(vfb->base.dev);
@@ -729,6 +733,9 @@ static int vmw_surface_dmabuf_pin(struct vmw_framebuffer 
*vfb)
return ret;
 }

+/**
+ * See vmw_surface_dmabuf_pin.
+ */
 static int vmw_surface_dmabuf_unpin(struct vmw_framebuffer *vfb)
 {
struct ttm_buffer_object *bo;
@@ -745,6 +752,9 @@ static int vmw_surface_dmabuf_unpin(struct vmw_framebuffer 
*vfb)
return 0;
 }

+/**
+ * Pin the dmabuffer to the start of vram.
+ */
 static int vmw_framebuffer_dmabuf_pin(struct vmw_framebuffer *vfb)
 {
struct vmw_private *dev_priv = vmw_priv(vfb->base.dev);
-- 
1.7.4.4

[PATCH 03/26] vmwgfx: Document vmw_fifo_reserve

[Thomas Hellstrom]

From: Jakob Bornecrantz 

Signed-off-by: Jakob Bornecrantz 
Reviewed-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
index 3ba9cac..881f67a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
@@ -277,6 +277,16 @@ static int vmw_fifo_wait(struct vmw_private *dev_priv,
return ret;
 }

+/**
+ * Reserve @bytes number of bytes in the fifo.
+ *
+ * This function will return NULL (error) on two conditions:
+ *  If it timeouts waiting for fifo space, or if @bytes is larger than the
+ *   available fifo space.
+ *
+ * Returns:
+ *   Pointer to the fifo, or null on error (possible hardware hang).
+ */
 void *vmw_fifo_reserve(struct vmw_private *dev_priv, uint32_t bytes)
 {
struct vmw_fifo_state *fifo_state = _priv->fifo;
-- 
1.7.4.4

[PATCH 02/26] vmwgfx: Update register files to latest from vmware-sdk

[Thomas Hellstrom]

From: Jakob Bornecrantz 

Signed-off-by: Jakob Bornecrantz 
Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/vmwgfx/svga3d_reg.h   |  259 +++--
 drivers/gpu/drm/vmwgfx/svga_escape.h  |2 +-
 drivers/gpu/drm/vmwgfx/svga_overlay.h |   22 ++--
 drivers/gpu/drm/vmwgfx/svga_reg.h |  220 +---
 4 files changed, 359 insertions(+), 144 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/svga3d_reg.h 
b/drivers/gpu/drm/vmwgfx/svga3d_reg.h
index 77cb453..d0e085e 100644
--- a/drivers/gpu/drm/vmwgfx/svga3d_reg.h
+++ b/drivers/gpu/drm/vmwgfx/svga3d_reg.h
@@ -57,7 +57,8 @@ typedef enum {
SVGA3D_HWVERSION_WS6_B1= SVGA3D_MAKE_HWVERSION(1, 1),
SVGA3D_HWVERSION_FUSION_11 = SVGA3D_MAKE_HWVERSION(1, 4),
SVGA3D_HWVERSION_WS65_B1   = SVGA3D_MAKE_HWVERSION(2, 0),
-   SVGA3D_HWVERSION_CURRENT   = SVGA3D_HWVERSION_WS65_B1,
+   SVGA3D_HWVERSION_WS8_B1= SVGA3D_MAKE_HWVERSION(2, 1),
+   SVGA3D_HWVERSION_CURRENT   = SVGA3D_HWVERSION_WS8_B1,
 } SVGA3dHardwareVersion;

 /*
@@ -67,7 +68,8 @@ typedef enum {
 typedef uint32 SVGA3dBool; /* 32-bit Bool definition */
 #define SVGA3D_NUM_CLIPPLANES   6
 #define SVGA3D_MAX_SIMULTANEOUS_RENDER_TARGETS  8
-
+#define SVGA3D_MAX_CONTEXT_IDS  256
+#define SVGA3D_MAX_SURFACE_IDS  (32 * 1024)

 /*
  * Surface formats.
@@ -79,76 +81,91 @@ typedef uint32 SVGA3dBool; /* 32-bit Bool definition */
  */

 typedef enum SVGA3dSurfaceFormat {
-   SVGA3D_FORMAT_INVALID = 0,
+   SVGA3D_FORMAT_INVALID   = 0,

-   SVGA3D_X8R8G8B8   = 1,
-   SVGA3D_A8R8G8B8   = 2,
+   SVGA3D_X8R8G8B8 = 1,
+   SVGA3D_A8R8G8B8 = 2,

-   SVGA3D_R5G6B5 = 3,
-   SVGA3D_X1R5G5B5   = 4,
-   SVGA3D_A1R5G5B5   = 5,
-   SVGA3D_A4R4G4B4   = 6,
+   SVGA3D_R5G6B5   = 3,
+   SVGA3D_X1R5G5B5 = 4,
+   SVGA3D_A1R5G5B5 = 5,
+   SVGA3D_A4R4G4B4 = 6,

-   SVGA3D_Z_D32  = 7,
-   SVGA3D_Z_D16  = 8,
-   SVGA3D_Z_D24S8= 9,
-   SVGA3D_Z_D15S1= 10,
+   SVGA3D_Z_D32= 7,
+   SVGA3D_Z_D16= 8,
+   SVGA3D_Z_D24S8  = 9,
+   SVGA3D_Z_D15S1  = 10,

-   SVGA3D_LUMINANCE8= 11,
-   SVGA3D_LUMINANCE4_ALPHA4 = 12,
-   SVGA3D_LUMINANCE16   = 13,
-   SVGA3D_LUMINANCE8_ALPHA8 = 14,
+   SVGA3D_LUMINANCE8   = 11,
+   SVGA3D_LUMINANCE4_ALPHA4= 12,
+   SVGA3D_LUMINANCE16  = 13,
+   SVGA3D_LUMINANCE8_ALPHA8= 14,

-   SVGA3D_DXT1   = 15,
-   SVGA3D_DXT2   = 16,
-   SVGA3D_DXT3   = 17,
-   SVGA3D_DXT4   = 18,
-   SVGA3D_DXT5   = 19,
+   SVGA3D_DXT1 = 15,
+   SVGA3D_DXT2 = 16,
+   SVGA3D_DXT3 = 17,
+   SVGA3D_DXT4 = 18,
+   SVGA3D_DXT5 = 19,

-   SVGA3D_BUMPU8V8   = 20,
-   SVGA3D_BUMPL6V5U5 = 21,
-   SVGA3D_BUMPX8L8V8U8   = 22,
-   SVGA3D_BUMPL8V8U8 = 23,
+   SVGA3D_BUMPU8V8 = 20,
+   SVGA3D_BUMPL6V5U5   = 21,
+   SVGA3D_BUMPX8L8V8U8 = 22,
+   SVGA3D_BUMPL8V8U8   = 23,

-   SVGA3D_ARGB_S10E5 = 24,   /* 16-bit floating-point ARGB */
-   SVGA3D_ARGB_S23E8 = 25,   /* 32-bit floating-point ARGB */
+   SVGA3D_ARGB_S10E5   = 24,   /* 16-bit floating-point ARGB */
+   SVGA3D_ARGB_S23E8   = 25,   /* 32-bit floating-point ARGB */

-   SVGA3D_A2R10G10B10= 26,
+   SVGA3D_A2R10G10B10  = 26,

/* signed formats */
-   SVGA3D_V8U8   = 27,
-   SVGA3D_Q8W8V8U8   = 28,
-   SVGA3D_CxV8U8 = 29,
+   SVGA3D_V8U8 = 27,
+   SVGA3D_Q8W8V8U8 = 28,
+   SVGA3D_CxV8U8   = 29,

/* mixed formats */
-   SVGA3D_X8L8V8U8   = 30,
-   SVGA3D_A2W10V10U10= 31,
+   SVGA3D_X8L8V8U8 = 30,
+   SVGA3D_A2W10V10U10  = 31,

-   SVGA3D_ALPHA8 = 32,
+   SVGA3D_ALPHA8   = 32,

/* Single- and dual-component floating point formats */
-   SVGA3D_R_S10E5= 33,
-   SVGA3D_R_S23E8= 34,
-   SVGA3D_RG_S10E5   = 35,
-   SVGA3D_RG_S23E8   = 36,
+   SVGA3D_R_S10E5  = 33,
+   SVGA3D_R_S23E8  = 34,
+   SVGA3D_RG_S10E5 = 35,
+   SVGA3D_RG_S23E8 = 36,

/*
 * Any surface can be used as a buffer object, but SVGA3D_BUFFER is
 * the most efficient format to use when creating new surfaces
 * expressly for index or vertex data.
 */
-   SVGA3D_BUFFER = 37,

-   SVGA3D_Z_D24X8= 38,
+   SVGA3D_BUFFER   = 37,
+
+   SVGA3D_Z_D24X8   

[PATCH 01/26] ttm: export ttm_bo_create

[Thomas Hellstrom]

Used by the vmwgfx driver.

Signed-off-by: Thomas Hellstrom 
---
 drivers/gpu/drm/ttm/ttm_bo.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index b824d9b..6e96c85 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1295,6 +1295,7 @@ int ttm_bo_create(struct ttm_bo_device *bdev,

return ret;
 }
+EXPORT_SYMBOL(ttm_bo_create);

 static int ttm_bo_force_list_clean(struct ttm_bo_device *bdev,
unsigned mem_type, bool allow_errors)
-- 
1.7.4.4

[PATCH -next 00/26] vmwgfx updates v2.

[Thomas Hellstrom]

A series of updates to
*) Deal with new device features like screen objects.
*) Handle query buffer object pinning correctly.
*) Make hardware surfaces swappable.

v2:
Rebased on Dave's freedesktop.org "linux" repo.
Incorporating Konrad's feedback in patches 05 and 06 and as an
additional cleanup patch (26)

KMS and TTM questions

[James Simmons]

> There is a fully functional unichrome DRM on top of TTM, that together with
> the 3D driver in mesa's openchrome branch worked like a charm (even
> outperformed Intel's i965 with identical CPU at the time).
> Problem was that it was not backwards compatible with via's old drm.
> 
> It should serve as a good starting point though, if I can remember where I put
> it

I have a copy of your work already and yes I had to foward port it since 
the TTM api changed quite a bit from when you wrote that code.

[PATCH v6] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

[Inki Dae]

This patch is a DRM Driver for Samsung SoC Exynos4210 and now enables
only FIMD yet but we will add HDMI support also in the future.

this patch is based on git repository below:
git://people.freedesktop.org/~airlied/linux.git
branch name: drm-next
commit-id: 88ef4e3f4f616462b78a7838eb3ffc3818d30f67

you can refer to our working repository below:
http://git.infradead.org/users/kmpark/linux-2.6-samsung
branch name: samsung-drm

We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c
based on Linux framebuffer) but couldn't so because lowlevel codes
of s3c-fb.c are included internally and so FIMD module of this driver has
its own lowlevel codes.

We used GEM framework for buffer management and DMA APIs(dma_alloc_*)
for buffer allocation so we can allocate physically continuous memory
for DMA through it and also we could use CMA later if CMA is applied to
mainline.

Refer to this link for CMA(Continuous Memory Allocator):
http://lkml.org/lkml/2011/7/20/45

this driver supports only physically continuous memory(non-iommu).

Links to previous versions of the patchset:
v1: < https://lwn.net/Articles/454380/ >
v2: < http://www.spinics.net/lists/kernel/msg1224275.html >
v3: < http://www.spinics.net/lists/dri-devel/msg13755.html >
v4: < http://permalink.gmane.org/gmane.comp.video.dri.devel/60439 >
v5: < http://comments.gmane.org/gmane.comp.video.dri.devel/60802 >

Changelog v2:
DRM: add DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl command.

this feature maps user address space to physical memory region
once user application requests DRM_IOCTL_SAMSUNG_GEM_MMAP ioctl.

DRM: code clean and add exception codes.

Changelog v3:
DRM: Support multiple irq.

FIMD and HDMI have their own irq handler but DRM Framework can regiter
only one irq handler this patch supports mutiple irq for Samsung SoC.

DRM: Consider modularization.

each DRM, FIMD could be built as a module.

DRM: Have indenpendent crtc object.

crtc isn't specific to SoC Platform so this patch gets a crtc
to be used as common object.
created crtc could be attached to any encoder object.

DRM: code clean and add exception codes.

Changelog v4:
DRM: remove is_defult from samsung_fb.

is_default isn't used for default framebuffer.

DRM: code refactoring to fimd module.
this patch is be considered with multiple display objects and
would use its own request_irq() to register a irq handler instead of
drm framework's one.

DRM: remove find_samsung_drm_gem_object()

DRM: move kernel private data structures and definitions to driver folder.

samsung_drm.h would contain only public information for userspace
ioctl interface.

DRM: code refactoring to gem modules.
buffer module isn't dependent of gem module anymore.

DRM: fixed security issue.

DRM: remove encoder porinter from specific connector.

samsung connector doesn't need to have generic encoder.

DRM: code clean and add exception codes.

Changelog v5:
DRM: updated fimd(display controller) driver.
added various pixel formats, color key and pixel blending features.

DRM: removed end_buf_off from samsung_drm_overlay structure.
this variable isn't used and end buffer address would be
calculated by each sub driver.

DRM: use generic function for mmap_offset.
replaced samsung_drm_gem_create_mmap_offset() and
samsung_drm_free_mmap_offset() with generic ones applied
to mainline recentrly.

DRM: removed unnecessary codes and added exception codes.

DRM: added comments and code clean.

Changelog v6:
DRM: added default config options.

DRM: added padding for 64-bit align.

DRM: changed prefix 'samsung' to 'exynos'

Signed-off-by: Inki Dae 
Signed-off-by: Joonyoung Shim 
Signed-off-by: Seung-Woo Kim 
Signed-off-by: kyungmin.park 
Reviewed-by: Konrad Rzeszutek Wilk 
---
 drivers/gpu/drm/Kconfig   |2 +
 drivers/gpu/drm/Makefile  |1 +
 drivers/gpu/drm/exynos/Kconfig|   20 +
 drivers/gpu/drm/exynos/Makefile   |   11 +
 drivers/gpu/drm/exynos/exynos_drm_buf.c   |  110 
 drivers/gpu/drm/exynos/exynos_drm_buf.h   |   50 ++
 drivers/gpu/drm/exynos/exynos_drm_connector.c |  293 +
 drivers/gpu/drm/exynos/exynos_drm_connector.h |   34 +
 drivers/gpu/drm/exynos/exynos_drm_core.c  |  272 +
 drivers/gpu/drm/exynos/exynos_drm_crtc.c  |  344 +++
 drivers/gpu/drm/exynos/exynos_drm_crtc.h  |   39 ++
 drivers/gpu/drm/exynos/exynos_drm_drv.c   |  230 +++
 drivers/gpu/drm/exynos/exynos_drm_drv.h   |  242 
 drivers/gpu/drm/exynos/exynos_drm_encoder.c   |  271 +
 drivers/gpu/drm/exynos/exynos_drm_encoder.h   |   45 ++
 drivers/gpu/drm/exynos/exynos_drm_fb.c|  271 +
 drivers/gpu/drm/exynos/exynos_drm_fb.h|   47 ++
 drivers/gpu/drm/exynos/exynos_drm_fbdev.c |  441 ++
 drivers/gpu/drm/exynos/exynos_drm_fbdev.h |   37 ++
 drivers/gpu/drm/exynos/exynos_drm_fimd.c  |  796 

[PATCH] drm/radeon/kms: fix dp_detect handling for DP bridge chips

[Michel Dänzer]

On Die, 2011-10-04 at 12:23 -0400, alexdeucher at gmail.com wrote: 
> From: Alex Deucher 
> 
> The HPD pin is not reliable for detecting whether a monitor
> is connected or not.  Skip HPD and just use DDC or load
> detection.
> 
> Fixes phantom VGA connected bugs.
> 
> Signed-off-by: Alex Deucher 

Just verified that it no longer incorrectly detects VGA as connected on
my Llano board.

Reviewed-by: Michel D?nzer 
Tested-by: Michel D?nzer 


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

KMS and TTM questions

[Thomas Hellstrom]

On 10/03/2011 09:14 PM, Alan Cox wrote:
>> the front buffer. The problem was the buffer offset for the second
>> allocation was the same as the VQ buffer. I'm stump to what I'm doing
>> wrong, so does anyone have a idea?
>>  
> I gave up trying to understand TTM (they don't make happy pills that big)
> and used GEM and a simple allocator. The private allocator GEM change
> means you can now use GEM to magic up objects that are in on card or
> stolen memory where applicable not just backed in system memory.
>

IMHO people making that comment just don't understand the problems TTM 
is trying to solve, but it usually dawns on them when they have worked 
on their own specialized solution for a year or so...

/Thomas

KMS and TTM questions

[Thomas Hellstrom]

On 10/04/2011 01:07 AM, Alan Cox wrote:
>> Thats fine as long as you don't want to do acceleration or object
>> migration between GTT
>> and VRAM type memory. Now I expect when you give out this advice you
>>  
> Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
> It's all effectively in the GART with the 'stolen' pages preloaded into
> the translation tables by the BIOS at vga init time.
>

VRAM memory (at least on the older unichromes) is taken from on-board 
RAM and set up by the BIOS, and from a device programmer's point of view 
works like a discrete card VRAM, and is *not* part of the GART.

On some devices (K8M800) , the VRAM pages could be accessed by the CPU 
directly at the top of VRAM, which was substantially faster.

There is a fully functional unichrome DRM on top of TTM, that together 
with the 3D driver in mesa's openchrome branch worked like a charm (even 
outperformed Intel's i965 with identical CPU at the time).
Problem was that it was not backwards compatible with via's old drm.

It should serve as a good starting point though, if I can remember where 
I put it

/Thomas

[Bug 41467] No display with switcheroo

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41467

--- Comment #6 from Michael Lothian  2011-10-04 
18:33:20 PDT ---
How do I use the Intel graphics as default?

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[git pull] drm fixes

[Dave Airlie]

Hi Linus,

all radeon fixes, one nasty startup crash and/or memory corruption on one 
family of radeon hd6450s resulted in a patch to stop setting a bunch of 
regs in the drivers and let the BIOS set them correctly, displayport 
regression fix, and some off-by-one in the cursor code around the corners 
of the screens.

its a bit bigger than I'd like but the register setting removal had to 
remove the unused functions.

Dave.

The following changes since commit 9b13776977d45505469edc6decc93e9e3799afe2:

  Merge branch 'for-linus' of git://git.infradead.org/users/sameo/mfd-2.6 
(2011-10-02 19:23:44 -0700)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux.git drm-fixes

Alex Deucher (4):
  drm/radeon/kms: fix regression in DP aux defer handling
  drm/radeon/kms: add retry limits for native DP aux defer
  drm/radeon/kms: Fix logic error in DP HPD handler
  drm/radeon/kms: fix channel_remap setup (v2)

Michel D?nzer (3):
  drm/radeon: Simplify cursor x/yorigin calculation.
  drm/radeon: Update AVIVO cursor coordinate origin before x/yorigin 
calculation.
  drm/radeon: Set cursor x/y to 0 when x/yorigin > 0.

Nicholas Miell (1):
  drm/radeon/kms: fix cursor image off-by-one error

 drivers/gpu/drm/radeon/atombios_dp.c   |   16 +---
 drivers/gpu/drm/radeon/evergreen.c |   44 
 drivers/gpu/drm/radeon/ni.c|   32 -
 drivers/gpu/drm/radeon/radeon_connectors.c |8 ++--
 drivers/gpu/drm/radeon/radeon_cursor.c |   40 ++---
 drivers/gpu/drm/radeon/rv770.c |   51 
 6 files changed, 33 insertions(+), 158 deletions(-)

[PATCH] drm/radeon/kms: retry aux transactions if there are status flags

[alexdeuc...@gmail.com]

From: Alex Deucher 

If there are error flags in the aux status, retry the transaction.
This makes aux much more reliable, especially on llano systems.

Signed-off-by: Alex Deucher 
Cc: stable at kernel.org
---
 drivers/gpu/drm/radeon/atombios_dp.c |   12 +---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/atombios_dp.c 
b/drivers/gpu/drm/radeon/atombios_dp.c
index 4da2388..79e8ebc 100644
--- a/drivers/gpu/drm/radeon/atombios_dp.c
+++ b/drivers/gpu/drm/radeon/atombios_dp.c
@@ -129,7 +129,9 @@ static int radeon_dp_aux_native_write(struct 
radeon_connector *radeon_connector,
for (retry = 0; retry < 4; retry++) {
ret = radeon_process_aux_ch(dig_connector->dp_i2c_bus,
msg, msg_bytes, NULL, 0, delay, 
);
-   if (ret < 0)
+   if (ret == -EBUSY)
+   continue;
+   else if (ret < 0)
return ret;
if ((ack & AUX_NATIVE_REPLY_MASK) == AUX_NATIVE_REPLY_ACK)
return send_bytes;
@@ -160,7 +162,9 @@ static int radeon_dp_aux_native_read(struct 
radeon_connector *radeon_connector,
for (retry = 0; retry < 4; retry++) {
ret = radeon_process_aux_ch(dig_connector->dp_i2c_bus,
msg, msg_bytes, recv, recv_bytes, 
delay, );
-   if (ret < 0)
+   if (ret == -EBUSY)
+   continue;
+   else if (ret < 0)
return ret;
if ((ack & AUX_NATIVE_REPLY_MASK) == AUX_NATIVE_REPLY_ACK)
return ret;
@@ -236,7 +240,9 @@ int radeon_dp_i2c_aux_ch(struct i2c_adapter *adapter, int 
mode,
for (retry = 0; retry < 4; retry++) {
ret = radeon_process_aux_ch(auxch,
msg, msg_bytes, reply, reply_bytes, 
0, );
-   if (ret < 0) {
+   if (ret == -EBUSY)
+   continue;
+   else if (ret < 0) {
DRM_DEBUG_KMS("aux_ch failed %d\n", ret);
return ret;
}
-- 
1.7.1.1

[PATCH] drm/radeon/kms: fix channel_remap setup (v2)

[Michel Dänzer]

On Die, 2011-10-04 at 10:46 -0400, alexdeucher at gmail.com wrote: 
> From: Alex Deucher 
> 
> Most asics just use the hw default value which requires
> no explicit programming.  For those that need a different
> value, the vbios will program it properly.  As such,
> there's no need to program these registers explicitly
> in the driver.  Changing MC_SHARED_CHREMAP requires a reload
> of all data in vram otherwise its contents will be scambled.
> 
> Fixes:
> https://bugs.freedesktop.org/show_bug.cgi?id=40103
> 
> v2: drop now unused channel_remap functions.
> 
> Signed-off-by: Alex Deucher 

Reviewed-by: Michel D?nzer 


-- 
Earthling Michel D?nzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer

[Bug 41467] No display with switcheroo

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41467

--- Comment #5 from Alex Deucher  2011-10-04 17:01:26 PDT 
---
You have a muxless laptop which means the discrete card is not connected to any
displays.  You won't be able to use the discrete card until the xserver gets
the ability to decouple rendering and display (i.e., rendering with one GPU,
displaying with another).  It's a huge amount of work and won't be supported
any time some.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41467] No display with switcheroo

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41467

Alex Deucher  changed:

   What|Removed |Added

  Attachment #51985|text/x-log  |text/plain
  mime type||
  Attachment #51985|0   |1
   is patch||

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41467] No display with switcheroo

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41467

--- Comment #4 from Michael Lothian  2011-10-04 
16:49:18 PDT ---
I should probably mention that I'm running git master from Linus' tree last
updated 6 hours ago with your fixes (I've tried with and without those fixes)

Unfortunately as this is a new laptop I don't know if this is a regression or
not

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41467] No display with switcheroo

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41467

--- Comment #3 from Michael Lothian  2011-10-04 
16:47:35 PDT ---
Created an attachment (id=51987)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=51987)
xorg.log.0 Radeon

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41467] No display with switcheroo

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41467

--- Comment #2 from Michael Lothian  2011-10-04 
16:47:03 PDT ---
Created an attachment (id=51986)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=51986)
xorg.log.0 Intel

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41467] No display with switcheroo

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41467

--- Comment #1 from Michael Lothian  2011-10-04 
16:46:27 PDT ---
Created an attachment (id=51985)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=51985)
dmesg

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41467] New: No display with switcheroo

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41467

   Summary: No display with switcheroo
   Product: DRI
   Version: XOrg CVS
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: critical
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: mike at fireburn.co.uk


Created an attachment (id=51984)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=51984)
lspci -nn

Hi

I've gotten a new laptop - HP Envy 14 2002ea

I've configured my kernel for the Intel and Radeon graphics and enabled the
switcheroo option too

When booting the kms screen with Tux at the top shows for a split second before
going blank - fortunately I can SSH in - also nomodeset works

I'm going to attach the lspci, dmesg and xorg.log for both set as the default

I've also changed the bios setting between Dynamic and Fixed but it's made no
difference

If you need any more information please let me know

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

KMS and TTM questions

[James Simmons]

> >> Without code to look at we all can start guessing :) my guess is either
> >> you are not using the proper offset field or you are allocating from
> >> different memory pool.
> >
> > http://cgit.freedesktop.org/~jsimmons/drm-openchrome
> >
> 
> >From quick glimpse ttm_bo_allocate in via/init_ttm.c loose the
> TTM_PL_FLAG_NO_EVICT so you vq buffer is not allocated with the no
> evict flags, then i guess it got evicted on first bo allocation which
> is strange, maybe first bo has some lpfn constraint.

Tried it and it didn't help. Its the ttm_buffer_object offset that should
vary for each buffer object created from some memory pool. That 
offset is set from bo->mem.mm_node if it is present. Looking at the 
code ttm_bo_init should end up calling ttm_bo_move_buffer which should in 
turn set up the bo->mem.mm_node. I guess I really need to debug the code 
to see what is going on.

[PATCH] [rfc] drm: add some caps for userspace to discover more info for dumb KMS driver

[James Simmons]

> From: Dave Airlie 
> 
> For the simple KMS driver case we need some more info about argb cursor
> limits and a preferred depth and if shadowed framebuffer access is preferred.
> 
> I've only added this for intel/radeon which support the dumb ioctls so far.
> 
> I really don't want to expose a truck load of info, just enough for X to
> start without configuration with a hw cursor.
> 
> If you need something really fancy you should be writing a real X.org driver.
> ---
>  drivers/gpu/drm/drm_ioctl.c |   12 
>  drivers/gpu/drm/i915/intel_display.c|5 +
>  drivers/gpu/drm/radeon/radeon_display.c |5 +
>  include/drm/drm.h   |4 
>  include/drm/drm_crtc.h  |4 
>  5 files changed, 30 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 904d7e9..37d2ce7 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -283,6 +283,18 @@ int drm_getcap(struct drm_device *dev, void *data, 
> struct drm_file *file_priv)
>   case DRM_CAP_VBLANK_HIGH_CRTC:
>   req->value = 1;
>   break;
> + case DRM_CAP_DUMB_ARGB_CURSOR_WIDTH:
> + req->value = dev->mode_config.max_cursor_width;
> + break;
> + case DRM_CAP_DUMB_ARGB_CURSOR_HEIGHT:
> + req->value = dev->mode_config.max_cursor_height;
> + break;
> + case DRM_CAP_DUMB_PREFERRED_DEPTH:
> + req->value = dev->mode_config.preferred_depth;
> + break;
> + case DRM_CAP_DUMB_PREFER_SHADOW:
> + req->value = dev->mode_config.prefer_shadow;
> + break;
>   default:
>   return -EINVAL;
>   }

Could it be possible to make it a per drm_crtc. I have run into the 
issue of the case of a system with 2 CRTC but the hardware cursor is 
supported on only one CRTC. The other is that the cursor dimensions might 
actually vary on each CRTC.

KMS and TTM questions

[James Simmons]

> On Mon, Oct 3, 2011 at 8:14 PM, Alan Cox  wrote:
> >> the front buffer. The problem was the buffer offset for the second
> >> allocation was the same as the VQ buffer. I'm stump to what I'm doing
> >> wrong, so does anyone have a idea?
> >
> > I gave up trying to understand TTM (they don't make happy pills that big)
> > and used GEM and a simple allocator. The private allocator GEM change
> > means you can now use GEM to magic up objects that are in on card or
> > stolen memory where applicable not just backed in system memory.

I did both as I like my cake and to eat it too :-)

> Thats fine as long as you don't want to do acceleration or object
> migration between GTT
> and VRAM type memory. Now I expect when you give out this advice you
> should also state the limitations your advice leads to.

The accelerated moves is what made me implement an TTM layer. I 
wanted to try out using ttm_bo_move for the fbcon copyarea and 
imageblit functions as a experiment. Also in the future I like
totry out tiling support for fbcon with my dri driver. Yes fbcon 
supports tiles. All thats down the road. For now I just need to get a 
working driver.

KMS and TTM questions

[James Simmons]

> >> > Thats fine as long as you don't want to do acceleration or object
> >> > migration between GTT
> >> > and VRAM type memory. Now I expect when you give out this advice you
> >>
> >> Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
> >> It's all effectively in the GART with the 'stolen' pages preloaded into
> >> the translation tables by the BIOS at vga init time.
> >>
> >> It has fake VRAM type memory but thats really an illusion (although one
> >> the driver seems to like to keep up). The GEM changes do mean you can
> >> plug the existing allocator in the VIA driver into GEM directly. Whether
> >> that would be a good idea or not given the other things you then need to
> >> do I don't know - but it does seem to be me to be a stepping stone in the
> >> right direction that is much easier to make ?
> >
> > That is correct. In fact the via driver detects what type of system ram is
> > used so I can limit what resolutions are supported. Its possible that the
> > memory doesn't have the bandwidth to support a very large resolution on
> > older systems.
> 
> Is vram actually handled via a scatter/gather page table or is it just
> a pointer to a contiguous chunk of stolen system memory at the top of
> ram?

Stolen chuck. At the same time newer chipsets, VX900, have pcie gart 
table to move data to and from the "vram". 

KMS and TTM questions

[James Simmons]

> > Second question I have is how are monochrome cursor images
> > handled with KMS. Yes we need to support CLE266 which is used in a lot
> 
> That depends on your libkms for the device. You can allocate a one bit
> deep object if you want. Reading libkms source is probably what you need
> if you've not already done os.

No special libkms for our hardware. Currently the via driver implements 
dumb buffers so I can work with the generic libkms library. Once tile 
support is implemented then a special buffer manager will need to be 
implemented.

KMS and TTM questions

[James Simmons]

> > ? ? ? ?Second question I have is how are monochrome cursor images
> > handled with KMS. Yes we need to support CLE266 which is used in a lot
> > of POS devices. That chipset only supports monochrome cursors.
> 
> As far as I know, the KMS cursor API doesn't really care what type of
> cursors are supported.  That's a client driver (ddx, etc.)
> implementation detail.  The cursor interface just basically has on,
> off, and position. The client driver (ddx, etc.) can choose to upload
> a ARGB or mono image.  We should probably add some sort of flag to KMS
> to ask the driver what types of cursors they support so this could be
> supported in a generic way.

That is the bit missing. I seen recently you had a patch for passing info 
to userland. It would be nice to add what color depths the cursor 
supports.

KMS and TTM questions

[James Simmons]

> > Thats fine as long as you don't want to do acceleration or object
> > migration between GTT
> > and VRAM type memory. Now I expect when you give out this advice you
> 
> Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
> It's all effectively in the GART with the 'stolen' pages preloaded into
> the translation tables by the BIOS at vga init time.
> 
> It has fake VRAM type memory but thats really an illusion (although one
> the driver seems to like to keep up). The GEM changes do mean you can
> plug the existing allocator in the VIA driver into GEM directly. Whether
> that would be a good idea or not given the other things you then need to
> do I don't know - but it does seem to be me to be a stepping stone in the
> right direction that is much easier to make ?

That is correct. In fact the via driver detects what type of system ram is 
used so I can limit what resolutions are supported. Its possible that the 
memory doesn't have the bandwidth to support a very large resolution on 
older systems.

[PATCH 1/2] drm/ttm: add a way to bo_wait for either the last read or last write

[Thomas Hellstrom]

On 08/07/2011 10:39 PM, Marek Ol??k wrote:
> Sometimes we want to know whether a buffer is busy and wait for it (bo_wait).
> However, sometimes it would be more useful to be able to query whether
> a buffer is busy and being either read or written, and wait until it's stopped
> being either read or written. The point of this is to be able to avoid
> unnecessary waiting, e.g. if a GPU has written something to a buffer and is 
> now
> reading that buffer, and a CPU wants to map that buffer for read, it needs to
> only wait for the last write. If there were no write, there wouldn't be any
> waiting needed.
>
> This, or course, requires user space drivers to send read/write flags
> with each relocation (like we have read/write domains in radeon, so we can
> actually use those for something useful now).
>
> Now how this patch works:
>
> The read/write flags should passed to ttm_validate_buffer. TTM maintains
> separate sync objects of the last read and write for each buffer, in addition
> to the sync object of the last use of a buffer. ttm_bo_wait then operates
> with one the sync objects.
>
> Signed-off-by: Marek Ol??k
>

Bah, I totally missed this patch and thus never reviewed it :( Probably 
on vacation.

There are a couple of things I'd like to point out.

1) The bo subsystem may never assume that fence objects are ordered, so 
that when we unref
bo::sync_obj, we may never assume that previously attached fence objects 
are signaled and can be unref'd
Think for example fence objects submitted to different command streams. 
This is a bug and must be fixed.
We can detach fence objects from buffers in the driver validation code, 
because that code knows whether fences are implicitly ordered, or can 
order them either by inserting a barrier (semaphore in NV languange) or 
waiting for the fence to expire. (For example if the new validation is 
READ and the fence currently attached is WRITE, we might need to 
schedule a gpu cache flush before detaching the write fence).

2) Can't we say that a write_sync_obj is simply a sync_obj? What's the 
difference between those two? I think we should remove the 
write_sync_obj bo member.

3) Ideally we should have a linked list of read sync objects, with their 
own sync_obj_arg, but since there apparently aren't any consumers yet, 
we could wait with that.

/Thomas

[git pull] drm fixes

[Alex Deucher]

On Tue, Oct 4, 2011 at 12:58 PM, Linus Torvalds
 wrote:
> On Tue, Oct 4, 2011 at 9:34 AM, Dave Airlie  wrote:
>>
>> all radeon fixes, one nasty startup crash and/or memory corruption on one
>> family of radeon hd6450s resulted in a patch to stop setting a bunch of
>> regs in the drivers and let the BIOS set them correctly, displayport
>> regression fix, and some off-by-one in the cursor code around the corners
>> of the screens.
>
> Has this been tested with suspend/resume on a lot of machines?
>
> In general, the registers that get set on boot correctly absolutely do
> *not* get set on resume.
>
> So the registers that you now no longer set at boot-time should almost
> certainly still be saved and restored across suspend/resume. I don't
> know the code well enough to read the diffs, but a quick grep seems to
> show that when you removed the boot-time setup, you also removed the
> resume-time setup (well, at least MC_SHARED_CHREMAP doesn't seem to be
> used anywhere any more: it may be that it's saved-restores in some
> kind of "loop over all registers" that wouldn't have triggered the
> grep).
>
> I pulled, but please verify that whole thing.

It's safe.  The hw default value is fine (value in the register at
asic power up).  On most cards the hw default value is is fine.  If it
needs to be overridden in certain cases, that's handled by the
asic_init vbios table which is executed at boot by the vbios and by
the driver at resume time.

Alex

[PATCH] drm/radeon/kms: fix dp_detect handling for DP bridge chips

[alexdeuc...@gmail.com]

From: Alex Deucher 

The HPD pin is not reliable for detecting whether a monitor
is connected or not.  Skip HPD and just use DDC or load
detection.

Fixes phantom VGA connected bugs.

Signed-off-by: Alex Deucher 
Cc: stable at kernel.org
---
 drivers/gpu/drm/radeon/radeon_connectors.c |   21 ++---
 1 files changed, 6 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c 
b/drivers/gpu/drm/radeon/radeon_connectors.c
index bce63fd..449c3d8 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -1303,23 +1303,14 @@ radeon_dp_detect(struct drm_connector *connector, bool 
force)
/* get the DPCD from the bridge */
radeon_dp_getdpcd(radeon_connector);

-   if (radeon_hpd_sense(rdev, radeon_connector->hpd.hpd))
-   ret = connector_status_connected;
-   else {
-   /* need to setup ddc on the bridge */
-   if (encoder)
-   radeon_atom_ext_encoder_setup_ddc(encoder);
+   if (encoder) {
+   /* setup ddc on the bridge */
+   radeon_atom_ext_encoder_setup_ddc(encoder);
if (radeon_ddc_probe(radeon_connector,
-
radeon_connector->requires_extended_probe))
+
radeon_connector->requires_extended_probe)) /* try DDC */
ret = connector_status_connected;
-   }
-
-   if ((ret == connector_status_disconnected) &&
-   radeon_connector->dac_load_detect) {
-   struct drm_encoder *encoder = 
radeon_best_single_encoder(connector);
-   struct drm_encoder_helper_funcs *encoder_funcs;
-   if (encoder) {
-   encoder_funcs = encoder->helper_private;
+   else if (radeon_connector->dac_load_detect) { /* try 
load detection */
+   struct drm_encoder_helper_funcs *encoder_funcs 
= encoder->helper_private;
ret = encoder_funcs->detect(encoder, connector);
}
}
-- 
1.7.1.1

[PATCH] drm/radeon/kms: fix channel_remap setup (v2)

[alexdeuc...@gmail.com]

From: Alex Deucher 

Most asics just use the hw default value which requires
no explicit programming.  For those that need a different
value, the vbios will program it properly.  As such,
there's no need to program these registers explicitly
in the driver.  Changing MC_SHARED_CHREMAP requires a reload
of all data in vram otherwise its contents will be scambled.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=40103

v2: drop now unused channel_remap functions.

Signed-off-by: Alex Deucher 
Cc: stable at kernel.org
---
 drivers/gpu/drm/radeon/evergreen.c |   44 ---
 drivers/gpu/drm/radeon/ni.c|   32 --
 drivers/gpu/drm/radeon/rv770.c |   51 
 3 files changed, 0 insertions(+), 127 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index e8a7467..c4ffa14 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -1590,48 +1590,6 @@ static u32 evergreen_get_tile_pipe_to_backend_map(struct 
radeon_device *rdev,
return backend_map;
 }

-static void evergreen_program_channel_remap(struct radeon_device *rdev)
-{
-   u32 tcp_chan_steer_lo, tcp_chan_steer_hi, mc_shared_chremap, tmp;
-
-   tmp = RREG32(MC_SHARED_CHMAP);
-   switch ((tmp & NOOFCHAN_MASK) >> NOOFCHAN_SHIFT) {
-   case 0:
-   case 1:
-   case 2:
-   case 3:
-   default:
-   /* default mapping */
-   mc_shared_chremap = 0x00fac688;
-   break;
-   }
-
-   switch (rdev->family) {
-   case CHIP_HEMLOCK:
-   case CHIP_CYPRESS:
-   case CHIP_BARTS:
-   tcp_chan_steer_lo = 0x54763210;
-   tcp_chan_steer_hi = 0xba98;
-   break;
-   case CHIP_JUNIPER:
-   case CHIP_REDWOOD:
-   case CHIP_CEDAR:
-   case CHIP_PALM:
-   case CHIP_SUMO:
-   case CHIP_SUMO2:
-   case CHIP_TURKS:
-   case CHIP_CAICOS:
-   default:
-   tcp_chan_steer_lo = 0x76543210;
-   tcp_chan_steer_hi = 0xba98;
-   break;
-   }
-
-   WREG32(TCP_CHAN_STEER_LO, tcp_chan_steer_lo);
-   WREG32(TCP_CHAN_STEER_HI, tcp_chan_steer_hi);
-   WREG32(MC_SHARED_CHREMAP, mc_shared_chremap);
-}
-
 static void evergreen_gpu_init(struct radeon_device *rdev)
 {
u32 cc_rb_backend_disable = 0;
@@ -2078,8 +2036,6 @@ static void evergreen_gpu_init(struct radeon_device *rdev)
WREG32(DMIF_ADDR_CONFIG, gb_addr_config);
WREG32(HDP_ADDR_CONFIG, gb_addr_config);

-   evergreen_program_channel_remap(rdev);
-
num_shader_engines = ((RREG32(GB_ADDR_CONFIG) & NUM_SHADER_ENGINES(3)) 
>> 12) + 1;
grbm_gfx_index = INSTANCE_BROADCAST_WRITES;

diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 99fbd79..8c79ca9 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -569,36 +569,6 @@ static u32 cayman_get_tile_pipe_to_backend_map(struct 
radeon_device *rdev,
return backend_map;
 }

-static void cayman_program_channel_remap(struct radeon_device *rdev)
-{
-   u32 tcp_chan_steer_lo, tcp_chan_steer_hi, mc_shared_chremap, tmp;
-
-   tmp = RREG32(MC_SHARED_CHMAP);
-   switch ((tmp & NOOFCHAN_MASK) >> NOOFCHAN_SHIFT) {
-   case 0:
-   case 1:
-   case 2:
-   case 3:
-   default:
-   /* default mapping */
-   mc_shared_chremap = 0x00fac688;
-   break;
-   }
-
-   switch (rdev->family) {
-   case CHIP_CAYMAN:
-   default:
-   //tcp_chan_steer_lo = 0x54763210
-   tcp_chan_steer_lo = 0x76543210;
-   tcp_chan_steer_hi = 0xba98;
-   break;
-   }
-
-   WREG32(TCP_CHAN_STEER_LO, tcp_chan_steer_lo);
-   WREG32(TCP_CHAN_STEER_HI, tcp_chan_steer_hi);
-   WREG32(MC_SHARED_CHREMAP, mc_shared_chremap);
-}
-
 static u32 cayman_get_disable_mask_per_asic(struct radeon_device *rdev,
u32 disable_mask_per_se,
u32 max_disable_mask_per_se,
@@ -842,8 +812,6 @@ static void cayman_gpu_init(struct radeon_device *rdev)
WREG32(DMIF_ADDR_CONFIG, gb_addr_config);
WREG32(HDP_ADDR_CONFIG, gb_addr_config);

-   cayman_program_channel_remap(rdev);
-
/* primary versions */
WREG32(CC_RB_BACKEND_DISABLE, cc_rb_backend_disable);
WREG32(CC_SYS_RB_BACKEND_DISABLE, cc_rb_backend_disable);
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 4720d00..b13c2ee 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -536,55 +536,6 @@ static u32 r700_get_tile_pipe_to_backend_map(struct 
radeon_device *rdev,
return backend_map;
 }

-static void rv770_program_channel_remap(struct radeon_device *rdev)
-{
-   u32 

[Bug 41445] XBMC problem with playing the videos i915_dri.so

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41445

Ian Romanick  changed:

   What|Removed |Added

Product|DRI |Mesa
Version|unspecified |7.11
  Component|libGL   |Drivers/DRI/i915
 AssignedTo|dri-devel at lists.freedesktop |idr at freedesktop.org
   |.org|
 CC||eric at anholt.net

--- Comment #11 from Ian Romanick  2011-10-04 10:36:44 
PDT ---
(In reply to comment #10)
> Created an attachment (id=51931)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=51931)
> Xbmc_crashlog

Can you install a version of the driver that includes debug symbols?  The
backtrace only shows what's listed below, and that, unfortunately, doesn't tell
us anything.

#0  0x7f726ae3e2b9 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i915_dri.so
#1  0x7f726ad3876f in ?? () from /usr/lib/x86_64-linux-gnu/dri/i915_dri.so
#2  0x7f726ad2b5e9 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i915_dri.so
#3  0x7f726ac86057 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i915_dri.so
#4  0x7f726ad2bf8f in ?? () from /usr/lib/x86_64-linux-gnu/dri/i915_dri.so
#5  0x7f726ad2c646 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i915_dri.so
#6  0x7f726ad23918 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i915_dri.so
#7  0x7f726ad1b1ea in ?? () from /usr/lib/x86_64-linux-gnu/dri/i915_dri.so
#8  0x7f726ad1b3c0 in ?? () from /usr/lib/x86_64-linux-gnu/dri/i915_dri.so
#9  0x7f726ad1b83c in ?? () from /usr/lib/x86_64-linux-gnu/dri/i915_dri.so
#10 0x7f726ad1c05d in ?? () from /usr/lib/x86_64-linux-gnu/dri/i915_dri.so

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[git pull] drm fixes

[Linus Torvalds]

On Tue, Oct 4, 2011 at 9:34 AM, Dave Airlie  wrote:
>
> all radeon fixes, one nasty startup crash and/or memory corruption on one
> family of radeon hd6450s resulted in a patch to stop setting a bunch of
> regs in the drivers and let the BIOS set them correctly, displayport
> regression fix, and some off-by-one in the cursor code around the corners
> of the screens.

Has this been tested with suspend/resume on a lot of machines?

In general, the registers that get set on boot correctly absolutely do
*not* get set on resume.

So the registers that you now no longer set at boot-time should almost
certainly still be saved and restored across suspend/resume. I don't
know the code well enough to read the diffs, but a quick grep seems to
show that when you removed the boot-time setup, you also removed the
resume-time setup (well, at least MC_SHARED_CHREMAP doesn't seem to be
used anywhere any more: it may be that it's saved-restores in some
kind of "loop over all registers" that wouldn't have triggered the
grep).

I pulled, but please verify that whole thing.

  Linus

[PATCH] drm/radeon/kms: fix channel_remap setup

[alexdeuc...@gmail.com]

From: Alex Deucher 

Most asics just use the hw default value which requires
no explicit programming.  For those that need a different
value, the vbios will program it properly.  As such,
there's no need to program these registers explicitly
in the driver.  Changing these registers requires a reload
of all data in vram otherwise its contents will be scambled.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=40103

Signed-off-by: Alex Deucher 
Cc: stable at kernel.org
---
 drivers/gpu/drm/radeon/evergreen.c |3 ++-
 drivers/gpu/drm/radeon/ni.c|3 ++-
 drivers/gpu/drm/radeon/rv770.c |3 ++-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index e8a7467..276509d 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2078,7 +2078,8 @@ static void evergreen_gpu_init(struct radeon_device *rdev)
WREG32(DMIF_ADDR_CONFIG, gb_addr_config);
WREG32(HDP_ADDR_CONFIG, gb_addr_config);

-   evergreen_program_channel_remap(rdev);
+   /* Use the hw default or as set up by the vbios */
+   /* evergreen_program_channel_remap(rdev);*/

num_shader_engines = ((RREG32(GB_ADDR_CONFIG) & NUM_SHADER_ENGINES(3)) 
>> 12) + 1;
grbm_gfx_index = INSTANCE_BROADCAST_WRITES;
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 99fbd79..f15bf6b 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -842,7 +842,8 @@ static void cayman_gpu_init(struct radeon_device *rdev)
WREG32(DMIF_ADDR_CONFIG, gb_addr_config);
WREG32(HDP_ADDR_CONFIG, gb_addr_config);

-   cayman_program_channel_remap(rdev);
+   /* Use the hw default or as set up by the vbios */
+   /* cayman_program_channel_remap(rdev); */

/* primary versions */
WREG32(CC_RB_BACKEND_DISABLE, cc_rb_backend_disable);
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 4720d00..98e3b7e 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -785,7 +785,8 @@ static void rv770_gpu_init(struct radeon_device *rdev)
WREG32(DCP_TILING_CONFIG, (gb_tiling_config & 0x));
WREG32(HDP_TILING_CONFIG, (gb_tiling_config & 0x));

-   rv770_program_channel_remap(rdev);
+   /* Use the hw default or as set up by the vbios */
+   /* rv770_program_channel_remap(rdev); */

WREG32(CC_RB_BACKEND_DISABLE,  cc_rb_backend_disable);
WREG32(CC_GC_SHADER_PIPE_CONFIG,   cc_gc_shader_pipe_config);
-- 
1.7.1.1

KMS and TTM questions

[Alex Deucher]

On Tue, Oct 4, 2011 at 9:45 AM, James Simmons  wrote:
>
>> > ? ? ? ?Second question I have is how are monochrome cursor images
>> > handled with KMS. Yes we need to support CLE266 which is used in a lot
>> > of POS devices. That chipset only supports monochrome cursors.
>>
>> As far as I know, the KMS cursor API doesn't really care what type of
>> cursors are supported. ?That's a client driver (ddx, etc.)
>> implementation detail. ?The cursor interface just basically has on,
>> off, and position. The client driver (ddx, etc.) can choose to upload
>> a ARGB or mono image. ?We should probably add some sort of flag to KMS
>> to ask the driver what types of cursors they support so this could be
>> supported in a generic way.
>
> That is the bit missing. I seen recently you had a patch for passing info
> to userland. It would be nice to add what color depths the cursor
> supports.

I think Dave proposed something like that for the generic KMS ddx.

Alex

KMS and TTM questions

[Alex Deucher]

On Tue, Oct 4, 2011 at 9:42 AM, James Simmons  wrote:
>
>> > Thats fine as long as you don't want to do acceleration or object
>> > migration between GTT
>> > and VRAM type memory. Now I expect when you give out this advice you
>>
>> Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
>> It's all effectively in the GART with the 'stolen' pages preloaded into
>> the translation tables by the BIOS at vga init time.
>>
>> It has fake VRAM type memory but thats really an illusion (although one
>> the driver seems to like to keep up). The GEM changes do mean you can
>> plug the existing allocator in the VIA driver into GEM directly. Whether
>> that would be a good idea or not given the other things you then need to
>> do I don't know - but it does seem to be me to be a stepping stone in the
>> right direction that is much easier to make ?
>
> That is correct. In fact the via driver detects what type of system ram is
> used so I can limit what resolutions are supported. Its possible that the
> memory doesn't have the bandwidth to support a very large resolution on
> older systems.

Is vram actually handled via a scatter/gather page table or is it just
a pointer to a contiguous chunk of stolen system memory at the top of
ram?

Alex

[Bug 39897] Graphical glitches in some games on Evergreen

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39897

Michel D?nzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #26 from Michel D?nzer  2011-10-04 09:29:01 
PDT ---
(In reply to comment #24)
> R600_TILING=1 produces the rendering errors.
> Is it still worth a new bug report?

It's up to you, but it would basically be an enhancement request, as
R600_TILING is disabled by default.

This bug is very likely fixed upstream, resolving.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[PATCH v5] DRM: add DRM Driver for Samsung SoC EXYNOS4210.

[Inki Dae]

Hi, Konrad Rzeszutek Wilk.

> -Original Message-
> From: Konrad Rzeszutek Wilk [mailto:konrad.wilk at oracle.com]
> Sent: Tuesday, October 04, 2011 12:46 AM
> To: Inki Dae
> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
> kyungmin.park at samsung.com; sw0312.kim at samsung.com;
jy0922.shim at samsung.com;
> rob.clark at linaro.org
> Subject: Re: [PATCH v5] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
> 
> > diff --git a/drivers/gpu/drm/samsung/Kconfig
> b/drivers/gpu/drm/samsung/Kconfig
> > new file mode 100644
> > index 000..34cedda
> > --- /dev/null
> > +++ b/drivers/gpu/drm/samsung/Kconfig
> > @@ -0,0 +1,18 @@
> > +config DRM_SAMSUNG
> > +   tristate "DRM Support for Samsung SoC EXYNOS Series"
> > +   depends on DRM && PLAT_SAMSUNG
> 
> You should probably also have a default 'm' option?
> 

Yes, right. I will add a default 'm' or 'n' option. thank you.

> > +   select DRM_KMS_HELPER
> > +   select FB_CFB_FILLRECT
> > +   select FB_CFB_COPYAREA
> > +   select FB_CFB_IMAGEBLIT
> > +   select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
> > +   help
> > + Choose this option if you have a Samsung SoC EXYNOS chipset.
> > + If M is selected the module will be called samsungdrm.
> > +
> > +config DRM_SAMSUNG_FIMD
> > +   tristate "Samsung DRM FIMD"
> > +   depends on DRM_SAMSUNG
> > +   help
> > + Choose this option if you want to use Samsung FIMD for DRM.
> > + If M is selected, the module will be called samsung_drm_fimd
> 
> .. which is just nitpicking and optional so. I took a look at the code and
> you can stick 'Reviewed-by: Konrad Rzeszutek Wilk
> '
> if you want to.

Of course, we want :) I will add you as a reviewer. we will send V6 patch
soon. and thank you for your comments and advices again. 

[RESEND] An inquiry about DRM Driver for Samsung SoC Exynos4.

[Inki Dae]

Hi, Dave.

> -Original Message-
> From: Dave Airlie [mailto:airlied at gmail.com]
> Sent: Monday, October 03, 2011 7:17 PM
> To: Inki Dae
> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
> kyungmin.park at samsung.com
> Subject: Re: [RESEND] An inquiry about DRM Driver for Samsung SoC Exynos4.
> 
> >
> > We would look forward to your comments. thank you.
> 
> I think the only thing I can see wanting changing at this point is to
> add padding to the
> offset ioctl.
> 
> struct drm_samsung_gem_map_off {
> unsigned int handle;
> uint64_t offset;
> };
> 
> just add an unsigned int pad; between the two members so the 64-bit
> fields get natively aligned.
> 

Ok, get it. I will add the padding. thank you.

> >
> >> I still dislike the samsung_drm_ everywhere, just because no other
> >> driver does this, but if it helps with backtraces in the future maybe
> >> its okay.
> >>
> >
> > Ok, get it. we would consider using 'exynos' instead of 'samsung'
> seriously
> > if you don't want 'samsung' prefix and then with your comments, the
> change
> > would be done on PATCH v6.
> 
> Yeah I think it would be a good idea to just go with exynos, and then
> I'll merge V6 into -next.
> 
> Dave.

Ok, get it. I will send patch V6 soon. thank you for your review.

i915 kmemleak report

[Sitsofe Wheeler]

Hi,

I've been finding that kmemleak reports that i915 is leaking gem
buffers (although it takes about 20 minutes before the supposed leaks
occur).  The leaks normally occur in batches of 13 and seem to require
chrome to be running looking at a page like google.com while a
gnome-terminal is also present. It is important that the screensaver is
postponed using something like
watch "xdg-screensaver reset" .

A batch of the leaks are below:

unreferenced object 0xe9b1d640 (size 148):
  comm "Xorg", pid 1398, jiffies 4294740514 (age 4367.634s)
  hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[] kmemleak_alloc+0x27/0x50
[] kmem_cache_alloc+0xc5/0x180
[] idr_pre_get+0x54/0x80
[] drm_gem_handle_create+0x3c/0xd0
[] i915_gem_create+0x49/0xa0
[] i915_gem_create_ioctl+0x28/0x40
[] drm_ioctl+0x1d6/0x470
[] do_vfs_ioctl+0x7e/0x5a0
[] sys_ioctl+0x39/0x70
[] sysenter_do_call+0x12/0x36
[] 0x
unreferenced object 0xe9b1d780 (size 148):
  comm "Xorg", pid 1398, jiffies 4294740514 (age 4367.634s)
  hex dump (first 32 bytes):
00 00 00 00 40 d6 b1 e9 00 00 00 00 00 00 00 00   at ...
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[] kmemleak_alloc+0x27/0x50
[] kmem_cache_alloc+0xc5/0x180
[] idr_pre_get+0x54/0x80
[] drm_gem_handle_create+0x3c/0xd0
[] i915_gem_create+0x49/0xa0
[] i915_gem_create_ioctl+0x28/0x40
[] drm_ioctl+0x1d6/0x470
[] do_vfs_ioctl+0x7e/0x5a0
[] sys_ioctl+0x39/0x70
[] sysenter_do_call+0x12/0x36
[] 0x
unreferenced object 0xeb0db000 (size 148):
  comm "Xorg", pid 1398, jiffies 4294740514 (age 4367.634s)
  hex dump (first 32 bytes):
00 00 00 00 80 d7 b1 e9 00 00 00 00 00 00 00 00  
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[] kmemleak_alloc+0x27/0x50
[] kmem_cache_alloc+0xc5/0x180
[] idr_pre_get+0x54/0x80
[] drm_gem_handle_create+0x3c/0xd0
[] i915_gem_create+0x49/0xa0
[] i915_gem_create_ioctl+0x28/0x40
[] drm_ioctl+0x1d6/0x470
[] do_vfs_ioctl+0x7e/0x5a0
[] sys_ioctl+0x39/0x70
[] sysenter_do_call+0x12/0x36
[] 0x
unreferenced object 0xe3d37b40 (size 148):
  comm "Xorg", pid 1398, jiffies 4294740514 (age 4367.634s)
  hex dump (first 32 bytes):
00 00 00 00 00 b0 0d eb 00 00 00 00 00 00 00 00  
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[] kmemleak_alloc+0x27/0x50
[] kmem_cache_alloc+0xc5/0x180
[] idr_pre_get+0x54/0x80
[] drm_gem_handle_create+0x3c/0xd0
[] i915_gem_create+0x49/0xa0
[] i915_gem_create_ioctl+0x28/0x40
[] drm_ioctl+0x1d6/0x470
[] do_vfs_ioctl+0x7e/0x5a0
[] sys_ioctl+0x39/0x70
[] sysenter_do_call+0x12/0x36
[] 0x
unreferenced object 0xe3d37780 (size 148):
  comm "Xorg", pid 1398, jiffies 4294740514 (age 4367.654s)
  hex dump (first 32 bytes):
00 00 00 00 40 7b d3 e3 00 00 00 00 00 00 00 00  @{..
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[] kmemleak_alloc+0x27/0x50
[] kmem_cache_alloc+0xc5/0x180
[] idr_pre_get+0x54/0x80
[] drm_gem_handle_create+0x3c/0xd0
[] i915_gem_create+0x49/0xa0
[] i915_gem_create_ioctl+0x28/0x40
[] drm_ioctl+0x1d6/0x470
[] do_vfs_ioctl+0x7e/0x5a0
[] sys_ioctl+0x39/0x70
[] sysenter_do_call+0x12/0x36
[] 0x
unreferenced object 0xe3d373c0 (size 148):
  comm "Xorg", pid 1398, jiffies 4294740514 (age 4367.654s)
  hex dump (first 32 bytes):
00 00 00 00 80 77 d3 e3 00 00 00 00 00 00 00 00  .w..
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[] kmemleak_alloc+0x27/0x50
[] kmem_cache_alloc+0xc5/0x180
[] idr_pre_get+0x54/0x80
[] drm_gem_handle_create+0x3c/0xd0
[] i915_gem_create+0x49/0xa0
[] i915_gem_create_ioctl+0x28/0x40
[] drm_ioctl+0x1d6/0x470
[] do_vfs_ioctl+0x7e/0x5a0
[] sys_ioctl+0x39/0x70
[] sysenter_do_call+0x12/0x36
[] 0x
unreferenced object 0xe3d37640 (size 148):
  comm "Xorg", pid 1398, jiffies 4294740515 (age 4367.653s)
  hex dump (first 32 bytes):
00 00 00 00 c0 73 d3 e3 00 00 00 00 00 00 00 00  .s..
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[] kmemleak_alloc+0x27/0x50
[] kmem_cache_alloc+0xc5/0x180
[] idr_pre_get+0x54/0x80
[] drm_gem_handle_create+0x3c/0xd0
[] i915_gem_create+0x49/0xa0
[] i915_gem_create_ioctl+0x28/0x40
[] drm_ioctl+0x1d6/0x470
[] do_vfs_ioctl+0x7e/0x5a0
[] sys_ioctl+0x39/0x70
[] sysenter_do_call+0x12/0x36
[] 0x
unreferenced object 0xe3d37a00 (size 148):
  comm "Xorg", pid 1398, jiffies 4294740515 (age 4367.653s)
  hex dump (first 32 bytes):

[Bug 41418] [RV350] Screen corruption with certain resolutions on LVDS (scaled)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41418

--- Comment #5 from Alex Deucher  2011-10-04 06:43:32 PDT 
---
Can you attach the output of xrandr --verbose?  Note that Full aspect scaling
is not implemented for pre-avivo asics, so make sure you are not using that. 
Center and Full do work however.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41445] XBMC problem with playing the videos i915_dri.so

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41445

--- Comment #10 from Wojtek  2011-10-04 04:44:51 PDT ---
Created an attachment (id=51931)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=51931)
Xbmc_crashlog

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41445] XBMC problem with playing the videos i915_dri.so

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41445

--- Comment #9 from Wojtek  2011-10-04 04:44:22 PDT ---
Created an attachment (id=51930)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=51930)
Xorg.log

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41445] XBMC problem with playing the videos i915_dri.so

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41445

--- Comment #8 from Wojtek  2011-10-04 04:43:57 PDT ---
Created an attachment (id=51929)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=51929)
Glxgears

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41445] XBMC problem with playing the videos i915_dri.so

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41445

--- Comment #7 from Wojtek  2011-10-04 04:43:38 PDT ---
Created an attachment (id=51928)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=51928)
Glxheads

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41445] XBMC problem with playing the videos i915_dri.so

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41445

--- Comment #6 from Wojtek  2011-10-04 04:43:17 PDT ---
Created an attachment (id=51927)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=51927)
Glxinfo

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41445] XBMC problem with playing the videos i915_dri.so

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41445

--- Comment #5 from Wojtek  2011-10-04 04:42:57 PDT ---
Created an attachment (id=51926)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=51926)
Uname

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41445] XBMC problem with playing the videos i915_dri.so

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41445

--- Comment #4 from Wojtek  2011-10-04 04:42:40 PDT ---
Created an attachment (id=51925)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=51925)
Lspci

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41445] XBMC problem with playing the videos i915_dri.so

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41445

--- Comment #3 from Wojtek  2011-10-04 04:42:11 PDT ---
Created an attachment (id=51924)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=51924)
Lsmod

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41445] XBMC problem with playing the videos i915_dri.so

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41445

--- Comment #2 from Wojtek  2011-10-04 04:41:44 PDT ---
Created an attachment (id=51923)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=51923)
Dmesg

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41445] XBMC problem with playing the videos i915_dri.so

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41445

--- Comment #1 from Wojtek  2011-10-04 04:41:10 PDT ---
Created an attachment (id=51922)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=51922)
Debian version

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 41445] New: XBMC problem with playing the videos i915_dri.so

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=41445

   Summary: XBMC problem with playing the videos i915_dri.so
   Product: DRI
   Version: unspecified
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: major
  Priority: medium
 Component: libGL
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: wojtasek85 at wp.pl


Hello,

When I try play the video file with built-in player "DVDPlayer", the XBMC media
center suddenly shutting down. In crash log I see that the problem occurred
with i915_dri.so.

I use a Debian testing environment (wheezy) 64 bit and whole system was
upgraded to newest one.


Please look on attached archive.


Best regards

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

[Bug 39953] Flicker after waking from DPMS sleep

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39953

Simon Strandman  changed:

   What|Removed |Added

 CC||simon.strandman at gmail.com

--- Comment #3 from Simon Strandman  2011-10-04 
01:05:19 PDT ---
I have this problem too on similar E350-based hardware.

Sometimes I get this flicker, sometimes the screen is garbled (bug #36513).
When I get a garbled screen the flicker usually persists even after a reboot.
(Though this never happens in windows so I don't think it's a hardware issue.)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.

KMS and TTM questions

[Alan Cox]

> Thats fine as long as you don't want to do acceleration or object
> migration between GTT
> and VRAM type memory. Now I expect when you give out this advice you

Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
It's all effectively in the GART with the 'stolen' pages preloaded into
the translation tables by the BIOS at vga init time.

It has fake VRAM type memory but thats really an illusion (although one
the driver seems to like to keep up). The GEM changes do mean you can
plug the existing allocator in the VIA driver into GEM directly. Whether
that would be a good idea or not given the other things you then need to
do I don't know - but it does seem to be me to be a stepping stone in the
right direction that is much easier to make ?

I'm fairly sure the real problem is that we have no way to treat stolen
pages as generic kernel memory. The ideal case would be to simply put
that memory back into the kernel memory pools. I did a little poking at
this but it makes suspend/resume horribly exciting and while some
hardware puts it at civilised bus addresses (end of 'real' memory
usually) not everyone seems to do it that way.

You can migrate the physical pages under a GEM object as well - in fact
it happens every time pages get swapped out and back in.

[Bug 41445] XBMC problem with playing the videos i915_dri.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41445

--- Comment #2 from Wojtek wojtase...@wp.pl 2011-10-04 04:41:44 PDT ---
Created an attachment (id=51923)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=51923)
Dmesg

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 41445] XBMC problem with playing the videos i915_dri.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41445

--- Comment #3 from Wojtek wojtase...@wp.pl 2011-10-04 04:42:11 PDT ---
Created an attachment (id=51924)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=51924)
Lsmod

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 41445] XBMC problem with playing the videos i915_dri.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41445

--- Comment #5 from Wojtek wojtase...@wp.pl 2011-10-04 04:42:57 PDT ---
Created an attachment (id=51926)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=51926)
Uname

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 41445] XBMC problem with playing the videos i915_dri.so

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41445

--- Comment #6 from Wojtek wojtase...@wp.pl 2011-10-04 04:43:17 PDT ---
Created an attachment (id=51927)
 -- (https://bugs.freedesktop.org/attachment.cgi?id=51927)
Glxinfo

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 41418] [RV350] Screen corruption with certain resolutions on LVDS (scaled)

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=41418

--- Comment #5 from Alex Deucher ag...@yahoo.com 2011-10-04 06:43:32 PDT ---
Can you attach the output of xrandr --verbose?  Note that Full aspect scaling
is not implemented for pre-avivo asics, so make sure you are not using that. 
Center and Full do work however.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: KMS and TTM questions

[James Simmons]

         Second question I have is how are monochrome cursor images
  handled with KMS. Yes we need to support CLE266 which is used in a lot
  of POS devices. That chipset only supports monochrome cursors.
 
 As far as I know, the KMS cursor API doesn't really care what type of
 cursors are supported.  That's a client driver (ddx, etc.)
 implementation detail.  The cursor interface just basically has on,
 off, and position. The client driver (ddx, etc.) can choose to upload
 a ARGB or mono image.  We should probably add some sort of flag to KMS
 to ask the driver what types of cursors they support so this could be
 supported in a generic way.

That is the bit missing. I seen recently you had a patch for passing info 
to userland. It would be nice to add what color depths the cursor 
supports.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: KMS and TTM questions

[Alex Deucher]

On Tue, Oct 4, 2011 at 9:42 AM, James Simmons jsimm...@infradead.org wrote:

  Thats fine as long as you don't want to do acceleration or object
  migration between GTT
  and VRAM type memory. Now I expect when you give out this advice you

 Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
 It's all effectively in the GART with the 'stolen' pages preloaded into
 the translation tables by the BIOS at vga init time.

 It has fake VRAM type memory but thats really an illusion (although one
 the driver seems to like to keep up). The GEM changes do mean you can
 plug the existing allocator in the VIA driver into GEM directly. Whether
 that would be a good idea or not given the other things you then need to
 do I don't know - but it does seem to be me to be a stepping stone in the
 right direction that is much easier to make ?

 That is correct. In fact the via driver detects what type of system ram is
 used so I can limit what resolutions are supported. Its possible that the
 memory doesn't have the bandwidth to support a very large resolution on
 older systems.

Is vram actually handled via a scatter/gather page table or is it just
a pointer to a contiguous chunk of stolen system memory at the top of
ram?

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: KMS and TTM questions

[Alex Deucher]

On Tue, Oct 4, 2011 at 9:45 AM, James Simmons jsimm...@infradead.org wrote:

         Second question I have is how are monochrome cursor images
  handled with KMS. Yes we need to support CLE266 which is used in a lot
  of POS devices. That chipset only supports monochrome cursors.

 As far as I know, the KMS cursor API doesn't really care what type of
 cursors are supported.  That's a client driver (ddx, etc.)
 implementation detail.  The cursor interface just basically has on,
 off, and position. The client driver (ddx, etc.) can choose to upload
 a ARGB or mono image.  We should probably add some sort of flag to KMS
 to ask the driver what types of cursors they support so this could be
 supported in a generic way.

 That is the bit missing. I seen recently you had a patch for passing info
 to userland. It would be nice to add what color depths the cursor
 supports.

I think Dave proposed something like that for the generic KMS ddx.

Alex
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: KMS and TTM questions

[James Simmons]

  Second question I have is how are monochrome cursor images
  handled with KMS. Yes we need to support CLE266 which is used in a lot
 
 That depends on your libkms for the device. You can allocate a one bit
 deep object if you want. Reading libkms source is probably what you need
 if you've not already done os.

No special libkms for our hardware. Currently the via driver implements 
dumb buffers so I can work with the generic libkms library. Once tile 
support is implemented then a special buffer manager will need to be 
implemented.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/radeon/kms: fix channel_remap setup

[alexdeucher]

From: Alex Deucher alexander.deuc...@amd.com

Most asics just use the hw default value which requires
no explicit programming.  For those that need a different
value, the vbios will program it properly.  As such,
there's no need to program these registers explicitly
in the driver.  Changing these registers requires a reload
of all data in vram otherwise its contents will be scambled.

Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=40103

Signed-off-by: Alex Deucher alexander.deuc...@amd.com
Cc: sta...@kernel.org
---
 drivers/gpu/drm/radeon/evergreen.c |3 ++-
 drivers/gpu/drm/radeon/ni.c|3 ++-
 drivers/gpu/drm/radeon/rv770.c |3 ++-
 3 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/radeon/evergreen.c 
b/drivers/gpu/drm/radeon/evergreen.c
index e8a7467..276509d 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -2078,7 +2078,8 @@ static void evergreen_gpu_init(struct radeon_device *rdev)
WREG32(DMIF_ADDR_CONFIG, gb_addr_config);
WREG32(HDP_ADDR_CONFIG, gb_addr_config);
 
-   evergreen_program_channel_remap(rdev);
+   /* Use the hw default or as set up by the vbios */
+   /* evergreen_program_channel_remap(rdev);*/
 
num_shader_engines = ((RREG32(GB_ADDR_CONFIG)  NUM_SHADER_ENGINES(3)) 
 12) + 1;
grbm_gfx_index = INSTANCE_BROADCAST_WRITES;
diff --git a/drivers/gpu/drm/radeon/ni.c b/drivers/gpu/drm/radeon/ni.c
index 99fbd79..f15bf6b 100644
--- a/drivers/gpu/drm/radeon/ni.c
+++ b/drivers/gpu/drm/radeon/ni.c
@@ -842,7 +842,8 @@ static void cayman_gpu_init(struct radeon_device *rdev)
WREG32(DMIF_ADDR_CONFIG, gb_addr_config);
WREG32(HDP_ADDR_CONFIG, gb_addr_config);
 
-   cayman_program_channel_remap(rdev);
+   /* Use the hw default or as set up by the vbios */
+   /* cayman_program_channel_remap(rdev); */
 
/* primary versions */
WREG32(CC_RB_BACKEND_DISABLE, cc_rb_backend_disable);
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 4720d00..98e3b7e 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -785,7 +785,8 @@ static void rv770_gpu_init(struct radeon_device *rdev)
WREG32(DCP_TILING_CONFIG, (gb_tiling_config  0x));
WREG32(HDP_TILING_CONFIG, (gb_tiling_config  0x));
 
-   rv770_program_channel_remap(rdev);
+   /* Use the hw default or as set up by the vbios */
+   /* rv770_program_channel_remap(rdev); */
 
WREG32(CC_RB_BACKEND_DISABLE,  cc_rb_backend_disable);
WREG32(CC_GC_SHADER_PIPE_CONFIG,   cc_gc_shader_pipe_config);
-- 
1.7.1.1

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: KMS and TTM questions

[James Simmons]

   Thats fine as long as you don't want to do acceleration or object
   migration between GTT
   and VRAM type memory. Now I expect when you give out this advice you
 
  Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
  It's all effectively in the GART with the 'stolen' pages preloaded into
  the translation tables by the BIOS at vga init time.
 
  It has fake VRAM type memory but thats really an illusion (although one
  the driver seems to like to keep up). The GEM changes do mean you can
  plug the existing allocator in the VIA driver into GEM directly. Whether
  that would be a good idea or not given the other things you then need to
  do I don't know - but it does seem to be me to be a stepping stone in the
  right direction that is much easier to make ?
 
  That is correct. In fact the via driver detects what type of system ram is
  used so I can limit what resolutions are supported. Its possible that the
  memory doesn't have the bandwidth to support a very large resolution on
  older systems.
 
 Is vram actually handled via a scatter/gather page table or is it just
 a pointer to a contiguous chunk of stolen system memory at the top of
 ram?

Stolen chuck. At the same time newer chipsets, VX900, have pcie gart 
table to move data to and from the vram. 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 39897] Graphical glitches in some games on Evergreen

[bugzilla-daemon]

https://bugs.freedesktop.org/show_bug.cgi?id=39897

Michel Dänzer mic...@daenzer.net changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #26 from Michel Dänzer mic...@daenzer.net 2011-10-04 09:29:01 PDT 
---
(In reply to comment #24)
 R600_TILING=1 produces the rendering errors.
 Is it still worth a new bug report?

It's up to you, but it would basically be an enhancement request, as
R600_TILING is disabled by default.

This bug is very likely fixed upstream, resolving.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: KMS and TTM questions

[Thomas Hellstrom]

On 10/04/2011 01:07 AM, Alan Cox wrote:

Thats fine as long as you don't want to do acceleration or object
migration between GTT
and VRAM type memory. Now I expect when you give out this advice you
 

Yes but the VIA doesn't if I recall correctly have any 'VRAM type memory'.
It's all effectively in the GART with the 'stolen' pages preloaded into
the translation tables by the BIOS at vga init time.
   


VRAM memory (at least on the older unichromes) is taken from on-board 
RAM and set up by the BIOS, and from a device programmer's point of view 
works like a discrete card VRAM, and is *not* part of the GART.


On some devices (K8M800) , the VRAM pages could be accessed by the CPU 
directly at the top of VRAM, which was substantially faster.


There is a fully functional unichrome DRM on top of TTM, that together 
with the 3D driver in mesa's openchrome branch worked like a charm (even 
outperformed Intel's i965 with identical CPU at the time).

Problem was that it was not backwards compatible with via's old drm.

It should serve as a good starting point though, if I can remember where 
I put it


/Thomas





___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [git pull] drm fixes

[Linus Torvalds]

On Tue, Oct 4, 2011 at 9:34 AM, Dave Airlie airl...@linux.ie wrote:

 all radeon fixes, one nasty startup crash and/or memory corruption on one
 family of radeon hd6450s resulted in a patch to stop setting a bunch of
 regs in the drivers and let the BIOS set them correctly, displayport
 regression fix, and some off-by-one in the cursor code around the corners
 of the screens.

Has this been tested with suspend/resume on a lot of machines?

In general, the registers that get set on boot correctly absolutely do
*not* get set on resume.

So the registers that you now no longer set at boot-time should almost
certainly still be saved and restored across suspend/resume. I don't
know the code well enough to read the diffs, but a quick grep seems to
show that when you removed the boot-time setup, you also removed the
resume-time setup (well, at least MC_SHARED_CHREMAP doesn't seem to be
used anywhere any more: it may be that it's saved-restores in some
kind of loop over all registers that wouldn't have triggered the
grep).

I pulled, but please verify that whole thing.

  Linus
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 01/26] ttm: export ttm_bo_create

[Thomas Hellstrom]

Used by the vmwgfx driver.

Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
 drivers/gpu/drm/ttm/ttm_bo.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index b824d9b..6e96c85 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1295,6 +1295,7 @@ int ttm_bo_create(struct ttm_bo_device *bdev,
 
return ret;
 }
+EXPORT_SYMBOL(ttm_bo_create);
 
 static int ttm_bo_force_list_clean(struct ttm_bo_device *bdev,
unsigned mem_type, bool allow_errors)
-- 
1.7.4.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 02/26] vmwgfx: Update register files to latest from vmware-sdk

[Thomas Hellstrom]

From: Jakob Bornecrantz ja...@vmware.com

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
 drivers/gpu/drm/vmwgfx/svga3d_reg.h   |  259 +++--
 drivers/gpu/drm/vmwgfx/svga_escape.h  |2 +-
 drivers/gpu/drm/vmwgfx/svga_overlay.h |   22 ++--
 drivers/gpu/drm/vmwgfx/svga_reg.h |  220 +---
 4 files changed, 359 insertions(+), 144 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/svga3d_reg.h 
b/drivers/gpu/drm/vmwgfx/svga3d_reg.h
index 77cb453..d0e085e 100644
--- a/drivers/gpu/drm/vmwgfx/svga3d_reg.h
+++ b/drivers/gpu/drm/vmwgfx/svga3d_reg.h
@@ -57,7 +57,8 @@ typedef enum {
SVGA3D_HWVERSION_WS6_B1= SVGA3D_MAKE_HWVERSION(1, 1),
SVGA3D_HWVERSION_FUSION_11 = SVGA3D_MAKE_HWVERSION(1, 4),
SVGA3D_HWVERSION_WS65_B1   = SVGA3D_MAKE_HWVERSION(2, 0),
-   SVGA3D_HWVERSION_CURRENT   = SVGA3D_HWVERSION_WS65_B1,
+   SVGA3D_HWVERSION_WS8_B1= SVGA3D_MAKE_HWVERSION(2, 1),
+   SVGA3D_HWVERSION_CURRENT   = SVGA3D_HWVERSION_WS8_B1,
 } SVGA3dHardwareVersion;
 
 /*
@@ -67,7 +68,8 @@ typedef enum {
 typedef uint32 SVGA3dBool; /* 32-bit Bool definition */
 #define SVGA3D_NUM_CLIPPLANES   6
 #define SVGA3D_MAX_SIMULTANEOUS_RENDER_TARGETS  8
-
+#define SVGA3D_MAX_CONTEXT_IDS  256
+#define SVGA3D_MAX_SURFACE_IDS  (32 * 1024)
 
 /*
  * Surface formats.
@@ -79,76 +81,91 @@ typedef uint32 SVGA3dBool; /* 32-bit Bool definition */
  */
 
 typedef enum SVGA3dSurfaceFormat {
-   SVGA3D_FORMAT_INVALID = 0,
+   SVGA3D_FORMAT_INVALID   = 0,
 
-   SVGA3D_X8R8G8B8   = 1,
-   SVGA3D_A8R8G8B8   = 2,
+   SVGA3D_X8R8G8B8 = 1,
+   SVGA3D_A8R8G8B8 = 2,
 
-   SVGA3D_R5G6B5 = 3,
-   SVGA3D_X1R5G5B5   = 4,
-   SVGA3D_A1R5G5B5   = 5,
-   SVGA3D_A4R4G4B4   = 6,
+   SVGA3D_R5G6B5   = 3,
+   SVGA3D_X1R5G5B5 = 4,
+   SVGA3D_A1R5G5B5 = 5,
+   SVGA3D_A4R4G4B4 = 6,
 
-   SVGA3D_Z_D32  = 7,
-   SVGA3D_Z_D16  = 8,
-   SVGA3D_Z_D24S8= 9,
-   SVGA3D_Z_D15S1= 10,
+   SVGA3D_Z_D32= 7,
+   SVGA3D_Z_D16= 8,
+   SVGA3D_Z_D24S8  = 9,
+   SVGA3D_Z_D15S1  = 10,
 
-   SVGA3D_LUMINANCE8= 11,
-   SVGA3D_LUMINANCE4_ALPHA4 = 12,
-   SVGA3D_LUMINANCE16   = 13,
-   SVGA3D_LUMINANCE8_ALPHA8 = 14,
+   SVGA3D_LUMINANCE8   = 11,
+   SVGA3D_LUMINANCE4_ALPHA4= 12,
+   SVGA3D_LUMINANCE16  = 13,
+   SVGA3D_LUMINANCE8_ALPHA8= 14,
 
-   SVGA3D_DXT1   = 15,
-   SVGA3D_DXT2   = 16,
-   SVGA3D_DXT3   = 17,
-   SVGA3D_DXT4   = 18,
-   SVGA3D_DXT5   = 19,
+   SVGA3D_DXT1 = 15,
+   SVGA3D_DXT2 = 16,
+   SVGA3D_DXT3 = 17,
+   SVGA3D_DXT4 = 18,
+   SVGA3D_DXT5 = 19,
 
-   SVGA3D_BUMPU8V8   = 20,
-   SVGA3D_BUMPL6V5U5 = 21,
-   SVGA3D_BUMPX8L8V8U8   = 22,
-   SVGA3D_BUMPL8V8U8 = 23,
+   SVGA3D_BUMPU8V8 = 20,
+   SVGA3D_BUMPL6V5U5   = 21,
+   SVGA3D_BUMPX8L8V8U8 = 22,
+   SVGA3D_BUMPL8V8U8   = 23,
 
-   SVGA3D_ARGB_S10E5 = 24,   /* 16-bit floating-point ARGB */
-   SVGA3D_ARGB_S23E8 = 25,   /* 32-bit floating-point ARGB */
+   SVGA3D_ARGB_S10E5   = 24,   /* 16-bit floating-point ARGB */
+   SVGA3D_ARGB_S23E8   = 25,   /* 32-bit floating-point ARGB */
 
-   SVGA3D_A2R10G10B10= 26,
+   SVGA3D_A2R10G10B10  = 26,
 
/* signed formats */
-   SVGA3D_V8U8   = 27,
-   SVGA3D_Q8W8V8U8   = 28,
-   SVGA3D_CxV8U8 = 29,
+   SVGA3D_V8U8 = 27,
+   SVGA3D_Q8W8V8U8 = 28,
+   SVGA3D_CxV8U8   = 29,
 
/* mixed formats */
-   SVGA3D_X8L8V8U8   = 30,
-   SVGA3D_A2W10V10U10= 31,
+   SVGA3D_X8L8V8U8 = 30,
+   SVGA3D_A2W10V10U10  = 31,
 
-   SVGA3D_ALPHA8 = 32,
+   SVGA3D_ALPHA8   = 32,
 
/* Single- and dual-component floating point formats */
-   SVGA3D_R_S10E5= 33,
-   SVGA3D_R_S23E8= 34,
-   SVGA3D_RG_S10E5   = 35,
-   SVGA3D_RG_S23E8   = 36,
+   SVGA3D_R_S10E5  = 33,
+   SVGA3D_R_S23E8  = 34,
+   SVGA3D_RG_S10E5 = 35,
+   SVGA3D_RG_S23E8 = 36,
 
/*
 * Any surface can be used as a buffer object, but SVGA3D_BUFFER is
 * the most efficient format to use when creating new surfaces
 * expressly for index or vertex data.
 */
-   SVGA3D_BUFFER = 37,
 
-   SVGA3D_Z_D24X8= 38,
+   SVGA3D_BUFFER

[PATCH 03/26] vmwgfx: Document vmw_fifo_reserve

[Thomas Hellstrom]

From: Jakob Bornecrantz ja...@vmware.com

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
Reviewed-by: Thomas Hellstrom thellst...@vmware.com
---
 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
index 3ba9cac..881f67a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
@@ -277,6 +277,16 @@ static int vmw_fifo_wait(struct vmw_private *dev_priv,
return ret;
 }
 
+/**
+ * Reserve @bytes number of bytes in the fifo.
+ *
+ * This function will return NULL (error) on two conditions:
+ *  If it timeouts waiting for fifo space, or if @bytes is larger than the
+ *   available fifo space.
+ *
+ * Returns:
+ *   Pointer to the fifo, or null on error (possible hardware hang).
+ */
 void *vmw_fifo_reserve(struct vmw_private *dev_priv, uint32_t bytes)
 {
struct vmw_fifo_state *fifo_state = dev_priv-fifo;
-- 
1.7.4.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 04/26] vmwgfx: Add comments for buffer pinning code

[Thomas Hellstrom]

From: Jakob Bornecrantz ja...@vmware.com

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
Reviewed-by: Thomas Hellstrom thellst...@vmware.com
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |   10 ++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 1a4c84c..c14eb76 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -706,6 +706,10 @@ static struct drm_framebuffer_funcs 
vmw_framebuffer_dmabuf_funcs = {
.create_handle = vmw_framebuffer_create_handle,
 };
 
+/**
+ * We need to reserve the start of vram because the host might
+ * scribble to it at mode changes, so we need to reserve it.
+ */
 static int vmw_surface_dmabuf_pin(struct vmw_framebuffer *vfb)
 {
struct vmw_private *dev_priv = vmw_priv(vfb-base.dev);
@@ -729,6 +733,9 @@ static int vmw_surface_dmabuf_pin(struct vmw_framebuffer 
*vfb)
return ret;
 }
 
+/**
+ * See vmw_surface_dmabuf_pin.
+ */
 static int vmw_surface_dmabuf_unpin(struct vmw_framebuffer *vfb)
 {
struct ttm_buffer_object *bo;
@@ -745,6 +752,9 @@ static int vmw_surface_dmabuf_unpin(struct vmw_framebuffer 
*vfb)
return 0;
 }
 
+/**
+ * Pin the dmabuffer to the start of vram.
+ */
 static int vmw_framebuffer_dmabuf_pin(struct vmw_framebuffer *vfb)
 {
struct vmw_private *dev_priv = vmw_priv(vfb-base.dev);
-- 
1.7.4.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 05/26] vmwgfx: Make sure the reserved area is at the start of vram

[Thomas Hellstrom]

From: Jakob Bornecrantz ja...@vmware.com

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index c14eb76..7ee8b8e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -717,6 +717,9 @@ static int vmw_surface_dmabuf_pin(struct vmw_framebuffer 
*vfb)
vmw_framebuffer_to_vfbs(vfb-base);
unsigned long size = vfbs-base.base.pitch * vfbs-base.base.height;
int ret;
+   struct ttm_placement ne_placement = vmw_vram_ne_placement;
+
+   ne_placement.lpfn = (size + (PAGE_SIZE - 1)) / PAGE_SIZE;
 
vfbs-buffer = kzalloc(sizeof(*vfbs-buffer), GFP_KERNEL);
if (unlikely(vfbs-buffer == NULL))
-- 
1.7.4.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 06/26] vmwgfx: Some comments and BUG_ON

[Thomas Hellstrom]

From: Jakob Bornecrantz ja...@vmware.com

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index fa26e64..cc8c08b 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -681,6 +681,9 @@ static int vmw_resize_cmd_bounce(struct vmw_sw_context 
*sw_context,
  * Creates a fence object and submits a command stream marker.
  * If this fails for some reason, We sync the fifo and return NULL.
  * It is then safe to fence buffers with a NULL pointer.
+ *
+ * If @p_handle is not NULL @file_priv must also not be NULL. Creates
+ * a userspace handle if @p_handle is not NULL, otherwise not.
  */
 
 int vmw_execbuf_fence_commands(struct drm_file *file_priv,
@@ -692,6 +695,8 @@ int vmw_execbuf_fence_commands(struct drm_file *file_priv,
int ret;
bool synced = false;
 
+   /* p_handle implies file_priv. */
+   BUG_ON(p_handle != NULL  file_priv == NULL);
 
ret = vmw_fifo_send_fence(dev_priv, sequence);
if (unlikely(ret != 0)) {
-- 
1.7.4.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 07/26] vmwgfx: Break out execbuf command processing

[Thomas Hellstrom]

This will make it easier to execute commands operating on user-space
resources but generated by the kernel.

JB: Added tracking if the sw_context was called from the kernel or userspace.

Signed-off-by: Thomas Hellstrom thellst...@vmware.com
Signed-off-by: Jakob Bornecrantz ja...@vmware.com
Reviewed-by: Jakob Bornecrantz ja...@vmware.com
---
 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |9 ++
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |  136 ++-
 2 files changed, 89 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h 
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index 564a815..edd1e83 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -139,6 +139,7 @@ struct vmw_sw_context{
struct ida bo_list;
uint32_t last_cid;
bool cid_valid;
+   bool kernel; /** is the called made from the kernel */
uint32_t last_sid;
uint32_t sid_translation;
bool sid_valid;
@@ -449,6 +450,14 @@ extern int vmw_dma_quiescent(struct drm_device *dev);
 
 extern int vmw_execbuf_ioctl(struct drm_device *dev, void *data,
 struct drm_file *file_priv);
+extern int vmw_execbuf_process(struct drm_file *file_priv,
+  struct vmw_private *dev_priv,
+  void __user *user_commands,
+  void *kernel_commands,
+  uint32_t command_size,
+  uint64_t throttle_us,
+  struct drm_vmw_fence_rep __user
+  *user_fence_rep);
 
 /**
  * IRQs and wating - vmwgfx_irq.c
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index cc8c08b..542c852 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -531,9 +531,9 @@ out_err:
 
 static int vmw_cmd_check_all(struct vmw_private *dev_priv,
 struct vmw_sw_context *sw_context,
+void *buf,
 uint32_t size)
 {
-   void *buf = sw_context-cmd_bounce;
int32_t cur_size = size;
int ret;
 
@@ -724,58 +724,44 @@ int vmw_execbuf_fence_commands(struct drm_file *file_priv,
return 0;
 }
 
-int vmw_execbuf_ioctl(struct drm_device *dev, void *data,
- struct drm_file *file_priv)
+int vmw_execbuf_process(struct drm_file *file_priv,
+   struct vmw_private *dev_priv,
+   void __user *user_commands,
+   void *kernel_commands,
+   uint32_t command_size,
+   uint64_t throttle_us,
+   struct drm_vmw_fence_rep __user *user_fence_rep)
 {
-   struct vmw_private *dev_priv = vmw_priv(dev);
-   struct drm_vmw_execbuf_arg *arg = (struct drm_vmw_execbuf_arg *)data;
-   struct drm_vmw_fence_rep fence_rep;
-   struct drm_vmw_fence_rep __user *user_fence_rep;
-   int ret;
-   void *user_cmd;
-   void *cmd;
struct vmw_sw_context *sw_context = dev_priv-ctx;
-   struct vmw_master *vmaster = vmw_master(file_priv-master);
+   struct drm_vmw_fence_rep fence_rep;
struct vmw_fence_obj *fence;
uint32_t handle;
+   void *cmd;
+   int ret;
 
-   /*
-* This will allow us to extend the ioctl argument while
-* maintaining backwards compatibility:
-* We take different code paths depending on the value of
-* arg-version.
-*/
-
-   if (unlikely(arg-version != DRM_VMW_EXECBUF_VERSION)) {
-   DRM_ERROR(Incorrect execbuf version.\n);
-   DRM_ERROR(You're running outdated experimental 
- vmwgfx user-space drivers.);
-   return -EINVAL;
-   }
-
-   ret = ttm_read_lock(vmaster-lock, true);
+   ret = mutex_lock_interruptible(dev_priv-cmdbuf_mutex);
if (unlikely(ret != 0))
-   return ret;
+   return -ERESTARTSYS;
 
-   ret = mutex_lock_interruptible(dev_priv-cmdbuf_mutex);
-   if (unlikely(ret != 0)) {
-   ret = -ERESTARTSYS;
-   goto out_no_cmd_mutex;
-   }
+   if (kernel_commands == NULL) {
+   sw_context-kernel = false;
 
-   ret = vmw_resize_cmd_bounce(sw_context, arg-command_size);
-   if (unlikely(ret != 0))
-   goto out_unlock;
+   ret = vmw_resize_cmd_bounce(sw_context, command_size);
+   if (unlikely(ret != 0))
+   goto out_unlock;
 
-   user_cmd = (void __user *)(unsigned long)arg-commands;
-   ret = copy_from_user(sw_context-cmd_bounce,
-user_cmd, arg-command_size);
 
-   if (unlikely(ret != 0)) {
-   ret = -EFAULT;
-   DRM_ERROR(Failed copying commands.\n);
-   goto 

[PATCH 08/26] vmwgfx: Break out dirty submission code

[Thomas Hellstrom]

From: Jakob Bornecrantz ja...@vmware.com

In preperation for screen objects, still leaves the delayed workqueue
for surface updates in place.

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c |  144 ++-
 1 files changed, 90 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index 7ee8b8e..1dbb67e 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -433,6 +433,49 @@ out_unlock:
mutex_unlock(vfbs-work_lock);
 }
 
+static int do_surface_dirty_ldu(struct vmw_private *dev_priv,
+   struct vmw_framebuffer *framebuffer,
+   struct vmw_surface *surf,
+   unsigned flags, unsigned color,
+   struct drm_clip_rect *clips,
+   unsigned num_clips, int inc)
+{
+   SVGA3dCopyRect *cr;
+   int i;
+
+   struct {
+   SVGA3dCmdHeader header;
+   SVGA3dCmdPresent body;
+   SVGA3dCopyRect cr;
+   } *cmd;
+
+   cmd = vmw_fifo_reserve(dev_priv, sizeof(*cmd) + (num_clips - 1) *
+  sizeof(cmd-cr));
+   if (unlikely(cmd == NULL)) {
+   DRM_ERROR(Fifo reserve failed.\n);
+   return -ENOMEM;
+   }
+
+   memset(cmd, 0, sizeof(*cmd));
+
+   cmd-header.id = cpu_to_le32(SVGA_3D_CMD_PRESENT);
+   cmd-header.size = cpu_to_le32(sizeof(cmd-body) + num_clips *
+  sizeof(cmd-cr));
+   cmd-body.sid = cpu_to_le32(surf-res.id);
+
+   for (i = 0, cr = cmd-cr; i  num_clips; i++, cr++, clips += inc) {
+   cr-x = cpu_to_le16(clips-x1);
+   cr-y = cpu_to_le16(clips-y1);
+   cr-srcx = cr-x;
+   cr-srcy = cr-y;
+   cr-w = cpu_to_le16(clips-x2 - clips-x1);
+   cr-h = cpu_to_le16(clips-y2 - clips-y1);
+   }
+
+   vmw_fifo_commit(dev_priv, sizeof(*cmd) + (num_clips - 1) *
+   sizeof(cmd-cr));
+   return 0;
+}
 
 int vmw_framebuffer_surface_dirty(struct drm_framebuffer *framebuffer,
  struct drm_file *file_priv,
@@ -446,15 +489,7 @@ int vmw_framebuffer_surface_dirty(struct drm_framebuffer 
*framebuffer,
vmw_framebuffer_to_vfbs(framebuffer);
struct vmw_surface *surf = vfbs-surface;
struct drm_clip_rect norect;
-   SVGA3dCopyRect *cr;
-   int i, inc = 1;
-   int ret;
-
-   struct {
-   SVGA3dCmdHeader header;
-   SVGA3dCmdPresent body;
-   SVGA3dCopyRect cr;
-   } *cmd;
+   int ret, inc = 1;
 
if (unlikely(vfbs-master != file_priv-master))
return -EINVAL;
@@ -493,29 +528,10 @@ int vmw_framebuffer_surface_dirty(struct drm_framebuffer 
*framebuffer,
inc = 2; /* skip source rects */
}
 
-   cmd = vmw_fifo_reserve(dev_priv, sizeof(*cmd) + (num_clips - 1) * 
sizeof(cmd-cr));
-   if (unlikely(cmd == NULL)) {
-   DRM_ERROR(Fifo reserve failed.\n);
-   ttm_read_unlock(vmaster-lock);
-   return -ENOMEM;
-   }
-
-   memset(cmd, 0, sizeof(*cmd));
+   ret = do_surface_dirty_ldu(dev_priv, vfbs-base, surf,
+  flags, color,
+  clips, num_clips, inc);
 
-   cmd-header.id = cpu_to_le32(SVGA_3D_CMD_PRESENT);
-   cmd-header.size = cpu_to_le32(sizeof(cmd-body) + num_clips * 
sizeof(cmd-cr));
-   cmd-body.sid = cpu_to_le32(surf-res.id);
-
-   for (i = 0, cr = cmd-cr; i  num_clips; i++, cr++, clips += inc) {
-   cr-x = cpu_to_le16(clips-x1);
-   cr-y = cpu_to_le16(clips-y1);
-   cr-srcx = cr-x;
-   cr-srcy = cr-y;
-   cr-w = cpu_to_le16(clips-x2 - clips-x1);
-   cr-h = cpu_to_le16(clips-y2 - clips-y1);
-   }
-
-   vmw_fifo_commit(dev_priv, sizeof(*cmd) + (num_clips - 1) * 
sizeof(cmd-cr));
ttm_read_unlock(vmaster-lock);
return 0;
 }
@@ -648,6 +664,41 @@ void vmw_framebuffer_dmabuf_destroy(struct drm_framebuffer 
*framebuffer)
kfree(vfbd);
 }
 
+static int do_dmabuf_dirty_ldu(struct vmw_private *dev_priv,
+  struct vmw_framebuffer *framebuffer,
+  struct vmw_dma_buffer *buffer,
+  unsigned flags, unsigned color,
+  struct drm_clip_rect *clips,
+  unsigned num_clips, int increment)
+{
+   size_t fifo_size;
+   int i;
+
+   struct {
+   uint32_t header;
+   SVGAFifoCmdUpdate body;
+   } *cmd;
+
+   fifo_size = sizeof(*cmd) * num_clips;
+   cmd = 

[PATCH 09/26] vmwgfx: Expand the command checker to cover screen object commands

[Thomas Hellstrom]

From: Jakob Bornecrantz ja...@vmware.com

Signed-off-by: Jakob Bornecrantz ja...@vmware.com
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |   77 +--
 1 files changed, 72 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
index 542c852..c98c347 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
@@ -450,6 +450,73 @@ static int vmw_cmd_tex_state(struct vmw_private *dev_priv,
return 0;
 }
 
+static int vmw_cmd_check_define_gmrfb(struct vmw_private *dev_priv,
+ struct vmw_sw_context *sw_context,
+ void *buf)
+{
+   struct vmw_dma_buffer *vmw_bo;
+   int ret;
+
+   struct {
+   uint32_t header;
+   SVGAFifoCmdDefineGMRFB body;
+   } *cmd = buf;
+
+   ret = vmw_translate_guest_ptr(dev_priv, sw_context,
+ cmd-body.ptr,
+ vmw_bo);
+   if (unlikely(ret != 0))
+   return ret;
+
+   vmw_dmabuf_unreference(vmw_bo);
+
+   return ret;
+}
+
+static int vmw_cmd_check_not_3d(struct vmw_private *dev_priv,
+   struct vmw_sw_context *sw_context,
+   void *buf, uint32_t *size)
+{
+   uint32_t size_remaining = *size;
+   bool need_kernel = true;
+   uint32_t cmd_id;
+
+   cmd_id = le32_to_cpu(((uint32_t *)buf)[0]);
+   switch (cmd_id) {
+   case SVGA_CMD_UPDATE:
+   *size = sizeof(uint32_t) + sizeof(SVGAFifoCmdUpdate);
+   need_kernel = false;
+   break;
+   case SVGA_CMD_DEFINE_GMRFB:
+   *size = sizeof(uint32_t) + sizeof(SVGAFifoCmdDefineGMRFB);
+   break;
+   case SVGA_CMD_BLIT_GMRFB_TO_SCREEN:
+   *size = sizeof(uint32_t) + sizeof(SVGAFifoCmdBlitGMRFBToScreen);
+   break;
+   case SVGA_CMD_BLIT_SCREEN_TO_GMRFB:
+   *size = sizeof(uint32_t) + sizeof(SVGAFifoCmdBlitGMRFBToScreen);
+   break;
+   default:
+   DRM_ERROR(Unsupported SVGA command: %u.\n, cmd_id);
+   return -EINVAL;
+   }
+
+   if (*size  size_remaining) {
+   DRM_ERROR(Invalid SVGA command (size mismatch):
+  %u.\n, cmd_id);
+   return -EINVAL;
+   }
+
+   if (unlikely(need_kernel  !sw_context-kernel)) {
+   DRM_ERROR(Kernel only SVGA command: %u.\n, cmd_id);
+   return -EPERM;
+   }
+
+   if (cmd_id == SVGA_CMD_DEFINE_GMRFB)
+   return vmw_cmd_check_define_gmrfb(dev_priv, sw_context, buf);
+
+   return 0;
+}
 
 typedef int (*vmw_cmd_func) (struct vmw_private *,
 struct vmw_sw_context *,
@@ -502,11 +569,11 @@ static int vmw_cmd_check(struct vmw_private *dev_priv,
SVGA3dCmdHeader *header = (SVGA3dCmdHeader *) buf;
int ret;
 
-   cmd_id = ((uint32_t *)buf)[0];
-   if (cmd_id == SVGA_CMD_UPDATE) {
-   *size = 5  2;
-   return 0;
-   }
+   cmd_id = le32_to_cpu(((uint32_t *)buf)[0]);
+   /* Handle any none 3D commands */
+   if (unlikely(cmd_id  SVGA_CMD_MAX))
+   return vmw_cmd_check_not_3d(dev_priv, sw_context, buf, size);
+
 
cmd_id = le32_to_cpu(header-id);
*size = le32_to_cpu(header-size) + sizeof(SVGA3dCmdHeader);
-- 
1.7.4.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel