date:20120912

From: Rob Clark 

Start breaking out the mutable state of the CRTC into it's own
structure.  Plus add _check_state() and _set_property() helpers.
This only moves the state that is related to scanout fb, which
is needed for nuclear-pageflip.  The rest of the mutable state
should be moved from drm_crtc to drm_crtc_state as part of the
atomic-modeset implementation.
---
 drivers/gpu/drm/drm_crtc.c|   88 ++---
 drivers/gpu/drm/drm_crtc_helper.c |   51 ++---
 drivers/gpu/drm/drm_fb_helper.c   |   11 ++---
 include/drm/drm_crtc.h|   49 -
 4 files changed, 143 insertions(+), 56 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f421fa6a..6d22c8c 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -396,7 +396,7 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)

/* remove from any CRTC */
list_for_each_entry(crtc, >mode_config.crtc_list, head) {
-   if (crtc->fb == fb) {
+   if (crtc->state->fb == fb) {
/* should turn off the crtc */
drm_mode_crtc_set_obj_prop(crtc, state, 
config->prop_fb_id, 0);
}
@@ -446,7 +446,7 @@ int drm_crtc_init(struct drm_device *dev, struct drm_crtc 
*crtc,

crtc->dev = dev;
crtc->funcs = funcs;
-   crtc->invert_dimensions = false;
+   crtc->state->invert_dimensions = false;

mutex_lock(>mode_config.mutex);

@@ -455,7 +455,7 @@ int drm_crtc_init(struct drm_device *dev, struct drm_crtc 
*crtc,
goto out;

crtc->base.properties = >properties;
-   crtc->base.propvals = >propvals;
+   crtc->base.propvals = >state->propvals;

list_add_tail(>head, >mode_config.crtc_list);
dev->mode_config.num_crtc++;
@@ -496,6 +496,67 @@ void drm_crtc_cleanup(struct drm_crtc *crtc)
 }
 EXPORT_SYMBOL(drm_crtc_cleanup);

+int drm_crtc_check_state(struct drm_crtc *crtc,
+   struct drm_crtc_state *state)
+{
+   struct drm_framebuffer *fb = state->fb;
+   int hdisplay, vdisplay;
+
+   /* disabling the crtc is allowed: */
+   if (!fb)
+   return 0;
+
+   hdisplay = crtc->mode.hdisplay;
+   vdisplay = crtc->mode.vdisplay;
+
+   if (state->invert_dimensions)
+   swap(hdisplay, vdisplay);
+
+   if (hdisplay > fb->width ||
+   vdisplay > fb->height ||
+   state->x > fb->width - hdisplay ||
+   state->y > fb->height - vdisplay) {
+   DRM_DEBUG_KMS("Invalid fb size %ux%u for CRTC viewport 
%ux%u+%d+%d%s.\n",
+ fb->width, fb->height, hdisplay, vdisplay,
+ state->x, state->y,
+ state->invert_dimensions ? " (inverted)" : "");
+   return -ENOSPC;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_crtc_check_state);
+
+void drm_crtc_commit_state(struct drm_crtc *crtc,
+   struct drm_crtc_state *state)
+{
+   crtc->state = state;
+   crtc->base.propvals = >propvals;
+}
+EXPORT_SYMBOL(drm_crtc_commit_state);
+
+int drm_crtc_set_property(struct drm_crtc *crtc,
+   struct drm_crtc_state *state,
+   struct drm_property *property, uint64_t value)
+{
+   struct drm_device *dev = crtc->dev;
+   struct drm_mode_config *config = >mode_config;
+
+   if (property == config->prop_fb_id) {
+   struct drm_mode_object *obj = drm_property_get_obj(property, 
value);
+   state->fb = obj ? obj_to_fb(obj) : NULL;
+   } else if (property == config->prop_crtc_x) {
+   state->x = *(int *)
+   } else if (property == config->prop_crtc_y) {
+   state->y = *(int32_t *)
+   } else {
+   return -EINVAL;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_crtc_set_property);
+
 /**
  * drm_mode_probed_add - add a mode to a connector's probed mode list
  * @connector: connector the new mode
@@ -1614,11 +1675,11 @@ int drm_mode_getcrtc(struct drm_device *dev,
}
crtc = obj_to_crtc(obj);

-   crtc_resp->x = crtc->x;
-   crtc_resp->y = crtc->y;
+   crtc_resp->x = crtc->state->x;
+   crtc_resp->y = crtc->state->y;
crtc_resp->gamma_size = crtc->gamma_size;
-   if (crtc->fb)
-   crtc_resp->fb_id = crtc->fb->base.id;
+   if (crtc->state->fb)
+   crtc_resp->fb_id = crtc->state->fb->base.id;
else
crtc_resp->fb_id = 0;

@@ -2072,12 +2133,12 @@ int drm_mode_setcrtc(struct drm_device *dev, void *data,
/* If we have a mode we need a framebuffer. */
/* If we pass -1, set the mode with the currently bound fb */
if (crtc_req->fb_id == -1) {
-   if (!crtc->fb) {
+   if (!crtc->state->fb) {

[RFC 08/11] drm: convert page_flip to properties

From: Rob Clark 

Use atomic properties mechanism for CRTC page_flip.  This by itself
doesn't accomplish anything, but it avoids having multiple code
paths to do the same thing when nuclear-pageflip and atomic-modeset
are introduced.
---
 drivers/gpu/drm/drm_crtc.c |   69 +++-
 include/drm/drm_crtc.h |   13 -
 2 files changed, 30 insertions(+), 52 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 5f310d3..f421fa6a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -386,9 +386,7 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
struct drm_mode_config *config = >mode_config;
struct drm_crtc *crtc;
struct drm_plane *plane;
-   struct drm_mode_set set;
void *state;
-   int ret;

state = dev->driver->atomic_begin(dev, NULL);
if (IS_ERR(state)) {
@@ -400,12 +398,7 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
list_for_each_entry(crtc, >mode_config.crtc_list, head) {
if (crtc->fb == fb) {
/* should turn off the crtc */
-   memset(, 0, sizeof(struct drm_mode_set));
-   set.crtc = crtc;
-   set.fb = NULL;
-   ret = crtc->funcs->set_config();
-   if (ret)
-   DRM_ERROR("failed to reset crtc %p when fb was 
deleted\n", crtc);
+   drm_mode_crtc_set_obj_prop(crtc, state, 
config->prop_fb_id, 0);
}
}

@@ -448,6 +441,7 @@ EXPORT_SYMBOL(drm_framebuffer_remove);
 int drm_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
   const struct drm_crtc_funcs *funcs)
 {
+   struct drm_mode_config *config = >mode_config;
int ret;

crtc->dev = dev;
@@ -466,6 +460,10 @@ int drm_crtc_init(struct drm_device *dev, struct drm_crtc 
*crtc,
list_add_tail(>head, >mode_config.crtc_list);
dev->mode_config.num_crtc++;

+   drm_object_attach_property(>base, config->prop_fb_id, 0);
+   drm_object_attach_property(>base, config->prop_crtc_x, 0);
+   drm_object_attach_property(>base, config->prop_crtc_y, 0);
+
  out:
mutex_unlock(>mode_config.mutex);

@@ -3773,12 +3771,12 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
 void *data, struct drm_file *file_priv)
 {
struct drm_mode_crtc_page_flip *page_flip = data;
+   struct drm_mode_config *config = >mode_config;
struct drm_mode_object *obj;
struct drm_crtc *crtc;
-   struct drm_framebuffer *fb;
struct drm_pending_vblank_event *e = NULL;
unsigned long flags;
-   int hdisplay, vdisplay;
+   void *state;
int ret = -EINVAL;

if (page_flip->flags & ~DRM_MODE_PAGE_FLIP_FLAGS ||
@@ -3786,11 +3784,22 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
return -EINVAL;

mutex_lock(>mode_config.mutex);
-   obj = drm_mode_object_find(dev, page_flip->crtc_id, 
DRM_MODE_OBJECT_CRTC);
-   if (!obj)
-   goto out;
+
+   obj = drm_mode_object_find(dev, page_flip->crtc_id,
+   DRM_MODE_OBJECT_CRTC);
+   if (!obj) {
+   DRM_DEBUG_KMS("Unknown CRTC ID %d\n", page_flip->crtc_id);
+   ret = -ENOENT;
+   goto out_unlock;
+   }
crtc = obj_to_crtc(obj);

+   state = dev->driver->atomic_begin(dev, crtc);
+   if (IS_ERR(state)) {
+   ret = PTR_ERR(state);
+   goto out_unlock;
+   }
+
if (crtc->fb == NULL) {
/* The framebuffer is currently unbound, presumably
 * due to a hotplug event, that userspace has not
@@ -3800,31 +3809,6 @@ int drm_mode_page_flip_ioctl(struct drm_device *dev,
goto out;
}

-   if (crtc->funcs->page_flip == NULL)
-   goto out;
-
-   obj = drm_mode_object_find(dev, page_flip->fb_id, DRM_MODE_OBJECT_FB);
-   if (!obj)
-   goto out;
-   fb = obj_to_fb(obj);
-
-   hdisplay = crtc->mode.hdisplay;
-   vdisplay = crtc->mode.vdisplay;
-
-   if (crtc->invert_dimensions)
-   swap(hdisplay, vdisplay);
-
-   if (hdisplay > fb->width ||
-   vdisplay > fb->height ||
-   crtc->x > fb->width - hdisplay ||
-   crtc->y > fb->height - vdisplay) {
-   DRM_DEBUG_KMS("Invalid fb size %ux%u for CRTC viewport 
%ux%u+%d+%d%s.\n",
- fb->width, fb->height, hdisplay, vdisplay, 
crtc->x, crtc->y,
- crtc->invert_dimensions ? " (inverted)" : "");
-   ret = -ENOSPC;
-   goto out;
-   }
-
if (page_flip->flags & DRM_MODE_PAGE_FLIP_EVENT) {
ret = -ENOMEM;
spin_lock_irqsave(>event_lock, flags);

[RFC 07/11] drm: add drm_plane_state

From: Rob Clark 

Break the mutable state of a plane out into a separate structure.
This makes it easier to have some helpers for plane->set_property()
and for checking for invalid params.  The idea is that individual
drivers can wrap the state struct in their own struct which adds
driver specific parameters, for easy build-up of state across
multiple set_property() calls and for easy atomic commit or roll-
back.

The same should be done for CRTC, encoder, and connector, but this
patch only includes the first part (plane).
---
 drivers/gpu/drm/drm_crtc.c |  119 
 include/drm/drm_crtc.h |   52 ---
 2 files changed, 154 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 81a63fe..5f310d3 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -410,7 +410,7 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
}

list_for_each_entry(plane, >mode_config.plane_list, head) {
-   if (plane->fb == fb) {
+   if (plane->state->fb == fb) {
/* should turn off the crtc */
drm_mode_plane_set_obj_prop(plane, state, 
config->prop_crtc_id, 0);
drm_mode_plane_set_obj_prop(plane, state, 
config->prop_fb_id, 0);
@@ -688,7 +688,7 @@ int drm_plane_init(struct drm_device *dev, struct drm_plane 
*plane,
goto out;

plane->base.properties = >properties;
-   plane->base.propvals = >propvals;
+   plane->base.propvals = >state->propvals;
plane->dev = dev;
plane->funcs = funcs;
plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
@@ -749,6 +749,110 @@ void drm_plane_cleanup(struct drm_plane *plane)
 }
 EXPORT_SYMBOL(drm_plane_cleanup);

+int drm_plane_check_state(struct drm_plane *plane,
+   struct drm_plane_state *state)
+{
+   unsigned int fb_width, fb_height;
+   struct drm_framebuffer *fb = state->fb;
+   int i;
+
+   /* disabling the plane is allowed: */
+   if (!fb)
+   return 0;
+
+   fb_width = fb->width << 16;
+   fb_height = fb->height << 16;
+
+   /* Check whether this plane supports the fb pixel format. */
+   for (i = 0; i < plane->format_count; i++)
+   if (fb->pixel_format == plane->format_types[i])
+   break;
+   if (i == plane->format_count) {
+   DRM_DEBUG_KMS("Invalid pixel format 0x%08x\n", 
fb->pixel_format);
+   return -EINVAL;
+   }
+
+   /* Make sure source coordinates are inside the fb. */
+   if (state->src_w > fb_width ||
+   state->src_x > fb_width - state->src_w ||
+   state->src_h > fb_height ||
+   state->src_y > fb_height - state->src_h) {
+   DRM_DEBUG_KMS("Invalid source coordinates "
+ "%u.%06ux%u.%06u+%u.%06u+%u.%06u\n",
+ state->src_w >> 16,
+ ((state->src_w & 0x) * 15625) >> 10,
+ state->src_h >> 16,
+ ((state->src_h & 0x) * 15625) >> 10,
+ state->src_x >> 16,
+ ((state->src_x & 0x) * 15625) >> 10,
+ state->src_y >> 16,
+ ((state->src_y & 0x) * 15625) >> 10);
+   return -ENOSPC;
+   }
+
+   /* Give drivers some help against integer overflows */
+   if (state->crtc_w > INT_MAX ||
+   state->crtc_x > INT_MAX - (int32_t) state->crtc_w ||
+   state->crtc_h > INT_MAX ||
+   state->crtc_y > INT_MAX - (int32_t) state->crtc_h) {
+   DRM_DEBUG_KMS("Invalid CRTC coordinates %ux%u+%d+%d\n",
+ state->crtc_w, state->crtc_h,
+ state->crtc_x, state->crtc_y);
+   return -ERANGE;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_plane_check_state);
+
+void drm_plane_commit_state(struct drm_plane *plane,
+   struct drm_plane_state *state)
+{
+   plane->state = state;
+   plane->base.propvals = >propvals;
+}
+EXPORT_SYMBOL(drm_plane_commit_state);
+
+int drm_plane_set_property(struct drm_plane *plane,
+   struct drm_plane_state *state,
+   struct drm_property *property, uint64_t value)
+{
+   struct drm_device *dev = plane->dev;
+   struct drm_mode_config *config = >mode_config;
+
+   drm_object_property_set_value(>base,
+   >propvals, property, value);
+
+   if (property == config->prop_fb_id) {
+   struct drm_mode_object *obj = drm_property_get_obj(property, 
value);
+   state->fb = obj ? obj_to_fb(obj) : NULL;
+   } else if (property ==

[RFC 06/11] drm: convert plane to properties

From: Rob Clark 

Use atomic properties mechanism to set plane attributes.  This by
itself doesn't accomplish anything, but it avoids having multiple
code paths to do the same thing when nuclear-pageflip and atomic-
modeset are introduced.
---
 drivers/gpu/drm/drm_crtc.c |  257 ++--
 include/drm/drm_crtc.h |   32 --
 2 files changed, 179 insertions(+), 110 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 245c462..81a63fe 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -38,6 +38,9 @@
 #include "drm_edid.h"
 #include "drm_fourcc.h"

+static int drm_mode_set_obj_prop(struct drm_mode_object *obj,
+   void *state, struct drm_property *property, uint64_t value);
+
 /* Avoid boilerplate.  I'm tired of typing. */
 #define DRM_ENUM_NAME_FN(fnname, list) \
char *fnname(int val)   \
@@ -380,11 +383,19 @@ EXPORT_SYMBOL(drm_framebuffer_cleanup);
 void drm_framebuffer_remove(struct drm_framebuffer *fb)
 {
struct drm_device *dev = fb->dev;
+   struct drm_mode_config *config = >mode_config;
struct drm_crtc *crtc;
struct drm_plane *plane;
struct drm_mode_set set;
+   void *state;
int ret;

+   state = dev->driver->atomic_begin(dev, NULL);
+   if (IS_ERR(state)) {
+   DRM_ERROR("failed to disable crtc and/or plane when fb was 
deleted\n");
+   return;
+   }
+
/* remove from any CRTC */
list_for_each_entry(crtc, >mode_config.crtc_list, head) {
if (crtc->fb == fb) {
@@ -401,15 +412,19 @@ void drm_framebuffer_remove(struct drm_framebuffer *fb)
list_for_each_entry(plane, >mode_config.plane_list, head) {
if (plane->fb == fb) {
/* should turn off the crtc */
-   ret = plane->funcs->disable_plane(plane);
-   if (ret)
-   DRM_ERROR("failed to disable plane with busy 
fb\n");
-   /* disconnect the plane from the fb and crtc: */
-   plane->fb = NULL;
-   plane->crtc = NULL;
+   drm_mode_plane_set_obj_prop(plane, state, 
config->prop_crtc_id, 0);
+   drm_mode_plane_set_obj_prop(plane, state, 
config->prop_fb_id, 0);
}
}

+   /* just disabling stuff shouldn't fail, hopefully: */
+   if(dev->driver->atomic_check(dev, state))
+   DRM_ERROR("failed to disable crtc and/or plane when fb was 
deleted\n");
+   else
+   dev->driver->atomic_commit(dev, state, NULL);
+
+   dev->driver->atomic_end(dev, state);
+
list_del(>filp_head);

drm_framebuffer_unreference(fb);
@@ -663,6 +678,7 @@ int drm_plane_init(struct drm_device *dev, struct drm_plane 
*plane,
   const uint32_t *formats, uint32_t format_count,
   bool priv)
 {
+   struct drm_mode_config *config = >mode_config;
int ret;

mutex_lock(>mode_config.mutex);
@@ -699,6 +715,17 @@ int drm_plane_init(struct drm_device *dev, struct 
drm_plane *plane,
INIT_LIST_HEAD(>head);
}

+   drm_object_attach_property(>base, config->prop_fb_id, 0);
+   drm_object_attach_property(>base, config->prop_crtc_id, 0);
+   drm_object_attach_property(>base, config->prop_crtc_x, 0);
+   drm_object_attach_property(>base, config->prop_crtc_y, 0);
+   drm_object_attach_property(>base, config->prop_crtc_w, 0);
+   drm_object_attach_property(>base, config->prop_crtc_h, 0);
+   drm_object_attach_property(>base, config->prop_src_x, 0);
+   drm_object_attach_property(>base, config->prop_src_y, 0);
+   drm_object_attach_property(>base, config->prop_src_w, 0);
+   drm_object_attach_property(>base, config->prop_src_h, 0);
+
  out:
mutex_unlock(>mode_config.mutex);

@@ -772,23 +799,91 @@ void drm_mode_destroy(struct drm_device *dev, struct 
drm_display_mode *mode)
 }
 EXPORT_SYMBOL(drm_mode_destroy);

-static int drm_mode_create_standard_connector_properties(struct drm_device 
*dev)
+static int drm_mode_create_standard_properties(struct drm_device *dev)
 {
-   struct drm_property *edid;
-   struct drm_property *dpms;
+   struct drm_property *prop;

/*
 * Standard properties (apply to all connectors)
 */
-   edid = drm_property_create(dev, DRM_MODE_PROP_BLOB |
+   prop = drm_property_create(dev, DRM_MODE_PROP_BLOB |
   DRM_MODE_PROP_IMMUTABLE,
   "EDID", 0);
-   dev->mode_config.edid_property = edid;
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.edid_property = prop;

-   dpms = drm_property_create_enum(dev, 0,
+   prop = drm_property_create_enum(dev, 0,

[RFC 05/11] drm: split property values out

From: Rob Clark 

Split property values out into a different struct, so we can later
move property values into state structs.  This will allow the
property values to stay in sync w/ the state updates which are
either discarded or atomically committed.
---
 drivers/gpu/drm/drm_crtc.c |   27 ++-
 include/drm/drm_crtc.h |   10 +-
 2 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index e62ae6a..245c462 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -446,6 +446,7 @@ int drm_crtc_init(struct drm_device *dev, struct drm_crtc 
*crtc,
goto out;

crtc->base.properties = >properties;
+   crtc->base.propvals = >propvals;

list_add_tail(>head, >mode_config.crtc_list);
dev->mode_config.num_crtc++;
@@ -547,6 +548,7 @@ int drm_connector_init(struct drm_device *dev,
goto out;

connector->base.properties = >properties;
+   connector->base.propvals = >propvals;
connector->dev = dev;
connector->funcs = funcs;
connector->connector_type = connector_type;
@@ -670,6 +672,7 @@ int drm_plane_init(struct drm_device *dev, struct drm_plane 
*plane,
goto out;

plane->base.properties = >properties;
+   plane->base.propvals = >propvals;
plane->dev = dev;
plane->funcs = funcs;
plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
@@ -1549,7 +1552,7 @@ int drm_mode_getconnector(struct drm_device *dev, void 
*data,
goto out;
}

-   if (put_user(connector->properties.values[i],
+   if (put_user(connector->propvals.values[i],
 prop_values + copied)) {
ret = -EFAULT;
goto out;
@@ -2944,7 +2947,8 @@ EXPORT_SYMBOL(drm_connector_attach_property);
 int drm_connector_property_set_value(struct drm_connector *connector,
  struct drm_property *property, uint64_t value)
 {
-   return drm_object_property_set_value(>base, property, value);
+   return drm_object_property_set_value(>base,
+   >propvals, property, value);
 }
 EXPORT_SYMBOL(drm_connector_property_set_value);

@@ -2970,19 +2974,20 @@ void drm_object_attach_property(struct drm_mode_object 
*obj,
}

obj->properties->ids[count] = property->base.id;
-   obj->properties->values[count] = init_val;
+   obj->propvals->values[count] = init_val;
obj->properties->count++;
 }
 EXPORT_SYMBOL(drm_object_attach_property);

 int drm_object_property_set_value(struct drm_mode_object *obj,
+ struct drm_object_property_values *propvals,
  struct drm_property *property, uint64_t val)
 {
int i;

for (i = 0; i < obj->properties->count; i++) {
if (obj->properties->ids[i] == property->base.id) {
-   obj->properties->values[i] = val;
+   propvals->values[i] = val;
return 0;
}
}
@@ -2998,7 +3003,7 @@ int drm_object_property_get_value(struct drm_mode_object 
*obj,

for (i = 0; i < obj->properties->count; i++) {
if (obj->properties->ids[i] == property->base.id) {
-   *val = obj->properties->values[i];
+   *val = obj->propvals->values[i];
return 0;
}
}
@@ -3273,7 +3278,9 @@ static int drm_mode_connector_set_obj_prop(struct 
drm_connector *connector,

/* store the property value if successful */
if (!ret)
-   drm_object_property_set_value(>base, property, 
value);
+   drm_object_property_set_value(>base,
+   >propvals, property, value);
+
return ret;
 }

@@ -3286,7 +3293,8 @@ static int drm_mode_crtc_set_obj_prop(struct drm_crtc 
*crtc,
if (crtc->funcs->set_property)
ret = crtc->funcs->set_property(crtc, state, property, value);
if (!ret)
-   drm_object_property_set_value(>base, property, value);
+   drm_object_property_set_value(>base, >propvals,
+   property, value);

return ret;
 }
@@ -3300,7 +3308,8 @@ static int drm_mode_plane_set_obj_prop(struct drm_plane 
*plane,
if (plane->funcs->set_property)
ret = plane->funcs->set_property(plane, state, property, value);
if (!ret)
-   drm_object_property_set_value(>base, property, value);
+   drm_object_property_set_value(>base, >propvals,
+   property, value);

return ret;
 }
@@ -3401,7 +3410,7 @@ int drm_mode_obj_get_properties_ioctl(struct

[RFC 04/11] drm: add DRM_MODE_PROP_SIGNED property flag

From: Rob Clark 

Flag for range property types indicating that the value is a signed
integer rather than unsigned.  For range properties, the signed flag
will trigger use of signed integer comparisions, to handle negative
values properly.
---
 drivers/gpu/drm/drm_crtc.c |   10 --
 include/drm/drm_crtc.h |9 +
 include/drm/drm_mode.h |2 ++
 3 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 2b4526e..e62ae6a 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3210,9 +3210,15 @@ EXPORT_SYMBOL(drm_mode_connector_update_edid_property);
 static bool drm_property_change_is_valid(struct drm_property *property,
 uint64_t value)
 {
-   if (property->flags & DRM_MODE_PROP_IMMUTABLE)
+   if (property->flags & DRM_MODE_PROP_IMMUTABLE) {
return false;
-   if (property->flags & DRM_MODE_PROP_RANGE) {
+   } else if (property->flags & 
(DRM_MODE_PROP_RANGE|DRM_MODE_PROP_SIGNED)) {
+   int64_t svalue = U642I64(value);
+   if (svalue < U642I64(property->values[0]) ||
+   svalue > U642I64(property->values[1]))
+   return false;
+   return true;
+   } else if (property->flags & DRM_MODE_PROP_RANGE) {
if (value < property->values[0] || value > property->values[1])
return false;
return true;
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 0dbf2be..dc67f5f 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -61,6 +61,15 @@ struct drm_object_properties {
uint64_t values[DRM_OBJECT_MAX_PROPERTY];
 };

+static inline int64_t U642I64(uint64_t val)
+{
+   return (int64_t)*((int64_t *));
+}
+static inline uint64_t I642U64(int64_t val)
+{
+   return (uint64_t)*((uint64_t *));
+}
+
 /*
  * Note on terminology:  here, for brevity and convenience, we refer to 
connector
  * control chips as 'CRTCs'.  They can control any type of connector, VGA, 
LVDS,
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 15689d4..9cc0336 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -241,6 +241,8 @@ struct drm_mode_get_connector {
  * be changed dynamically, assuming the pixel format does not change.
  */
 #define DRM_MODE_PROP_DYNAMIC  (1<<24)
+/* Indicates that numeric property values are signed rather than unsigned: */
+#define DRM_MODE_PROP_SIGNED   (1<<25)

 struct drm_mode_property_enum {
__u64 value;
-- 
1.7.9.5

[RFC 03/11] drm: add DRM_MODE_PROP_DYNAMIC property flag

From: Rob Clark 

This indicates to userspace that the property is something that can
be set dynamically without requiring a "test" step to check if the
hw is capable.  This allows a userspace compositor, such as weston,
to avoid an extra ioctl to check whether it needs to fall-back to
GPU to composite some surface prior to submission of GPU render
commands.
---
 include/drm/drm_mode.h |9 +
 1 file changed, 9 insertions(+)

diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index cee4c53..15689d4 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -232,6 +232,15 @@ struct drm_mode_get_connector {
 #define DRM_MODE_PROP_BLOB (1<<4)
 #define DRM_MODE_PROP_BITMASK  (1<<5) /* bitmask of enumerated types */
 #define DRM_MODE_PROP_OBJECT   (1<<6) /* drm mode object */
+/* Properties that are not dynamic cannot safely be changed without a
+ * atomic-modeset / atomic-pageflip test step.  But if userspace is
+ * only changing dynamic properties, it is guaranteed that the change
+ * will not exceed hw limits, so no test step is required.
+ *
+ * Note that fb_id properties are a bit ambiguous.. they of course can
+ * be changed dynamically, assuming the pixel format does not change.
+ */
+#define DRM_MODE_PROP_DYNAMIC  (1<<24)

 struct drm_mode_property_enum {
__u64 value;
-- 
1.7.9.5

[RFC 02/11] drm: add object property type

From: Rob Clark 

An object property is an id (idr) for a drm mode object.  This
will allow a property to be used set/get a framebuffer, CRTC, etc.
---
 drivers/gpu/drm/drm_crtc.c |   35 ++-
 include/drm/drm_crtc.h |   10 ++
 include/drm/drm_mode.h |1 +
 3 files changed, 41 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 3a087cf..2b4526e 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2756,6 +2756,8 @@ struct drm_property *drm_property_create(struct 
drm_device *dev, int flags,
if (!property)
return NULL;

+   property->dev = dev;
+
if (num_values) {
property->values = kzalloc(sizeof(uint64_t)*num_values, 
GFP_KERNEL);
if (!property->values)
@@ -2859,6 +2861,23 @@ struct drm_property *drm_property_create_range(struct 
drm_device *dev, int flags
 }
 EXPORT_SYMBOL(drm_property_create_range);

+struct drm_property *drm_property_create_object(struct drm_device *dev,
+int flags, const char *name, uint32_t 
type)
+{
+   struct drm_property *property;
+
+   flags |= DRM_MODE_PROP_OBJECT;
+
+   property = drm_property_create(dev, flags, name, 1);
+   if (!property)
+   return NULL;
+
+   property->values[0] = type;
+
+   return property;
+}
+EXPORT_SYMBOL(drm_property_create_object);
+
 int drm_property_add_enum(struct drm_property *property, int index,
  uint64_t value, const char *name)
 {
@@ -3203,6 +3222,11 @@ static bool drm_property_change_is_valid(struct 
drm_property *property,
for (i = 0; i < property->num_values; i++)
valid_mask |= (1ULL << property->values[i]);
return !(value & ~valid_mask);
+   } else if (property->flags & DRM_MODE_PROP_OBJECT) {
+   /* a zero value for an object property translates to null: */
+   if (value)
+   return true;
+   return drm_property_get_obj(property, value) != NULL;
} else {
int i;
for (i = 0; i < property->num_values; i++)
@@ -3243,7 +3267,7 @@ static int drm_mode_connector_set_obj_prop(struct 
drm_connector *connector,

/* store the property value if successful */
if (!ret)
-   drm_connector_property_set_value(connector, property, value);
+   drm_object_property_set_value(>base, property, 
value);
return ret;
 }

@@ -3275,9 +3299,8 @@ static int drm_mode_plane_set_obj_prop(struct drm_plane 
*plane,
return ret;
 }

-static int drm_mode_set_obj_prop(struct drm_device *dev,
-   struct drm_mode_object *obj, void *state,
-   struct drm_property *property, uint64_t value)
+static int drm_mode_set_obj_prop(struct drm_mode_object *obj,
+   void *state, struct drm_property *property, uint64_t value)
 {
if (drm_property_change_is_valid(property, value)) {
switch (obj->type) {
@@ -3291,6 +3314,8 @@ static int drm_mode_set_obj_prop(struct drm_device *dev,
return drm_mode_plane_set_obj_prop(obj_to_plane(obj),
state, property, value);
}
+   } else {
+   DRM_DEBUG("invalid value: %s = %llx\n", property->name, value);
}

return -EINVAL;
@@ -3325,7 +3350,7 @@ static int drm_mode_set_obj_prop_id(struct drm_device 
*dev, void *state,
return -EINVAL;
property = obj_to_property(prop_obj);

-   return drm_mode_set_obj_prop(dev, arg_obj, state, property, value);
+   return drm_mode_set_obj_prop(arg_obj, state, property, value);
 }

 int drm_mode_obj_get_properties_ioctl(struct drm_device *dev, void *data,
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index a609190..0dbf2be 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -291,6 +291,7 @@ struct drm_property {
char name[DRM_PROP_NAME_LEN];
uint32_t num_values;
uint64_t *values;
+   struct drm_device *dev;

struct list_head enum_blob_list;
 };
@@ -955,6 +956,8 @@ struct drm_property *drm_property_create_bitmask(struct 
drm_device *dev,
 struct drm_property *drm_property_create_range(struct drm_device *dev, int 
flags,
 const char *name,
 uint64_t min, uint64_t max);
+struct drm_property *drm_property_create_object(struct drm_device *dev,
+int flags, const char *name, uint32_t 
type);
 extern void drm_property_destroy(struct drm_device *dev, struct drm_property 
*property);
 extern int drm_property_add_enum(struct drm_property *property, int index,
 uint64_t value, const char *name);
@@ -974,6 +977,13

[RFC 01/11] drm: add atomic fxns

From: Rob Clark 

The 'atomic' mechanism allows for multiple properties to be updated,
checked, and commited atomically.  This will be the basis of atomic-
modeset and nuclear-pageflip.

The basic flow is:

   state = dev->atomic_begin();
   for (... one or more ...)
  obj->set_property(obj, state, prop, value);
   if (dev->atomic_check(state))
  dev->atomic_commit(state, event);
   dev->atomic_end(state);

The split of check and commit steps is to allow for ioctls with a
test-only flag (which would skip the commit step).

The atomic functions are mandatory, as they will end up getting
called from enough places that it is easier not to have to bother
with if-null checks everywhere.

TODO:
  + add some stub atomic functions that can be used by drivers
until they are updated to support atomic operations natively
  + roll-back previous property values if check/commit fails, so
userspace doesn't see incorrect values.
---
 drivers/gpu/drm/drm_crtc.c |  126 +++-
 include/drm/drmP.h |   52 ++
 include/drm/drm_crtc.h |8 +--
 3 files changed, 135 insertions(+), 51 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 7552675..3a087cf 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3227,12 +3227,11 @@ int drm_mode_connector_property_set_ioctl(struct 
drm_device *dev,
return drm_mode_obj_set_property_ioctl(dev, _set_prop, file_priv);
 }

-static int drm_mode_connector_set_obj_prop(struct drm_mode_object *obj,
-  struct drm_property *property,
+static int drm_mode_connector_set_obj_prop(struct drm_connector *connector,
+  void *state, struct drm_property 
*property,
   uint64_t value)
 {
int ret = -EINVAL;
-   struct drm_connector *connector = obj_to_connector(obj);

/* Do DPMS ourselves */
if (property == connector->dev->mode_config.dpms_property) {
@@ -3240,7 +3239,7 @@ static int drm_mode_connector_set_obj_prop(struct 
drm_mode_object *obj,
(*connector->funcs->dpms)(connector, (int)value);
ret = 0;
} else if (connector->funcs->set_property)
-   ret = connector->funcs->set_property(connector, property, 
value);
+   ret = connector->funcs->set_property(connector, state, 
property, value);

/* store the property value if successful */
if (!ret)
@@ -3248,36 +3247,87 @@ static int drm_mode_connector_set_obj_prop(struct 
drm_mode_object *obj,
return ret;
 }

-static int drm_mode_crtc_set_obj_prop(struct drm_mode_object *obj,
- struct drm_property *property,
+static int drm_mode_crtc_set_obj_prop(struct drm_crtc *crtc,
+ void *state, struct drm_property 
*property,
  uint64_t value)
 {
int ret = -EINVAL;
-   struct drm_crtc *crtc = obj_to_crtc(obj);

if (crtc->funcs->set_property)
-   ret = crtc->funcs->set_property(crtc, property, value);
+   ret = crtc->funcs->set_property(crtc, state, property, value);
if (!ret)
-   drm_object_property_set_value(obj, property, value);
+   drm_object_property_set_value(>base, property, value);

return ret;
 }

-static int drm_mode_plane_set_obj_prop(struct drm_mode_object *obj,
- struct drm_property *property,
+static int drm_mode_plane_set_obj_prop(struct drm_plane *plane,
+ void *state, struct drm_property 
*property,
  uint64_t value)
 {
int ret = -EINVAL;
-   struct drm_plane *plane = obj_to_plane(obj);

if (plane->funcs->set_property)
-   ret = plane->funcs->set_property(plane, property, value);
+   ret = plane->funcs->set_property(plane, state, property, value);
if (!ret)
-   drm_object_property_set_value(obj, property, value);
+   drm_object_property_set_value(>base, property, value);

return ret;
 }

+static int drm_mode_set_obj_prop(struct drm_device *dev,
+   struct drm_mode_object *obj, void *state,
+   struct drm_property *property, uint64_t value)
+{
+   if (drm_property_change_is_valid(property, value)) {
+   switch (obj->type) {
+   case DRM_MODE_OBJECT_CONNECTOR:
+   return 
drm_mode_connector_set_obj_prop(obj_to_connector(obj),
+   state, property, value);
+   case DRM_MODE_OBJECT_CRTC:
+   return drm_mode_crtc_set_obj_prop(obj_to_crtc(obj),
+   state, property, value);
+   case

[RFC 00/11] atomic pageflip (v2)

From: Rob Clark 

This is following a bit the approach that Ville is taking for atomic-
modeset, in that it is switching over to using properties for everything.
The advantage of this approach is that it makes it easier to add new
attributes to set as part of a page-flip (and even opens the option to
add new object types).

The basic principles are:
 a) split out object state (in this case, plane and crtc, although I
expect more to be added as atomic-modeset is added) into seperate
structures that can be atomically commited or rolled back.  The
property values array is also split out into the state structs,
so that the property values visible to userspace automatically
reflect the current state (ie. property changes are either
committed or discarded depending on whether the state changes
are committed or discarded).
 b) expand the object property API (set_property()) to take a state
object.  The obj->set_property() simply updates the state object
without actually applying the changes to the hw.
 c) after all the property updates are done, the updated state can
be checked for correctness and against the hw capabilities, and
then either discarded or committed atomically.

Since we need to include properties in the atomic-pageflip scheme,
doing everything via properties avoids updating a bunch of additional
driver provided callbacks.  Instead we just drop crtc->page_flip()
and plane->update_plane().  By splitting out the object's mutable
state into drm_{plane,crtc,etc}_state structs (which are wrapped by
the individual drivers to add their own hw specific state), we can
use some helpers (drm_{plane,crtc,etc}_set_property() and
drm_{plane,crtc,etc}_check_state()) to keep core error checking in
drm core and avoid pushing the burden of dealing with common
properties to the individual drivers.

The intention is for this to also simplify atomic-modeset, by
providing some of the necessary infrastructure (object property types,
signed property values, and property's whose usespace visible values
automatically tracks the object state which is either committed or
discarded depending on whether the state change was committed to hw
or not) which will also be needed for atomic-modeset.

So far, I've only updated omapdrm to the new APIs, as a proof of
concept.  Only a few drivers support drm plane, so I expect the
updates to convert drm-plane to properties should not be so hard.
Possibly for crtc/pageflip we might need to have a transition period
where we still support crtc->page_flip() code path until all drivers
are updated.

My complete branch is here:

  https://github.com/robclark/kernel-omap4/commits/drm_nuclear
  git://github.com/robclark/kernel-omap4.git drm_nuclear

Open points (I think) are:
 + should atomic-pageflip support flips on multiple CRTCs.  I think
   it at least simplifies things if the driver knows up front which
   CRTC(s) are involved, and whether the operation is modeset (sync)
   or pageflip (async).
 + How to deal w/ hardware restrictions which span multiple CRTCs.
   One idea is to get rid of the test flag in the atomic-pageflip
   ioctl, and always do test operations via atomic-modeset ioctl
   w/ the test flag.

Rob Clark (11):
  drm: add atomic fxns
  drm: add object property type
  drm: add DRM_MODE_PROP_DYNAMIC property flag
  drm: add DRM_MODE_PROP_SIGNED property flag
  drm: split property values out
  drm: convert plane to properties
  drm: add drm_plane_state
  drm: convert page_flip to properties
  drm: add drm_crtc_state
  drm: atomic pageflip
  drm/omap: update for atomic age

 drivers/gpu/drm/drm_crtc.c|  838 -
 drivers/gpu/drm/drm_crtc_helper.c |   51 +-
 drivers/gpu/drm/drm_drv.c |1 +
 drivers/gpu/drm/drm_fb_helper.c   |   11 +-
 drivers/staging/omapdrm/Makefile  |1 +
 drivers/staging/omapdrm/omap_atomic.c |  339 +
 drivers/staging/omapdrm/omap_atomic.h |   52 ++
 drivers/staging/omapdrm/omap_crtc.c   |  246 +-
 drivers/staging/omapdrm/omap_drv.c|   21 +-
 drivers/staging/omapdrm/omap_drv.h|   45 +-
 drivers/staging/omapdrm/omap_fb.c |   44 +-
 drivers/staging/omapdrm/omap_plane.c  |  296 ++--
 include/drm/drm.h |2 +
 include/drm/drmP.h|   52 ++
 include/drm/drm_crtc.h|  179 +--
 include/drm/drm_mode.h|   50 ++
 16 files changed, 1607 insertions(+), 621 deletions(-)
 create mode 100644 drivers/staging/omapdrm/omap_atomic.c
 create mode 100644 drivers/staging/omapdrm/omap_atomic.h

-- 
1.7.9.5

[PATCH] drm: change ioctl permissions

From: Rob Clark 

Previously read-only KMS ioctls had some somewhat inconsistent settings
regarding whether mastership was required.  For example, GETRESOURCES
did not require master, but GETPLANERESOURCES, GETPROPERTY, etc. did.

At least for debugging, it is nice to be able to use modetest to dump
property values while another process is master, and there seems to
be no harm in allowing read-only access to the KMS state to other
processes.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_drv.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 9238de4..73e5633 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -140,10 +140,10 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_PRIME_HANDLE_TO_FD, 
drm_prime_handle_to_fd_ioctl, DRM_AUTH|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_PRIME_FD_TO_HANDLE, 
drm_prime_fd_to_handle_ioctl, DRM_AUTH|DRM_UNLOCKED),

-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES, drm_mode_getplane_res, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANERESOURCES, drm_mode_getplane_res, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCRTC, drm_mode_getcrtc, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETCRTC, drm_mode_setcrtc, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANE, drm_mode_getplane, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPLANE, drm_mode_getplane, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETPLANE, drm_mode_setplane, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_CURSOR, drm_mode_cursor_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETGAMMA, drm_mode_gamma_get_ioctl, 
DRM_UNLOCKED),
@@ -152,9 +152,9 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETCONNECTOR, drm_mode_getconnector, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_ATTACHMODE, drm_mode_attachmode_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_DETACHMODE, drm_mode_detachmode_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPERTY, drm_mode_getproperty_ioctl, 
DRM_MASTER | DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPERTY, drm_mode_getproperty_ioctl, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_SETPROPERTY, 
drm_mode_connector_property_set_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPBLOB, drm_mode_getblob_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETPROPBLOB, drm_mode_getblob_ioctl, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_GETFB, drm_mode_getfb, 
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB, drm_mode_addfb, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_ADDFB2, drm_mode_addfb2, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
@@ -164,7 +164,7 @@ static struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_DUMB, drm_mode_create_dumb_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_MAP_DUMB, drm_mode_mmap_dumb_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_DESTROY_DUMB, drm_mode_destroy_dumb_ioctl, 
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
-   DRM_IOCTL_DEF(DRM_IOCTL_MODE_OBJ_GETPROPERTIES, 
drm_mode_obj_get_properties_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+   DRM_IOCTL_DEF(DRM_IOCTL_MODE_OBJ_GETPROPERTIES, 
drm_mode_obj_get_properties_ioctl, DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_OBJ_SETPROPERTY, 
drm_mode_obj_set_property_ioctl, DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
 };

-- 
1.7.9.5

[RFC 0/9] nuclear pageflip

On Wed, Sep 12, 2012 at 01:00:19PM -0500, Clark, Rob wrote:
> On Wed, Sep 12, 2012 at 12:27 PM, Ville Syrj?l?
>  wrote:
> > On Wed, Sep 12, 2012 at 10:48:16AM -0500, Rob Clark wrote:
> >> But I think we could still do this w/ one ioctl per crtc for 
> >> atomic-pageflip.
> >
> > We could, if we want to sacrifice the synced multi display case. I just
> > think it might be a real use case at some point. IVI feels like the most
> > likely short term cadidate to me, but perhaps someone would finally
> > introduce some new style phone/tablet thingy. I have seen
> > concepts/prototypes of such multi display gadgets in the past, but the
> > industry apparently got a bit stuck on the rectangular slab with
> > touchscreen on one side design.
> 
> I could be wrong, but I think IVI the screens would normally be too
> far apart to matter?

I was thinking of something like a display on the dash that normally
sits low with only a small sliver visible, and extends upwards when
you fire up a movie player for example. Internally it could be made
up of two displays for power savings purposes.

> Anyways, it is really only a problem if you can't do two ioctl()s
> within one vblank period. If it actually turns out to be a real
> problem,

Well exactly that's the problem this whole atomic pageflip stuff is
trying to tackle, no? ;)

> we could always add later an ioctl that takes an array of
> 'struct drm_mode_crtc_atomic_page_flip's.  I'm not sure if this is
> really useful or not.. but maybe I'm thinking too much about how
> weston does it's rendering of different output's independently.

I'm just now thinking of surfaceflinger's way of doing things, with
its prepare and commit phases. If you need to issue two ioctls to handle
cloned displays, then you can end up in a somewhat funky situation.

Let's say you have a video overlay in use (one each display naturally),
and you increase the downscaling factor enough so that you now have
enough memory bandwith to support only one overlay. With independent
check ioctls for each display, you never have the full device state
available in the kernel, so each check succeeds during the prepare
phase. So you decide that you can keep using the video overlays.

You then proceed to commit the state, but after the first display has
been commited you get an error when trying to commit the second one.
What can you do now? The only option is to keep displaying the old
frame on the other displays for some time longer, and then on the
next frame you can switch to GPU composition. But on the next frame you
perhaps no longer need to use GPU composition, but since you can't
verify that in the prepare phase, you have no other option but to use
GPU composition.

So when you run into a configuration that can be supported only
partially, you get animation stalls on some displays due to skipped
frames, and you always have to fall back to GPU composition for the 
next frame.

If on the other hand you would check the whole state in one ioctl,
you'd get the error in the first prepare phase, and could fall back
to GPU composition immediately.

Am I too much of a perfectionst in considering such things? I don't
think so, but perhaps other people disagree.

> I wonder.. if you have some special hw setup where you can keep the
> multiple display's in sync-lock, maybe a special virtual crtc would
> work.  That way userspace it appears as a single display.  I'm not
> really sure how crazy that would be to implement.

Sure, add more abstraction layers and you can solve any problem :)

> But I think in the
> common case, where the displays are not vsync locked, treating the
> page flips of different crtc's independently, and rendering the
> contents for different outputs independently (like weston) makes the
> most sense.

My API design doesn't preclude that at all. In light of my android tale
above how would weston decide whether it can use overlays in such a
case?

-- 
Ville Syrj?l?
Intel OTC

[PATCH] gma600: Enable HDMI support

2012-09-12 Thread Alan Cox

From: Alan Cox 

There are still some mysteries left, in particular how (and in
fact if) the EDID is supposed to work on the HDMI port. However
the basic stuff now works and I can plug my Q550 into an HDMI
display and get the expected results.

Signed-off-by: Alan Cox 
---

 drivers/gpu/drm/gma500/oaktrail.h|6 
 drivers/gpu/drm/gma500/oaktrail_crtc.c   |8 +
 drivers/gpu/drm/gma500/oaktrail_device.c |2 
 drivers/gpu/drm/gma500/oaktrail_hdmi.c   |  366 +-
 4 files changed, 366 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/gma500/oaktrail.h 
b/drivers/gpu/drm/gma500/oaktrail.h
index f2f9f38..30adbbe 100644
--- a/drivers/gpu/drm/gma500/oaktrail.h
+++ b/drivers/gpu/drm/gma500/oaktrail.h
@@ -249,3 +249,9 @@ extern void oaktrail_hdmi_i2c_exit(struct pci_dev *dev);
 extern void oaktrail_hdmi_save(struct drm_device *dev);
 extern void oaktrail_hdmi_restore(struct drm_device *dev);
 extern void oaktrail_hdmi_init(struct drm_device *dev, struct 
psb_intel_mode_device *mode_dev);
+extern int oaktrail_crtc_hdmi_mode_set(struct drm_crtc *crtc, struct 
drm_display_mode *mode,
+   struct drm_display_mode 
*adjusted_mode, int x, int y,
+   struct drm_framebuffer *old_fb);
+extern void oaktrail_crtc_hdmi_dpms(struct drm_crtc *crtc, int mode);
+
+
diff --git a/drivers/gpu/drm/gma500/oaktrail_crtc.c 
b/drivers/gpu/drm/gma500/oaktrail_crtc.c
index cdafd2a..4ec2962 100644
--- a/drivers/gpu/drm/gma500/oaktrail_crtc.c
+++ b/drivers/gpu/drm/gma500/oaktrail_crtc.c
@@ -168,6 +168,11 @@ static void oaktrail_crtc_dpms(struct drm_crtc *crtc, int 
mode)
const struct psb_offset *map = _priv->regmap[pipe];
u32 temp;

+   if (pipe == 1) {
+   oaktrail_crtc_hdmi_dpms(crtc, mode);
+   return;
+   }
+
if (!gma_power_begin(dev, true))
return;

@@ -302,6 +307,9 @@ static int oaktrail_crtc_mode_set(struct drm_crtc *crtc,
uint64_t scalingType = DRM_MODE_SCALE_FULLSCREEN;
struct drm_connector *connector;

+   if (pipe == 1)
+   return oaktrail_crtc_hdmi_mode_set(crtc, mode, adjusted_mode, 
x, y, old_fb);
+
if (!gma_power_begin(dev, true))
return 0;

diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c 
b/drivers/gpu/drm/gma500/oaktrail_device.c
index cf49ba5..a177082 100644
--- a/drivers/gpu/drm/gma500/oaktrail_device.c
+++ b/drivers/gpu/drm/gma500/oaktrail_device.c
@@ -544,7 +544,7 @@ const struct psb_ops oaktrail_chip_ops = {
.accel_2d = 1,
.pipes = 2,
.crtcs = 2,
-   .hdmi_mask = (1 << 0),
+   .hdmi_mask = (1 << 1),
.lvds_mask = (1 << 0),
.cursor_needs_phys = 0,
.sgx_offset = MRST_SGX_OFFSET,
diff --git a/drivers/gpu/drm/gma500/oaktrail_hdmi.c 
b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
index 2eb3dc4..b0c83fa 100644
--- a/drivers/gpu/drm/gma500/oaktrail_hdmi.c
+++ b/drivers/gpu/drm/gma500/oaktrail_hdmi.c
@@ -155,6 +155,346 @@ static void oaktrail_hdmi_audio_disable(struct drm_device 
*dev)
HDMI_READ(HDMI_HCR);
 }

+static void wait_for_vblank(struct drm_device *dev)
+{
+   /* Wait for 20ms, i.e. one cycle at 50hz. */
+   mdelay(20);
+}
+
+static unsigned int htotal_calculate(struct drm_display_mode *mode)
+{
+   u32 htotal, new_crtc_htotal;
+
+   htotal = (mode->crtc_hdisplay - 1) | ((mode->crtc_htotal - 1) << 16);
+
+   /* 
+* 1024 x 768  new_crtc_htotal = 0x1024; 
+* 1280 x 1024 new_crtc_htotal = 0x0c34;
+*/
+   new_crtc_htotal = (mode->crtc_htotal - 1) * 200 * 1000 / mode->clock;
+
+   DRM_DEBUG_KMS("new crtc htotal 0x%4x\n", new_crtc_htotal);
+   return ((mode->crtc_hdisplay - 1) | (new_crtc_htotal << 16));
+}
+
+static void oaktrail_hdmi_find_dpll(struct drm_crtc *crtc, int target,
+   int refclk, struct oaktrail_hdmi_clock 
*best_clock)
+{
+   int np_min, np_max, nr_min, nr_max;
+   int np, nr, nf;
+
+   np_min = DIV_ROUND_UP(oaktrail_hdmi_limit.vco.min, target * 10);
+   np_max = oaktrail_hdmi_limit.vco.max / (target * 10);
+   if (np_min < oaktrail_hdmi_limit.np.min)
+   np_min = oaktrail_hdmi_limit.np.min;
+   if (np_max > oaktrail_hdmi_limit.np.max)
+   np_max = oaktrail_hdmi_limit.np.max;
+
+   nr_min = DIV_ROUND_UP((refclk * 1000), (target * 10 * np_max));
+   nr_max = DIV_ROUND_UP((refclk * 1000), (target * 10 * np_min));
+   if (nr_min < oaktrail_hdmi_limit.nr.min)
+   nr_min = oaktrail_hdmi_limit.nr.min;
+   if (nr_max > oaktrail_hdmi_limit.nr.max)
+   nr_max = oaktrail_hdmi_limit.nr.max;
+
+   np = DIV_ROUND_UP((refclk * 1000), (target * 10 * nr_max));
+   nr = DIV_ROUND_UP((refclk * 1000), (target * 10 * np));
+   nf = DIV_ROUND_CLOSEST((target * 10 * np * nr), refclk);
+

[RFC 1/9] drm: add atomic fxns

On Wed, Sep 12, 2012 at 12:35:01PM -0500, Rob Clark wrote:
> On Wed, Sep 12, 2012 at 11:57 AM, Jesse Barnes  
> wrote:
> > On Sun,  9 Sep 2012 22:03:14 -0500
> > Rob Clark  wrote:
> >
> >> From: Rob Clark 
> >>
> >> The 'atomic' mechanism allows for multiple properties to be updated,
> >> checked, and commited atomically.  This will be the basis of atomic-
> >> modeset and nuclear-pageflip.
> >>
> >> The basic flow is:
> >>
> >>state = dev->atomic_begin();
> >>for (... one or more ...)
> >>   obj->set_property(obj, state, prop, value);
> >>if (dev->atomic_check(state))
> >>   dev->atomic_commit(state, event);
> >>dev->atomic_end(state);
> >
> > I think the above is more suited to drm_crtc_helper code.  I think the
> > top level callback should contain the arrays and be a single "multi
> > flip" hook (or maybe a check then set double callback).  For some
> > drivers that'll end up being a lot simpler, rather than sprinkling
> > atomic handling code in all the set_property callbacks.
> 
> well, there are a few other places in drm_crtc.c where I want to use
> the new API, to avoid drivers having to support both atomic API and
> old set_plane/page_flip stuff.. the transactional API makes that a bit
> easier, I think.. or at least I don't have to construct an array on
> the stack.

Usually you would need to build up the full state anyway before you can
tell if it's good or bad. I don't see what some big array would buy here.

> > Having a transactional API just seems a little messier with both the
> > atomic state and per-property state to track and rollback in the case
> > of failure.
> 
> For the rollback, I think I'm just going to move the array of property
> values into drm_{crtc,plane,etc}_state.  That way, userspace doesn't
> see updated property values if they are not committed.  It makes the
> property value rollback automatic.

This was my original idea as well. Separate the current and future
states cleanly. At the moment it's all mixed up inside the objects
somewhere. I sort of abandoned the idea so that I could avoid touching
too much driver code while prototyping the atomic modesetting, but
that's certainly the way I would design the system.

-- 
Ville Syrj?l?
Intel OTC

[RFC 0/9] nuclear pageflip

On Wed, Sep 12, 2012 at 10:48:16AM -0500, Rob Clark wrote:
> On Wed, Sep 12, 2012 at 10:32 AM, Ville Syrj?l?
>  wrote:
> > On Wed, Sep 12, 2012 at 10:23:48AM -0500, Rob Clark wrote:
> >> On Wed, Sep 12, 2012 at 10:12 AM, Ville Syrj?l?
> >>  wrote:
> >> > On Wed, Sep 12, 2012 at 09:42:27AM -0500, Rob Clark wrote:
> >> >> On Wed, Sep 12, 2012 at 9:34 AM, Ville Syrj?l?
> >> >>  wrote:
> >> >> > On Wed, Sep 12, 2012 at 09:28:43AM -0500, Rob Clark wrote:
> >> >> >> On Wed, Sep 12, 2012 at 9:23 AM, Ville Syrj?l?
> >> >> >>  wrote:
> >> >> >> > On Wed, Sep 12, 2012 at 07:30:18AM -0500, Rob Clark wrote:
> >> >> >> >> On Wed, Sep 12, 2012 at 3:59 AM, Ville Syrj?l?
> >> >> >> >>  wrote:
> >> >> >> >> > On Tue, Sep 11, 2012 at 05:07:49PM -0500, Rob Clark wrote:
> >> >> >> >> >> On Tue, Sep 11, 2012 at 4:15 PM, Ben Widawsky  >> >> >> >> >> bwidawsk.net> wrote:
> >> >> >> >> >> > On Sun, 9 Sep 2012 22:19:59 -0500
> >> >> >> >> >> > Rob Clark  wrote:
> >> >> >> >> >> >
> >> >> >> >> >> >> On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark  >> >> >> >> >> >> linaro.org> wrote:
> >> >> >> >> >> >> > From: Rob Clark 
> >> >> >> >> >> >> >
> >> >> >> >> >> >> > This is following a bit the approach that Ville is taking 
> >> >> >> >> >> >> > for atomic-
> >> >> >> >> >> >> > modeset, in that it is switching over to using properties 
> >> >> >> >> >> >> > for everything.
> >> >> >> >> >> >> > The advantage of this approach is that it makes it easier 
> >> >> >> >> >> >> > to add new
> >> >> >> >> >> >> > attributes to set as part of a page-flip (and even opens 
> >> >> >> >> >> >> > the option to
> >> >> >> >> >> >> > add new object types).
> >> >> >> >> >> >>
> >> >> >> >> >> >> oh, and for those wondering what the hell this is all about,
> >> >> >> >> >> >> nuclear-pageflip is a pageflip that atomically updates the 
> >> >> >> >> >> >> CRTC layer
> >> >> >> >> >> >> and zero or more attached plane layers, optionally changing 
> >> >> >> >> >> >> various
> >> >> >> >> >> >> properties such as z-order (or even blending modes, etc) 
> >> >> >> >> >> >> atomically.
> >> >> >> >> >> >> It includes the option for a test step so userspace 
> >> >> >> >> >> >> compositor can
> >> >> >> >> >> >> test a proposed configuration (if any properties not marked 
> >> >> >> >> >> >> as
> >> >> >> >> >> >> 'dynamic' are updated).  This intended to allow, for 
> >> >> >> >> >> >> example, weston
> >> >> >> >> >> >> compositor to synchronize updates to plane (sprite) layers 
> >> >> >> >> >> >> with CRTC
> >> >> >> >> >> >> layer.
> >> >> >> >> >> >>
> >> >> >> >> >> >
> >> >> >> >> >> > Can we please name this something different? I complained 
> >> >> >> >> >> > about this in
> >> >> >> >> >> > IRC, but I don't know if you hang around in #intel-gfx.
> >> >> >> >> >> >
> >> >> >> >> >> > Some suggestions:
> >> >> >> >> >> > multiplane pageflip
> >> >> >> >> >> > muliplane atomic pageflip
> >> >> >> >> >> > atomic multiplane pageflip
> >> >> >> >> >> > atomic multiflip
> >> >> >> >> >> > pageflip of atomic and multiplane nature
> >> >> >> >> >> >
> >> >> >> >> >> > Nuclear is not at all descriptive and requires as your 
> >> >> >> >> >> > response shows
> >> >> >> >> >> > :-)
> >> >> >> >> >> >
> >> >> >> >> >>
> >> >> >> >> >> fair enough.. I was originally calling it atomic-pageflip until
> >> >> >> >> >> someone (I don't remember who) started calling it 
> >> >> >> >> >> nuclear-pageflip to
> >> >> >> >> >> differentiate from atomic-modeset.  But IMO we could just call 
> >> >> >> >> >> the two
> >> >> >> >> >> ioclts atomic-modeset and atomic-pageflip.  (Or even modeset2 
> >> >> >> >> >> and
> >> >> >> >> >> pageflip2, but that seems much more boring)
> >> >> >> >> >
> >> >> >> >> > My plan has been to use the same ioctl for both uses. They'll 
> >> >> >> >> > need
> >> >> >> >> > nearly identical handling anyway on the ioctl level. I have 
> >> >> >> >> > something
> >> >> >> >> > semi-working currently, but I need to clean it up a bit before 
> >> >> >> >> > I can
> >> >> >> >> > show it to anyone.
> >> >> >> >>
> >> >> >> >> I do think the atomic-pageflip ioctl really should take the 
> >> >> >> >> crtc-id..
> >> >> >> >> so probably should be two ioctls, but nearly identical
> >> >> >> >
> >> >> >> > But then you can't support atomic pageflips across multiple crtcs 
> >> >> >> > even
> >> >> >> > if the hardware would allow it. I would hate to add such 
> >> >> >> > limitation to
> >> >> >> > the API. I can immediately think of a use case; combining several
> >> >> >> > smaller displays to form a single larger display.
> >> >> >> >
> >> >> >> > With a unified API you could just add some kind of flag that tells 
> >> >> >> > the
> >> >> >> > kernel that user space really wants an atomic update, and if the
> >> >> >> > driver/hardware can't do it, it can return an error.
> >> >> >>
> >> >> >> well, that is really only a problem for X11..  and atomic flip across
> >> >> >> multiple crtc's is a potential mess from performance standpoint 
> >> >>

[REVIEW][PATCH 12/15] userns: Convert drm to use kuid and kgid and struct pid where appropriate

2012-09-12 Thread Eric W. Biederman

Dave Airlie  writes:

>> Blink Blink this had not been converted to use struct pid ages ago?
>>
>> - On drm open capture the openers kuid and struct pid.
>> - On drm close release the kuid and struct pid
>> - When reporting the uid and pid convert the kuid and struct pid
>>   into values in the appropriate namespace.
>>
>
> Hi Eric,
>
> I'm fine with this seems okay, do you want me to merge it via
> drm-next?

My plan is to merge it via my user namespace tree.  And since you have
responed positively I will add your acked-by.  There are some nice
synergies when I get all of the changes in one tree.

If for some reason you want to carry this in your drm tree we can work
something out.

In this case I expect the change isn't big enough to worry about.

Eric

[PATCH 8/8] drm/radeon: rework the VM code a bit more

On 12.09.2012 15:54, Jerome Glisse wrote:
> On Wed, Sep 12, 2012 at 8:08 AM, Christian K?nig
>  wrote:
>> On 11.09.2012 18:11, Jerome Glisse wrote:
>>> On Tue, Sep 11, 2012 at 10:10 AM, Christian K?nig
>>>  wrote:
 Roughly based on how nouveau is handling it. Instead of
 adding the bo_va when the address is set add the bo_va
 when the handle is opened, but set the address to zero
 until userspace tells us where to place it.

 This fixes another bunch of problems with glamor.
>>> What exactly are the fix ? I don't see why this change is needed. It
>>> make things more complicated in my view.
>> Applications can open GEM Handles multiple times, so what happens is that
>> (for example) the DDX creates an BO to back a pixmap, hands that over to
>> GLAMOR and than closes the handle again (a bit later and also not all the
>> times).
>>
>> In the end the kernel complains that bo x isn't in vm y, what makes sense
>> cause the DDX has removed the mapping by closing the handle. What we don't
>> have in this picture is that the handle was opened two times, once for
>> creation and once for handing it over to GLAMOR.
>>
>> I see three possible solutions to that problem:
>> 1. Remember how many times a handle was opened in a vm context, that is what
>> this patch does.
>>
>> 2. Instead of removing the mapping on closing the handle we change usespace
>> to remove the mapping separately.
>>
>> 3. Change GEM to only call the open/close callbacks when the handle is
>> opened and closed for the first/last time in a process context, that would
>> also eliminate the refcounting nouveau is currently doing.
>>
>> Feel free to choose one, I just have implemented number 1 because that was
>> the simplest way to go (for me).
>>
>> Cheers,
>> Christian.
> I am all ok for the refcounting part but i don't think the always add
> a va to bo is a good idea. It just add more code for no good reason.
Always adding a va to a bo is only an issue on cayman, on SI and further 
we will need a va for each bo anyway.

The problem with not adding a va is that I just need something to 
actually count the number of references in.

So there isn't so much of an alternative to adding the va on opening the 
handle.

Cheers,
Christian.

>
> Cheers,
> Jerome
>
 Signed-off-by: Christian K?nig 
 ---
drivers/gpu/drm/radeon/radeon.h  |   30 ---
drivers/gpu/drm/radeon/radeon_gart.c |  147
 ++
drivers/gpu/drm/radeon/radeon_gem.c  |   47 +--
3 files changed, 153 insertions(+), 71 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/radeon.h
 b/drivers/gpu/drm/radeon/radeon.h
 index 8cca1d2..4d67f0f 100644
 --- a/drivers/gpu/drm/radeon/radeon.h
 +++ b/drivers/gpu/drm/radeon/radeon.h
 @@ -292,17 +292,20 @@ struct radeon_mman {

/* bo virtual address in a specific vm */
struct radeon_bo_va {
 -   /* bo list is protected by bo being reserved */
 +   /* protected by bo being reserved */
   struct list_headbo_list;
 -   /* vm list is protected by vm mutex */
 -   struct list_headvm_list;
 -   /* constant after initialization */
 -   struct radeon_vm*vm;
 -   struct radeon_bo*bo;
   uint64_tsoffset;
   uint64_teoffset;
   uint32_tflags;
   boolvalid;
 +   unsignedref_count;
>>> unsigned refcount is a recipe for failure, if somehow you over unref
>>> then you va will stay alive forever and this overunref will probably
>>> go unnoticed.
>>>
 +
 +   /* protected by vm mutex */
 +   struct list_headvm_list;
 +
 +   /* constant after initialization */
 +   struct radeon_vm*vm;
 +   struct radeon_bo*bo;
};

struct radeon_bo {
 @@ -1848,14 +1851,15 @@ void radeon_vm_bo_invalidate(struct radeon_device
 *rdev,
struct radeon_bo *bo);
struct radeon_bo_va *radeon_vm_bo_find(struct radeon_vm *vm,
  struct radeon_bo *bo);
 -int radeon_vm_bo_add(struct radeon_device *rdev,
 -struct radeon_vm *vm,
 -struct radeon_bo *bo,
 -uint64_t offset,
 -uint32_t flags);
 +struct radeon_bo_va *radeon_vm_bo_add(struct radeon_device *rdev,
 + struct radeon_vm *vm,
 + struct radeon_bo *bo);
 +int radeon_vm_bo_set_addr(struct radeon_device *rdev,
 + struct radeon_bo_va *bo_va,
 +

[PATCH 8/8] drm/radeon: rework the VM code a bit more

On 12.09.2012 15:54, Jerome Glisse wrote:
> On Wed, Sep 12, 2012 at 8:08 AM, Christian K?nig
>  wrote:
>> On 11.09.2012 18:11, Jerome Glisse wrote:
>>> On Tue, Sep 11, 2012 at 10:10 AM, Christian K?nig
>>>  wrote:
 Roughly based on how nouveau is handling it. Instead of
 adding the bo_va when the address is set add the bo_va
 when the handle is opened, but set the address to zero
 until userspace tells us where to place it.

 This fixes another bunch of problems with glamor.
>>> What exactly are the fix ? I don't see why this change is needed. It
>>> make things more complicated in my view.
>> Applications can open GEM Handles multiple times, so what happens is that
>> (for example) the DDX creates an BO to back a pixmap, hands that over to
>> GLAMOR and than closes the handle again (a bit later and also not all the
>> times).
>>
>> In the end the kernel complains that bo x isn't in vm y, what makes sense
>> cause the DDX has removed the mapping by closing the handle. What we don't
>> have in this picture is that the handle was opened two times, once for
>> creation and once for handing it over to GLAMOR.
>>
>> I see three possible solutions to that problem:
>> 1. Remember how many times a handle was opened in a vm context, that is what
>> this patch does.
>>
>> 2. Instead of removing the mapping on closing the handle we change usespace
>> to remove the mapping separately.
>>
>> 3. Change GEM to only call the open/close callbacks when the handle is
>> opened and closed for the first/last time in a process context, that would
>> also eliminate the refcounting nouveau is currently doing.
>>
>> Feel free to choose one, I just have implemented number 1 because that was
>> the simplest way to go (for me).
>>
>> Cheers,
>> Christian.
> I am all ok for the refcounting part but i don't think the always add
> a va to bo is a good idea. It just add more code for no good reason.
Always adding a va to a bo is only an issue on cayman, on SI and further 
we will need a va for each bo anyway.

The problem with not adding a va is that I just need something to 
actually count the number of references in.

So there isn't so much of an alternative to adding the va on opening the 
handle.

Cheers,
Christian.

>
> Cheers,
> Jerome
>
 Signed-off-by: Christian K?nig 
 ---
drivers/gpu/drm/radeon/radeon.h  |   30 ---
drivers/gpu/drm/radeon/radeon_gart.c |  147
 ++
drivers/gpu/drm/radeon/radeon_gem.c  |   47 +--
3 files changed, 153 insertions(+), 71 deletions(-)

 diff --git a/drivers/gpu/drm/radeon/radeon.h
 b/drivers/gpu/drm/radeon/radeon.h
 index 8cca1d2..4d67f0f 100644
 --- a/drivers/gpu/drm/radeon/radeon.h
 +++ b/drivers/gpu/drm/radeon/radeon.h
 @@ -292,17 +292,20 @@ struct radeon_mman {

/* bo virtual address in a specific vm */
struct radeon_bo_va {
 -   /* bo list is protected by bo being reserved */
 +   /* protected by bo being reserved */
   struct list_headbo_list;
 -   /* vm list is protected by vm mutex */
 -   struct list_headvm_list;
 -   /* constant after initialization */
 -   struct radeon_vm*vm;
 -   struct radeon_bo*bo;
   uint64_tsoffset;
   uint64_teoffset;
   uint32_tflags;
   boolvalid;
 +   unsignedref_count;
>>> unsigned refcount is a recipe for failure, if somehow you over unref
>>> then you va will stay alive forever and this overunref will probably
>>> go unnoticed.
>>>
 +
 +   /* protected by vm mutex */
 +   struct list_headvm_list;
 +
 +   /* constant after initialization */
 +   struct radeon_vm*vm;
 +   struct radeon_bo*bo;
};

struct radeon_bo {
 @@ -1848,14 +1851,15 @@ void radeon_vm_bo_invalidate(struct radeon_device
 *rdev,
struct radeon_bo *bo);
struct radeon_bo_va *radeon_vm_bo_find(struct radeon_vm *vm,
  struct radeon_bo *bo);
 -int radeon_vm_bo_add(struct radeon_device *rdev,
 -struct radeon_vm *vm,
 -struct radeon_bo *bo,
 -uint64_t offset,
 -uint32_t flags);
 +struct radeon_bo_va *radeon_vm_bo_add(struct radeon_device *rdev,
 + struct radeon_vm *vm,
 + struct radeon_bo *bo);
 +int radeon_vm_bo_set_addr(struct radeon_device *rdev,
 + struct radeon_bo_va *bo_va,
 +

[PATCH 2/2] tests/testdisplay: Test the stereo 3D modes

2012-09-12 Thread Lespiau, Damien

Because this patch is adding a few test images, it's about 6MB
uncompressed, it can be downloaded from:

http://damien.lespiau.name/files/patches/0002-tests-testdisplay-Test-the-stereo-3D-modes.patch.bz2

-- 
Damien

[PATCH 2/2] tests/testdisplay: Test the stereo 3D modes

From: Damien Lespiau 

Now that modes have flags to describe which 3d formats the sink
supports, it's time to test them.

The new test cycles through the supported 3D formats and paint 3D
stereoscopic images taken from publicly available samples:
  http://www.quantumdata.com/apps/3D/sample_BMP.asp

Signed-off-by: Damien Lespiau 
---
 tests/1080FP.png| Bin 0 -> 2291944 bytes
 tests/1080TB.png| Bin 0 -> 1137594 bytes
 tests/720FP.png | Bin 0 -> 1088754 bytes
 tests/720TB.png | Bin 0 -> 555755 bytes
 tests/testdisplay.c | 216 +++-
 5 files changed, 213 insertions(+), 3 deletions(-)
 create mode 100644 tests/1080FP.png
 create mode 100644 tests/1080TB.png
 create mode 100644 tests/720FP.png
 create mode 100644 tests/720TB.png

diff --git a/tests/1080FP.png b/tests/1080FP.png
new file mode 100644
index 
..92f668a74d505d99eed923fc5f6d9e078c1da696
GIT binary patch
literal 2291944
zcmV)KK)Sz)P)Px#AY({UO#lFTCIA3{ga82g0001h=l}q9FaQARU;qF*
zm;eA5aGbhPJOBU#08mU+MSq*;daU??so#aT{E)fdkF4^6sLz3>ypgJ?m#LS7qlKKd
zsF0kOa*CH*bBA_(h>o16o3w;~mx5%2Ut)GoS!h61W-vHNDMnWnVk|p9Dn?K+NMb5GPefaLJW+>4TbEI1m~MQqa*C!*zc
zhEO#|8dh9CTWL;4ODr}#C{;{AKvfzwI~pf886`Ff9Vi!iif)gKZ*Y5HZEHbRTQF~W
zP+)dJMN1k%OFlk5J#K7IZ){(WjDL=tyPvzzp1j|lyzrLF{9t^=EIoEAJ7Hpor+JyW
zVtj{ymSB{paF3^9hNM$|mQiknLXVkYkeYCBc|xbQaE^;$GDQn5ED9|w85J88C^se}
zEF}#M6$l9h5Elv=Ckj_wPO-#>zQ>5F#df8tVy3HbtG9zSI}0Tp7Zw{Q6DBAn9157V
zYkrABWoj`_SsPJi8cbvhK2-}fEhmDdsDq at Lj***LXMAIXa6C#+U3##0i at 1B3m|SXL
zd3|<}tGlkXxthe`NM?LuhL~P;GJ=+Gj+jz^iBXWZ(07c_b&7&^b$N|_VX~~IsL9}`
z%kwiwdZ?>{UUeH+cbQ~-cvnzgSX^Lun$U-w&^|m(R$Y5(dYO=`>2YKhQ1P$I!LZ(HtXT#N749(bKZk

[PATCH 1/2] lib: Dump information about the supported 3D stereo formats

From: Damien Lespiau 

When dumping the details of a mode, let's add the 3D formats the mode
supports.

Signed-off-by: Damien Lespiau 
---
 lib/drmtest.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/lib/drmtest.c b/lib/drmtest.c
index 8df9797..4d5a67c 100644
--- a/lib/drmtest.c
+++ b/lib/drmtest.c
@@ -812,7 +812,15 @@ unsigned int kmstest_create_fb(int fd, int width, int 
height, int bpp,

 void kmstest_dump_mode(drmModeModeInfo *mode)
 {
-   printf("  %s %d %d %d %d %d %d %d %d %d 0x%x 0x%x %d\n",
+   bool stereo_3d = mode->flags & DRM_MODE_FLAG_3D_MASK;
+   char flags_str[32];
+
+   snprintf(flags_str, sizeof(flags_str), " (3D:%s%s%s)",
+mode->flags & DRM_MODE_FLAG_3D_TOP_BOTTOM ? " TB": "",
+mode->flags & DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF ? " SBSH": "",
+mode->flags & DRM_MODE_FLAG_3D_FRAME_PACKING ? " FP": "");
+
+   printf("  %s %d %d %d %d %d %d %d %d %d 0x%x 0x%x %d%s\n",
   mode->name,
   mode->vrefresh,
   mode->hdisplay,
@@ -825,7 +833,8 @@ void kmstest_dump_mode(drmModeModeInfo *mode)
   mode->vtotal,
   mode->flags,
   mode->type,
-  mode->clock);
+  mode->clock,
+  stereo_3d ? flags_str : "");
fflush(stdout);
 }

-- 
1.7.11.4

[PATCH] Sync the mode flags for the stereo 3D formats

From: Damien Lespiau 

Signed-off-by: Damien Lespiau 
---
 include/drm/drm_mode.h | 35 +--
 xf86drmMode.h  | 35 +--
 2 files changed, 42 insertions(+), 28 deletions(-)

diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 62ba997..1ab936c 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -42,20 +42,27 @@

 /* Video mode flags */
 /* bit compatible with the xorg definitions. */
-#define DRM_MODE_FLAG_PHSYNC   (1<<0)
-#define DRM_MODE_FLAG_NHSYNC   (1<<1)
-#define DRM_MODE_FLAG_PVSYNC   (1<<2)
-#define DRM_MODE_FLAG_NVSYNC   (1<<3)
-#define DRM_MODE_FLAG_INTERLACE(1<<4)
-#define DRM_MODE_FLAG_DBLSCAN  (1<<5)
-#define DRM_MODE_FLAG_CSYNC(1<<6)
-#define DRM_MODE_FLAG_PCSYNC   (1<<7)
-#define DRM_MODE_FLAG_NCSYNC   (1<<8)
-#define DRM_MODE_FLAG_HSKEW(1<<9) /* hskew provided */
-#define DRM_MODE_FLAG_BCAST(1<<10)
-#define DRM_MODE_FLAG_PIXMUX   (1<<11)
-#define DRM_MODE_FLAG_DBLCLK   (1<<12)
-#define DRM_MODE_FLAG_CLKDIV2  (1<<13)
+#define DRM_MODE_FLAG_PHSYNC   (1<<0)
+#define DRM_MODE_FLAG_NHSYNC   (1<<1)
+#define DRM_MODE_FLAG_PVSYNC   (1<<2)
+#define DRM_MODE_FLAG_NVSYNC   (1<<3)
+#define DRM_MODE_FLAG_INTERLACE(1<<4)
+#define DRM_MODE_FLAG_DBLSCAN  (1<<5)
+#define DRM_MODE_FLAG_CSYNC(1<<6)
+#define DRM_MODE_FLAG_PCSYNC   (1<<7)
+#define DRM_MODE_FLAG_NCSYNC   (1<<8)
+#define DRM_MODE_FLAG_HSKEW(1<<9) /* hskew provided */
+#define DRM_MODE_FLAG_BCAST(1<<10)
+#define DRM_MODE_FLAG_PIXMUX   (1<<11)
+#define DRM_MODE_FLAG_DBLCLK   (1<<12)
+#define DRM_MODE_FLAG_CLKDIV2  (1<<13)
+#define DRM_MODE_FLAG_3D_TOP_BOTTOM(1<<14)
+#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF (1<<15)
+#define DRM_MODE_FLAG_3D_FRAME_PACKING (1<<16)
+
+#define DRM_MODE_FLAG_3D_MASK  (DRM_MODE_FLAG_3D_TOP_BOTTOM |  \
+DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF |   \
+DRM_MODE_FLAG_3D_FRAME_PACKING)

 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
diff --git a/xf86drmMode.h b/xf86drmMode.h
index 8e40034..f88522e 100644
--- a/xf86drmMode.h
+++ b/xf86drmMode.h
@@ -81,20 +81,27 @@ extern "C" {

 /* Video mode flags */
 /* bit compatible with the xorg definitions. */
-#define DRM_MODE_FLAG_PHSYNC(1<<0)
-#define DRM_MODE_FLAG_NHSYNC(1<<1)
-#define DRM_MODE_FLAG_PVSYNC(1<<2)
-#define DRM_MODE_FLAG_NVSYNC(1<<3)
-#define DRM_MODE_FLAG_INTERLACE (1<<4)
-#define DRM_MODE_FLAG_DBLSCAN   (1<<5)
-#define DRM_MODE_FLAG_CSYNC (1<<6)
-#define DRM_MODE_FLAG_PCSYNC(1<<7)
-#define DRM_MODE_FLAG_NCSYNC(1<<8)
-#define DRM_MODE_FLAG_HSKEW (1<<9) /* hskew provided */
-#define DRM_MODE_FLAG_BCAST (1<<10)
-#define DRM_MODE_FLAG_PIXMUX(1<<11)
-#define DRM_MODE_FLAG_DBLCLK(1<<12)
-#define DRM_MODE_FLAG_CLKDIV2   (1<<13)
+#define DRM_MODE_FLAG_PHSYNC   (1<<0)
+#define DRM_MODE_FLAG_NHSYNC   (1<<1)
+#define DRM_MODE_FLAG_PVSYNC   (1<<2)
+#define DRM_MODE_FLAG_NVSYNC   (1<<3)
+#define DRM_MODE_FLAG_INTERLACE(1<<4)
+#define DRM_MODE_FLAG_DBLSCAN  (1<<5)
+#define DRM_MODE_FLAG_CSYNC(1<<6)
+#define DRM_MODE_FLAG_PCSYNC   (1<<7)
+#define DRM_MODE_FLAG_NCSYNC   (1<<8)
+#define DRM_MODE_FLAG_HSKEW(1<<9) /* hskew provided */
+#define DRM_MODE_FLAG_BCAST(1<<10)
+#define DRM_MODE_FLAG_PIXMUX   (1<<11)
+#define DRM_MODE_FLAG_DBLCLK   (1<<12)
+#define DRM_MODE_FLAG_CLKDIV2  (1<<13)
+#define DRM_MODE_FLAG_3D_TOP_BOTTOM(1<<14)
+#define DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF (1<<15)
+#define DRM_MODE_FLAG_3D_FRAME_PACKING (1<<16)
+
+#define DRM_MODE_FLAG_3D_MASK  (DRM_MODE_FLAG_3D_TOP_BOTTOM |  \
+DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF |   \
+DRM_MODE_FLAG_3D_FRAME_PACKING)

 /* DPMS flags */
 /* bit compatible with the xorg definitions. */
-- 
1.7.11.4

[PATCH 3/3] drm/i915: Add HDMI vendor info frame support

From: Damien Lespiau 

When scanning out a 3D framebuffer, send the corresponding infoframe to
the HDMI sink.

See http://www.hdmi.org/manufacturer/specification.aspx for details.

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/i915/intel_drv.h  | 14 
 drivers/gpu/drm/i915/intel_hdmi.c | 71 ++-
 2 files changed, 84 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cd54cf8..76d488e 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -263,6 +263,13 @@ struct cxsr_latency {
 #define DIP_SPD_BD 0xa
 #define DIP_SPD_SCD0xb

+#define DIP_TYPE_VENDOR0x81
+#define DIP_VERSION_VENDOR 0x1
+#define DIP_HDMI_3D_PRESENT(0x2<<4)
+#define DIP_HDMI_3D_STRUCT_FP  (0x0<<4)
+#define DIP_HDMI_3D_STRUCT_TB  (0x6<<4)
+#define DIP_HDMI_3D_STRUCT_SBSH(0x8<<4)
+
 struct dip_infoframe {
uint8_t type;   /* HB0 */
uint8_t ver;/* HB1 */
@@ -292,6 +299,12 @@ struct dip_infoframe {
uint8_t pd[16];
uint8_t sdi;
} __attribute__ ((packed)) spd;
+   struct {
+   uint8_t vendor_id[3];
+   uint8_t video_format;
+   uint8_t s3d_struct;
+   uint8_t s3d_ext_data;
+   } __attribute__ ((packed)) hdmi;
uint8_t payload[27];
} __attribute__ ((packed)) body;
 } __attribute__((packed));
@@ -305,6 +318,7 @@ struct intel_hdmi {
bool has_hdmi_sink;
bool has_audio;
enum hdmi_force_audio force_audio;
+   unsigned int s3d_mode;
void (*write_infoframe)(struct drm_encoder *encoder,
struct dip_infoframe *frame);
void (*set_infoframes)(struct drm_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 98f6024..ab0553d 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -83,6 +83,8 @@ static u32 g4x_infoframe_index(struct dip_infoframe *frame)
return VIDEO_DIP_SELECT_AVI;
case DIP_TYPE_SPD:
return VIDEO_DIP_SELECT_SPD;
+   case DIP_TYPE_VENDOR:
+   return VIDEO_DIP_SELECT_VENDOR;
default:
DRM_DEBUG_DRIVER("unknown info frame type %d\n", frame->type);
return 0;
@@ -96,6 +98,8 @@ static u32 g4x_infoframe_enable(struct dip_infoframe *frame)
return VIDEO_DIP_ENABLE_AVI;
case DIP_TYPE_SPD:
return VIDEO_DIP_ENABLE_SPD;
+   case DIP_TYPE_VENDOR:
+   return VIDEO_DIP_ENABLE_VENDOR;
default:
DRM_DEBUG_DRIVER("unknown info frame type %d\n", frame->type);
return 0;
@@ -338,6 +342,51 @@ static void intel_hdmi_set_spd_infoframe(struct 
drm_encoder *encoder)
intel_set_infoframe(encoder, _if);
 }

+static void intel_hdmi_set_hdmi_infoframe(struct drm_encoder *encoder)
+{
+   struct intel_hdmi *intel_hdmi = enc_to_intel_hdmi(encoder);
+   struct dip_infoframe hdmi_if;
+
+   /* We really only need to send a HDMI vendor info frame when having
+* a 3D format to describe */
+   if (!intel_hdmi->s3d_mode)
+   return;
+
+   memset(_if, 0, sizeof(hdmi_if));
+   hdmi_if.type = DIP_TYPE_VENDOR;
+   hdmi_if.ver = DIP_VERSION_VENDOR;
+   /* HDMI IEEE registration id, least significant bit first */
+   hdmi_if.body.hdmi.vendor_id[0] = 0x03;
+   hdmi_if.body.hdmi.vendor_id[1] = 0xc0;
+   hdmi_if.body.hdmi.vendor_id[2] = 0x00;
+   hdmi_if.body.hdmi.video_format = DIP_HDMI_3D_PRESENT;
+   if (intel_hdmi->s3d_mode & DRM_MODE_FLAG_3D_FRAME_PACKING)
+   hdmi_if.body.hdmi.s3d_struct = DIP_HDMI_3D_STRUCT_FP;
+   else if (intel_hdmi->s3d_mode & DRM_MODE_FLAG_3D_TOP_BOTTOM)
+   hdmi_if.body.hdmi.s3d_struct = DIP_HDMI_3D_STRUCT_TB;
+   else if (intel_hdmi->s3d_mode & DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF)
+   hdmi_if.body.hdmi.s3d_struct = DIP_HDMI_3D_STRUCT_SBSH;
+   /* len is the payload len, not including checksum. Side by side (half)
+* has an extra byte for 3D_Ext_Data */
+   if (intel_hdmi->s3d_mode & DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF) {
+   hdmi_if.len = 6;
+   /* SBSH is subsampled by a factor of 2 */
+   hdmi_if.body.hdmi.s3d_ext_data = 2 << 4;
+   } else
+   hdmi_if.len = 5;
+
+   DRM_DEBUG_DRIVER("3D payload (len %d) %02x %02x %02x %02x %02x %02x\n",
+   hdmi_if.len,
+   hdmi_if.body.payload[0],
+   hdmi_if.body.payload[1],
+   hdmi_if.body.payload[2],
+   hdmi_if.body.payload[3],
+

[PATCH 2/3] drm: Add Stereo 3D properties

From: Damien Lespiau 

The "select 3D mode" property can be connected to connectors to signal
user space that 3D framebuffers can be scanned out to the said
connector.

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/drm_crtc.c | 32 
 include/drm/drm_crtc.h |  4 
 2 files changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 6fbfc24..dcd6d81 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -841,6 +841,38 @@ int drm_mode_create_tv_properties(struct drm_device *dev, 
int num_modes,
 }
 EXPORT_SYMBOL(drm_mode_create_tv_properties);

+static const struct drm_prop_enum_list s3d_modes_list[] =
+{
+   { 0, "None" },
+   { DRM_MODE_FLAG_3D_TOP_BOTTOM, "Top bottom" },
+   { DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF, "Side by side (half)" },
+   { DRM_MODE_FLAG_3D_FRAME_PACKING, "Frame packing" }
+};
+
+/**
+ * drm_mode_create_3d_property - create stereo 3D properties
+ * @dev: DRM device
+ *
+ * Called by a driver the first time it's needed, must be attached to modes
+ * that supports stereo 3D formats.
+ */
+int drm_mode_create_3d_property(struct drm_device *dev)
+{
+   struct drm_property *s3d_selector;
+
+   if (dev->mode_config.s3d_select_mode_property)
+   return 0;
+
+   s3d_selector = drm_property_create_enum(dev, 0,
+   "select 3D mode",
+   s3d_modes_list,
+   ARRAY_SIZE(s3d_modes_list));
+   dev->mode_config.s3d_select_mode_property = s3d_selector;
+
+   return 0;
+}
+EXPORT_SYMBOL(drm_mode_create_3d_property);
+
 /**
  * drm_mode_create_scaling_mode_property - create scaling mode property
  * @dev: DRM device
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index bfacf0d..5a6e024 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -802,6 +802,9 @@ struct drm_mode_config {
struct drm_property *tv_saturation_property;
struct drm_property *tv_hue_property;

+   /* Stereo 3D properties */
+   struct drm_property *s3d_select_mode_property;
+
/* Optional properties */
struct drm_property *scaling_mode_property;
struct drm_property *dithering_mode_property;
@@ -950,6 +953,7 @@ extern int drm_property_add_enum(struct drm_property 
*property, int index,
 extern int drm_mode_create_dvi_i_properties(struct drm_device *dev);
 extern int drm_mode_create_tv_properties(struct drm_device *dev, int 
num_formats,
 char *formats[]);
+extern int drm_mode_create_3d_property(struct drm_device *dev);
 extern int drm_mode_create_scaling_mode_property(struct drm_device *dev);
 extern int drm_mode_create_dithering_property(struct drm_device *dev);
 extern int drm_mode_create_dirty_info_property(struct drm_device *dev);
-- 
1.7.11.4

[PATCH 1/3] drm: Parse the HDMI cea vendor block for 3D present

From: Damien Lespiau 

For now, let's just look at the 3D_present flag of the CEA HDMI vendor
block to detect if the sink supports a small list of then mandatory 3D
formats.

See the HDMI 1.4a 3D extraction for detail:
  http://www.hdmi.org/manufacturer/specification.aspx

Signed-off-by: Damien Lespiau 
---
 drivers/gpu/drm/drm_edid.c | 84 --
 include/drm/drm_mode.h | 35 +++
 2 files changed, 103 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index b7ee230..9ffd5c8 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1522,21 +1522,101 @@ do_cea_modes (struct drm_connector *connector, u8 *db, 
u8 len)
return modes;
 }

+static bool cea_hdmi_3d_present(u8 *hdmi)
+{
+   u8 len, skip = 0;
+
+   len = hdmi[0] & 0x1f;
+
+   if (len < 8)
+   return false;
+
+   /* no HDMI_Video_present */
+   if (!(hdmi[8] & (1<<5)))
+   return false;
+
+   /* Latency_fields_present */
+   if (hdmi[8] & (1 << 7))
+   skip += 2;
+
+   /* I_Latency_fields_present */
+   if (hdmi[8] & (1 << 6))
+   skip += 2;
+
+   /* the declared length is not long enough */
+   if (len < (9 + skip))
+   return false;
+
+   return (hdmi[9 + skip] & (1 << 7)) != 0;
+}
+
+static const struct {
+   int width, height, freq;
+   unsigned int select, value;
+   unsigned int formats;
+} s3d_mandatory_modes[] = {
+   { 1920, 1080, 24, DRM_MODE_FLAG_INTERLACE, 0,
+ DRM_MODE_FLAG_3D_TOP_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING },
+   { 1920, 1080, 50, DRM_MODE_FLAG_INTERLACE, DRM_MODE_FLAG_INTERLACE,
+ DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
+   { 1920, 1080, 60, DRM_MODE_FLAG_INTERLACE, DRM_MODE_FLAG_INTERLACE,
+ DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF },
+   { 1280, 720,  50, DRM_MODE_FLAG_INTERLACE, 0,
+ DRM_MODE_FLAG_3D_TOP_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING },
+   { 1280, 720,  60, DRM_MODE_FLAG_INTERLACE, 0,
+ DRM_MODE_FLAG_3D_TOP_BOTTOM | DRM_MODE_FLAG_3D_FRAME_PACKING }
+};
+
+static void cea_hdmi_patch_mandatory_3d_mode(struct drm_display_mode *mode)
+{
+   int i;
+
+   for (i = 0; i < ARRAY_SIZE(s3d_mandatory_modes); i++) {
+   if (mode->hdisplay == s3d_mandatory_modes[i].width &&
+   mode->vdisplay == s3d_mandatory_modes[i].height &&
+   (mode->flags & s3d_mandatory_modes[i].select) ==
+   s3d_mandatory_modes[i].value &&
+   drm_mode_vrefresh(mode) == s3d_mandatory_modes[i].freq) {
+   mode->flags |= s3d_mandatory_modes[i].formats;
+   }
+   }
+}
+
+static void cea_hdmi_patch_mandatory_3d_modes(struct drm_connector *connector)
+{
+   struct drm_display_mode *mode;
+
+   list_for_each_entry(mode, >probed_modes, head)
+   cea_hdmi_patch_mandatory_3d_mode(mode);
+}
+
 static int
 add_cea_modes(struct drm_connector *connector, struct edid *edid)
 {
u8 * cea = drm_find_cea_extension(edid);
-   u8 * db, dbl;
+   u8 * db, *hdmi = NULL, dbl;
int modes = 0;

+   /* let's find the cea modes before looking at the hdmi vendor block
+* as the 3d_present flag needs to know about the supported modes
+* to infer the 3D modes */
if (cea && cea[1] >= 3) {
for (db = cea + 4; db < cea + cea[2]; db += dbl + 1) {
dbl = db[0] & 0x1f;
-   if (((db[0] & 0xe0) >> 5) == VIDEO_BLOCK)
+   switch ((db[0] & 0xe0) >> 5) {
+   case VIDEO_BLOCK:
modes += do_cea_modes (connector, db+1, dbl);
+   break;
+   case VENDOR_BLOCK:
+   hdmi = db;
+   break;
+   }
}
}

+   if (hdmi && cea_hdmi_3d_present(hdmi))
+   cea_hdmi_patch_mandatory_3d_modes(connector);
+
return modes;
 }

diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 3d6301b..04b4996 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -44,20 +44,27 @@

 /* Video mode flags */
 /* bit compatible with the xorg definitions. */
-#define DRM_MODE_FLAG_PHSYNC   (1<<0)
-#define DRM_MODE_FLAG_NHSYNC   (1<<1)
-#define DRM_MODE_FLAG_PVSYNC   (1<<2)
-#define DRM_MODE_FLAG_NVSYNC   (1<<3)
-#define DRM_MODE_FLAG_INTERLACE(1<<4)
-#define DRM_MODE_FLAG_DBLSCAN  (1<<5)
-#define DRM_MODE_FLAG_CSYNC(1<<6)
-#define DRM_MODE_FLAG_PCSYNC   (1<<7)
-#define DRM_MODE_FLAG_NCSYNC   (1<<8)
-#define DRM_MODE_FLAG_HSKEW(1<<9) /* hskew provided */
-#define DRM_MODE_FLAG_BCAST(1<<10)
-#define DRM_MODE_FLAG_PIXMUX   (1<<11)
-#define DRM_MODE_FLAG_DBLCLK

[RFC] Stereo 3D modes support

Hi,

This series introduces stereo 3D modes support and is split in 3 chunks:

1. 3 kernel patches to parse the 3D_present flag of the HDMI CEA vendor block,
   to expose 3D formats flags in modes and to add a new property on connectors
   supporting stereo 3D,

2. Sync the new mode flags in libdrm,

3. Use testdisplay from intel-gpu-tools to test the Top Bottom and Frame
   Packing modes,

A few notes:

- An (edited) extract of HDMI 1.4a for 3D formats is available publicly:
   http://www.hdmi.org/manufacturer/specification.aspx

- I tried to come up with a way to not disrupt current user space with extra 3D
  modes. The 3D formats (the different ways of laying out buffers with left and
  right frames) that a mode supports are indicated with flags in mode.flags.
  This also means that no extra mode is added to the mode list, the format flags
  are added on already exposed 2D modes.

- For now, only the 3D_present flags of the CEA HDMI block is being parsed,
  only exposing the then "mandatory" 3D formats (see HDMI 1.4a 3D spec)

- When scanning out a 3D framebuffer, the "select 3D mode" property attached to
  a connector can be used to tell the driver to send the HDMI vendor infoframes
  with the 3D format details.

- 3D test images are available at:
http://www.quantumdata.com/apps/3D/sample_BMP.asp

- These patches have taken some inspiration from previous work of Armin Reese
   and Sateesh Kavuri.

Comments, suggestions and reviews are greatly appreciated!

--
Damien

[RFC][PATCH 4/4] drm: i915: Atomic pageflip WIP

From: Ville Syrj?l? 

Use the drm_flip helper to implement atomic page flipping.

Work in progress. Ignore the huge mess in intel_sprite.c for now.
---
 drivers/gpu/drm/i915/i915_drv.h  |4 +
 drivers/gpu/drm/i915/i915_irq.c  |   10 +-
 drivers/gpu/drm/i915/intel_atomic.c  |  449 +-
 drivers/gpu/drm/i915/intel_display.c |  171 +
 drivers/gpu/drm/i915/intel_drv.h |   29 +++
 drivers/gpu/drm/i915/intel_sprite.c  |  386 ++---
 6 files changed, 841 insertions(+), 208 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 57e4894..e29994f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -41,6 +41,8 @@
 #include 
 #include 

+#include "drm_flip.h"
+
 /* General customization:
  */

@@ -845,6 +847,8 @@ typedef struct drm_i915_private {
struct work_struct parity_error_work;
bool hw_contexts_disabled;
uint32_t hw_context_size;
+
+   struct drm_flip_driver flip_driver;
 } drm_i915_private_t;

 /* Iterate over initialised rings */
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 23f2ea0..78ff3e0 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -37,6 +37,8 @@
 #include "i915_trace.h"
 #include "intel_drv.h"

+void intel_handle_vblank(struct drm_device *dev, int pipe);
+
 /* For display hotplug interrupt */
 static void
 ironlake_enable_display_irq(drm_i915_private_t *dev_priv, u32 mask)
@@ -548,7 +550,7 @@ static irqreturn_t valleyview_irq_handler(DRM_IRQ_ARGS)

for_each_pipe(pipe) {
if (pipe_stats[pipe] & PIPE_VBLANK_INTERRUPT_STATUS)
-   drm_handle_vblank(dev, pipe);
+   intel_handle_vblank(dev, pipe);

if (pipe_stats[pipe] & PLANE_FLIPDONE_INT_STATUS_VLV) {
intel_prepare_page_flip(dev, pipe);
@@ -686,7 +688,7 @@ static irqreturn_t ivybridge_irq_handler(DRM_IRQ_ARGS)
intel_finish_page_flip_plane(dev, i);
}
if (de_iir & (DE_PIPEA_VBLANK_IVB << (5 * i)))
-   drm_handle_vblank(dev, i);
+   intel_handle_vblank(dev, i);
}

/* check event from PCH */
@@ -779,10 +781,10 @@ static irqreturn_t ironlake_irq_handler(DRM_IRQ_ARGS)
}

if (de_iir & DE_PIPEA_VBLANK)
-   drm_handle_vblank(dev, 0);
+   intel_handle_vblank(dev, 0);

if (de_iir & DE_PIPEB_VBLANK)
-   drm_handle_vblank(dev, 1);
+   intel_handle_vblank(dev, 1);

/* check event from PCH */
if (de_iir & DE_PCH_EVENT) {
diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 0a96d15..6d8d7d3 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -3,6 +3,7 @@

 #include 
 #include 
+#include 

 #include "intel_drv.h"

@@ -1309,6 +1310,46 @@ static void update_props(const struct drm_device *dev,
}
 }

+static int atomic_pipe_commit(struct drm_device *dev,
+ struct intel_atomic_state *state,
+ int pipe);
+
+static int try_atomic_commit(struct drm_device *dev, struct intel_atomic_state 
*s)
+{
+   int ret;
+   int i;
+   u32 pipes = 0;
+
+   for (i = 0; i < dev->mode_config.num_crtc; i++) {
+   struct intel_crtc_state *st = >crtc[i];
+
+   if (st->mode_dirty)
+   return -EAGAIN;
+
+   if (st->fb_dirty)
+   pipes |= 1 << to_intel_crtc(st->crtc)->pipe;
+   }
+
+   for (i = 0; i < dev->mode_config.num_plane; i++) {
+   struct intel_plane_state *st = >plane[i];
+
+   if (st->dirty)
+   pipes |= 1 << to_intel_plane(st->plane)->pipe;
+   }
+
+   if (hweight32(pipes) != 1)
+   return -EAGAIN;
+
+   ret = atomic_pipe_commit(dev, s, ffs(pipes) - 1);
+   if (ret)
+   return ret;
+
+   /* don't restore the old state in end() */
+   s->dirty = false;
+
+   return 0;
+}
+
 static int intel_atomic_commit(struct drm_device *dev, void *state)
 {
struct intel_atomic_state *s = state;
@@ -1325,17 +1366,23 @@ static int intel_atomic_commit(struct drm_device *dev, 
void *state)
if (ret)
return ret;

-   ret = apply_config(dev, s);
+   /* try to apply asynchronously and atomically */
+   ret = try_atomic_commit(dev, s);
+
+   /* fall back to sync/non-atomic */
if (ret) {
-   unpin_fbs(dev, s);
-   unpin_cursors(dev, s);
-   s->restore_hw = true;
-   return ret;
-   }
+

[RFC][PATCH 3/4] drm: i915: Pass gem object to intel_finish_fb()

From: Ville Syrj?l? 

intel_finish_fb() has no use for the drm_framebuffer metadata, so pass
the gem object directly.

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/i915/intel_atomic.c  |2 +-
 drivers/gpu/drm/i915/intel_display.c |7 +++
 drivers/gpu/drm/i915/intel_drv.h |2 +-
 3 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index e9eaa8a..0a96d15 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -797,7 +797,7 @@ static void unpin_work_func(struct work_struct *work)
intel_wait_for_vblank(dev, pipe);
vblank_waited |= 1 << pipe;
}
-   intel_finish_fb(fb);
+   intel_finish_fb(obj);
intel_unpin_fb_obj(obj);

mutex_unlock(>struct_mutex);
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 46fb4d1..01c1a19 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2188,9 +2188,8 @@ intel_pipe_set_base_atomic(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
 }

 int
-intel_finish_fb(struct drm_framebuffer *old_fb)
+intel_finish_fb(struct drm_i915_gem_object *obj)
 {
-   struct drm_i915_gem_object *obj = to_intel_framebuffer(old_fb)->obj;
struct drm_i915_private *dev_priv = obj->base.dev->dev_private;
bool was_interruptible = dev_priv->mm.interruptible;
int ret;
@@ -2250,7 +2249,7 @@ _intel_pipe_set_base(struct drm_crtc *crtc, int x, int y,
}

if (old_fb)
-   intel_finish_fb(old_fb);
+   intel_finish_fb(to_intel_framebuffer(old_fb)->obj);

ret = dev_priv->display.update_plane(crtc, crtc->fb, x, y);
if (ret) {
@@ -2862,7 +2861,7 @@ static void intel_crtc_wait_for_pending_flips(struct 
drm_crtc *crtc)
return;

mutex_lock(>struct_mutex);
-   intel_finish_fb(crtc->fb);
+   intel_finish_fb(to_intel_framebuffer(crtc->fb)->obj);
mutex_unlock(>struct_mutex);
 }

diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9deb3f4..fa81676 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -440,7 +440,7 @@ extern int intel_pin_and_fence_fb_obj(struct drm_device 
*dev,
  struct drm_i915_gem_object *obj,
  struct intel_ring_buffer *pipelined);
 extern void intel_unpin_fb_obj(struct drm_i915_gem_object *obj);
-extern int intel_finish_fb(struct drm_framebuffer *fb);
+extern int intel_finish_fb(struct drm_i915_gem_object *obj);

 extern int intel_framebuffer_init(struct drm_device *dev,
  struct intel_framebuffer *ifb,
-- 
1.7.8.6

[RFC][PATCH 2/4] drm: Add drm_flip helper

From: Ville Syrj?l? 

The drm_flip mechanism can be used to implement robust page flipping
support, and also to synchronize the flips on multiple hardware
scanout engines (eg. CRTCs and overlays).

Signed-off-by: Ville Syrj?l? 
---
 drivers/gpu/drm/Makefile   |2 +-
 drivers/gpu/drm/drm_flip.c |  374 
 include/drm/drm_flip.h |  244 +
 3 files changed, 619 insertions(+), 1 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_flip.c
 create mode 100644 include/drm/drm_flip.h

diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index f65f65e..72ce54a 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -12,7 +12,7 @@ drm-y   :=drm_auth.o drm_buffer.o drm_bufs.o 
drm_cache.o \
drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
drm_crtc.o drm_modes.o drm_edid.o \
drm_info.o drm_debugfs.o drm_encoder_slave.o \
-   drm_trace_points.o drm_global.o drm_prime.o
+   drm_trace_points.o drm_global.o drm_prime.o drm_flip.o

 drm-$(CONFIG_COMPAT) += drm_ioc32.o

diff --git a/drivers/gpu/drm/drm_flip.c b/drivers/gpu/drm/drm_flip.c
new file mode 100644
index 000..4e716a3
--- /dev/null
+++ b/drivers/gpu/drm/drm_flip.c
@@ -0,0 +1,374 @@
+/*
+ * Copyright (C) 2012 Intel Corporation
+ *
+ * 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, sublicense,
+ * 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 NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS 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.
+ *
+ * Authors:
+ * Ville Syrj?l? 
+ */
+
+#include 
+
+static void drm_flip_driver_cleanup(struct work_struct *work)
+{
+   struct drm_flip *flip, *next;
+   struct drm_flip_driver *driver =
+   container_of(work, struct drm_flip_driver, cleanup_work);
+   LIST_HEAD(list);
+
+   spin_lock_irq(>lock);
+
+   list_cut_position(,
+ >cleanup_list,
+ driver->cleanup_list.prev);
+
+   spin_unlock_irq(>lock);
+
+   if (list_empty())
+   return;
+
+   list_for_each_entry_safe(flip, next, , list) {
+   struct drm_flip_helper *helper = flip->helper;
+
+   WARN_ON(!flip->finished);
+
+   helper->funcs->cleanup(flip);
+   }
+}
+
+static void drm_flip_driver_finish(struct work_struct *work)
+{
+   struct drm_flip *flip, *next;
+   struct drm_flip_driver *driver =
+   container_of(work, struct drm_flip_driver, finish_work);
+   LIST_HEAD(list);
+   bool need_cleanup = false;
+
+   spin_lock_irq(>lock);
+
+   list_cut_position(,
+ >finish_list,
+ driver->finish_list.prev);
+
+   spin_unlock_irq(>lock);
+
+   if (list_empty())
+   return;
+
+   list_for_each_entry_safe(flip, next, , list) {
+   struct drm_flip_helper *helper = flip->helper;
+
+   helper->funcs->finish(flip);
+
+   spin_lock_irq(>lock);
+
+   flip->finished = true;
+
+   /*
+* It's possible that drm_flip_set_scanout() was called after we
+* pulled this flip from finish_list, in which case the flip
+* could be in need of cleanup, but not on cleanup_list.
+*/
+   if (flip == helper->scanout_flip) {
+   list_del_init(>list);
+   } else {
+   need_cleanup = true;
+   list_move_tail(>list, >cleanup_list);
+   }
+
+   spin_unlock_irq(>lock);
+   }
+
+   if (need_cleanup)
+   queue_work(driver->wq, >cleanup_work);
+}
+
+static bool drm_flip_set_scanout(struct drm_flip_helper *helper,
+struct drm_flip *flip)
+{
+   struct drm_flip_driver *driver = helper->driver;
+   struct drm_flip *old = helper->scanout_flip;
+
+

[RFC][PATCH 1/4] drm/i915: Try to commit single pipe in one go

From: Ville Syrj?l? 

---
 drivers/gpu/drm/i915/intel_atomic.c |   23 ---
 1 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index e439c04..e9eaa8a 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -907,6 +907,7 @@ static int apply_config(struct drm_device *dev,
for (i = 0; i < dev->mode_config.num_crtc; i++) {
struct intel_crtc_state *st = >crtc[i];
struct intel_crtc *intel_crtc = to_intel_crtc(st->crtc);
+   int j;

if (st->mode_dirty) {
ret = crtc_mode_set(st->crtc);
@@ -925,21 +926,21 @@ static int apply_config(struct drm_device *dev,
 intel_crtc->cursor_height,
 intel_crtc->cursor_bo,
 intel_crtc->cursor_addr);
-   }

-   for (i = 0; i < dev->mode_config.num_plane; i++) {
-   struct intel_plane_state *st = >plane[i];
-   struct drm_plane *plane = st->plane;
+   for (j = 0; j < dev->mode_config.num_plane; j++) {
+   struct intel_plane_state *pst = >plane[j];
+   struct drm_plane *plane = pst->plane;

-   if (!s->plane[i].dirty)
-   continue;
+   if (!pst->dirty)
+   continue;

-   if (!plane->crtc)
-   continue;
+   if (plane->crtc != st->crtc)
+   continue;

-   ret = intel_commit_plane(plane, plane->crtc, plane->fb, 
>coords, false);
-   if (ret)
-   return ret;
+   ret = intel_commit_plane(plane, plane->crtc, plane->fb, 
>coords, false);
+   if (ret)
+   return ret;
+   }
}

for (i = 0; i < dev->mode_config.num_crtc; i++) {
-- 
1.7.8.6

[RFC][PATCH] Atomic page flip WIP


I'm posting this as rather raw just to get a bit more substance to the
discussions.

The drm_flip thingy may seem a bit too mid-layerish for people's taste,
but at least it is almost completely driven by explicit function calls
from the driver (the wq side is the exception naturally).

I originally wrote drm_flip for Medfield, where I used it syncronize the
pipe's primary layer and one or two video overlays (gen3 style overlays).
So it's a fairly well proven tehnology. I can post a version of the video
overlay code too in case someone would be interested in having drm_planes
on gen3 hardware.

This set applies on top of my earlier drm_atomic_4 branch:
https://gitorious.org/vsyrjala/linux/commits/drm_atomic_4

[RFC 0/9] nuclear pageflip

On Wed, Sep 12, 2012 at 10:23:48AM -0500, Rob Clark wrote:
> On Wed, Sep 12, 2012 at 10:12 AM, Ville Syrj?l?
>  wrote:
> > On Wed, Sep 12, 2012 at 09:42:27AM -0500, Rob Clark wrote:
> >> On Wed, Sep 12, 2012 at 9:34 AM, Ville Syrj?l?
> >>  wrote:
> >> > On Wed, Sep 12, 2012 at 09:28:43AM -0500, Rob Clark wrote:
> >> >> On Wed, Sep 12, 2012 at 9:23 AM, Ville Syrj?l?
> >> >>  wrote:
> >> >> > On Wed, Sep 12, 2012 at 07:30:18AM -0500, Rob Clark wrote:
> >> >> >> On Wed, Sep 12, 2012 at 3:59 AM, Ville Syrj?l?
> >> >> >>  wrote:
> >> >> >> > On Tue, Sep 11, 2012 at 05:07:49PM -0500, Rob Clark wrote:
> >> >> >> >> On Tue, Sep 11, 2012 at 4:15 PM, Ben Widawsky  >> >> >> >> bwidawsk.net> wrote:
> >> >> >> >> > On Sun, 9 Sep 2012 22:19:59 -0500
> >> >> >> >> > Rob Clark  wrote:
> >> >> >> >> >
> >> >> >> >> >> On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark  >> >> >> >> >> linaro.org> wrote:
> >> >> >> >> >> > From: Rob Clark 
> >> >> >> >> >> >
> >> >> >> >> >> > This is following a bit the approach that Ville is taking 
> >> >> >> >> >> > for atomic-
> >> >> >> >> >> > modeset, in that it is switching over to using properties 
> >> >> >> >> >> > for everything.
> >> >> >> >> >> > The advantage of this approach is that it makes it easier to 
> >> >> >> >> >> > add new
> >> >> >> >> >> > attributes to set as part of a page-flip (and even opens the 
> >> >> >> >> >> > option to
> >> >> >> >> >> > add new object types).
> >> >> >> >> >>
> >> >> >> >> >> oh, and for those wondering what the hell this is all about,
> >> >> >> >> >> nuclear-pageflip is a pageflip that atomically updates the 
> >> >> >> >> >> CRTC layer
> >> >> >> >> >> and zero or more attached plane layers, optionally changing 
> >> >> >> >> >> various
> >> >> >> >> >> properties such as z-order (or even blending modes, etc) 
> >> >> >> >> >> atomically.
> >> >> >> >> >> It includes the option for a test step so userspace compositor 
> >> >> >> >> >> can
> >> >> >> >> >> test a proposed configuration (if any properties not marked as
> >> >> >> >> >> 'dynamic' are updated).  This intended to allow, for example, 
> >> >> >> >> >> weston
> >> >> >> >> >> compositor to synchronize updates to plane (sprite) layers 
> >> >> >> >> >> with CRTC
> >> >> >> >> >> layer.
> >> >> >> >> >>
> >> >> >> >> >
> >> >> >> >> > Can we please name this something different? I complained about 
> >> >> >> >> > this in
> >> >> >> >> > IRC, but I don't know if you hang around in #intel-gfx.
> >> >> >> >> >
> >> >> >> >> > Some suggestions:
> >> >> >> >> > multiplane pageflip
> >> >> >> >> > muliplane atomic pageflip
> >> >> >> >> > atomic multiplane pageflip
> >> >> >> >> > atomic multiflip
> >> >> >> >> > pageflip of atomic and multiplane nature
> >> >> >> >> >
> >> >> >> >> > Nuclear is not at all descriptive and requires as your response 
> >> >> >> >> > shows
> >> >> >> >> > :-)
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >> fair enough.. I was originally calling it atomic-pageflip until
> >> >> >> >> someone (I don't remember who) started calling it 
> >> >> >> >> nuclear-pageflip to
> >> >> >> >> differentiate from atomic-modeset.  But IMO we could just call 
> >> >> >> >> the two
> >> >> >> >> ioclts atomic-modeset and atomic-pageflip.  (Or even modeset2 and
> >> >> >> >> pageflip2, but that seems much more boring)
> >> >> >> >
> >> >> >> > My plan has been to use the same ioctl for both uses. They'll need
> >> >> >> > nearly identical handling anyway on the ioctl level. I have 
> >> >> >> > something
> >> >> >> > semi-working currently, but I need to clean it up a bit before I 
> >> >> >> > can
> >> >> >> > show it to anyone.
> >> >> >>
> >> >> >> I do think the atomic-pageflip ioctl really should take the crtc-id..
> >> >> >> so probably should be two ioctls, but nearly identical
> >> >> >
> >> >> > But then you can't support atomic pageflips across multiple crtcs even
> >> >> > if the hardware would allow it. I would hate to add such limitation to
> >> >> > the API. I can immediately think of a use case; combining several
> >> >> > smaller displays to form a single larger display.
> >> >> >
> >> >> > With a unified API you could just add some kind of flag that tells the
> >> >> > kernel that user space really wants an atomic update, and if the
> >> >> > driver/hardware can't do it, it can return an error.
> >> >>
> >> >> well, that is really only a problem for X11..  and atomic flip across
> >> >> multiple crtc's is a potential mess from performance standpoint unless
> >> >> your displays are vsync'd lock.
> >> >
> >> > It won't be truly atomic unless they are vsync locked. But anyways more
> >> > buffers can be used to solve the performance problem. But that's a
> >> > separate issue and in that case it doesn't really matter whether you
> >> > issue separate ioctls for each crtc.
> >>
> >> that was basically my thinking.. separate ioctls for each crtc.  The
> >> way my branch works currently, you can do this.  A page-flip on crtc
> >> #2 won't care that there is still a

[RFC 0/9] nuclear pageflip

On Wed, Sep 12, 2012 at 09:42:27AM -0500, Rob Clark wrote:
> On Wed, Sep 12, 2012 at 9:34 AM, Ville Syrj?l?
>  wrote:
> > On Wed, Sep 12, 2012 at 09:28:43AM -0500, Rob Clark wrote:
> >> On Wed, Sep 12, 2012 at 9:23 AM, Ville Syrj?l?
> >>  wrote:
> >> > On Wed, Sep 12, 2012 at 07:30:18AM -0500, Rob Clark wrote:
> >> >> On Wed, Sep 12, 2012 at 3:59 AM, Ville Syrj?l?
> >> >>  wrote:
> >> >> > On Tue, Sep 11, 2012 at 05:07:49PM -0500, Rob Clark wrote:
> >> >> >> On Tue, Sep 11, 2012 at 4:15 PM, Ben Widawsky  
> >> >> >> wrote:
> >> >> >> > On Sun, 9 Sep 2012 22:19:59 -0500
> >> >> >> > Rob Clark  wrote:
> >> >> >> >
> >> >> >> >> On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark  >> >> >> >> linaro.org> wrote:
> >> >> >> >> > From: Rob Clark 
> >> >> >> >> >
> >> >> >> >> > This is following a bit the approach that Ville is taking for 
> >> >> >> >> > atomic-
> >> >> >> >> > modeset, in that it is switching over to using properties for 
> >> >> >> >> > everything.
> >> >> >> >> > The advantage of this approach is that it makes it easier to 
> >> >> >> >> > add new
> >> >> >> >> > attributes to set as part of a page-flip (and even opens the 
> >> >> >> >> > option to
> >> >> >> >> > add new object types).
> >> >> >> >>
> >> >> >> >> oh, and for those wondering what the hell this is all about,
> >> >> >> >> nuclear-pageflip is a pageflip that atomically updates the CRTC 
> >> >> >> >> layer
> >> >> >> >> and zero or more attached plane layers, optionally changing 
> >> >> >> >> various
> >> >> >> >> properties such as z-order (or even blending modes, etc) 
> >> >> >> >> atomically.
> >> >> >> >> It includes the option for a test step so userspace compositor can
> >> >> >> >> test a proposed configuration (if any properties not marked as
> >> >> >> >> 'dynamic' are updated).  This intended to allow, for example, 
> >> >> >> >> weston
> >> >> >> >> compositor to synchronize updates to plane (sprite) layers with 
> >> >> >> >> CRTC
> >> >> >> >> layer.
> >> >> >> >>
> >> >> >> >
> >> >> >> > Can we please name this something different? I complained about 
> >> >> >> > this in
> >> >> >> > IRC, but I don't know if you hang around in #intel-gfx.
> >> >> >> >
> >> >> >> > Some suggestions:
> >> >> >> > multiplane pageflip
> >> >> >> > muliplane atomic pageflip
> >> >> >> > atomic multiplane pageflip
> >> >> >> > atomic multiflip
> >> >> >> > pageflip of atomic and multiplane nature
> >> >> >> >
> >> >> >> > Nuclear is not at all descriptive and requires as your response 
> >> >> >> > shows
> >> >> >> > :-)
> >> >> >> >
> >> >> >>
> >> >> >> fair enough.. I was originally calling it atomic-pageflip until
> >> >> >> someone (I don't remember who) started calling it nuclear-pageflip to
> >> >> >> differentiate from atomic-modeset.  But IMO we could just call the 
> >> >> >> two
> >> >> >> ioclts atomic-modeset and atomic-pageflip.  (Or even modeset2 and
> >> >> >> pageflip2, but that seems much more boring)
> >> >> >
> >> >> > My plan has been to use the same ioctl for both uses. They'll need
> >> >> > nearly identical handling anyway on the ioctl level. I have something
> >> >> > semi-working currently, but I need to clean it up a bit before I can
> >> >> > show it to anyone.
> >> >>
> >> >> I do think the atomic-pageflip ioctl really should take the crtc-id..
> >> >> so probably should be two ioctls, but nearly identical
> >> >
> >> > But then you can't support atomic pageflips across multiple crtcs even
> >> > if the hardware would allow it. I would hate to add such limitation to
> >> > the API. I can immediately think of a use case; combining several
> >> > smaller displays to form a single larger display.
> >> >
> >> > With a unified API you could just add some kind of flag that tells the
> >> > kernel that user space really wants an atomic update, and if the
> >> > driver/hardware can't do it, it can return an error.
> >>
> >> well, that is really only a problem for X11..  and atomic flip across
> >> multiple crtc's is a potential mess from performance standpoint unless
> >> your displays are vsync'd lock.
> >
> > It won't be truly atomic unless they are vsync locked. But anyways more
> > buffers can be used to solve the performance problem. But that's a
> > separate issue and in that case it doesn't really matter whether you
> > issue separate ioctls for each crtc.
> 
> that was basically my thinking.. separate ioctls for each crtc.  The
> way my branch works currently, you can do this.  A page-flip on crtc
> #2 won't care that there is still a flip pending on crtc #1.
> 
> I guess that doesn't strictly guarantee that the two pageflips happen
> at the exact same time, but unless you have some way to vsync lock the
> two displays, I don't think that is possible anyways.

Sure you need hardware to keep the pipes in sync.

> So I'm not
> really sure it is worth over-complicating the ioctl to support two
> crtc's. The error checking in case a vsync is still pending is much
> easier in the driver if you know the crtc

[PATCH 3/3] drm: exynos: hdmi: clean dependency on plf data for mixer, hdmi context

exynos-drm-hdmi need context pointers from hdmi and mixer. These
pointers were expected from the plf data. Cleaned this dependency
by exporting i/f which are called by hdmi, mixer driver probes
for setting their context.

Signed-off-by: Rahul Sharma 
---
 drivers/gpu/drm/exynos/exynos_drm_hdmi.c |   47 +++--
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h |2 +
 drivers/gpu/drm/exynos/exynos_hdmi.c |3 ++
 drivers/gpu/drm/exynos/exynos_mixer.c|3 ++
 4 files changed, 32 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
index 0584132..4c8d933 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.c
@@ -29,6 +29,11 @@
 #define get_ctx_from_subdrv(subdrv)container_of(subdrv,\
struct drm_hdmi_context, subdrv);

+/* Common hdmi subdrv needs to access the hdmi and mixer though context.
+* These should be initialied by the repective drivers */
+static struct exynos_drm_hdmi_context *hdmi_ctx;
+static struct exynos_drm_hdmi_context *mixer_ctx;
+
 /* these callback points shoud be set by specific drivers. */
 static struct exynos_hdmi_ops *hdmi_ops;
 static struct exynos_mixer_ops *mixer_ops;
@@ -41,6 +46,18 @@ struct drm_hdmi_context {
boolenabled[MIXER_WIN_NR];
 };

+void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context *ctx)
+{
+   if (ctx)
+   hdmi_ctx = ctx;
+}
+
+void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx)
+{
+   if (ctx)
+   mixer_ctx = ctx;
+}
+
 void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops)
 {
DRM_DEBUG_KMS("%s\n", __FILE__);
@@ -303,46 +320,30 @@ static int hdmi_subdrv_probe(struct drm_device *drm_dev,
 {
struct exynos_drm_subdrv *subdrv = to_subdrv(dev);
struct drm_hdmi_context *ctx;
-   struct platform_device *pdev = to_platform_device(dev);
-   struct exynos_drm_common_hdmi_pd *pd;

DRM_DEBUG_KMS("%s\n", __FILE__);

-   pd = pdev->dev.platform_data;
-
-   if (!pd) {
-   DRM_DEBUG_KMS("platform data is null.\n");
-   return -EFAULT;
-   }
-
-   if (!pd->hdmi_dev) {
+   if (!hdmi_ctx) {
DRM_DEBUG_KMS("hdmi device is null.\n");
return -EFAULT;
}

-   if (!pd->mixer_dev) {
+   if (!mixer_ctx) {
DRM_DEBUG_KMS("mixer device is null.\n");
return -EFAULT;
}

ctx = get_ctx_from_subdrv(subdrv);

-   ctx->hdmi_ctx = (struct exynos_drm_hdmi_context *)
-   to_context(pd->hdmi_dev);
-   if (!ctx->hdmi_ctx) {
-   DRM_DEBUG_KMS("hdmi context is null.\n");
+   if (!ctx) {
+   DRM_DEBUG_KMS("context is null.\n");
return -EFAULT;
}

-   ctx->hdmi_ctx->drm_dev = drm_dev;
-
-   ctx->mixer_ctx = (struct exynos_drm_hdmi_context *)
-   to_context(pd->mixer_dev);
-   if (!ctx->mixer_ctx) {
-   DRM_DEBUG_KMS("mixer context is null.\n");
-   return -EFAULT;
-   }
+   ctx->hdmi_ctx = hdmi_ctx;
+   ctx->mixer_ctx = mixer_ctx;

+   ctx->hdmi_ctx->drm_dev = drm_dev;
ctx->mixer_ctx->drm_dev = drm_dev;

return 0;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h 
b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
index d9f9e9f..2da5ffd 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_hdmi.h
@@ -73,6 +73,8 @@ struct exynos_mixer_ops {
void (*win_disable)(void *ctx, int zpos);
 };

+void exynos_hdmi_drv_attach(struct exynos_drm_hdmi_context *ctx);
+void exynos_mixer_drv_attach(struct exynos_drm_hdmi_context *ctx);
 void exynos_hdmi_ops_register(struct exynos_hdmi_ops *ops);
 void exynos_mixer_ops_register(struct exynos_mixer_ops *ops);
 #endif
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 5236256..82ee810 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -2599,6 +2599,9 @@ static int __devinit hdmi_probe(struct platform_device 
*pdev)

drm_hdmi_ctx = platform_get_drvdata(pdev);

+   /* Attach HDMI Driver to common hdmi. */
+   exynos_hdmi_drv_attach(drm_hdmi_ctx);
+
/* register specific callbacks to common hdmi. */
exynos_hdmi_ops_register(_ops);

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 7d04a40..f9e26f2 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -1165,6 +1165,9 @@ static int __devinit mixer_probe(struct platform_device 
*pdev)
if (ret)
goto fail;

+   /* attach mixer driver to common hdmi. */
+   exynos_mixer_drv_attach(drm_hdmi_ctx);
+
/* register specific callback point

[PATCH 2/3] drm: exynos: hdmi: add exynos5 support to hdmi driver

Added support for exynos5 to hdmi driver. Resource init
is splitted for exynos5 and exynos4. Exynos5 hdmi driver
is dt based while exynos4 hdmi driver is not.

Signed-off-by: Rahul Sharma 
Signed-off-by: Shirish S 
Signed-off-by: Fahad Kunnathadi 
---
 drivers/gpu/drm/exynos/exynos_hdmi.c |  300 ++
 1 files changed, 269 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c 
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index a6aea6f..5236256 100644
--- a/drivers/gpu/drm/exynos/exynos_hdmi.c
+++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
@@ -32,6 +32,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 

 #include 

@@ -61,11 +64,13 @@ struct hdmi_context {
boolpowered;
boolis_v13;
booldvi_mode;
+   boolis_soc_exynos5;
struct mutexhdmi_mutex;

void __iomem*regs;
-   unsigned intexternal_irq;
-   unsigned intinternal_irq;
+   int external_irq;
+   int internal_irq;
+   int hpd_gpio;

struct i2c_client   *ddc_port;
struct i2c_client   *hdmiphy_port;
@@ -953,6 +958,23 @@ static inline void hdmi_reg_writemask(struct hdmi_context 
*hdata,
writel(value, hdata->regs + reg_id);
 }

+static void hdmi_cfg_hpd(struct hdmi_context *hdata, bool internal)
+{
+   if (!internal) {
+   s3c_gpio_cfgpin(hdata->hpd_gpio, S3C_GPIO_SFN(0xf));
+   s3c_gpio_setpull(hdata->hpd_gpio, S3C_GPIO_PULL_DOWN);
+   } else {
+   s3c_gpio_cfgpin(hdata->hpd_gpio, S3C_GPIO_SFN(3));
+   s3c_gpio_setpull(hdata->hpd_gpio, S3C_GPIO_PULL_NONE);
+   }
+}
+
+static int hdmi_get_hpd(struct hdmi_context *hdata)
+{
+   int gpio_stat = gpio_get_value(hdata->hpd_gpio);
+   return gpio_stat;
+}
+
 static void hdmi_v13_regs_dump(struct hdmi_context *hdata, char *prefix)
 {
 #define DUMPREG(reg_id) \
@@ -2026,6 +2048,9 @@ static void hdmi_poweron(struct hdmi_context *hdata)

if (hdata->cfg_hpd)
hdata->cfg_hpd(true);
+   else
+   hdmi_cfg_hpd(hdata, true);
+
mutex_unlock(>hdmi_mutex);

pm_runtime_get_sync(hdata->dev);
@@ -2063,6 +2088,8 @@ static void hdmi_poweroff(struct hdmi_context *hdata)
mutex_lock(>hdmi_mutex);
if (hdata->cfg_hpd)
hdata->cfg_hpd(false);
+   else
+   hdmi_cfg_hpd(hdata, false);

hdata->powered = false;

@@ -2110,17 +2137,16 @@ static irqreturn_t hdmi_external_irq_thread(int irq, 
void *arg)
struct exynos_drm_hdmi_context *ctx = arg;
struct hdmi_context *hdata = ctx->ctx;

-   if (!hdata->get_hpd)
-   goto out;
-
mutex_lock(>hdmi_mutex);
-   hdata->hpd = hdata->get_hpd();
+   if (hdata->get_hpd)
+   hdata->hpd = hdata->get_hpd();
+   else
+   hdata->hpd = hdmi_get_hpd(hdata);
mutex_unlock(>hdmi_mutex);

if (ctx->drm_dev)
drm_helper_hpd_irq_event(ctx->drm_dev);

-out:
return IRQ_HANDLED;
 }

@@ -2203,23 +2229,25 @@ static int __devinit hdmi_resources_init(struct 
hdmi_context *hdata)

clk_set_parent(res->sclk_hdmi, res->sclk_pixel);

-   res->regul_bulk = kzalloc(ARRAY_SIZE(supply) *
-   sizeof(res->regul_bulk[0]), GFP_KERNEL);
-   if (!res->regul_bulk) {
-   DRM_ERROR("failed to get memory for regulators\n");
-   goto fail;
-   }
-   for (i = 0; i < ARRAY_SIZE(supply); ++i) {
-   res->regul_bulk[i].supply = supply[i];
-   res->regul_bulk[i].consumer = NULL;
-   }
-   ret = regulator_bulk_get(dev, ARRAY_SIZE(supply), res->regul_bulk);
-   if (ret) {
-   DRM_ERROR("failed to get regulators\n");
-   goto fail;
+   if (!hdata->is_soc_exynos5) {
+   res->regul_bulk = kzalloc(ARRAY_SIZE(supply) *
+   sizeof(res->regul_bulk[0]), GFP_KERNEL);
+   if (!res->regul_bulk) {
+   DRM_ERROR("failed to get memory for regulators\n");
+   goto fail;
+   }
+   for (i = 0; i < ARRAY_SIZE(supply); ++i) {
+   res->regul_bulk[i].supply = supply[i];
+   res->regul_bulk[i].consumer = NULL;
+   }
+   ret = regulator_bulk_get(dev, ARRAY_SIZE(supply),
+   res->regul_bulk);
+   if (ret) {
+   DRM_ERROR("failed to get regulators\n");
+   goto fail;
+   }
+   res->regul_count = ARRAY_SIZE(supply);

[PATCH 1/3] drm: exynos: hdmi: add exynos5 support to mixer driver

Added support for exynos5 to drm mixer driver. Exynos5 works
with dt enabled while in exynos4 mixer device information can
be passed either way (dt or plf data). This situation is taken
cared.

Signed-off-by: Rahul Sharma 
Signed-off-by: Shirish S 
Signed-off-by: Fahad Kunnathadi 
---
 drivers/gpu/drm/exynos/exynos_mixer.c |  153 ++---
 drivers/gpu/drm/exynos/regs-mixer.h   |2 +
 2 files changed, 142 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
b/drivers/gpu/drm/exynos/exynos_mixer.c
index 8a43ee1..7d04a40 100644
--- a/drivers/gpu/drm/exynos/exynos_mixer.c
+++ b/drivers/gpu/drm/exynos/exynos_mixer.c
@@ -71,6 +71,7 @@ struct mixer_resources {
struct clk  *sclk_mixer;
struct clk  *sclk_hdmi;
struct clk  *sclk_dac;
+   boolis_soc_exynos5;
 };

 struct mixer_context {
@@ -251,7 +252,8 @@ static void mixer_vsync_set_update(struct mixer_context 
*ctx, bool enable)
mixer_reg_writemask(res, MXR_STATUS, enable ?
MXR_STATUS_SYNC_ENABLE : 0, MXR_STATUS_SYNC_ENABLE);

-   vp_reg_write(res, VP_SHADOW_UPDATE, enable ?
+   if (!res->is_soc_exynos5)
+   vp_reg_write(res, VP_SHADOW_UPDATE, enable ?
VP_SHADOW_UPDATE_ENABLE : 0);
 }

@@ -615,15 +617,21 @@ static void mixer_win_reset(struct mixer_context *ctx)
val = MXR_GRP_CFG_ALPHA_VAL(0);
mixer_reg_write(res, MXR_VIDEO_CFG, val);

-   /* configuration of Video Processor Registers */
-   vp_win_reset(ctx);
-   vp_default_filter(res);
+   if (!res->is_soc_exynos5) {
+   /* configuration of Video Processor Registers */
+   vp_win_reset(ctx);
+   vp_default_filter(res);
+   }

/* disable all layers */
mixer_reg_writemask(res, MXR_CFG, 0, MXR_CFG_GRP0_ENABLE);
mixer_reg_writemask(res, MXR_CFG, 0, MXR_CFG_GRP1_ENABLE);
mixer_reg_writemask(res, MXR_CFG, 0, MXR_CFG_VP_ENABLE);

+   /* enable vsync interrupt after mixer reset*/
+   mixer_reg_writemask(res, MXR_INT_EN, MXR_INT_EN_VSYNC,
+   MXR_INT_EN_VSYNC);
+
mixer_vsync_set_update(ctx, true);
spin_unlock_irqrestore(>reg_slock, flags);
 }
@@ -645,7 +653,8 @@ static void mixer_poweron(struct mixer_context *ctx)
pm_runtime_get_sync(ctx->dev);

clk_enable(res->mixer);
-   clk_enable(res->vp);
+   if (!res->is_soc_exynos5)
+   clk_enable(res->vp);
clk_enable(res->sclk_mixer);

mixer_reg_write(res, MXR_INT_EN, ctx->int_en);
@@ -666,7 +675,8 @@ static void mixer_poweroff(struct mixer_context *ctx)
ctx->int_en = mixer_reg_read(res, MXR_INT_EN);

clk_disable(res->mixer);
-   clk_disable(res->vp);
+   if (!res->is_soc_exynos5)
+   clk_disable(res->vp);
clk_disable(res->sclk_mixer);

pm_runtime_put_sync(ctx->dev);
@@ -797,11 +807,16 @@ static void mixer_win_mode_set(void *ctx,
 static void mixer_win_commit(void *ctx, int win)
 {
struct mixer_context *mixer_ctx = ctx;
+   struct mixer_resources *res = _ctx->mixer_res;

DRM_DEBUG_KMS("[%d] %s, win: %d\n", __LINE__, __func__, win);

-   if (win > 1)
-   vp_video_buffer(mixer_ctx, win);
+   if (!res->is_soc_exynos5) {
+   if (win > 1)
+   vp_video_buffer(mixer_ctx, win);
+   else
+   mixer_graph_buffer(mixer_ctx, win);
+   }
else
mixer_graph_buffer(mixer_ctx, win);
 }
@@ -888,6 +903,12 @@ static irqreturn_t mixer_irq_handler(int irq, void *arg)

/* handling VSYNC */
if (val & MXR_INT_STATUS_VSYNC) {
+   /* layer update mandatory for exynos5 soc,and not present
+   * in exynos4 */
+   if (res->is_soc_exynos5)
+   mixer_reg_writemask(res, MXR_CFG, ~0,
+   MXR_CFG_LAYER_UPDATE);
+
/* interlace scan need to check shadow register */
if (ctx->interlace) {
base = mixer_reg_read(res, MXR_GRAPHIC_BASE(0));
@@ -919,8 +940,81 @@ out:
return IRQ_HANDLED;
 }

-static int __devinit mixer_resources_init(struct exynos_drm_hdmi_context *ctx,
-struct platform_device *pdev)
+static int __devinit mixer_resources_init_exynos5(
+   struct exynos_drm_hdmi_context *ctx,
+   struct platform_device *pdev)
+{
+   struct mixer_context *mixer_ctx = ctx->ctx;
+   struct device *dev = >dev;
+   struct mixer_resources *mixer_res = _ctx->mixer_res;
+   struct resource *res;
+   int ret;
+
+   DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
+
+   mixer_res->is_soc_exynos5 = true;
+   spin_lock_init(_res->reg_slock);
+
+   mixer_res->mixer = clk_get(dev,

[PATCH 0/3] drm: exynos: hdmi: add exynos5 support for drm hdmi

This patch set adds the support for Samsung's Exynos5250 in DRM-HDMI. It
includes modifcations in hdmi and mixer paltform drivers. Also, removes
the dependency on plf data for hdmi, mixer context pointers needed by
exynos-drm-hdmi. 

This patchset is based on branch exynos-drm-next at 
git://git.infradead.org/users/kmpark/linux-samsung (linux v3.6-rc4)

Rahul Sharma (3):
  drm: exynos: hdmi: add exynos5 support to mixer driver
  drm: exynos: hdmi: add exynos5 support to hdmi driver
  drm: exynos: hdmi: clean dependency on plf data for mixer, hdmi
context

 drivers/gpu/drm/exynos/exynos_drm_hdmi.c |   47 +++---
 drivers/gpu/drm/exynos/exynos_drm_hdmi.h |2 +
 drivers/gpu/drm/exynos/exynos_hdmi.c |  303 +++---
 drivers/gpu/drm/exynos/exynos_mixer.c|  156 ++--
 drivers/gpu/drm/exynos/regs-mixer.h  |2 +
 5 files changed, 443 insertions(+), 67 deletions(-)

[RFC 0/9] nuclear pageflip

On Wed, Sep 12, 2012 at 09:28:43AM -0500, Rob Clark wrote:
> On Wed, Sep 12, 2012 at 9:23 AM, Ville Syrj?l?
>  wrote:
> > On Wed, Sep 12, 2012 at 07:30:18AM -0500, Rob Clark wrote:
> >> On Wed, Sep 12, 2012 at 3:59 AM, Ville Syrj?l?
> >>  wrote:
> >> > On Tue, Sep 11, 2012 at 05:07:49PM -0500, Rob Clark wrote:
> >> >> On Tue, Sep 11, 2012 at 4:15 PM, Ben Widawsky  
> >> >> wrote:
> >> >> > On Sun, 9 Sep 2012 22:19:59 -0500
> >> >> > Rob Clark  wrote:
> >> >> >
> >> >> >> On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark  
> >> >> >> wrote:
> >> >> >> > From: Rob Clark 
> >> >> >> >
> >> >> >> > This is following a bit the approach that Ville is taking for 
> >> >> >> > atomic-
> >> >> >> > modeset, in that it is switching over to using properties for 
> >> >> >> > everything.
> >> >> >> > The advantage of this approach is that it makes it easier to add 
> >> >> >> > new
> >> >> >> > attributes to set as part of a page-flip (and even opens the 
> >> >> >> > option to
> >> >> >> > add new object types).
> >> >> >>
> >> >> >> oh, and for those wondering what the hell this is all about,
> >> >> >> nuclear-pageflip is a pageflip that atomically updates the CRTC layer
> >> >> >> and zero or more attached plane layers, optionally changing various
> >> >> >> properties such as z-order (or even blending modes, etc) atomically.
> >> >> >> It includes the option for a test step so userspace compositor can
> >> >> >> test a proposed configuration (if any properties not marked as
> >> >> >> 'dynamic' are updated).  This intended to allow, for example, weston
> >> >> >> compositor to synchronize updates to plane (sprite) layers with CRTC
> >> >> >> layer.
> >> >> >>
> >> >> >
> >> >> > Can we please name this something different? I complained about this 
> >> >> > in
> >> >> > IRC, but I don't know if you hang around in #intel-gfx.
> >> >> >
> >> >> > Some suggestions:
> >> >> > multiplane pageflip
> >> >> > muliplane atomic pageflip
> >> >> > atomic multiplane pageflip
> >> >> > atomic multiflip
> >> >> > pageflip of atomic and multiplane nature
> >> >> >
> >> >> > Nuclear is not at all descriptive and requires as your response shows
> >> >> > :-)
> >> >> >
> >> >>
> >> >> fair enough.. I was originally calling it atomic-pageflip until
> >> >> someone (I don't remember who) started calling it nuclear-pageflip to
> >> >> differentiate from atomic-modeset.  But IMO we could just call the two
> >> >> ioclts atomic-modeset and atomic-pageflip.  (Or even modeset2 and
> >> >> pageflip2, but that seems much more boring)
> >> >
> >> > My plan has been to use the same ioctl for both uses. They'll need
> >> > nearly identical handling anyway on the ioctl level. I have something
> >> > semi-working currently, but I need to clean it up a bit before I can
> >> > show it to anyone.
> >>
> >> I do think the atomic-pageflip ioctl really should take the crtc-id..
> >> so probably should be two ioctls, but nearly identical
> >
> > But then you can't support atomic pageflips across multiple crtcs even
> > if the hardware would allow it. I would hate to add such limitation to
> > the API. I can immediately think of a use case; combining several
> > smaller displays to form a single larger display.
> >
> > With a unified API you could just add some kind of flag that tells the
> > kernel that user space really wants an atomic update, and if the
> > driver/hardware can't do it, it can return an error.
> 
> well, that is really only a problem for X11..  and atomic flip across
> multiple crtc's is a potential mess from performance standpoint unless
> your displays are vsync'd lock.

It won't be truly atomic unless they are vsync locked. But anyways more 
buffers can be used to solve the performance problem. But that's a
separate issue and in that case it doesn't really matter whether you
issue separate ioctls for each crtc.

> weston already renders each output individually, rather than spanning
> a single fb across multiple displays like x11 does.  So this problem
> really doesn't exist for weston.

It does if you want to make sure the user sees the flip on both displays
at the same time.

-- 
Ville Syrj?l?
Intel OTC

Memory eviction in ttm

2012-09-12 Thread Maarten Lankhorst

Op 12-09-12 15:28, Thomas Hellstrom schreef:
> On 09/12/2012 02:48 PM, Maarten Lankhorst wrote:
>> Hey Thomas,
>>
>> I'm playing around with moving reservations from ttm to global, but how ttm
>> ttm is handling reservations is getting in the way.  The code wants to move
>> the bo from the lru lock at the same time a reservation is made, but that
>> seems to be slightly too strict. It would really help me if that guarantee
>> is removed.
> Hi, Maarten.
>
> Removing that restriction is not really possible at the moment.
> Also the memory accounting code depends on this, and may cause reservations
> in the most awkward places. Since these reservations don't have a ticket
> they may and will cause deadlocks. So in short the restriction is there
> to avoid deadlocks caused by ticketless reservations.
Yeah I was afraid of that, however with some buffers no longer managed by ttm
it will be impossible to guarantee that buffers are not reserved while on the 
lru list.

I've been working on adding some lockdep state to the generic reservations
code. It was already complaining about lru_lock, so hopefully if there is any
potential for reservation deadlock, lockdep will throw big scary errors at you.

If the guarantee that all buffers on the lru list can be reserved can be 
removed,
it would also be a step forward to make dma-buf buffers evictable.

>> Is it true that only the ttm_mem_evict code depends on it? And in that case
>> wouldn't it be better to attempt to free any buffer that can be reserved
>> without blocking first, instead of blocking on the first entry in the list?
> Normally there is no reservation blocking, since the items on the LRU lists
> are guaranteed not to be reserved, but if we reserve without taking off
> LRU lists, the above may be a good optimization.
..?

~Maarten

[RFC 0/9] nuclear pageflip

On Wed, Sep 12, 2012 at 07:30:18AM -0500, Rob Clark wrote:
> On Wed, Sep 12, 2012 at 3:59 AM, Ville Syrj?l?
>  wrote:
> > On Tue, Sep 11, 2012 at 05:07:49PM -0500, Rob Clark wrote:
> >> On Tue, Sep 11, 2012 at 4:15 PM, Ben Widawsky  wrote:
> >> > On Sun, 9 Sep 2012 22:19:59 -0500
> >> > Rob Clark  wrote:
> >> >
> >> >> On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark  
> >> >> wrote:
> >> >> > From: Rob Clark 
> >> >> >
> >> >> > This is following a bit the approach that Ville is taking for atomic-
> >> >> > modeset, in that it is switching over to using properties for 
> >> >> > everything.
> >> >> > The advantage of this approach is that it makes it easier to add new
> >> >> > attributes to set as part of a page-flip (and even opens the option to
> >> >> > add new object types).
> >> >>
> >> >> oh, and for those wondering what the hell this is all about,
> >> >> nuclear-pageflip is a pageflip that atomically updates the CRTC layer
> >> >> and zero or more attached plane layers, optionally changing various
> >> >> properties such as z-order (or even blending modes, etc) atomically.
> >> >> It includes the option for a test step so userspace compositor can
> >> >> test a proposed configuration (if any properties not marked as
> >> >> 'dynamic' are updated).  This intended to allow, for example, weston
> >> >> compositor to synchronize updates to plane (sprite) layers with CRTC
> >> >> layer.
> >> >>
> >> >
> >> > Can we please name this something different? I complained about this in
> >> > IRC, but I don't know if you hang around in #intel-gfx.
> >> >
> >> > Some suggestions:
> >> > multiplane pageflip
> >> > muliplane atomic pageflip
> >> > atomic multiplane pageflip
> >> > atomic multiflip
> >> > pageflip of atomic and multiplane nature
> >> >
> >> > Nuclear is not at all descriptive and requires as your response shows
> >> > :-)
> >> >
> >>
> >> fair enough.. I was originally calling it atomic-pageflip until
> >> someone (I don't remember who) started calling it nuclear-pageflip to
> >> differentiate from atomic-modeset.  But IMO we could just call the two
> >> ioclts atomic-modeset and atomic-pageflip.  (Or even modeset2 and
> >> pageflip2, but that seems much more boring)
> >
> > My plan has been to use the same ioctl for both uses. They'll need
> > nearly identical handling anyway on the ioctl level. I have something
> > semi-working currently, but I need to clean it up a bit before I can
> > show it to anyone.
> 
> I do think the atomic-pageflip ioctl really should take the crtc-id..
> so probably should be two ioctls, but nearly identical

But then you can't support atomic pageflips across multiple crtcs even
if the hardware would allow it. I would hate to add such limitation to
the API. I can immediately think of a use case; combining several
smaller displays to form a single larger display.

With a unified API you could just add some kind of flag that tells the
kernel that user space really wants an atomic update, and if the
driver/hardware can't do it, it can return an error.

-- 
Ville Syrj?l?
Intel OTC

[PATCH 3/9] drivers/gpu/drm/ttm/ttm_page_alloc_dma.c: Remove useless kfree

2012-09-12 Thread Peter Senna Tschudin

From: Peter Senna Tschudin 

Remove useless kfree() and clean up code related to the removal.

The semantic patch that finds this problem is as follows:
(http://coccinelle.lip6.fr/)

// 
@r exists@
position p1,p2;
expression x;
@@

if (x at p1 == NULL) { ... kfree at p2(x); ... return ...; }

@unchanged exists@
position r.p1,r.p2;
expression e <= r.x,x,e1;
iterator I;
statement S;
@@

if (x at p1 == NULL) { ... when != I(x,...) S
when != e = e1
when != e += e1
when != e -= e1
when != ++e
when != --e
when != e++
when != e--
when != 
   kfree at p2(x); ... return ...; }

@ok depends on unchanged exists@
position any r.p1;
position r.p2;
expression x;
@@

... when != true x at p1 == NULL
kfree at p2(x);

@depends on !ok && unchanged@
position r.p2;
expression x;
@@

*kfree at p2(x);
// 

Signed-off-by: Peter Senna Tschudin 

---
 drivers/gpu/drm/ttm/ttm_page_alloc_dma.c |5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c 
b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
index 4f9e548..969d765 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc_dma.c
@@ -1060,7 +1060,7 @@ int ttm_dma_page_alloc_init(struct ttm_mem_global *glob, 
unsigned max_pages)

_manager = kzalloc(sizeof(*_manager), GFP_KERNEL);
if (!_manager)
-   goto err_manager;
+   goto err;

mutex_init(&_manager->lock);
INIT_LIST_HEAD(&_manager->pools);
@@ -1078,9 +1078,6 @@ int ttm_dma_page_alloc_init(struct ttm_mem_global *glob, 
unsigned max_pages)
}
ttm_dma_pool_mm_shrink_init(_manager);
return 0;
-err_manager:
-   kfree(_manager);
-   _manager = NULL;
 err:
return ret;
 }

runtime PM and special power switches

On Wed, Sep 12, 2012 at 3:13 PM, Dave Airlie  wrote:
> On Wed, Sep 12, 2012 at 8:58 AM, Rafael J. Wysocki  wrote:
>> On Wednesday, September 12, 2012, Dave Airlie wrote:
>>> On Wed, Sep 12, 2012 at 7:32 AM, Alan Stern  
>>> wrote:
>>> > On Tue, 11 Sep 2012, Rafael J. Wysocki wrote:
>>> >
>>> >> Hi,
>>> >>
>>> >> On Tuesday, September 11, 2012, Dave Airlie wrote:
>>> >> > Hi Rafael,
>>> >> >
>>> >> > I've been investigating runtime PM support for some use-cases on GPUs.
>>> >> >
>>> >> > In some laptops we have a secondary GPU (optimus) that can be powered
>>> >> > up for certain 3D tasks and then turned off when finished with. Now I
>>> >> > did an initial pass on supporting it without using the kernel runtime
>>> >> > PM stuff, but Alan said I should take a look so here I am.
>>> >>
>>> >> Alan Stern or Alan Cox? :-)
>>> >>
>>> >> > While I've started to get a handle on things, we have a bit of an
>>> >> > extra that I'm not sure we cater for.
>>> >> >
>>> >> > Currently we get called from the PCI layer which after we are finished
>>> >> > with our runtime suspend callback, will go put the device into the
>>> >> > correct state etc, however on these optimus/powerxpress laptops we
>>> >> > have a separate ACPI or platform driver controlled power switch that
>>> >> > we need to call once the PCI layer is finished the job. This switch
>>> >> > effectively turns the power to the card completely off leaving it
>>> >> > drawing no power.
>>> >> >
>>> >> > No we can't hit the switch from the driver callback as the PCI layer
>>> >> > will get lost, so I'm wondering how you'd envisage we could plug this
>>> >> > in.
>>> >>
>>> >> Hmm.  In principle we might modify pci_pm_runtime_suspend() so that it
>>> >> doesn't call pci_finish_runtime_suspend() if pci_dev->state_saved is
>>> >> set.  That would actually make it work in analogy with 
>>> >> pci_pm_suspend_noirq(),
>>> >> so perhaps it's not even too dangerous.
>>> >
>>> > This sounds more like a job for a power domain.  Unless the power
>>> > switch is already in the device hierarchy as a parent to the PCI
>>> > device.
>>>
>>> I'll have to investigate power domains then,
>>>
>>> The switch is hidden in many different places, one some laptops its in
>>> a ACPI _DSM on one GPU, on others its in an ACPI _DSM on the other
>>> one, in some its in a different ACPI _DSM, then we have it in the ACPI
>>> ATPX method on others, and finally Apple have it in a piece of hw that
>>> isn't just on the LPC bus or somewhere like that.
>>>
>>> Currently we just hide it all inside vga_switcheroo and I'd just need
>>> an interface to call that once the layers have stopped poking
>>> registers in PCI config space, if we could fix PCI runtime suspend so
>>> the driver was the last to g 2et called then that would also not suck.
>>
>> Well, as I said, we may try to change the PCI layer so that it doesn't
>> access the device any more in pci_pm_runtime_suspend() if it sees that
>> pci_dev->state_saved has been set by the driver's callback.  Then,
>> your drivers would only need to set pci_dev->state_saved in their
>> .runtime_suspend() callbacks.
>>
>
> Actually it appears I'll need this, I'd forgotten things are a bit
> messier than I thought
>
> So there are two variants on the _DSM for nvidia dual-gpu machines,
> the older pre-optimus _DSM requires
> an explicit power off call post-D3, however for optimus _DSM the D3
> transition will flick the power switch, however
> the pci code then goes and seem to turn the device back to D0 for some
> reason. So yes after save state,
> I'd really appreciate if it the pci layer would stop poking my device.
>
>> Alternatively, which may be less hackish but more work, you can set the
>> pm_domain pointer in the device structure to a struct dev_pm_domain whose
>> ops will just call the corresponding bus type's ops except for
>> .runtime_suspend() that will execute the additional ACPI stuff after calling
>> the bus type's method.
>
> I've mostly written this, and it seems to work, I've jsut set a
> pm_domain in the vga switcheroo code that copies the dev->bus->pm
> into a private structure. I'll need this for the old nvidia and radeon
> poweroffs.
>


http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-opt-pwr
is my current WIP branch

http://cgit.freedesktop.org/~airlied/linux/diff/drivers/gpu/vga/vga_switcheroo.c?h=drm-opt-pwr=8952007a8799a5b096d64a8217e3001e2ebed2ab
contains what I've done to override the 2 pms ops we need to override
for older GPUs

http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-opt-pwr=005fdf5c184f9b857cbd8cb7195898d776f68670
is my current PCI workaround.

Dave.

[Bug 28550] [UMS vs KMS]: Openarena performance drops by half with KMS enabled

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTABUG

--- Comment #4 from Andreas Boll  2012-09-12 
15:44:29 UTC ---
(In reply to comment #3)
> > 1) FPS observed is 60.2 
> 
> It's because KMS is limiting rendering to the refresh rate of your monitor to
> avoid tearing.
> 

Closing.

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

xserver-xorg-video-radeon 6.14.4: X has constant 10 % CPU usage

2012-09-12 Thread Paul Menzel

Am Dienstag, den 11.09.2012, 15:24 +0200 schrieb Michel D?nzer:
> On Die, 2012-09-11 at 15:07 +0200, Paul Menzel wrote: 
> > Am Dienstag, den 11.09.2012, 14:55 +0200 schrieb Michel D?nzer:
> > > On Die, 2012-09-11 at 14:42 +0200, Paul Menzel wrote: 
> > > > 
> > > > using Debian Sid/unstable with the awesome 3.4.13-1 window manager and
> > > > Evolution 3.4.3-1, htop shows X to constantly use 10 % of the CPU.
> > > > Closing Evolution the usage goes back to more or less 0 %.
> > > 
> > > I'm not seeing this. Is there something in your Evolution window(s) that
> > > is constantly repainting, e.g. a spinner in the status bar, a blinking
> > > cursor, ... ?
> > 
> > Now that you are mentioning it, in the bottom there is the message
> > ?Checking for New Messages? and next to it there is an animation where
> > something goes around a circle. Canceling that removes X?s CPU usage.
> 
> That's a GTK+ spinner widget, which uses RENDER trapezoids, which is a
> software rendering fallback with EXA.

Could that be changed to not us some fallback?

> > Should I recommend something to the Evolution folks on how to due such
> > animations? Or is the only way to avoid animations?
> 
> I don't think there's anything wrong with the animation per se. However,
> one issue I've found is that Evolution schedules many actions as glib
> idle callbacks with priority lower than G_PRIORITY_HIGH_IDLE + 20, which
> is the priority used by GTK+ for drawing animations. This can result in
> the animations delaying the completion of the actual work they're
> representing.

I reported that issue as 

[Bug 683867] Schedule actions with priority higher than 
G_PRIORITY_HIGH_IDLE + 20

to the GNOME BTS [1] and Matthew Barnes replied that this should be done
in GTK+ itself.


Thanks,

Paul


[1] https://bugzilla.gnome.org/show_bug.cgi?id=683867
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120912/1afbb663/attachment.pgp>

Memory eviction in ttm

2012-09-12 Thread Thomas Hellstrom

On 09/12/2012 02:48 PM, Maarten Lankhorst wrote:
> Hey Thomas,
>
> I'm playing around with moving reservations from ttm to global, but how ttm
> ttm is handling reservations is getting in the way.  The code wants to move
> the bo from the lru lock at the same time a reservation is made, but that
> seems to be slightly too strict. It would really help me if that guarantee
> is removed.
Hi, Maarten.

Removing that restriction is not really possible at the moment.
Also the memory accounting code depends on this, and may cause reservations
in the most awkward places. Since these reservations don't have a ticket
they may and will cause deadlocks. So in short the restriction is there
to avoid deadlocks caused by ticketless reservations.

>
> Is it true that only the ttm_mem_evict code depends on it? And in that case
> wouldn't it be better to attempt to free any buffer that can be reserved
> without blocking first, instead of blocking on the first entry in the list?
Normally there is no reservation blocking, since the items on the LRU lists
are guaranteed not to be reserved, but if we reserve without taking off
LRU lists, the above may be a good optimization.

>
> This would make integration a lot easier, since I could wait with taking the
> lru lock until after reservation is complete, or any time before unreserving.
>
> ~Maarten
>
/Thomas

runtime PM and special power switches

On Wed, Sep 12, 2012 at 8:58 AM, Rafael J. Wysocki  wrote:
> On Wednesday, September 12, 2012, Dave Airlie wrote:
>> On Wed, Sep 12, 2012 at 7:32 AM, Alan Stern  
>> wrote:
>> > On Tue, 11 Sep 2012, Rafael J. Wysocki wrote:
>> >
>> >> Hi,
>> >>
>> >> On Tuesday, September 11, 2012, Dave Airlie wrote:
>> >> > Hi Rafael,
>> >> >
>> >> > I've been investigating runtime PM support for some use-cases on GPUs.
>> >> >
>> >> > In some laptops we have a secondary GPU (optimus) that can be powered
>> >> > up for certain 3D tasks and then turned off when finished with. Now I
>> >> > did an initial pass on supporting it without using the kernel runtime
>> >> > PM stuff, but Alan said I should take a look so here I am.
>> >>
>> >> Alan Stern or Alan Cox? :-)
>> >>
>> >> > While I've started to get a handle on things, we have a bit of an
>> >> > extra that I'm not sure we cater for.
>> >> >
>> >> > Currently we get called from the PCI layer which after we are finished
>> >> > with our runtime suspend callback, will go put the device into the
>> >> > correct state etc, however on these optimus/powerxpress laptops we
>> >> > have a separate ACPI or platform driver controlled power switch that
>> >> > we need to call once the PCI layer is finished the job. This switch
>> >> > effectively turns the power to the card completely off leaving it
>> >> > drawing no power.
>> >> >
>> >> > No we can't hit the switch from the driver callback as the PCI layer
>> >> > will get lost, so I'm wondering how you'd envisage we could plug this
>> >> > in.
>> >>
>> >> Hmm.  In principle we might modify pci_pm_runtime_suspend() so that it
>> >> doesn't call pci_finish_runtime_suspend() if pci_dev->state_saved is
>> >> set.  That would actually make it work in analogy with 
>> >> pci_pm_suspend_noirq(),
>> >> so perhaps it's not even too dangerous.
>> >
>> > This sounds more like a job for a power domain.  Unless the power
>> > switch is already in the device hierarchy as a parent to the PCI
>> > device.
>>
>> I'll have to investigate power domains then,
>>
>> The switch is hidden in many different places, one some laptops its in
>> a ACPI _DSM on one GPU, on others its in an ACPI _DSM on the other
>> one, in some its in a different ACPI _DSM, then we have it in the ACPI
>> ATPX method on others, and finally Apple have it in a piece of hw that
>> isn't just on the LPC bus or somewhere like that.
>>
>> Currently we just hide it all inside vga_switcheroo and I'd just need
>> an interface to call that once the layers have stopped poking
>> registers in PCI config space, if we could fix PCI runtime suspend so
>> the driver was the last to g 2et called then that would also not suck.
>
> Well, as I said, we may try to change the PCI layer so that it doesn't
> access the device any more in pci_pm_runtime_suspend() if it sees that
> pci_dev->state_saved has been set by the driver's callback.  Then,
> your drivers would only need to set pci_dev->state_saved in their
> .runtime_suspend() callbacks.
>

Actually it appears I'll need this, I'd forgotten things are a bit
messier than I thought

So there are two variants on the _DSM for nvidia dual-gpu machines,
the older pre-optimus _DSM requires
an explicit power off call post-D3, however for optimus _DSM the D3
transition will flick the power switch, however
the pci code then goes and seem to turn the device back to D0 for some
reason. So yes after save state,
I'd really appreciate if it the pci layer would stop poking my device.

> Alternatively, which may be less hackish but more work, you can set the
> pm_domain pointer in the device structure to a struct dev_pm_domain whose
> ops will just call the corresponding bus type's ops except for
> .runtime_suspend() that will execute the additional ACPI stuff after calling
> the bus type's method.

I've mostly written this, and it seems to work, I've jsut set a
pm_domain in the vga switcheroo code that copies the dev->bus->pm
into a private structure. I'll need this for the old nvidia and radeon
poweroffs.

Dave.

[Bug 48693] -O2 optimization breaks 32 bit wine 3D on 64 bit system

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

Andreas Boll  changed:

   What|Removed |Added

  Component|Drivers/DRI/R600|Drivers/Gallium/r600

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

[Bug 31246] [RADEON::CYPRESS:R600C] reproducible hangs on piglit tests with HD5850

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #9 from Andreas Boll  2012-09-12 
15:02:14 UTC ---
(In reply to comment #8)
> The hang with glsl-vs-vec4-indexing-temp-dst-in-nested-loop-combined has been
> fixed for r600g now :)

Closing.

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

[RFC 1/9] drm: add atomic fxns

On Wed, Sep 12, 2012 at 2:05 PM, Jesse Barnes  
wrote:
> On Wed, 12 Sep 2012 12:35:01 -0500
> Rob Clark  wrote:
>
>> On Wed, Sep 12, 2012 at 11:57 AM, Jesse Barnes  
>> wrote:
>> > On Sun,  9 Sep 2012 22:03:14 -0500
>> > Rob Clark  wrote:
>> >
>> >> From: Rob Clark 
>> >>
>> >> The 'atomic' mechanism allows for multiple properties to be updated,
>> >> checked, and commited atomically.  This will be the basis of atomic-
>> >> modeset and nuclear-pageflip.
>> >>
>> >> The basic flow is:
>> >>
>> >>state = dev->atomic_begin();
>> >>for (... one or more ...)
>> >>   obj->set_property(obj, state, prop, value);
>> >>if (dev->atomic_check(state))
>> >>   dev->atomic_commit(state, event);
>> >>dev->atomic_end(state);
>> >
>> > I think the above is more suited to drm_crtc_helper code.  I think the
>> > top level callback should contain the arrays and be a single "multi
>> > flip" hook (or maybe a check then set double callback).  For some
>> > drivers that'll end up being a lot simpler, rather than sprinkling
>> > atomic handling code in all the set_property callbacks.
>>
>> well, there are a few other places in drm_crtc.c where I want to use
>> the new API, to avoid drivers having to support both atomic API and
>> old set_plane/page_flip stuff.. the transactional API makes that a bit
>> easier, I think.. or at least I don't have to construct an array on
>> the stack.
>>
>> But I'm not entirely convinced that it is a problem.. with
>> drm_{crtc,plane,etc}_state, it is just building up a set of values in
>> a state struct, and that state struct gets atomically committed.
>
> Yeah I know it can work this way, it just seemed like the begin, end,
> and set_property callbacks might be unnecessary if the props were all
> part of the state.  The driver call roll things back (or just not touch
> hw) if the check or commit fails...
>
> I guess ultimately, given the choice, I'd rather have the drivers
> calling into helper functions where possible, rather than having the
> core impose a specific set of semi-fine grained hooks.

well, that is is basically what is happening.. for example, the
driver's set_property() code would, if the driver doesn't have any
custom properties, basically just be:

int xyz_set_property(crtc, state, property, val)
{
  return drm_crtc_set_property(crtc,
xyz_get_crtc_state(state, crtc->pipe), property, val);
}

so the driver basically just has to map the generic void *state to the
appropriate 'struct drm_crtc_state *', and then call helpers.

But the driver is also free to intercept property values, if needed.
For example, with the private-plane setup in omapdrm, in the crtc I
intercept the fb-id property and also set it on the crtc's private
plane.

I suppose you could move the for loop iterating over an array of
properties into the driver.  I'm not really sure what that buys you,
since none of this is really applying state to hw at this stage.  Plus
I think we'd end up needing both fxn ptrs that take a single property
plus one that takes an array.

The part that is more important to give the driver flexibility is that
point where you need to apply the state to the hw, and here the driver
has complete control.  Although perhaps there is some room for
crtc-helpers to plug in below that for the modeset.

BR,
-R

>> > Having a transactional API just seems a little messier with both the
>> > atomic state and per-property state to track and rollback in the case
>> > of failure.
>>
>> For the rollback, I think I'm just going to move the array of property
>> values into drm_{crtc,plane,etc}_state.  That way, userspace doesn't
>> see updated property values if they are not committed.  It makes the
>> property value rollback automatic.
>
> Ok that seems reasonable.
>
> --
> Jesse Barnes, Intel Open Source Technology Center
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

Memory eviction in ttm

2012-09-12 Thread Maarten Lankhorst

Hey Thomas,

I'm playing around with moving reservations from ttm to global, but how ttm
ttm is handling reservations is getting in the way.  The code wants to move
the bo from the lru lock at the same time a reservation is made, but that
seems to be slightly too strict. It would really help me if that guarantee
is removed.

Is it true that only the ttm_mem_evict code depends on it? And in that case
wouldn't it be better to attempt to free any buffer that can be reserved
without blocking first, instead of blocking on the first entry in the list?

This would make integration a lot easier, since I could wait with taking the
lru lock until after reservation is complete, or any time before unreserving.

~Maarten

[RFC 0/9] nuclear pageflip

On Wed, Sep 12, 2012 at 1:58 PM, Ville Syrj?l?
 wrote:
> On Wed, Sep 12, 2012 at 01:00:19PM -0500, Clark, Rob wrote:
>> On Wed, Sep 12, 2012 at 12:27 PM, Ville Syrj?l?
>>  wrote:
>> > On Wed, Sep 12, 2012 at 10:48:16AM -0500, Rob Clark wrote:
>> >> But I think we could still do this w/ one ioctl per crtc for 
>> >> atomic-pageflip.
>> >
>> > We could, if we want to sacrifice the synced multi display case. I just
>> > think it might be a real use case at some point. IVI feels like the most
>> > likely short term cadidate to me, but perhaps someone would finally
>> > introduce some new style phone/tablet thingy. I have seen
>> > concepts/prototypes of such multi display gadgets in the past, but the
>> > industry apparently got a bit stuck on the rectangular slab with
>> > touchscreen on one side design.
>>
>> I could be wrong, but I think IVI the screens would normally be too
>> far apart to matter?
>
> I was thinking of something like a display on the dash that normally
> sits low with only a small sliver visible, and extends upwards when
> you fire up a movie player for example. Internally it could be made
> up of two displays for power savings purposes.
>
>> Anyways, it is really only a problem if you can't do two ioctl()s
>> within one vblank period. If it actually turns out to be a real
>> problem,
>
> Well exactly that's the problem this whole atomic pageflip stuff is
> trying to tackle, no? ;)
>
>> we could always add later an ioctl that takes an array of
>> 'struct drm_mode_crtc_atomic_page_flip's.  I'm not sure if this is
>> really useful or not.. but maybe I'm thinking too much about how
>> weston does it's rendering of different output's independently.
>
> I'm just now thinking of surfaceflinger's way of doing things, with
> its prepare and commit phases. If you need to issue two ioctls to handle
> cloned displays, then you can end up in a somewhat funky situation.
>
> Let's say you have a video overlay in use (one each display naturally),
> and you increase the downscaling factor enough so that you now have
> enough memory bandwith to support only one overlay. With independent
> check ioctls for each display, you never have the full device state
> available in the kernel, so each check succeeds during the prepare
> phase. So you decide that you can keep using the video overlays.
>
> You then proceed to commit the state, but after the first display has
> been commited you get an error when trying to commit the second one.
> What can you do now? The only option is to keep displaying the old
> frame on the other displays for some time longer, and then on the
> next frame you can switch to GPU composition. But on the next frame you
> perhaps no longer need to use GPU composition, but since you can't
> verify that in the prepare phase, you have no other option but to use
> GPU composition.
>
> So when you run into a configuration that can be supported only
> partially, you get animation stalls on some displays due to skipped
> frames, and you always have to fall back to GPU composition for the
> next frame.
>
> If on the other hand you would check the whole state in one ioctl,
> you'd get the error in the first prepare phase, and could fall back
> to GPU composition immediately.
>
> Am I too much of a perfectionst in considering such things? I don't
> think so, but perhaps other people disagree.

Ok, if you have a case where the state of the two crtc's are not
actually independent, then I think you have a valid point.

I'm not quite sure what userspace would do about it, though.. for the
general case where vsync isn't locked, and you can't even necessarily
assume vsync period is the same, then I don't really think you want to
couple rendering to the displays.  OTOH, the 'test' step can come
independent of vblank, so maybe you'd want to do the 'test' step
together, and then the flip parts independently.  Hmm...

>> I wonder.. if you have some special hw setup where you can keep the
>> multiple display's in sync-lock, maybe a special virtual crtc would
>> work.  That way userspace it appears as a single display.  I'm not
>> really sure how crazy that would be to implement.
>
> Sure, add more abstraction layers and you can solve any problem :)

well, not really.. but my point was this sort of setup would be a
somewhat custom hardware setup, so maybe some hack in that case isn't
such a bad idea.  I dunno..

>> But I think in the
>> common case, where the displays are not vsync locked, treating the
>> page flips of different crtc's independently, and rendering the
>> contents for different outputs independently (like weston) makes the
>> most sense.
>
> My API design doesn't preclude that at all. In light of my android tale
> above how would weston decide whether it can use overlays in such a
> case?

>From userspace API, I guess something like:

struct drm_mode_crtc_atomic_page_flip {
uint32_t flags;
uint32_t count_crtcs;
uint64_t crtc_ids_ptr;  /* array of uint32_t */

[Bug 30693] [RADEON::RV670:R600C] kwin 4.5.2] blur does not work with RV670 (it works with the old GLSL compiler)

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

Andreas Boll  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #11 from Andreas Boll  2012-09-12 
14:35:05 UTC ---
(In reply to comment #10)
> It does work with R600g and kwin 4.6.
> 
> RV670 with R600g, 2.6.38-rc4, xorg-server-1.9.4, mesa git, libdrm git,
> xf86-video-ati git, pageflipping on, colortiling on, swapbufferwaits off.
> 
> If you want you can close.

Closing.

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

[PATCH 7/8] drm/radeon: remove radeon_bo_clear_va

On 11.09.2012 18:12, Jerome Glisse wrote:
> On Tue, Sep 11, 2012 at 10:10 AM, Christian K?nig
>  wrote:
>> It is unnecessary when we remove the va in drm_close.
>>
>> Signed-off-by: Christian K?nig 
> NAK there is case for which drm_close is not call like ib pool and
> other iirc. This clear va is really a safety net.

Ah, ok that makes sense. Sorry I was just a bit confused about that.

Christian.

>
>> ---
>>   drivers/gpu/drm/radeon/radeon_object.c |   11 ---
>>   1 file changed, 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon_object.c 
>> b/drivers/gpu/drm/radeon/radeon_object.c
>> index 8d23b7e..d210fe5 100644
>> --- a/drivers/gpu/drm/radeon/radeon_object.c
>> +++ b/drivers/gpu/drm/radeon/radeon_object.c
>> @@ -46,16 +46,6 @@ static void radeon_bo_clear_surface_reg(struct radeon_bo 
>> *bo);
>>* function are calling it.
>>*/
>>
>> -void radeon_bo_clear_va(struct radeon_bo *bo)
>> -{
>> -   struct radeon_bo_va *bo_va, *tmp;
>> -
>> -   list_for_each_entry_safe(bo_va, tmp, >va, bo_list) {
>> -   /* remove from all vm address space */
>> -   radeon_vm_bo_rmv(bo->rdev, bo_va->vm, bo);
>> -   }
>> -}
>> -
>>   static void radeon_ttm_bo_destroy(struct ttm_buffer_object *tbo)
>>   {
>>  struct radeon_bo *bo;
>> @@ -65,7 +55,6 @@ static void radeon_ttm_bo_destroy(struct ttm_buffer_object 
>> *tbo)
>>  list_del_init(>list);
>>  mutex_unlock(>rdev->gem.mutex);
>>  radeon_bo_clear_surface_reg(bo);
>> -   radeon_bo_clear_va(bo);
>>  drm_gem_object_release(>gem_base);
>>  kfree(bo);
>>   }
>> --
>> 1.7.9.5
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 8/8] drm/radeon: rework the VM code a bit more

On 11.09.2012 18:11, Jerome Glisse wrote:
> On Tue, Sep 11, 2012 at 10:10 AM, Christian K?nig
>  wrote:
>> Roughly based on how nouveau is handling it. Instead of
>> adding the bo_va when the address is set add the bo_va
>> when the handle is opened, but set the address to zero
>> until userspace tells us where to place it.
>>
>> This fixes another bunch of problems with glamor.
> What exactly are the fix ? I don't see why this change is needed. It
> make things more complicated in my view.
Applications can open GEM Handles multiple times, so what happens is 
that (for example) the DDX creates an BO to back a pixmap, hands that 
over to GLAMOR and than closes the handle again (a bit later and also 
not all the times).

In the end the kernel complains that bo x isn't in vm y, what makes 
sense cause the DDX has removed the mapping by closing the handle. What 
we don't have in this picture is that the handle was opened two times, 
once for creation and once for handing it over to GLAMOR.

I see three possible solutions to that problem:
1. Remember how many times a handle was opened in a vm context, that is 
what this patch does.

2. Instead of removing the mapping on closing the handle we change 
usespace to remove the mapping separately.

3. Change GEM to only call the open/close callbacks when the handle is 
opened and closed for the first/last time in a process context, that 
would also eliminate the refcounting nouveau is currently doing.

Feel free to choose one, I just have implemented number 1 because that 
was the simplest way to go (for me).

Cheers,
Christian.

>
>> Signed-off-by: Christian K?nig 
>> ---
>>   drivers/gpu/drm/radeon/radeon.h  |   30 ---
>>   drivers/gpu/drm/radeon/radeon_gart.c |  147 
>> ++
>>   drivers/gpu/drm/radeon/radeon_gem.c  |   47 +--
>>   3 files changed, 153 insertions(+), 71 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/radeon/radeon.h 
>> b/drivers/gpu/drm/radeon/radeon.h
>> index 8cca1d2..4d67f0f 100644
>> --- a/drivers/gpu/drm/radeon/radeon.h
>> +++ b/drivers/gpu/drm/radeon/radeon.h
>> @@ -292,17 +292,20 @@ struct radeon_mman {
>>
>>   /* bo virtual address in a specific vm */
>>   struct radeon_bo_va {
>> -   /* bo list is protected by bo being reserved */
>> +   /* protected by bo being reserved */
>>  struct list_headbo_list;
>> -   /* vm list is protected by vm mutex */
>> -   struct list_headvm_list;
>> -   /* constant after initialization */
>> -   struct radeon_vm*vm;
>> -   struct radeon_bo*bo;
>>  uint64_tsoffset;
>>  uint64_teoffset;
>>  uint32_tflags;
>>  boolvalid;
>> +   unsignedref_count;
> unsigned refcount is a recipe for failure, if somehow you over unref
> then you va will stay alive forever and this overunref will probably
> go unnoticed.
>
>> +
>> +   /* protected by vm mutex */
>> +   struct list_headvm_list;
>> +
>> +   /* constant after initialization */
>> +   struct radeon_vm*vm;
>> +   struct radeon_bo*bo;
>>   };
>>
>>   struct radeon_bo {
>> @@ -1848,14 +1851,15 @@ void radeon_vm_bo_invalidate(struct radeon_device 
>> *rdev,
>>   struct radeon_bo *bo);
>>   struct radeon_bo_va *radeon_vm_bo_find(struct radeon_vm *vm,
>> struct radeon_bo *bo);
>> -int radeon_vm_bo_add(struct radeon_device *rdev,
>> -struct radeon_vm *vm,
>> -struct radeon_bo *bo,
>> -uint64_t offset,
>> -uint32_t flags);
>> +struct radeon_bo_va *radeon_vm_bo_add(struct radeon_device *rdev,
>> + struct radeon_vm *vm,
>> + struct radeon_bo *bo);
>> +int radeon_vm_bo_set_addr(struct radeon_device *rdev,
>> + struct radeon_bo_va *bo_va,
>> + uint64_t offset,
>> + uint32_t flags);
>>   int radeon_vm_bo_rmv(struct radeon_device *rdev,
>> -struct radeon_vm *vm,
>> -struct radeon_bo *bo);
>> +struct radeon_bo_va *bo_va);
>>
>>   /* audio */
>>   void r600_audio_update_hdmi(struct work_struct *work);
>> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c 
>> b/drivers/gpu/drm/radeon/radeon_gart.c
>> index 2c59491..2f28ff3 100644
>> --- a/drivers/gpu/drm/radeon/radeon_gart.c
>> +++ b/drivers/gpu/drm/radeon/radeon_gart.c
>> @@ -693,51 +693,83 @@ struct radeon_bo_va *radeon_vm_bo_find(struct 
>> radeon_vm *vm,
>>* @rdev: radeon_device pointer
>>* @vm: requested vm
>>* @bo: radeon buffer object
>> - * @offset: requested offset of the buffer in the VM address

[Bug 25871] nearest neighbour samples wrong texel (precision/rounding problem)

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

--- Comment #11 from Andreas Boll  2012-09-12 
13:56:46 UTC ---
(In reply to comment #10)
> 
> It's so long ago I don't remember the exact details. You can easily figure it
> out though. The test program creates a 4x4 checker board texture and then uses
> a single point on it to draw the triangles. The range [0.25,0.5[ should all be
> the same color. The bug was that as you approached 0.5, it started sampling 
> the
> next pixel prematurely.
> 
> So change the fragment program to use coordinate 0.4 or something like that.
> That colour should be the same as 0.4999... . Looking at the code, white seems
> to be the correct colour.

Ok I've got it.

With coordinate 0.4 I get a white color and with 0.4999 I get black.

Additionally I checked the other end of the range:
Between the range [0.2480468676,0.498046860099] the color is white.
If I change the fragment program to use coordinate 0.2480468675 then the color
is black. With 0.4980468601 I get also black.

So the issue persists in git mesa master 9.1-devel (git-e81ee67)

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

[PATCH 8/8] drm/radeon: rework the VM code a bit more

2012-09-12 Thread Jerome Glisse

On Wed, Sep 12, 2012 at 1:13 PM, Christian K?nig
 wrote:
> On 12.09.2012 15:54, Jerome Glisse wrote:
>>
>> On Wed, Sep 12, 2012 at 8:08 AM, Christian K?nig
>>  wrote:
>>>
>>> On 11.09.2012 18:11, Jerome Glisse wrote:

 On Tue, Sep 11, 2012 at 10:10 AM, Christian K?nig
  wrote:
>
> Roughly based on how nouveau is handling it. Instead of
> adding the bo_va when the address is set add the bo_va
> when the handle is opened, but set the address to zero
> until userspace tells us where to place it.
>
> This fixes another bunch of problems with glamor.

 What exactly are the fix ? I don't see why this change is needed. It
 make things more complicated in my view.
>>>
>>> Applications can open GEM Handles multiple times, so what happens is that
>>> (for example) the DDX creates an BO to back a pixmap, hands that over to
>>> GLAMOR and than closes the handle again (a bit later and also not all the
>>> times).
>>>
>>> In the end the kernel complains that bo x isn't in vm y, what makes sense
>>> cause the DDX has removed the mapping by closing the handle. What we
>>> don't
>>> have in this picture is that the handle was opened two times, once for
>>> creation and once for handing it over to GLAMOR.
>>>
>>> I see three possible solutions to that problem:
>>> 1. Remember how many times a handle was opened in a vm context, that is
>>> what
>>> this patch does.
>>>
>>> 2. Instead of removing the mapping on closing the handle we change
>>> usespace
>>> to remove the mapping separately.
>>>
>>> 3. Change GEM to only call the open/close callbacks when the handle is
>>> opened and closed for the first/last time in a process context, that
>>> would
>>> also eliminate the refcounting nouveau is currently doing.
>>>
>>> Feel free to choose one, I just have implemented number 1 because that
>>> was
>>> the simplest way to go (for me).
>>>
>>> Cheers,
>>> Christian.
>>
>> I am all ok for the refcounting part but i don't think the always add
>> a va to bo is a good idea. It just add more code for no good reason.
>
> Always adding a va to a bo is only an issue on cayman, on SI and further we
> will need a va for each bo anyway.
>
> The problem with not adding a va is that I just need something to actually
> count the number of references in.
>
> So there isn't so much of an alternative to adding the va on opening the
> handle.
>
> Cheers,
> Christian.

Ok fair enough

Cheers,
Jerome

>
>>
>> Cheers,
>> Jerome
>>
> Signed-off-by: Christian K?nig 
> ---
>drivers/gpu/drm/radeon/radeon.h  |   30 ---
>drivers/gpu/drm/radeon/radeon_gart.c |  147
> ++
>drivers/gpu/drm/radeon/radeon_gem.c  |   47 +--
>3 files changed, 153 insertions(+), 71 deletions(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon.h
> b/drivers/gpu/drm/radeon/radeon.h
> index 8cca1d2..4d67f0f 100644
> --- a/drivers/gpu/drm/radeon/radeon.h
> +++ b/drivers/gpu/drm/radeon/radeon.h
> @@ -292,17 +292,20 @@ struct radeon_mman {
>
>/* bo virtual address in a specific vm */
>struct radeon_bo_va {
> -   /* bo list is protected by bo being reserved */
> +   /* protected by bo being reserved */
>   struct list_headbo_list;
> -   /* vm list is protected by vm mutex */
> -   struct list_headvm_list;
> -   /* constant after initialization */
> -   struct radeon_vm*vm;
> -   struct radeon_bo*bo;
>   uint64_tsoffset;
>   uint64_teoffset;
>   uint32_tflags;
>   boolvalid;
> +   unsignedref_count;

 unsigned refcount is a recipe for failure, if somehow you over unref
 then you va will stay alive forever and this overunref will probably
 go unnoticed.

> +
> +   /* protected by vm mutex */
> +   struct list_headvm_list;
> +
> +   /* constant after initialization */
> +   struct radeon_vm*vm;
> +   struct radeon_bo*bo;
>};
>
>struct radeon_bo {
> @@ -1848,14 +1851,15 @@ void radeon_vm_bo_invalidate(struct
> radeon_device
> *rdev,
>struct radeon_bo *bo);
>struct radeon_bo_va *radeon_vm_bo_find(struct radeon_vm *vm,
>  struct radeon_bo *bo);
> -int radeon_vm_bo_add(struct radeon_device *rdev,
> -struct radeon_vm *vm,
> -struct radeon_bo *bo,
> -uint64_t offset,
> -uint32_t flags);
> +struct radeon_bo_va *radeon_vm_bo_add(struct radeon_device *rdev,
> +

[RFC 1/9] drm: add atomic fxns

On Wed, Sep 12, 2012 at 1:03 PM, Ville Syrj?l?
 wrote:
> On Wed, Sep 12, 2012 at 12:35:01PM -0500, Rob Clark wrote:
>> On Wed, Sep 12, 2012 at 11:57 AM, Jesse Barnes  
>> wrote:
>> > On Sun,  9 Sep 2012 22:03:14 -0500
>> > Rob Clark  wrote:
>> >
>> >> From: Rob Clark 
>> >>
>> >> The 'atomic' mechanism allows for multiple properties to be updated,
>> >> checked, and commited atomically.  This will be the basis of atomic-
>> >> modeset and nuclear-pageflip.
>> >>
>> >> The basic flow is:
>> >>
>> >>state = dev->atomic_begin();
>> >>for (... one or more ...)
>> >>   obj->set_property(obj, state, prop, value);
>> >>if (dev->atomic_check(state))
>> >>   dev->atomic_commit(state, event);
>> >>dev->atomic_end(state);
>> >
>> > I think the above is more suited to drm_crtc_helper code.  I think the
>> > top level callback should contain the arrays and be a single "multi
>> > flip" hook (or maybe a check then set double callback).  For some
>> > drivers that'll end up being a lot simpler, rather than sprinkling
>> > atomic handling code in all the set_property callbacks.
>>
>> well, there are a few other places in drm_crtc.c where I want to use
>> the new API, to avoid drivers having to support both atomic API and
>> old set_plane/page_flip stuff.. the transactional API makes that a bit
>> easier, I think.. or at least I don't have to construct an array on
>> the stack.
>
> Usually you would need to build up the full state anyway before you can
> tell if it's good or bad. I don't see what some big array would buy here.

yup.. this was why I added drm_{crtc,plane,etc}_check_state(), to
bring back the common state checking that used to be done in the ioctl
fxns

>> > Having a transactional API just seems a little messier with both the
>> > atomic state and per-property state to track and rollback in the case
>> > of failure.
>>
>> For the rollback, I think I'm just going to move the array of property
>> values into drm_{crtc,plane,etc}_state.  That way, userspace doesn't
>> see updated property values if they are not committed.  It makes the
>> property value rollback automatic.
>
> This was my original idea as well. Separate the current and future
> states cleanly. At the moment it's all mixed up inside the objects
> somewhere. I sort of abandoned the idea so that I could avoid touching
> too much driver code while prototyping the atomic modesetting, but
> that's certainly the way I would design the system.

Yeah, I don't see any other way to do it sanely other than separating
out the current/future state.  Fortunately for planes, there are only
a few drivers that support planes so it isn't too bad.  For full
modesetting, it gets to be a lot of search and replace.  But it makes
it so much cleaner so I think it is worth doing.

We could probably also simplify a bunch of the crtc helper code that
handles reverting to previous state.

BR,
-R

> --
> Ville Syrj?l?
> Intel OTC
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 25871] nearest neighbour samples wrong texel (precision/rounding problem)

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

--- Comment #10 from Pierre Ossman  2012-09-12 
13:03:19 UTC ---
(In reply to comment #7)
> 
> What is the expected behavior?

It's so long ago I don't remember the exact details. You can easily figure it
out though. The test program creates a 4x4 checker board texture and then uses
a single point on it to draw the triangles. The range [0.25,0.5[ should all be
the same color. The bug was that as you approached 0.5, it started sampling the
next pixel prematurely.

So change the fragment program to use coordinate 0.4 or something like that.
That colour should be the same as 0.4999... . Looking at the code, white seems
to be the correct colour.

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

[RFC 0/9] nuclear pageflip

2012-09-12 Thread Clark, Rob

On Wed, Sep 12, 2012 at 12:27 PM, Ville Syrj?l?
 wrote:
> On Wed, Sep 12, 2012 at 10:48:16AM -0500, Rob Clark wrote:
>> On Wed, Sep 12, 2012 at 10:32 AM, Ville Syrj?l?
>>  wrote:
>> > On Wed, Sep 12, 2012 at 10:23:48AM -0500, Rob Clark wrote:
>> >> On Wed, Sep 12, 2012 at 10:12 AM, Ville Syrj?l?
>> >>  wrote:
>> >> > On Wed, Sep 12, 2012 at 09:42:27AM -0500, Rob Clark wrote:
>> >> >> On Wed, Sep 12, 2012 at 9:34 AM, Ville Syrj?l?
>> >> >>  wrote:
>> >> >> > On Wed, Sep 12, 2012 at 09:28:43AM -0500, Rob Clark wrote:
>> >> >> >> On Wed, Sep 12, 2012 at 9:23 AM, Ville Syrj?l?
>> >> >> >>  wrote:
>> >> >> >> > On Wed, Sep 12, 2012 at 07:30:18AM -0500, Rob Clark wrote:
>> >> >> >> >> On Wed, Sep 12, 2012 at 3:59 AM, Ville Syrj?l?
>> >> >> >> >>  wrote:
>> >> >> >> >> > On Tue, Sep 11, 2012 at 05:07:49PM -0500, Rob Clark wrote:
>> >> >> >> >> >> On Tue, Sep 11, 2012 at 4:15 PM, Ben Widawsky > >> >> >> >> >> bwidawsk.net> wrote:
>> >> >> >> >> >> > On Sun, 9 Sep 2012 22:19:59 -0500
>> >> >> >> >> >> > Rob Clark  wrote:
>> >> >> >> >> >> >
>> >> >> >> >> >> >> On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark > >> >> >> >> >> >> linaro.org> wrote:
>> >> >> >> >> >> >> > From: Rob Clark 
>> >> >> >> >> >> >> >
>> >> >> >> >> >> >> > This is following a bit the approach that Ville is 
>> >> >> >> >> >> >> > taking for atomic-
>> >> >> >> >> >> >> > modeset, in that it is switching over to using 
>> >> >> >> >> >> >> > properties for everything.
>> >> >> >> >> >> >> > The advantage of this approach is that it makes it 
>> >> >> >> >> >> >> > easier to add new
>> >> >> >> >> >> >> > attributes to set as part of a page-flip (and even opens 
>> >> >> >> >> >> >> > the option to
>> >> >> >> >> >> >> > add new object types).
>> >> >> >> >> >> >>
>> >> >> >> >> >> >> oh, and for those wondering what the hell this is all 
>> >> >> >> >> >> >> about,
>> >> >> >> >> >> >> nuclear-pageflip is a pageflip that atomically updates the 
>> >> >> >> >> >> >> CRTC layer
>> >> >> >> >> >> >> and zero or more attached plane layers, optionally 
>> >> >> >> >> >> >> changing various
>> >> >> >> >> >> >> properties such as z-order (or even blending modes, etc) 
>> >> >> >> >> >> >> atomically.
>> >> >> >> >> >> >> It includes the option for a test step so userspace 
>> >> >> >> >> >> >> compositor can
>> >> >> >> >> >> >> test a proposed configuration (if any properties not 
>> >> >> >> >> >> >> marked as
>> >> >> >> >> >> >> 'dynamic' are updated).  This intended to allow, for 
>> >> >> >> >> >> >> example, weston
>> >> >> >> >> >> >> compositor to synchronize updates to plane (sprite) layers 
>> >> >> >> >> >> >> with CRTC
>> >> >> >> >> >> >> layer.
>> >> >> >> >> >> >>
>> >> >> >> >> >> >
>> >> >> >> >> >> > Can we please name this something different? I complained 
>> >> >> >> >> >> > about this in
>> >> >> >> >> >> > IRC, but I don't know if you hang around in #intel-gfx.
>> >> >> >> >> >> >
>> >> >> >> >> >> > Some suggestions:
>> >> >> >> >> >> > multiplane pageflip
>> >> >> >> >> >> > muliplane atomic pageflip
>> >> >> >> >> >> > atomic multiplane pageflip
>> >> >> >> >> >> > atomic multiflip
>> >> >> >> >> >> > pageflip of atomic and multiplane nature
>> >> >> >> >> >> >
>> >> >> >> >> >> > Nuclear is not at all descriptive and requires as your 
>> >> >> >> >> >> > response shows
>> >> >> >> >> >> > :-)
>> >> >> >> >> >> >
>> >> >> >> >> >>
>> >> >> >> >> >> fair enough.. I was originally calling it atomic-pageflip 
>> >> >> >> >> >> until
>> >> >> >> >> >> someone (I don't remember who) started calling it 
>> >> >> >> >> >> nuclear-pageflip to
>> >> >> >> >> >> differentiate from atomic-modeset.  But IMO we could just 
>> >> >> >> >> >> call the two
>> >> >> >> >> >> ioclts atomic-modeset and atomic-pageflip.  (Or even modeset2 
>> >> >> >> >> >> and
>> >> >> >> >> >> pageflip2, but that seems much more boring)
>> >> >> >> >> >
>> >> >> >> >> > My plan has been to use the same ioctl for both uses. They'll 
>> >> >> >> >> > need
>> >> >> >> >> > nearly identical handling anyway on the ioctl level. I have 
>> >> >> >> >> > something
>> >> >> >> >> > semi-working currently, but I need to clean it up a bit before 
>> >> >> >> >> > I can
>> >> >> >> >> > show it to anyone.
>> >> >> >> >>
>> >> >> >> >> I do think the atomic-pageflip ioctl really should take the 
>> >> >> >> >> crtc-id..
>> >> >> >> >> so probably should be two ioctls, but nearly identical
>> >> >> >> >
>> >> >> >> > But then you can't support atomic pageflips across multiple crtcs 
>> >> >> >> > even
>> >> >> >> > if the hardware would allow it. I would hate to add such 
>> >> >> >> > limitation to
>> >> >> >> > the API. I can immediately think of a use case; combining several
>> >> >> >> > smaller displays to form a single larger display.
>> >> >> >> >
>> >> >> >> > With a unified API you could just add some kind of flag that 
>> >> >> >> > tells the
>> >> >> >> > kernel that user space really wants an atomic update, and if the
>> >> >> >> > driver/hardware can't do it,

[RFC 1/9] drm: add atomic fxns

On Wed, Sep 12, 2012 at 11:57 AM, Jesse Barnes  
wrote:
> On Sun,  9 Sep 2012 22:03:14 -0500
> Rob Clark  wrote:
>
>> From: Rob Clark 
>>
>> The 'atomic' mechanism allows for multiple properties to be updated,
>> checked, and commited atomically.  This will be the basis of atomic-
>> modeset and nuclear-pageflip.
>>
>> The basic flow is:
>>
>>state = dev->atomic_begin();
>>for (... one or more ...)
>>   obj->set_property(obj, state, prop, value);
>>if (dev->atomic_check(state))
>>   dev->atomic_commit(state, event);
>>dev->atomic_end(state);
>
> I think the above is more suited to drm_crtc_helper code.  I think the
> top level callback should contain the arrays and be a single "multi
> flip" hook (or maybe a check then set double callback).  For some
> drivers that'll end up being a lot simpler, rather than sprinkling
> atomic handling code in all the set_property callbacks.

well, there are a few other places in drm_crtc.c where I want to use
the new API, to avoid drivers having to support both atomic API and
old set_plane/page_flip stuff.. the transactional API makes that a bit
easier, I think.. or at least I don't have to construct an array on
the stack.

But I'm not entirely convinced that it is a problem.. with
drm_{crtc,plane,etc}_state, it is just building up a set of values in
a state struct, and that state struct gets atomically committed.

> Having a transactional API just seems a little messier with both the
> atomic state and per-property state to track and rollback in the case
> of failure.

For the rollback, I think I'm just going to move the array of property
values into drm_{crtc,plane,etc}_state.  That way, userspace doesn't
see updated property values if they are not committed.  It makes the
property value rollback automatic.

BR,
-R

> --
> Jesse Barnes, Intel Open Source Technology Center
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 25871] nearest neighbour samples wrong texel (precision/rounding problem)

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

--- Comment #9 from Andreas Boll  2012-09-12 
12:34:21 UTC ---
(In reply to comment #8)
> might be fixed with this commit:
> http://cgit.freedesktop.org/mesa/mesa/commit/?id=f44bda17f515c411071ca8744ebd96039d9c583b


I can't see any difference between mesa git master and mesa 8.0.4 .

What is the expected behavior?

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

[PATCH 6/6] staging: drm/imx: Add TODO

Signed-off-by: Sascha Hauer 
---
 drivers/staging/imx-drm/TODO |   22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 drivers/staging/imx-drm/TODO

diff --git a/drivers/staging/imx-drm/TODO b/drivers/staging/imx-drm/TODO
new file mode 100644
index 000..2075646
--- /dev/null
+++ b/drivers/staging/imx-drm/TODO
@@ -0,0 +1,22 @@
+TODO:
+- get DRM Maintainer review for this code
+- Factor out more code to common helper functions
+- decide where to put the base driver. It is not specific to a subsystem
+  and would be used by DRM/KMS and media/V4L2
+- convert irq driver to irq_domain_add_linear
+
+Missing features (not necessarily for moving out out staging):
+
+- Add KMS plane support for CRTC driver
+- Add LDB (LVDS Display Bridge) support
+- Add i.MX6 HDMI support
+- Add support for IC (Image converter)
+- Add support for CSI (CMOS Sensor interface)
+- Add support for VDIC (Video Deinterlacer)
+
+Many work-in-progress patches for the above features exist. Contact
+Sascha Hauer  if you are interested in working
+on a specific feature.
+
+Please send any patches to Greg Kroah-Hartman  and
+Sascha Hauer 
-- 
1.7.10.4

[PATCH 5/6] staging: drm/imx: Add devicetree binding documentation

From: Philipp Zabel 

Signed-off-by: Philipp Zabel 
Signed-off-by: Sascha Hauer 
---
 .../bindings/staging/imx-drm/fsl-imx-drm.txt   |   41 
 1 file changed, 41 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt

diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt 
b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
new file mode 100644
index 000..07654f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -0,0 +1,41 @@
+Freescale i.MX IPUv3
+
+
+Required properties:
+- compatible: Should be "fsl,-ipu"
+- reg: should be register base and length as documented in the
+  datasheet
+- interrupts: Should contain sync interrupt and error interrupt,
+  in this order.
+- #crtc-cells: 1, See below
+
+example:
+
+ipu: ipu at 1800 {
+   #crtc-cells = <1>;
+   compatible = "fsl,imx53-ipu";
+   reg = <0x1800 0x08000>;
+   interrupts = <11 10>;
+};
+
+Parallel display support
+
+
+Required properties:
+- compatible: Should be "fsl,imx-parallel-display"
+- crtc: the crtc this display is connected to, see below
+Optional properties:
+- interface_pix_fmt: How this display is connected to the
+  crtc. Currently supported types: "rgb24", "rgb565"
+- edid: verbatim EDID data block describing attached display.
+- ddc: phandle describing the i2c bus handling the display data
+  channel
+
+example:
+
+display at di0 {
+   compatible = "fsl,imx-parallel-display";
+   edid = [edid-data];
+   crtc = < 0>;
+   interface-pix-fmt = "rgb24";
+};
-- 
1.7.10.4

[PATCH 4/6] staging: drm/imx: Add i.MX IPUv3 crtc support

This adds a i.MX51/53/6 IPU (Image Processing Unit) KMS driver. The
driver has been tested on the i.MX51 babbage board, the i.MX53 LOCO
board and the i.MX6q sabrelite board in different clone mode and dual
head setups.

Signed-off-by: Sascha Hauer 
---
 drivers/staging/imx-drm/Kconfig  |6 +
 drivers/staging/imx-drm/Makefile |1 +
 drivers/staging/imx-drm/ipuv3-crtc.c |  579 ++
 3 files changed, 586 insertions(+)
 create mode 100644 drivers/staging/imx-drm/ipuv3-crtc.c

diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
index 4849bfa..14b4449 100644
--- a/drivers/staging/imx-drm/Kconfig
+++ b/drivers/staging/imx-drm/Kconfig
@@ -27,3 +27,9 @@ config DRM_IMX_IPUV3_CORE
  Choose this if you have a i.MX5/6 system and want
  to use the IPU. This option only enables IPU base
  support.
+
+config DRM_IMX_IPUV3
+   tristate "DRM Support for i.MX IPUv3"
+   depends on DRM_IMX
+   help
+ Choose this if you have a i.MX5 or i.MX6 processor.
diff --git a/drivers/staging/imx-drm/Makefile b/drivers/staging/imx-drm/Makefile
index e3a5b6f..83a9056 100644
--- a/drivers/staging/imx-drm/Makefile
+++ b/drivers/staging/imx-drm/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_DRM_IMX) += imxdrm.o
 obj-$(CONFIG_DRM_IMX_PARALLEL_DISPLAY) += parallel-display.o
 obj-$(CONFIG_DRM_IMX_FB_HELPER) += imx-fbdev.o
 obj-$(CONFIG_DRM_IMX_IPUV3_CORE) += ipu-v3/
+obj-$(CONFIG_DRM_IMX_IPUV3)+= ipuv3-crtc.o
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
b/drivers/staging/imx-drm/ipuv3-crtc.c
new file mode 100644
index 000..78d3eda
--- /dev/null
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -0,0 +1,579 @@
+/*
+ * i.MX IPUv3 Graphics driver
+ *
+ * Copyright (C) 2011 Sascha Hauer, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "ipu-v3/imx-ipu-v3.h"
+#include "imx-drm.h"
+
+#define DRIVER_DESC"i.MX IPUv3 Graphics"
+
+struct ipu_framebuffer {
+   struct drm_framebuffer  base;
+   void*virt;
+   dma_addr_t  phys;
+   size_t  len;
+};
+
+struct ipu_crtc {
+   struct drm_fb_helperfb_helper;
+   struct ipu_framebuffer  ifb;
+   int num_crtcs;
+   struct device   *dev;
+   struct drm_crtc base;
+   struct imx_drm_crtc *imx_crtc;
+   struct ipuv3_channel*ipu_ch;
+   struct ipu_dc   *dc;
+   struct ipu_dp   *dp;
+   struct dmfc_channel *dmfc;
+   struct ipu_di   *di;
+   int enabled;
+   struct ipu_priv *ipu_priv;
+   struct drm_pending_vblank_event *page_flip_event;
+   struct drm_framebuffer  *newfb;
+   int irq;
+   u32 interface_pix_fmt;
+   unsigned long   di_clkflags;
+};
+
+#define to_ipu_crtc(x) container_of(x, struct ipu_crtc, base)
+
+static int calc_vref(struct drm_display_mode *mode)
+{
+   unsigned long htotal, vtotal;
+
+   htotal = mode->htotal;
+   vtotal = mode->vtotal;
+
+   if (!htotal || !vtotal)
+   return 60;
+
+   return mode->clock * 1000 / vtotal / htotal;
+}
+
+static int calc_bandwidth(struct drm_display_mode *mode, unsigned int vref)
+{
+   return mode->hdisplay * mode->vdisplay * vref;
+}
+
+static void ipu_fb_enable(struct ipu_crtc *ipu_crtc)
+{
+   if (ipu_crtc->enabled)
+   return;
+
+   ipu_di_enable(ipu_crtc->di);
+   ipu_dmfc_enable_channel(ipu_crtc->dmfc);
+   ipu_idmac_enable_channel(ipu_crtc->ipu_ch);
+   ipu_dc_enable_channel(ipu_crtc->dc);
+   if (ipu_crtc->dp)
+   ipu_dp_enable_channel(ipu_crtc->dp);
+
+   ipu_crtc->enabled = 1;
+}
+
+static void ipu_fb_disable(struct ipu_crtc *ipu_crtc)
+{
+   if (!ipu_crtc->enabled)
+   return;
+
+   if (ipu_crtc->dp)
+   ipu_dp_disable_channel(ipu_crtc->dp);
+   ipu_dc_disable_channel(ipu_crtc->dc);
+   ipu_idmac_disable_channel(ipu_crtc->ipu_ch);
+   ipu_dmfc_disable_channel(ipu_crtc->dmfc);
+

[PATCH 3/6] staging: drm/imx: add i.MX IPUv3 base driver

The IPU is the Image Processing Unit found on i.MX51/53/6 SoCs. It
features several units for image processing, this patch adds support
for the units needed for Framebuffer support, namely:

- Display Controller (dc)
- Display Interface (di)
- Display Multi Fifo Controller (dmfc)
- Display Processor (dp)
- Image DMA Controller (idmac)

This patch is based on the Freescale driver, but follows a different
approach. The Freescale code implements logical idmac channels and
the handling of the subunits is hidden in common idmac code pathes
in big switch/case statements. This patch instead just provides code
and resource management for the different subunits. The user, in this
case the framebuffer driver, decides how the different units play
together.

The IPU has other units missing in this patch:

- CMOS Sensor Interface (csi)
- Video Deinterlacer (vdi)
- Sensor Multi FIFO Controler (smfc)
- Image Converter (ic)
- Image Rotator (irt)

Signed-off-by: Sascha Hauer 
---
 drivers/staging/imx-drm/Kconfig |8 +
 drivers/staging/imx-drm/Makefile|1 +
 drivers/staging/imx-drm/ipu-v3/Makefile |3 +
 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h |  318 
 drivers/staging/imx-drm/ipu-v3/ipu-common.c | 1143 +++
 drivers/staging/imx-drm/ipu-v3/ipu-dc.c |  379 +
 drivers/staging/imx-drm/ipu-v3/ipu-di.c |  700 
 drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c   |  408 ++
 drivers/staging/imx-drm/ipu-v3/ipu-dp.c |  336 
 drivers/staging/imx-drm/ipu-v3/ipu-prv.h|  206 +
 10 files changed, 3502 insertions(+)
 create mode 100644 drivers/staging/imx-drm/ipu-v3/Makefile
 create mode 100644 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-common.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-dc.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-di.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-dp.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-prv.h

diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
index 9e27012..4849bfa 100644
--- a/drivers/staging/imx-drm/Kconfig
+++ b/drivers/staging/imx-drm/Kconfig
@@ -19,3 +19,11 @@ config DRM_IMX_FB_HELPER
 config DRM_IMX_PARALLEL_DISPLAY
tristate "Support for parallel displays"
depends on DRM_IMX
+
+config DRM_IMX_IPUV3_CORE
+   tristate "IPUv3 core support"
+   depends on DRM_IMX
+   help
+ Choose this if you have a i.MX5/6 system and want
+ to use the IPU. This option only enables IPU base
+ support.
diff --git a/drivers/staging/imx-drm/Makefile b/drivers/staging/imx-drm/Makefile
index c8f582e..e3a5b6f 100644
--- a/drivers/staging/imx-drm/Makefile
+++ b/drivers/staging/imx-drm/Makefile
@@ -5,3 +5,4 @@ obj-$(CONFIG_DRM_IMX) += imxdrm.o

 obj-$(CONFIG_DRM_IMX_PARALLEL_DISPLAY) += parallel-display.o
 obj-$(CONFIG_DRM_IMX_FB_HELPER) += imx-fbdev.o
+obj-$(CONFIG_DRM_IMX_IPUV3_CORE) += ipu-v3/
diff --git a/drivers/staging/imx-drm/ipu-v3/Makefile 
b/drivers/staging/imx-drm/ipu-v3/Makefile
new file mode 100644
index 000..28ed72e
--- /dev/null
+++ b/drivers/staging/imx-drm/ipu-v3/Makefile
@@ -0,0 +1,3 @@
+obj-$(CONFIG_DRM_IMX_IPUV3_CORE) += imx-ipu-v3.o
+
+imx-ipu-v3-objs := ipu-common.o ipu-dc.o ipu-di.o ipu-dp.o ipu-dmfc.o
diff --git a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h 
b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
new file mode 100644
index 000..74158dd
--- /dev/null
+++ b/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
@@ -0,0 +1,318 @@
+/*
+ * Copyright 2005-2009 Freescale Semiconductor, Inc.
+ *
+ * The code contained herein is licensed under the GNU Lesser General
+ * Public License.  You may obtain a copy of the GNU Lesser General
+ * Public License Version 2.1 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/lgpl-license.html
+ * http://www.gnu.org/copyleft/lgpl.html
+ */
+
+#ifndef __DRM_IPU_H__
+#define __DRM_IPU_H__
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct ipu_soc;
+
+enum ipuv3_type {
+   IPUV3EX,
+   IPUV3M,
+   IPUV3H,
+};
+
+/*
+ * Bitfield of Display Interface signal polarities.
+ */
+struct ipu_di_signal_cfg {
+   unsigned datamask_en:1;
+   unsigned interlaced:1;
+   unsigned odd_field_first:1;
+   unsigned clksel_en:1;
+   unsigned clkidle_en:1;
+   unsigned data_pol:1;/* true = inverted */
+   unsigned clk_pol:1; /* true = rising edge */
+   unsigned enable_pol:1;
+   unsigned Hsync_pol:1;   /* true = active high */
+   unsigned Vsync_pol:1;
+
+   u16 width;
+   u16 height;
+   u32 pixel_fmt;
+   u16 h_start_width;
+   u16 h_sync_width;
+   u16 h_end_width;
+   u16 v_start_width;
+   u16 v_sync_width;
+   u16 v_end_width;
+   u32 v_to_h_sync;
+   unsigned long

[PATCH 2/6] staging: drm/imx: Add parallel display support

This adds support for parallel displays for i.MX. It consists
of a drm encoder/connector pair which eventually passes EDID
data from the devicetree to the drm core.

Signed-off-by: Sascha Hauer 
---
 drivers/staging/imx-drm/Kconfig|4 +
 drivers/staging/imx-drm/Makefile   |1 +
 drivers/staging/imx-drm/parallel-display.c |  262 
 3 files changed, 267 insertions(+)
 create mode 100644 drivers/staging/imx-drm/parallel-display.c

diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
index 2ef867b..9e27012 100644
--- a/drivers/staging/imx-drm/Kconfig
+++ b/drivers/staging/imx-drm/Kconfig
@@ -15,3 +15,7 @@ config DRM_IMX_FB_HELPER
  The DRM framework can provide a legacy /dev/fb0 framebuffer
  for your device. This is necessary to get a framebuffer console
  and also for appplications using the legacy framebuffer API
+
+config DRM_IMX_PARALLEL_DISPLAY
+   tristate "Support for parallel displays"
+   depends on DRM_IMX
diff --git a/drivers/staging/imx-drm/Makefile b/drivers/staging/imx-drm/Makefile
index ff825f7..c8f582e 100644
--- a/drivers/staging/imx-drm/Makefile
+++ b/drivers/staging/imx-drm/Makefile
@@ -3,4 +3,5 @@ imxdrm-objs := imx-drm-core.o imx-fb.o

 obj-$(CONFIG_DRM_IMX) += imxdrm.o

+obj-$(CONFIG_DRM_IMX_PARALLEL_DISPLAY) += parallel-display.o
 obj-$(CONFIG_DRM_IMX_FB_HELPER) += imx-fbdev.o
diff --git a/drivers/staging/imx-drm/parallel-display.c 
b/drivers/staging/imx-drm/parallel-display.c
new file mode 100644
index 000..e757d42
--- /dev/null
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -0,0 +1,262 @@
+/*
+ * i.MX drm driver - parallel display implementation
+ *
+ * Copyright (C) 2012 Sascha Hauer, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "imx-drm.h"
+
+#define con_to_imxpd(x) container_of(x, struct imx_parallel_display, connector)
+#define enc_to_imxpd(x) container_of(x, struct imx_parallel_display, encoder)
+
+struct imx_parallel_display {
+   struct drm_connector connector;
+   struct imx_drm_connector *imx_drm_connector;
+   struct drm_encoder encoder;
+   struct imx_drm_encoder *imx_drm_encoder;
+   struct device *dev;
+   void *edid;
+   int edid_len;
+   u32 interface_pix_fmt;
+   int mode_valid;
+   struct drm_display_mode mode;
+};
+
+static enum drm_connector_status imx_pd_connector_detect(
+   struct drm_connector *connector, bool force)
+{
+   return connector_status_connected;
+}
+
+static void imx_pd_connector_destroy(struct drm_connector *connector)
+{
+   /* do not free here */
+}
+
+static int imx_pd_connector_get_modes(struct drm_connector *connector)
+{
+   struct imx_parallel_display *imxpd = con_to_imxpd(connector);
+   int num_modes = 0;
+
+   if (imxpd->edid) {
+   drm_mode_connector_update_edid_property(connector, imxpd->edid);
+   num_modes = drm_add_edid_modes(connector, imxpd->edid);
+   connector->display_info.raw_edid = NULL;
+   }
+
+   if (imxpd->mode_valid) {
+   struct drm_display_mode *mode = drm_mode_create(connector->dev);
+   drm_mode_copy(mode, >mode);
+   mode->type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+   drm_mode_probed_add(connector, mode);
+   num_modes++;
+   }
+
+   return num_modes;
+}
+
+static int imx_pd_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
+{
+   return 0;
+}
+
+static struct drm_encoder *imx_pd_connector_best_encoder(
+   struct drm_connector *connector)
+{
+   struct imx_parallel_display *imxpd = con_to_imxpd(connector);
+
+   return >encoder;
+}
+
+static void imx_pd_encoder_dpms(struct drm_encoder *encoder, int mode)
+{
+}
+
+static bool imx_pd_encoder_mode_fixup(struct drm_encoder *encoder,
+  const struct drm_display_mode *mode,
+  struct drm_display_mode *adjusted_mode)
+{
+   return true;
+}
+
+static void imx_pd_encoder_prepare(struct drm_encoder *encoder)
+{
+   struct imx_parallel_display *imxpd =

[PATCH 1/6] staging: drm/imx: Add i.MX drm core support

This patch adds the i.MX glue stuff between i.MX and drm.

Signed-off-by: Sascha Hauer 
---
 drivers/staging/Kconfig|2 +
 drivers/staging/Makefile   |1 +
 drivers/staging/imx-drm/Kconfig|   17 +
 drivers/staging/imx-drm/Makefile   |6 +
 drivers/staging/imx-drm/imx-drm-core.c |  882 
 drivers/staging/imx-drm/imx-drm.h  |   58 +++
 drivers/staging/imx-drm/imx-fb.c   |   47 ++
 drivers/staging/imx-drm/imx-fbdev.c|   74 +++
 8 files changed, 1087 insertions(+)
 create mode 100644 drivers/staging/imx-drm/Kconfig
 create mode 100644 drivers/staging/imx-drm/Makefile
 create mode 100644 drivers/staging/imx-drm/imx-drm-core.c
 create mode 100644 drivers/staging/imx-drm/imx-drm.h
 create mode 100644 drivers/staging/imx-drm/imx-fb.c
 create mode 100644 drivers/staging/imx-drm/imx-fbdev.c

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index e3402d5..4a3432f 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -136,4 +136,6 @@ source "drivers/staging/csr/Kconfig"

 source "drivers/staging/omap-thermal/Kconfig"

+source "drivers/staging/imx-drm/Kconfig"
+
 endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 3be59d0..b7dc4b1 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -60,3 +60,4 @@ obj-$(CONFIG_USB_G_CCG)   += ccg/
 obj-$(CONFIG_WIMAX_GDM72XX)+= gdm72xx/
 obj-$(CONFIG_CSR_WIFI) += csr/
 obj-$(CONFIG_OMAP_BANDGAP) += omap-thermal/
+obj-$(CONFIG_DRM_IMX)  += imx-drm/
diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
new file mode 100644
index 000..2ef867b
--- /dev/null
+++ b/drivers/staging/imx-drm/Kconfig
@@ -0,0 +1,17 @@
+config DRM_IMX
+   tristate "DRM Support for Freescale i.MX"
+   select DRM_KMS_HELPER
+   select DRM_GEM_CMA_HELPER
+   select DRM_KMS_CMA_HELPER
+   depends on DRM && ARCH_MXC
+   help
+ enable i.MX graphics support
+
+config DRM_IMX_FB_HELPER
+   tristate "provide legacy framebuffer /dev/fb0"
+   select DRM_KMS_CMA_HELPER
+   depends on DRM_IMX
+   help
+ The DRM framework can provide a legacy /dev/fb0 framebuffer
+ for your device. This is necessary to get a framebuffer console
+ and also for appplications using the legacy framebuffer API
diff --git a/drivers/staging/imx-drm/Makefile b/drivers/staging/imx-drm/Makefile
new file mode 100644
index 000..ff825f7
--- /dev/null
+++ b/drivers/staging/imx-drm/Makefile
@@ -0,0 +1,6 @@
+
+imxdrm-objs := imx-drm-core.o imx-fb.o
+
+obj-$(CONFIG_DRM_IMX) += imxdrm.o
+
+obj-$(CONFIG_DRM_IMX_FB_HELPER) += imx-fbdev.o
diff --git a/drivers/staging/imx-drm/imx-drm-core.c 
b/drivers/staging/imx-drm/imx-drm-core.c
new file mode 100644
index 000..225e835
--- /dev/null
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -0,0 +1,882 @@
+/*
+ * Freescale i.MX drm driver
+ *
+ * Copyright (C) 2011 Sascha Hauer, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "imx-drm.h"
+
+#define MAX_CRTC   4
+
+struct crtc_cookie {
+   void *cookie;
+   int id;
+   struct list_head list;
+};
+
+struct imx_drm_device {
+   struct drm_device   *drm;
+   struct device   *dev;
+   struct list_headcrtc_list;
+   struct list_headencoder_list;
+   struct list_headconnector_list;
+   struct mutexmutex;
+   int references;
+   int pipes;
+   struct drm_fbdev_cma*fbhelper;
+};
+
+struct imx_drm_crtc {
+   struct drm_crtc *crtc;
+   struct list_headlist;
+   struct imx_drm_device   *imxdrm;
+   int pipe;
+   struct imx_drm_crtc_helper_funcsimx_drm_helper_funcs;
+   struct module   *owner;
+   struct crtc_cookie  cookie;
+};
+
+struct imx_drm_encoder {
+   struct drm_encoder  *encoder;
+   struct list_headlist;
+   struct module   *owner;
+

[PATCH] Add i.MX IPUv3 base/KMS driver to the staging tree

Hi Greg et all,

The following adds the i.MX IPUv3 base and KMS driver to the staging
tree. It currently depends on two patches adding helper functions to
the DRM core. Dave Airlie already has signalled he is ok with these
helper functions. Apart from that, please let me know if there's anything
else blocking the IPU patches from going to staging. If not, I would
ping again once the helper patches show up in linux-next.

Thanks
 Sascha


The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217:

  Linux 3.6-rc5 (2012-09-08 16:43:45 -0700)

are available in the git repository at:

  git://git.pengutronix.de/git/imx/linux-2.6.git tags/staging-drm-imx

for you to fetch changes up to d344cf816ce270a74d5210d771646ad04c89a7cc:

  staging: drm/imx: Add TODO (2012-09-12 12:01:13 +0200)


This adds an ARM i.MX IPUv3 base and DRM driver to the staging
tree.


Philipp Zabel (1):
  staging: drm/imx: Add devicetree binding documentation

Sascha Hauer (5):
  staging: drm/imx: Add i.MX drm core support
  staging: drm/imx: Add parallel display support
  staging: drm/imx: add i.MX IPUv3 base driver
  staging: drm/imx: Add i.MX IPUv3 crtc support
  staging: drm/imx: Add TODO

 .../bindings/staging/imx-drm/fsl-imx-drm.txt   |   41 +
 drivers/staging/Kconfig|2 +
 drivers/staging/Makefile   |1 +
 drivers/staging/imx-drm/Kconfig|   35 +
 drivers/staging/imx-drm/Makefile   |9 +
 drivers/staging/imx-drm/TODO   |   22 +
 drivers/staging/imx-drm/imx-drm-core.c |  882 +++
 drivers/staging/imx-drm/imx-drm.h  |   58 +
 drivers/staging/imx-drm/imx-fb.c   |   47 +
 drivers/staging/imx-drm/imx-fbdev.c|   74 ++
 drivers/staging/imx-drm/ipu-v3/Makefile|3 +
 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h|  318 ++
 drivers/staging/imx-drm/ipu-v3/ipu-common.c| 1143 
 drivers/staging/imx-drm/ipu-v3/ipu-dc.c|  379 +++
 drivers/staging/imx-drm/ipu-v3/ipu-di.c|  700 
 drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c  |  408 +++
 drivers/staging/imx-drm/ipu-v3/ipu-dp.c|  336 ++
 drivers/staging/imx-drm/ipu-v3/ipu-prv.h   |  206 
 drivers/staging/imx-drm/ipuv3-crtc.c   |  579 ++
 drivers/staging/imx-drm/parallel-display.c |  262 +
 20 files changed, 5505 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
 create mode 100644 drivers/staging/imx-drm/Kconfig
 create mode 100644 drivers/staging/imx-drm/Makefile
 create mode 100644 drivers/staging/imx-drm/TODO
 create mode 100644 drivers/staging/imx-drm/imx-drm-core.c
 create mode 100644 drivers/staging/imx-drm/imx-drm.h
 create mode 100644 drivers/staging/imx-drm/imx-fb.c
 create mode 100644 drivers/staging/imx-drm/imx-fbdev.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/Makefile
 create mode 100644 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-common.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-dc.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-di.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-dp.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-prv.h
 create mode 100644 drivers/staging/imx-drm/ipuv3-crtc.c
 create mode 100644 drivers/staging/imx-drm/parallel-display.c

[RFC 1/9] drm: add atomic fxns

2012-09-12 Thread Jesse Barnes

On Wed, 12 Sep 2012 12:35:01 -0500
Rob Clark  wrote:

> On Wed, Sep 12, 2012 at 11:57 AM, Jesse Barnes  
> wrote:
> > On Sun,  9 Sep 2012 22:03:14 -0500
> > Rob Clark  wrote:
> >
> >> From: Rob Clark 
> >>
> >> The 'atomic' mechanism allows for multiple properties to be updated,
> >> checked, and commited atomically.  This will be the basis of atomic-
> >> modeset and nuclear-pageflip.
> >>
> >> The basic flow is:
> >>
> >>state = dev->atomic_begin();
> >>for (... one or more ...)
> >>   obj->set_property(obj, state, prop, value);
> >>if (dev->atomic_check(state))
> >>   dev->atomic_commit(state, event);
> >>dev->atomic_end(state);
> >
> > I think the above is more suited to drm_crtc_helper code.  I think the
> > top level callback should contain the arrays and be a single "multi
> > flip" hook (or maybe a check then set double callback).  For some
> > drivers that'll end up being a lot simpler, rather than sprinkling
> > atomic handling code in all the set_property callbacks.
> 
> well, there are a few other places in drm_crtc.c where I want to use
> the new API, to avoid drivers having to support both atomic API and
> old set_plane/page_flip stuff.. the transactional API makes that a bit
> easier, I think.. or at least I don't have to construct an array on
> the stack.
> 
> But I'm not entirely convinced that it is a problem.. with
> drm_{crtc,plane,etc}_state, it is just building up a set of values in
> a state struct, and that state struct gets atomically committed.

Yeah I know it can work this way, it just seemed like the begin, end,
and set_property callbacks might be unnecessary if the props were all
part of the state.  The driver call roll things back (or just not touch
hw) if the check or commit fails...

I guess ultimately, given the choice, I'd rather have the drivers
calling into helper functions where possible, rather than having the
core impose a specific set of semi-fine grained hooks.

> > Having a transactional API just seems a little messier with both the
> > atomic state and per-property state to track and rollback in the case
> > of failure.
> 
> For the rollback, I think I'm just going to move the array of property
> values into drm_{crtc,plane,etc}_state.  That way, userspace doesn't
> see updated property values if they are not committed.  It makes the
> property value rollback automatic.

Ok that seems reasonable.

-- 
Jesse Barnes, Intel Open Source Technology Center

[RFC 0/9] nuclear pageflip

On Tue, Sep 11, 2012 at 05:07:49PM -0500, Rob Clark wrote:
> On Tue, Sep 11, 2012 at 4:15 PM, Ben Widawsky  wrote:
> > On Sun, 9 Sep 2012 22:19:59 -0500
> > Rob Clark  wrote:
> >
> >> On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark  wrote:
> >> > From: Rob Clark 
> >> >
> >> > This is following a bit the approach that Ville is taking for atomic-
> >> > modeset, in that it is switching over to using properties for everything.
> >> > The advantage of this approach is that it makes it easier to add new
> >> > attributes to set as part of a page-flip (and even opens the option to
> >> > add new object types).
> >>
> >> oh, and for those wondering what the hell this is all about,
> >> nuclear-pageflip is a pageflip that atomically updates the CRTC layer
> >> and zero or more attached plane layers, optionally changing various
> >> properties such as z-order (or even blending modes, etc) atomically.
> >> It includes the option for a test step so userspace compositor can
> >> test a proposed configuration (if any properties not marked as
> >> 'dynamic' are updated).  This intended to allow, for example, weston
> >> compositor to synchronize updates to plane (sprite) layers with CRTC
> >> layer.
> >>
> >
> > Can we please name this something different? I complained about this in
> > IRC, but I don't know if you hang around in #intel-gfx.
> >
> > Some suggestions:
> > multiplane pageflip
> > muliplane atomic pageflip
> > atomic multiplane pageflip
> > atomic multiflip
> > pageflip of atomic and multiplane nature
> >
> > Nuclear is not at all descriptive and requires as your response shows
> > :-)
> >
> 
> fair enough.. I was originally calling it atomic-pageflip until
> someone (I don't remember who) started calling it nuclear-pageflip to
> differentiate from atomic-modeset.  But IMO we could just call the two
> ioclts atomic-modeset and atomic-pageflip.  (Or even modeset2 and
> pageflip2, but that seems much more boring)

My plan has been to use the same ioctl for both uses. They'll need
nearly identical handling anyway on the ioctl level. I have something
semi-working currently, but I need to clean it up a bit before I can
show it to anyone.

-- 
Ville Syrj?l?
Intel OTC

[Bug 51344] massive corruption on RV410

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

Christian K?nig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 AssignedTo|dri-devel at lists.freedesktop |deathsimple at vodafone.de
   |.org|
  Attachment #66942|0   |1
is obsolete||
  Attachment #66986|0   |1
is obsolete||

--- Comment #12 from Christian K?nig  2012-09-12 
11:49:46 UTC ---
Created attachment 67047
  --> https://bugs.freedesktop.org/attachment.cgi?id=67047
Possible fix

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

[Bug 33715] demo arbocclude regression since r600g: Implement asyncronous query results.

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

--- Comment #8 from Andreas Boll  2012-09-12 
11:34:03 UTC ---
Created attachment 67046
  --> https://bugs.freedesktop.org/attachment.cgi?id=67046
screenshot with llvmpipe, r600g

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

[Bug 33715] demo arbocclude regression since r600g: Implement asyncronous query results.

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

--- Comment #7 from Andreas Boll  2012-09-12 
11:33:24 UTC ---
Created attachment 67045
  --> https://bugs.freedesktop.org/attachment.cgi?id=67045
screenshot with softpipe

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

[Bug 33715] demo arbocclude regression since r600g: Implement asyncronous query results.

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

--- Comment #6 from Andreas Boll  2012-09-12 
11:30:34 UTC ---
(In reply to comment #5)
> Dave Airlie wrote:
> I don't think this is a bug, its just how the demo works, it paints red if the
> results aren't ready when first asked, which is perfectly within spec from 
> what
> I can see.

I can reproduce the same result:
with softpipe all squares have the same color
with llvmpipe and r600g the bottom square is red


Should we close this bug as NOTABUG?

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

[PATCH] gma500: Fix regression on Oaktrail devices

2012-09-12 Thread Alan Cox

From: Alan Cox 

The register map patches didn't set one value for the GMA600 which
means the Fujitsu Q550 dies on boot with the GMA500 driver enabled.

Add the map entry so we don't read from the device MMIO + 0 by mistake.

Signed-off-by: Alan Cox 
Cc: Horses 
---

 drivers/gpu/drm/gma500/oaktrail_device.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c 
b/drivers/gpu/drm/gma500/oaktrail_device.c
index 0f9b7db..cf49ba5 100644
--- a/drivers/gpu/drm/gma500/oaktrail_device.c
+++ b/drivers/gpu/drm/gma500/oaktrail_device.c
@@ -476,6 +476,7 @@ static const struct psb_offset oaktrail_regmap[2] = {
.pos = DSPAPOS,
.surf = DSPASURF,
.addr = MRST_DSPABASE,
+   .base = MRST_DSPABASE,
.status = PIPEASTAT,
.linoff = DSPALINOFF,
.tileoff = DSPATILEOFF,
@@ -499,6 +500,7 @@ static const struct psb_offset oaktrail_regmap[2] = {
.pos = DSPBPOS,
.surf = DSPBSURF,
.addr = DSPBBASE,
+   .base = DSPBBASE,
.status = PIPEBSTAT,
.linoff = DSPBLINOFF,
.tileoff = DSPBTILEOFF,

[RFC 0/9] nuclear pageflip

On Wed, Sep 12, 2012 at 10:32 AM, Ville Syrj?l?
 wrote:
> On Wed, Sep 12, 2012 at 10:23:48AM -0500, Rob Clark wrote:
>> On Wed, Sep 12, 2012 at 10:12 AM, Ville Syrj?l?
>>  wrote:
>> > On Wed, Sep 12, 2012 at 09:42:27AM -0500, Rob Clark wrote:
>> >> On Wed, Sep 12, 2012 at 9:34 AM, Ville Syrj?l?
>> >>  wrote:
>> >> > On Wed, Sep 12, 2012 at 09:28:43AM -0500, Rob Clark wrote:
>> >> >> On Wed, Sep 12, 2012 at 9:23 AM, Ville Syrj?l?
>> >> >>  wrote:
>> >> >> > On Wed, Sep 12, 2012 at 07:30:18AM -0500, Rob Clark wrote:
>> >> >> >> On Wed, Sep 12, 2012 at 3:59 AM, Ville Syrj?l?
>> >> >> >>  wrote:
>> >> >> >> > On Tue, Sep 11, 2012 at 05:07:49PM -0500, Rob Clark wrote:
>> >> >> >> >> On Tue, Sep 11, 2012 at 4:15 PM, Ben Widawsky > >> >> >> >> bwidawsk.net> wrote:
>> >> >> >> >> > On Sun, 9 Sep 2012 22:19:59 -0500
>> >> >> >> >> > Rob Clark  wrote:
>> >> >> >> >> >
>> >> >> >> >> >> On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark > >> >> >> >> >> linaro.org> wrote:
>> >> >> >> >> >> > From: Rob Clark 
>> >> >> >> >> >> >
>> >> >> >> >> >> > This is following a bit the approach that Ville is taking 
>> >> >> >> >> >> > for atomic-
>> >> >> >> >> >> > modeset, in that it is switching over to using properties 
>> >> >> >> >> >> > for everything.
>> >> >> >> >> >> > The advantage of this approach is that it makes it easier 
>> >> >> >> >> >> > to add new
>> >> >> >> >> >> > attributes to set as part of a page-flip (and even opens 
>> >> >> >> >> >> > the option to
>> >> >> >> >> >> > add new object types).
>> >> >> >> >> >>
>> >> >> >> >> >> oh, and for those wondering what the hell this is all about,
>> >> >> >> >> >> nuclear-pageflip is a pageflip that atomically updates the 
>> >> >> >> >> >> CRTC layer
>> >> >> >> >> >> and zero or more attached plane layers, optionally changing 
>> >> >> >> >> >> various
>> >> >> >> >> >> properties such as z-order (or even blending modes, etc) 
>> >> >> >> >> >> atomically.
>> >> >> >> >> >> It includes the option for a test step so userspace 
>> >> >> >> >> >> compositor can
>> >> >> >> >> >> test a proposed configuration (if any properties not marked as
>> >> >> >> >> >> 'dynamic' are updated).  This intended to allow, for example, 
>> >> >> >> >> >> weston
>> >> >> >> >> >> compositor to synchronize updates to plane (sprite) layers 
>> >> >> >> >> >> with CRTC
>> >> >> >> >> >> layer.
>> >> >> >> >> >>
>> >> >> >> >> >
>> >> >> >> >> > Can we please name this something different? I complained 
>> >> >> >> >> > about this in
>> >> >> >> >> > IRC, but I don't know if you hang around in #intel-gfx.
>> >> >> >> >> >
>> >> >> >> >> > Some suggestions:
>> >> >> >> >> > multiplane pageflip
>> >> >> >> >> > muliplane atomic pageflip
>> >> >> >> >> > atomic multiplane pageflip
>> >> >> >> >> > atomic multiflip
>> >> >> >> >> > pageflip of atomic and multiplane nature
>> >> >> >> >> >
>> >> >> >> >> > Nuclear is not at all descriptive and requires as your 
>> >> >> >> >> > response shows
>> >> >> >> >> > :-)
>> >> >> >> >> >
>> >> >> >> >>
>> >> >> >> >> fair enough.. I was originally calling it atomic-pageflip until
>> >> >> >> >> someone (I don't remember who) started calling it 
>> >> >> >> >> nuclear-pageflip to
>> >> >> >> >> differentiate from atomic-modeset.  But IMO we could just call 
>> >> >> >> >> the two
>> >> >> >> >> ioclts atomic-modeset and atomic-pageflip.  (Or even modeset2 and
>> >> >> >> >> pageflip2, but that seems much more boring)
>> >> >> >> >
>> >> >> >> > My plan has been to use the same ioctl for both uses. They'll need
>> >> >> >> > nearly identical handling anyway on the ioctl level. I have 
>> >> >> >> > something
>> >> >> >> > semi-working currently, but I need to clean it up a bit before I 
>> >> >> >> > can
>> >> >> >> > show it to anyone.
>> >> >> >>
>> >> >> >> I do think the atomic-pageflip ioctl really should take the 
>> >> >> >> crtc-id..
>> >> >> >> so probably should be two ioctls, but nearly identical
>> >> >> >
>> >> >> > But then you can't support atomic pageflips across multiple crtcs 
>> >> >> > even
>> >> >> > if the hardware would allow it. I would hate to add such limitation 
>> >> >> > to
>> >> >> > the API. I can immediately think of a use case; combining several
>> >> >> > smaller displays to form a single larger display.
>> >> >> >
>> >> >> > With a unified API you could just add some kind of flag that tells 
>> >> >> > the
>> >> >> > kernel that user space really wants an atomic update, and if the
>> >> >> > driver/hardware can't do it, it can return an error.
>> >> >>
>> >> >> well, that is really only a problem for X11..  and atomic flip across
>> >> >> multiple crtc's is a potential mess from performance standpoint unless
>> >> >> your displays are vsync'd lock.
>> >> >
>> >> > It won't be truly atomic unless they are vsync locked. But anyways more
>> >> > buffers can be used to solve the performance problem. But that's a
>> >> > separate issue and in that case it doesn't really matter whether you
>> >> > issue separate ioctls for

[RFC 0/9] nuclear pageflip

On Wed, Sep 12, 2012 at 10:12 AM, Ville Syrj?l?
 wrote:
> On Wed, Sep 12, 2012 at 09:42:27AM -0500, Rob Clark wrote:
>> On Wed, Sep 12, 2012 at 9:34 AM, Ville Syrj?l?
>>  wrote:
>> > On Wed, Sep 12, 2012 at 09:28:43AM -0500, Rob Clark wrote:
>> >> On Wed, Sep 12, 2012 at 9:23 AM, Ville Syrj?l?
>> >>  wrote:
>> >> > On Wed, Sep 12, 2012 at 07:30:18AM -0500, Rob Clark wrote:
>> >> >> On Wed, Sep 12, 2012 at 3:59 AM, Ville Syrj?l?
>> >> >>  wrote:
>> >> >> > On Tue, Sep 11, 2012 at 05:07:49PM -0500, Rob Clark wrote:
>> >> >> >> On Tue, Sep 11, 2012 at 4:15 PM, Ben Widawsky  
>> >> >> >> wrote:
>> >> >> >> > On Sun, 9 Sep 2012 22:19:59 -0500
>> >> >> >> > Rob Clark  wrote:
>> >> >> >> >
>> >> >> >> >> On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark > >> >> >> >> linaro.org> wrote:
>> >> >> >> >> > From: Rob Clark 
>> >> >> >> >> >
>> >> >> >> >> > This is following a bit the approach that Ville is taking for 
>> >> >> >> >> > atomic-
>> >> >> >> >> > modeset, in that it is switching over to using properties for 
>> >> >> >> >> > everything.
>> >> >> >> >> > The advantage of this approach is that it makes it easier to 
>> >> >> >> >> > add new
>> >> >> >> >> > attributes to set as part of a page-flip (and even opens the 
>> >> >> >> >> > option to
>> >> >> >> >> > add new object types).
>> >> >> >> >>
>> >> >> >> >> oh, and for those wondering what the hell this is all about,
>> >> >> >> >> nuclear-pageflip is a pageflip that atomically updates the CRTC 
>> >> >> >> >> layer
>> >> >> >> >> and zero or more attached plane layers, optionally changing 
>> >> >> >> >> various
>> >> >> >> >> properties such as z-order (or even blending modes, etc) 
>> >> >> >> >> atomically.
>> >> >> >> >> It includes the option for a test step so userspace compositor 
>> >> >> >> >> can
>> >> >> >> >> test a proposed configuration (if any properties not marked as
>> >> >> >> >> 'dynamic' are updated).  This intended to allow, for example, 
>> >> >> >> >> weston
>> >> >> >> >> compositor to synchronize updates to plane (sprite) layers with 
>> >> >> >> >> CRTC
>> >> >> >> >> layer.
>> >> >> >> >>
>> >> >> >> >
>> >> >> >> > Can we please name this something different? I complained about 
>> >> >> >> > this in
>> >> >> >> > IRC, but I don't know if you hang around in #intel-gfx.
>> >> >> >> >
>> >> >> >> > Some suggestions:
>> >> >> >> > multiplane pageflip
>> >> >> >> > muliplane atomic pageflip
>> >> >> >> > atomic multiplane pageflip
>> >> >> >> > atomic multiflip
>> >> >> >> > pageflip of atomic and multiplane nature
>> >> >> >> >
>> >> >> >> > Nuclear is not at all descriptive and requires as your response 
>> >> >> >> > shows
>> >> >> >> > :-)
>> >> >> >> >
>> >> >> >>
>> >> >> >> fair enough.. I was originally calling it atomic-pageflip until
>> >> >> >> someone (I don't remember who) started calling it nuclear-pageflip 
>> >> >> >> to
>> >> >> >> differentiate from atomic-modeset.  But IMO we could just call the 
>> >> >> >> two
>> >> >> >> ioclts atomic-modeset and atomic-pageflip.  (Or even modeset2 and
>> >> >> >> pageflip2, but that seems much more boring)
>> >> >> >
>> >> >> > My plan has been to use the same ioctl for both uses. They'll need
>> >> >> > nearly identical handling anyway on the ioctl level. I have something
>> >> >> > semi-working currently, but I need to clean it up a bit before I can
>> >> >> > show it to anyone.
>> >> >>
>> >> >> I do think the atomic-pageflip ioctl really should take the crtc-id..
>> >> >> so probably should be two ioctls, but nearly identical
>> >> >
>> >> > But then you can't support atomic pageflips across multiple crtcs even
>> >> > if the hardware would allow it. I would hate to add such limitation to
>> >> > the API. I can immediately think of a use case; combining several
>> >> > smaller displays to form a single larger display.
>> >> >
>> >> > With a unified API you could just add some kind of flag that tells the
>> >> > kernel that user space really wants an atomic update, and if the
>> >> > driver/hardware can't do it, it can return an error.
>> >>
>> >> well, that is really only a problem for X11..  and atomic flip across
>> >> multiple crtc's is a potential mess from performance standpoint unless
>> >> your displays are vsync'd lock.
>> >
>> > It won't be truly atomic unless they are vsync locked. But anyways more
>> > buffers can be used to solve the performance problem. But that's a
>> > separate issue and in that case it doesn't really matter whether you
>> > issue separate ioctls for each crtc.
>>
>> that was basically my thinking.. separate ioctls for each crtc.  The
>> way my branch works currently, you can do this.  A page-flip on crtc
>> #2 won't care that there is still a flip pending on crtc #1.
>>
>> I guess that doesn't strictly guarantee that the two pageflips happen
>> at the exact same time, but unless you have some way to vsync lock the
>> two displays, I don't think that is possible anyways.
>
> Sure you need hardware to keep the pipes in sync.
>
>> So I'm not

[RFC 1/9] drm: add atomic fxns

2012-09-12 Thread Jesse Barnes

On Sun,  9 Sep 2012 22:03:14 -0500
Rob Clark  wrote:

> From: Rob Clark 
> 
> The 'atomic' mechanism allows for multiple properties to be updated,
> checked, and commited atomically.  This will be the basis of atomic-
> modeset and nuclear-pageflip.
> 
> The basic flow is:
> 
>state = dev->atomic_begin();
>for (... one or more ...)
>   obj->set_property(obj, state, prop, value);
>if (dev->atomic_check(state))
>   dev->atomic_commit(state, event);
>dev->atomic_end(state);

I think the above is more suited to drm_crtc_helper code.  I think the
top level callback should contain the arrays and be a single "multi
flip" hook (or maybe a check then set double callback).  For some
drivers that'll end up being a lot simpler, rather than sprinkling
atomic handling code in all the set_property callbacks.

Having a transactional API just seems a little messier with both the
atomic state and per-property state to track and rollback in the case
of failure.

-- 
Jesse Barnes, Intel Open Source Technology Center

[Bug 51344] massive corruption on RV410

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

--- Comment #11 from Christian K?nig  2012-09-12 
09:55:57 UTC ---
(In reply to comment #10)
> Output from /sys/kernel/debug/dri/0/radeon_fence_info
> 
> --- ring 0 ---
> Last signaled fence 0xdeadbeef
> Last emitted  0x0670
> 
> --- ring 0 ---
> Last signaled fence 0xdeadbeef
> Last emitted  0x0c44

WTF? Well that's a very interesting information you've got us here, thanks
allot.

"deadbeef" is a pattern we usually use for ring and IB tests, and I have no
idea how that ended up as last signaled fence value.

Could you try Jeromes debugging patch
(http://people.freedesktop.org/~glisse/0001-debug-fence-emission-reception.patch)
and attach the resulting output.

Thx,
Christian.

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

[PATCH 8/8] drm/radeon: rework the VM code a bit more

2012-09-12 Thread Jerome Glisse

On Wed, Sep 12, 2012 at 8:08 AM, Christian K?nig
 wrote:
> On 11.09.2012 18:11, Jerome Glisse wrote:
>>
>> On Tue, Sep 11, 2012 at 10:10 AM, Christian K?nig
>>  wrote:
>>>
>>> Roughly based on how nouveau is handling it. Instead of
>>> adding the bo_va when the address is set add the bo_va
>>> when the handle is opened, but set the address to zero
>>> until userspace tells us where to place it.
>>>
>>> This fixes another bunch of problems with glamor.
>>
>> What exactly are the fix ? I don't see why this change is needed. It
>> make things more complicated in my view.
>
> Applications can open GEM Handles multiple times, so what happens is that
> (for example) the DDX creates an BO to back a pixmap, hands that over to
> GLAMOR and than closes the handle again (a bit later and also not all the
> times).
>
> In the end the kernel complains that bo x isn't in vm y, what makes sense
> cause the DDX has removed the mapping by closing the handle. What we don't
> have in this picture is that the handle was opened two times, once for
> creation and once for handing it over to GLAMOR.
>
> I see three possible solutions to that problem:
> 1. Remember how many times a handle was opened in a vm context, that is what
> this patch does.
>
> 2. Instead of removing the mapping on closing the handle we change usespace
> to remove the mapping separately.
>
> 3. Change GEM to only call the open/close callbacks when the handle is
> opened and closed for the first/last time in a process context, that would
> also eliminate the refcounting nouveau is currently doing.
>
> Feel free to choose one, I just have implemented number 1 because that was
> the simplest way to go (for me).
>
> Cheers,
> Christian.

I am all ok for the refcounting part but i don't think the always add
a va to bo is a good idea. It just add more code for no good reason.

Cheers,
Jerome

>
>>
>>> Signed-off-by: Christian K?nig 
>>> ---
>>>   drivers/gpu/drm/radeon/radeon.h  |   30 ---
>>>   drivers/gpu/drm/radeon/radeon_gart.c |  147
>>> ++
>>>   drivers/gpu/drm/radeon/radeon_gem.c  |   47 +--
>>>   3 files changed, 153 insertions(+), 71 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/radeon/radeon.h
>>> b/drivers/gpu/drm/radeon/radeon.h
>>> index 8cca1d2..4d67f0f 100644
>>> --- a/drivers/gpu/drm/radeon/radeon.h
>>> +++ b/drivers/gpu/drm/radeon/radeon.h
>>> @@ -292,17 +292,20 @@ struct radeon_mman {
>>>
>>>   /* bo virtual address in a specific vm */
>>>   struct radeon_bo_va {
>>> -   /* bo list is protected by bo being reserved */
>>> +   /* protected by bo being reserved */
>>>  struct list_headbo_list;
>>> -   /* vm list is protected by vm mutex */
>>> -   struct list_headvm_list;
>>> -   /* constant after initialization */
>>> -   struct radeon_vm*vm;
>>> -   struct radeon_bo*bo;
>>>  uint64_tsoffset;
>>>  uint64_teoffset;
>>>  uint32_tflags;
>>>  boolvalid;
>>> +   unsignedref_count;
>>
>> unsigned refcount is a recipe for failure, if somehow you over unref
>> then you va will stay alive forever and this overunref will probably
>> go unnoticed.
>>
>>> +
>>> +   /* protected by vm mutex */
>>> +   struct list_headvm_list;
>>> +
>>> +   /* constant after initialization */
>>> +   struct radeon_vm*vm;
>>> +   struct radeon_bo*bo;
>>>   };
>>>
>>>   struct radeon_bo {
>>> @@ -1848,14 +1851,15 @@ void radeon_vm_bo_invalidate(struct radeon_device
>>> *rdev,
>>>   struct radeon_bo *bo);
>>>   struct radeon_bo_va *radeon_vm_bo_find(struct radeon_vm *vm,
>>> struct radeon_bo *bo);
>>> -int radeon_vm_bo_add(struct radeon_device *rdev,
>>> -struct radeon_vm *vm,
>>> -struct radeon_bo *bo,
>>> -uint64_t offset,
>>> -uint32_t flags);
>>> +struct radeon_bo_va *radeon_vm_bo_add(struct radeon_device *rdev,
>>> + struct radeon_vm *vm,
>>> + struct radeon_bo *bo);
>>> +int radeon_vm_bo_set_addr(struct radeon_device *rdev,
>>> + struct radeon_bo_va *bo_va,
>>> + uint64_t offset,
>>> + uint32_t flags);
>>>   int radeon_vm_bo_rmv(struct radeon_device *rdev,
>>> -struct radeon_vm *vm,
>>> -struct radeon_bo *bo);
>>> +struct radeon_bo_va *bo_va);
>>>
>>>   /* audio */
>>>   void r600_audio_update_hdmi(struct work_struct *work);
>>> diff --git a/drivers/gpu/drm/radeon/radeon_gart.c
>>> b/drivers/gpu/drm/radeon/radeon_gart.c
>>> index 2c59491..2f28ff3 100644

[PATCH 1/6] staging: drm/imx: Add i.MX drm core support

2012-09-12 Thread Greg Kroah-Hartman

On Wed, Sep 12, 2012 at 12:31:09PM +0200, Sascha Hauer wrote:
> This patch adds the i.MX glue stuff between i.MX and drm.
> 
> Signed-off-by: Sascha Hauer 
> ---
>  drivers/staging/Kconfig|2 +
>  drivers/staging/Makefile   |1 +

The patch fails at this point when applying it.

What tree did you make it against?  Please do so against linux-next or
hopefully, the staging-next branch, and resubmit these.

Also, will this cause build errors if I don't have the needed patchs
that are in the DRM tree in my tree?

thanks,

greg k-h

[RFC 0/9] nuclear pageflip

On Wed, Sep 12, 2012 at 9:34 AM, Ville Syrj?l?
 wrote:
> On Wed, Sep 12, 2012 at 09:28:43AM -0500, Rob Clark wrote:
>> On Wed, Sep 12, 2012 at 9:23 AM, Ville Syrj?l?
>>  wrote:
>> > On Wed, Sep 12, 2012 at 07:30:18AM -0500, Rob Clark wrote:
>> >> On Wed, Sep 12, 2012 at 3:59 AM, Ville Syrj?l?
>> >>  wrote:
>> >> > On Tue, Sep 11, 2012 at 05:07:49PM -0500, Rob Clark wrote:
>> >> >> On Tue, Sep 11, 2012 at 4:15 PM, Ben Widawsky  
>> >> >> wrote:
>> >> >> > On Sun, 9 Sep 2012 22:19:59 -0500
>> >> >> > Rob Clark  wrote:
>> >> >> >
>> >> >> >> On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark > >> >> >> linaro.org> wrote:
>> >> >> >> > From: Rob Clark 
>> >> >> >> >
>> >> >> >> > This is following a bit the approach that Ville is taking for 
>> >> >> >> > atomic-
>> >> >> >> > modeset, in that it is switching over to using properties for 
>> >> >> >> > everything.
>> >> >> >> > The advantage of this approach is that it makes it easier to add 
>> >> >> >> > new
>> >> >> >> > attributes to set as part of a page-flip (and even opens the 
>> >> >> >> > option to
>> >> >> >> > add new object types).
>> >> >> >>
>> >> >> >> oh, and for those wondering what the hell this is all about,
>> >> >> >> nuclear-pageflip is a pageflip that atomically updates the CRTC 
>> >> >> >> layer
>> >> >> >> and zero or more attached plane layers, optionally changing various
>> >> >> >> properties such as z-order (or even blending modes, etc) atomically.
>> >> >> >> It includes the option for a test step so userspace compositor can
>> >> >> >> test a proposed configuration (if any properties not marked as
>> >> >> >> 'dynamic' are updated).  This intended to allow, for example, weston
>> >> >> >> compositor to synchronize updates to plane (sprite) layers with CRTC
>> >> >> >> layer.
>> >> >> >>
>> >> >> >
>> >> >> > Can we please name this something different? I complained about this 
>> >> >> > in
>> >> >> > IRC, but I don't know if you hang around in #intel-gfx.
>> >> >> >
>> >> >> > Some suggestions:
>> >> >> > multiplane pageflip
>> >> >> > muliplane atomic pageflip
>> >> >> > atomic multiplane pageflip
>> >> >> > atomic multiflip
>> >> >> > pageflip of atomic and multiplane nature
>> >> >> >
>> >> >> > Nuclear is not at all descriptive and requires as your response shows
>> >> >> > :-)
>> >> >> >
>> >> >>
>> >> >> fair enough.. I was originally calling it atomic-pageflip until
>> >> >> someone (I don't remember who) started calling it nuclear-pageflip to
>> >> >> differentiate from atomic-modeset.  But IMO we could just call the two
>> >> >> ioclts atomic-modeset and atomic-pageflip.  (Or even modeset2 and
>> >> >> pageflip2, but that seems much more boring)
>> >> >
>> >> > My plan has been to use the same ioctl for both uses. They'll need
>> >> > nearly identical handling anyway on the ioctl level. I have something
>> >> > semi-working currently, but I need to clean it up a bit before I can
>> >> > show it to anyone.
>> >>
>> >> I do think the atomic-pageflip ioctl really should take the crtc-id..
>> >> so probably should be two ioctls, but nearly identical
>> >
>> > But then you can't support atomic pageflips across multiple crtcs even
>> > if the hardware would allow it. I would hate to add such limitation to
>> > the API. I can immediately think of a use case; combining several
>> > smaller displays to form a single larger display.
>> >
>> > With a unified API you could just add some kind of flag that tells the
>> > kernel that user space really wants an atomic update, and if the
>> > driver/hardware can't do it, it can return an error.
>>
>> well, that is really only a problem for X11..  and atomic flip across
>> multiple crtc's is a potential mess from performance standpoint unless
>> your displays are vsync'd lock.
>
> It won't be truly atomic unless they are vsync locked. But anyways more
> buffers can be used to solve the performance problem. But that's a
> separate issue and in that case it doesn't really matter whether you
> issue separate ioctls for each crtc.

that was basically my thinking.. separate ioctls for each crtc.  The
way my branch works currently, you can do this.  A page-flip on crtc
#2 won't care that there is still a flip pending on crtc #1.

I guess that doesn't strictly guarantee that the two pageflips happen
at the exact same time, but unless you have some way to vsync lock the
two displays, I don't think that is possible anyways.  So I'm not
really sure it is worth over-complicating the ioctl to support two
crtc's.  The error checking in case a vsync is still pending is much
easier in the driver if you know the crtc up-front at the
atomic_begin() point.  Which is why I prefer to pass the crtc_id as a
field in the ioctl.

BR,
-R

>> weston already renders each output individually, rather than spanning
>> a single fb across multiple displays like x11 does.  So this problem
>> really doesn't exist for weston.
>
> It does if you want to make sure the user sees the flip on both displays
> at the same time.
>
>

[RFC 0/9] nuclear pageflip

On Wed, Sep 12, 2012 at 9:23 AM, Ville Syrj?l?
 wrote:
> On Wed, Sep 12, 2012 at 07:30:18AM -0500, Rob Clark wrote:
>> On Wed, Sep 12, 2012 at 3:59 AM, Ville Syrj?l?
>>  wrote:
>> > On Tue, Sep 11, 2012 at 05:07:49PM -0500, Rob Clark wrote:
>> >> On Tue, Sep 11, 2012 at 4:15 PM, Ben Widawsky  wrote:
>> >> > On Sun, 9 Sep 2012 22:19:59 -0500
>> >> > Rob Clark  wrote:
>> >> >
>> >> >> On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark  
>> >> >> wrote:
>> >> >> > From: Rob Clark 
>> >> >> >
>> >> >> > This is following a bit the approach that Ville is taking for atomic-
>> >> >> > modeset, in that it is switching over to using properties for 
>> >> >> > everything.
>> >> >> > The advantage of this approach is that it makes it easier to add new
>> >> >> > attributes to set as part of a page-flip (and even opens the option 
>> >> >> > to
>> >> >> > add new object types).
>> >> >>
>> >> >> oh, and for those wondering what the hell this is all about,
>> >> >> nuclear-pageflip is a pageflip that atomically updates the CRTC layer
>> >> >> and zero or more attached plane layers, optionally changing various
>> >> >> properties such as z-order (or even blending modes, etc) atomically.
>> >> >> It includes the option for a test step so userspace compositor can
>> >> >> test a proposed configuration (if any properties not marked as
>> >> >> 'dynamic' are updated).  This intended to allow, for example, weston
>> >> >> compositor to synchronize updates to plane (sprite) layers with CRTC
>> >> >> layer.
>> >> >>
>> >> >
>> >> > Can we please name this something different? I complained about this in
>> >> > IRC, but I don't know if you hang around in #intel-gfx.
>> >> >
>> >> > Some suggestions:
>> >> > multiplane pageflip
>> >> > muliplane atomic pageflip
>> >> > atomic multiplane pageflip
>> >> > atomic multiflip
>> >> > pageflip of atomic and multiplane nature
>> >> >
>> >> > Nuclear is not at all descriptive and requires as your response shows
>> >> > :-)
>> >> >
>> >>
>> >> fair enough.. I was originally calling it atomic-pageflip until
>> >> someone (I don't remember who) started calling it nuclear-pageflip to
>> >> differentiate from atomic-modeset.  But IMO we could just call the two
>> >> ioclts atomic-modeset and atomic-pageflip.  (Or even modeset2 and
>> >> pageflip2, but that seems much more boring)
>> >
>> > My plan has been to use the same ioctl for both uses. They'll need
>> > nearly identical handling anyway on the ioctl level. I have something
>> > semi-working currently, but I need to clean it up a bit before I can
>> > show it to anyone.
>>
>> I do think the atomic-pageflip ioctl really should take the crtc-id..
>> so probably should be two ioctls, but nearly identical
>
> But then you can't support atomic pageflips across multiple crtcs even
> if the hardware would allow it. I would hate to add such limitation to
> the API. I can immediately think of a use case; combining several
> smaller displays to form a single larger display.
>
> With a unified API you could just add some kind of flag that tells the
> kernel that user space really wants an atomic update, and if the
> driver/hardware can't do it, it can return an error.

well, that is really only a problem for X11..  and atomic flip across
multiple crtc's is a potential mess from performance standpoint unless
your displays are vsync'd lock.

weston already renders each output individually, rather than spanning
a single fb across multiple displays like x11 does.  So this problem
really doesn't exist for weston.

BR,
-R

> --
> Ville Syrj?l?
> Intel OTC
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

runtime PM and special power switches

On Wed, Sep 12, 2012 at 7:32 AM, Alan Stern  
wrote:
> On Tue, 11 Sep 2012, Rafael J. Wysocki wrote:
>
>> Hi,
>>
>> On Tuesday, September 11, 2012, Dave Airlie wrote:
>> > Hi Rafael,
>> >
>> > I've been investigating runtime PM support for some use-cases on GPUs.
>> >
>> > In some laptops we have a secondary GPU (optimus) that can be powered
>> > up for certain 3D tasks and then turned off when finished with. Now I
>> > did an initial pass on supporting it without using the kernel runtime
>> > PM stuff, but Alan said I should take a look so here I am.
>>
>> Alan Stern or Alan Cox? :-)
>>
>> > While I've started to get a handle on things, we have a bit of an
>> > extra that I'm not sure we cater for.
>> >
>> > Currently we get called from the PCI layer which after we are finished
>> > with our runtime suspend callback, will go put the device into the
>> > correct state etc, however on these optimus/powerxpress laptops we
>> > have a separate ACPI or platform driver controlled power switch that
>> > we need to call once the PCI layer is finished the job. This switch
>> > effectively turns the power to the card completely off leaving it
>> > drawing no power.
>> >
>> > No we can't hit the switch from the driver callback as the PCI layer
>> > will get lost, so I'm wondering how you'd envisage we could plug this
>> > in.
>>
>> Hmm.  In principle we might modify pci_pm_runtime_suspend() so that it
>> doesn't call pci_finish_runtime_suspend() if pci_dev->state_saved is
>> set.  That would actually make it work in analogy with 
>> pci_pm_suspend_noirq(),
>> so perhaps it's not even too dangerous.
>
> This sounds more like a job for a power domain.  Unless the power
> switch is already in the device hierarchy as a parent to the PCI
> device.

I'll have to investigate power domains then,

The switch is hidden in many different places, one some laptops its in
a ACPI _DSM on one GPU, on others its in an ACPI _DSM on the other
one, in some its in a different ACPI _DSM, then we have it in the ACPI
ATPX method on others, and finally Apple have it in a piece of hw that
isn't just on the LPC bus or somewhere like that.

Currently we just hide it all inside vga_switcheroo and I'd just need
an interface to call that once the layers have stopped poking
registers in PCI config space, if we could fix PCI runtime suspend so
the driver was the last to get called then that would also not suck.

Dave.

[RFC 0/9] nuclear pageflip

On Wed, Sep 12, 2012 at 3:59 AM, Ville Syrj?l?
 wrote:
> On Tue, Sep 11, 2012 at 05:07:49PM -0500, Rob Clark wrote:
>> On Tue, Sep 11, 2012 at 4:15 PM, Ben Widawsky  wrote:
>> > On Sun, 9 Sep 2012 22:19:59 -0500
>> > Rob Clark  wrote:
>> >
>> >> On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark  
>> >> wrote:
>> >> > From: Rob Clark 
>> >> >
>> >> > This is following a bit the approach that Ville is taking for atomic-
>> >> > modeset, in that it is switching over to using properties for 
>> >> > everything.
>> >> > The advantage of this approach is that it makes it easier to add new
>> >> > attributes to set as part of a page-flip (and even opens the option to
>> >> > add new object types).
>> >>
>> >> oh, and for those wondering what the hell this is all about,
>> >> nuclear-pageflip is a pageflip that atomically updates the CRTC layer
>> >> and zero or more attached plane layers, optionally changing various
>> >> properties such as z-order (or even blending modes, etc) atomically.
>> >> It includes the option for a test step so userspace compositor can
>> >> test a proposed configuration (if any properties not marked as
>> >> 'dynamic' are updated).  This intended to allow, for example, weston
>> >> compositor to synchronize updates to plane (sprite) layers with CRTC
>> >> layer.
>> >>
>> >
>> > Can we please name this something different? I complained about this in
>> > IRC, but I don't know if you hang around in #intel-gfx.
>> >
>> > Some suggestions:
>> > multiplane pageflip
>> > muliplane atomic pageflip
>> > atomic multiplane pageflip
>> > atomic multiflip
>> > pageflip of atomic and multiplane nature
>> >
>> > Nuclear is not at all descriptive and requires as your response shows
>> > :-)
>> >
>>
>> fair enough.. I was originally calling it atomic-pageflip until
>> someone (I don't remember who) started calling it nuclear-pageflip to
>> differentiate from atomic-modeset.  But IMO we could just call the two
>> ioclts atomic-modeset and atomic-pageflip.  (Or even modeset2 and
>> pageflip2, but that seems much more boring)
>
> My plan has been to use the same ioctl for both uses. They'll need
> nearly identical handling anyway on the ioctl level. I have something
> semi-working currently, but I need to clean it up a bit before I can
> show it to anyone.

I do think the atomic-pageflip ioctl really should take the crtc-id..
so probably should be two ioctls, but nearly identical

BR,
-R

> --
> Ville Syrj?l?
> Intel OTC
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

runtime PM and special power switches

2012-09-12 Thread Rafael J. Wysocki

On Wednesday, September 12, 2012, Dave Airlie wrote:
> On Wed, Sep 12, 2012 at 7:32 AM, Alan Stern  
> wrote:
> > On Tue, 11 Sep 2012, Rafael J. Wysocki wrote:
> >
> >> Hi,
> >>
> >> On Tuesday, September 11, 2012, Dave Airlie wrote:
> >> > Hi Rafael,
> >> >
> >> > I've been investigating runtime PM support for some use-cases on GPUs.
> >> >
> >> > In some laptops we have a secondary GPU (optimus) that can be powered
> >> > up for certain 3D tasks and then turned off when finished with. Now I
> >> > did an initial pass on supporting it without using the kernel runtime
> >> > PM stuff, but Alan said I should take a look so here I am.
> >>
> >> Alan Stern or Alan Cox? :-)
> >>
> >> > While I've started to get a handle on things, we have a bit of an
> >> > extra that I'm not sure we cater for.
> >> >
> >> > Currently we get called from the PCI layer which after we are finished
> >> > with our runtime suspend callback, will go put the device into the
> >> > correct state etc, however on these optimus/powerxpress laptops we
> >> > have a separate ACPI or platform driver controlled power switch that
> >> > we need to call once the PCI layer is finished the job. This switch
> >> > effectively turns the power to the card completely off leaving it
> >> > drawing no power.
> >> >
> >> > No we can't hit the switch from the driver callback as the PCI layer
> >> > will get lost, so I'm wondering how you'd envisage we could plug this
> >> > in.
> >>
> >> Hmm.  In principle we might modify pci_pm_runtime_suspend() so that it
> >> doesn't call pci_finish_runtime_suspend() if pci_dev->state_saved is
> >> set.  That would actually make it work in analogy with 
> >> pci_pm_suspend_noirq(),
> >> so perhaps it's not even too dangerous.
> >
> > This sounds more like a job for a power domain.  Unless the power
> > switch is already in the device hierarchy as a parent to the PCI
> > device.
> 
> I'll have to investigate power domains then,
> 
> The switch is hidden in many different places, one some laptops its in
> a ACPI _DSM on one GPU, on others its in an ACPI _DSM on the other
> one, in some its in a different ACPI _DSM, then we have it in the ACPI
> ATPX method on others, and finally Apple have it in a piece of hw that
> isn't just on the LPC bus or somewhere like that.
> 
> Currently we just hide it all inside vga_switcheroo and I'd just need
> an interface to call that once the layers have stopped poking
> registers in PCI config space, if we could fix PCI runtime suspend so
> the driver was the last to get called then that would also not suck.

Well, as I said, we may try to change the PCI layer so that it doesn't
access the device any more in pci_pm_runtime_suspend() if it sees that
pci_dev->state_saved has been set by the driver's callback.  Then,
your drivers would only need to set pci_dev->state_saved in their
.runtime_suspend() callbacks.

Alternatively, which may be less hackish but more work, you can set the
pm_domain pointer in the device structure to a struct dev_pm_domain whose
ops will just call the corresponding bus type's ops except for
.runtime_suspend() that will execute the additional ACPI stuff after calling
the bus type's method.

Thanks,
Rafael

runtime PM and special power switches

2012-09-12 Thread Rafael J. Wysocki

On Tuesday, September 11, 2012, Alan Stern wrote:
> On Tue, 11 Sep 2012, Rafael J. Wysocki wrote:
> 
> > Hi,
> > 
> > On Tuesday, September 11, 2012, Dave Airlie wrote:
> > > Hi Rafael,
> > > 
> > > I've been investigating runtime PM support for some use-cases on GPUs.
> > > 
> > > In some laptops we have a secondary GPU (optimus) that can be powered
> > > up for certain 3D tasks and then turned off when finished with. Now I
> > > did an initial pass on supporting it without using the kernel runtime
> > > PM stuff, but Alan said I should take a look so here I am.
> > 
> > Alan Stern or Alan Cox? :-)
> > 
> > > While I've started to get a handle on things, we have a bit of an
> > > extra that I'm not sure we cater for.
> > > 
> > > Currently we get called from the PCI layer which after we are finished
> > > with our runtime suspend callback, will go put the device into the
> > > correct state etc, however on these optimus/powerxpress laptops we
> > > have a separate ACPI or platform driver controlled power switch that
> > > we need to call once the PCI layer is finished the job. This switch
> > > effectively turns the power to the card completely off leaving it
> > > drawing no power.
> > > 
> > > No we can't hit the switch from the driver callback as the PCI layer
> > > will get lost, so I'm wondering how you'd envisage we could plug this
> > > in.
> > 
> > Hmm.  In principle we might modify pci_pm_runtime_suspend() so that it
> > doesn't call pci_finish_runtime_suspend() if pci_dev->state_saved is
> > set.  That would actually make it work in analogy with 
> > pci_pm_suspend_noirq(),
> > so perhaps it's not even too dangerous.
> 
> This sounds more like a job for a power domain.  Unless the power
> switch is already in the device hierarchy as a parent to the PCI
> device.

Good idea. :-)

Thanks,
Rafael

Re: runtime PM and special power switches

On Wed, Sep 12, 2012 at 3:13 PM, Dave Airlie airl...@gmail.com wrote:
On Wed, Sep 12, 2012 at 8:58 AM, Rafael J. Wysocki r...@sisk.pl wrote:
On Wednesday, September 12, 2012, Dave Airlie wrote:
On Wed, Sep 12, 2012 at 7:32 AM, Alan Stern st...@rowland.harvard.edu
wrote:
On Tue, 11 Sep 2012, Rafael J. Wysocki wrote:

Hi,

On Tuesday, September 11, 2012, Dave Airlie wrote:
Hi Rafael,

I've been investigating runtime PM support for some use-cases on GPUs.

In some laptops we have a secondary GPU (optimus) that can be powered
up for certain 3D tasks and then turned off when finished with. Now I
did an initial pass on supporting it without using the kernel runtime
PM stuff, but Alan said I should take a look so here I am.

Alan Stern or Alan Cox? :-)

While I've started to get a handle on things, we have a bit of an
extra that I'm not sure we cater for.

Currently we get called from the PCI layer which after we are finished
with our runtime suspend callback, will go put the device into the
correct state etc, however on these optimus/powerxpress laptops we
have a separate ACPI or platform driver controlled power switch that
we need to call once the PCI layer is finished the job. This switch
effectively turns the power to the card completely off leaving it
drawing no power.

No we can't hit the switch from the driver callback as the PCI layer
will get lost, so I'm wondering how you'd envisage we could plug this
in.

Hmm. In principle we might modify pci_pm_runtime_suspend() so that it
doesn't call pci_finish_runtime_suspend() if pci_dev-state_saved is
set. That would actually make it work in analogy with
pci_pm_suspend_noirq(),
so perhaps it's not even too dangerous.

This sounds more like a job for a power domain. Unless the power
switch is already in the device hierarchy as a parent to the PCI
device.

I'll have to investigate power domains then,

The switch is hidden in many different places, one some laptops its in
a ACPI _DSM on one GPU, on others its in an ACPI _DSM on the other
one, in some its in a different ACPI _DSM, then we have it in the ACPI
ATPX method on others, and finally Apple have it in a piece of hw that
isn't just on the LPC bus or somewhere like that.

Currently we just hide it all inside vga_switcheroo and I'd just need
an interface to call that once the layers have stopped poking
registers in PCI config space, if we could fix PCI runtime suspend so
the driver was the last to g 2et called then that would also not suck.

Well, as I said, we may try to change the PCI layer so that it doesn't
access the device any more in pci_pm_runtime_suspend() if it sees that
pci_dev-state_saved has been set by the driver's callback. Then,
your drivers would only need to set pci_dev-state_saved in their
.runtime_suspend() callbacks.

Actually it appears I'll need this, I'd forgotten things are a bit
messier than I thought

So there are two variants on the _DSM for nvidia dual-gpu machines,
the older pre-optimus _DSM requires
an explicit power off call post-D3, however for optimus _DSM the D3
transition will flick the power switch, however
the pci code then goes and seem to turn the device back to D0 for some
reason. So yes after save state,
I'd really appreciate if it the pci layer would stop poking my device.

Alternatively, which may be less hackish but more work, you can set the
pm_domain pointer in the device structure to a struct dev_pm_domain whose
ops will just call the corresponding bus type's ops except for
.runtime_suspend() that will execute the additional ACPI stuff after calling
the bus type's method.

I've mostly written this, and it seems to work, I've jsut set a
pm_domain in the vga switcheroo code that copies the dev-bus-pm
into a private structure. I'll need this for the old nvidia and radeon
poweroffs.

http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-opt-pwr
is my current WIP branch

http://cgit.freedesktop.org/~airlied/linux/diff/drivers/gpu/vga/vga_switcheroo.c?h=drm-opt-pwrid=8952007a8799a5b096d64a8217e3001e2ebed2ab
contains what I've done to override the 2 pms ops we need to override
for older GPUs

http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-opt-pwrid=005fdf5c184f9b857cbd8cb7195898d776f68670
is my current PCI workaround.

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

Re: [RFC 0/9] nuclear pageflip

On Tue, Sep 11, 2012 at 05:07:49PM -0500, Rob Clark wrote:
 On Tue, Sep 11, 2012 at 4:15 PM, Ben Widawsky b...@bwidawsk.net wrote:
  On Sun, 9 Sep 2012 22:19:59 -0500
  Rob Clark r...@ti.com wrote:
 
  On Sun, Sep 9, 2012 at 10:03 PM, Rob Clark rob.cl...@linaro.org wrote:
   From: Rob Clark r...@ti.com
  
   This is following a bit the approach that Ville is taking for atomic-
   modeset, in that it is switching over to using properties for everything.
   The advantage of this approach is that it makes it easier to add new
   attributes to set as part of a page-flip (and even opens the option to
   add new object types).
 
  oh, and for those wondering what the hell this is all about,
  nuclear-pageflip is a pageflip that atomically updates the CRTC layer
  and zero or more attached plane layers, optionally changing various
  properties such as z-order (or even blending modes, etc) atomically.
  It includes the option for a test step so userspace compositor can
  test a proposed configuration (if any properties not marked as
  'dynamic' are updated).  This intended to allow, for example, weston
  compositor to synchronize updates to plane (sprite) layers with CRTC
  layer.
 
 
  Can we please name this something different? I complained about this in
  IRC, but I don't know if you hang around in #intel-gfx.
 
  Some suggestions:
  multiplane pageflip
  muliplane atomic pageflip
  atomic multiplane pageflip
  atomic multiflip
  pageflip of atomic and multiplane nature
 
  Nuclear is not at all descriptive and requires as your response shows
  :-)
 
 
 fair enough.. I was originally calling it atomic-pageflip until
 someone (I don't remember who) started calling it nuclear-pageflip to
 differentiate from atomic-modeset.  But IMO we could just call the two
 ioclts atomic-modeset and atomic-pageflip.  (Or even modeset2 and
 pageflip2, but that seems much more boring)

My plan has been to use the same ioctl for both uses. They'll need
nearly identical handling anyway on the ioctl level. I have something
semi-working currently, but I need to clean it up a bit before I can
show it to anyone.

-- 
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 51344] massive corruption on RV410

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

--- Comment #11 from Christian König deathsim...@vodafone.de 2012-09-12 
09:55:57 UTC ---
(In reply to comment #10)
 Output from /sys/kernel/debug/dri/0/radeon_fence_info
 
 --- ring 0 ---
 Last signaled fence 0xdeadbeef
 Last emitted  0x0670
 
 --- ring 0 ---
 Last signaled fence 0xdeadbeef
 Last emitted  0x0c44

WTF? Well that's a very interesting information you've got us here, thanks
allot.

deadbeef is a pattern we usually use for ring and IB tests, and I have no
idea how that ended up as last signaled fence value.

Could you try Jeromes debugging patch
(http://people.freedesktop.org/~glisse/0001-debug-fence-emission-reception.patch)
and attach the resulting output.

Thx,
Christian.

-- 
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

[PATCH] gma500: Fix regression on Oaktrail devices

2012-09-12 Thread Alan Cox

From: Alan Cox a...@linux.intel.com

The register map patches didn't set one value for the GMA600 which
means the Fujitsu Q550 dies on boot with the GMA500 driver enabled.

Add the map entry so we don't read from the device MMIO + 0 by mistake.

Signed-off-by: Alan Cox a...@linux.intel.com
Cc: Horses sta...@vger.kernel.org
---

 drivers/gpu/drm/gma500/oaktrail_device.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c 
b/drivers/gpu/drm/gma500/oaktrail_device.c
index 0f9b7db..cf49ba5 100644
--- a/drivers/gpu/drm/gma500/oaktrail_device.c
+++ b/drivers/gpu/drm/gma500/oaktrail_device.c
@@ -476,6 +476,7 @@ static const struct psb_offset oaktrail_regmap[2] = {
.pos = DSPAPOS,
.surf = DSPASURF,
.addr = MRST_DSPABASE,
+   .base = MRST_DSPABASE,
.status = PIPEASTAT,
.linoff = DSPALINOFF,
.tileoff = DSPATILEOFF,
@@ -499,6 +500,7 @@ static const struct psb_offset oaktrail_regmap[2] = {
.pos = DSPBPOS,
.surf = DSPBSURF,
.addr = DSPBBASE,
+   .base = DSPBBASE,
.status = PIPEBSTAT,
.linoff = DSPBLINOFF,
.tileoff = DSPBTILEOFF,

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

[PATCH 5/6] staging: drm/imx: Add devicetree binding documentation

From: Philipp Zabel p.za...@pengutronix.de

Signed-off-by: Philipp Zabel p.za...@pengutronix.de
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
 .../bindings/staging/imx-drm/fsl-imx-drm.txt   |   41 
 1 file changed, 41 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt

diff --git a/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt 
b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
new file mode 100644
index 000..07654f0
--- /dev/null
+++ b/Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
@@ -0,0 +1,41 @@
+Freescale i.MX IPUv3
+
+
+Required properties:
+- compatible: Should be fsl,chip-ipu
+- reg: should be register base and length as documented in the
+  datasheet
+- interrupts: Should contain sync interrupt and error interrupt,
+  in this order.
+- #crtc-cells: 1, See below
+
+example:
+
+ipu: ipu@1800 {
+   #crtc-cells = 1;
+   compatible = fsl,imx53-ipu;
+   reg = 0x1800 0x08000;
+   interrupts = 11 10;
+};
+
+Parallel display support
+
+
+Required properties:
+- compatible: Should be fsl,imx-parallel-display
+- crtc: the crtc this display is connected to, see below
+Optional properties:
+- interface_pix_fmt: How this display is connected to the
+  crtc. Currently supported types: rgb24, rgb565
+- edid: verbatim EDID data block describing attached display.
+- ddc: phandle describing the i2c bus handling the display data
+  channel
+
+example:
+
+display@di0 {
+   compatible = fsl,imx-parallel-display;
+   edid = [edid-data];
+   crtc = ipu 0;
+   interface-pix-fmt = rgb24;
+};
-- 
1.7.10.4

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

[PATCH] Add i.MX IPUv3 base/KMS driver to the staging tree

Hi Greg et all,

The following adds the i.MX IPUv3 base and KMS driver to the staging
tree. It currently depends on two patches adding helper functions to
the DRM core. Dave Airlie already has signalled he is ok with these
helper functions. Apart from that, please let me know if there's anything
else blocking the IPU patches from going to staging. If not, I would
ping again once the helper patches show up in linux-next.

Thanks
 Sascha


The following changes since commit 55d512e245bc7699a8800e23df1a24195dd08217:

  Linux 3.6-rc5 (2012-09-08 16:43:45 -0700)

are available in the git repository at:

  git://git.pengutronix.de/git/imx/linux-2.6.git tags/staging-drm-imx

for you to fetch changes up to d344cf816ce270a74d5210d771646ad04c89a7cc:

  staging: drm/imx: Add TODO (2012-09-12 12:01:13 +0200)


This adds an ARM i.MX IPUv3 base and DRM driver to the staging
tree.


Philipp Zabel (1):
  staging: drm/imx: Add devicetree binding documentation

Sascha Hauer (5):
  staging: drm/imx: Add i.MX drm core support
  staging: drm/imx: Add parallel display support
  staging: drm/imx: add i.MX IPUv3 base driver
  staging: drm/imx: Add i.MX IPUv3 crtc support
  staging: drm/imx: Add TODO

 .../bindings/staging/imx-drm/fsl-imx-drm.txt   |   41 +
 drivers/staging/Kconfig|2 +
 drivers/staging/Makefile   |1 +
 drivers/staging/imx-drm/Kconfig|   35 +
 drivers/staging/imx-drm/Makefile   |9 +
 drivers/staging/imx-drm/TODO   |   22 +
 drivers/staging/imx-drm/imx-drm-core.c |  882 +++
 drivers/staging/imx-drm/imx-drm.h  |   58 +
 drivers/staging/imx-drm/imx-fb.c   |   47 +
 drivers/staging/imx-drm/imx-fbdev.c|   74 ++
 drivers/staging/imx-drm/ipu-v3/Makefile|3 +
 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h|  318 ++
 drivers/staging/imx-drm/ipu-v3/ipu-common.c| 1143 
 drivers/staging/imx-drm/ipu-v3/ipu-dc.c|  379 +++
 drivers/staging/imx-drm/ipu-v3/ipu-di.c|  700 
 drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c  |  408 +++
 drivers/staging/imx-drm/ipu-v3/ipu-dp.c|  336 ++
 drivers/staging/imx-drm/ipu-v3/ipu-prv.h   |  206 
 drivers/staging/imx-drm/ipuv3-crtc.c   |  579 ++
 drivers/staging/imx-drm/parallel-display.c |  262 +
 20 files changed, 5505 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
 create mode 100644 drivers/staging/imx-drm/Kconfig
 create mode 100644 drivers/staging/imx-drm/Makefile
 create mode 100644 drivers/staging/imx-drm/TODO
 create mode 100644 drivers/staging/imx-drm/imx-drm-core.c
 create mode 100644 drivers/staging/imx-drm/imx-drm.h
 create mode 100644 drivers/staging/imx-drm/imx-fb.c
 create mode 100644 drivers/staging/imx-drm/imx-fbdev.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/Makefile
 create mode 100644 drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-common.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-dc.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-di.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-dmfc.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-dp.c
 create mode 100644 drivers/staging/imx-drm/ipu-v3/ipu-prv.h
 create mode 100644 drivers/staging/imx-drm/ipuv3-crtc.c
 create mode 100644 drivers/staging/imx-drm/parallel-display.c

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

[PATCH 2/6] staging: drm/imx: Add parallel display support

This adds support for parallel displays for i.MX. It consists
of a drm encoder/connector pair which eventually passes EDID
data from the devicetree to the drm core.

Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
 drivers/staging/imx-drm/Kconfig|4 +
 drivers/staging/imx-drm/Makefile   |1 +
 drivers/staging/imx-drm/parallel-display.c |  262 
 3 files changed, 267 insertions(+)
 create mode 100644 drivers/staging/imx-drm/parallel-display.c

diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
index 2ef867b..9e27012 100644
--- a/drivers/staging/imx-drm/Kconfig
+++ b/drivers/staging/imx-drm/Kconfig
@@ -15,3 +15,7 @@ config DRM_IMX_FB_HELPER
  The DRM framework can provide a legacy /dev/fb0 framebuffer
  for your device. This is necessary to get a framebuffer console
  and also for appplications using the legacy framebuffer API
+
+config DRM_IMX_PARALLEL_DISPLAY
+   tristate Support for parallel displays
+   depends on DRM_IMX
diff --git a/drivers/staging/imx-drm/Makefile b/drivers/staging/imx-drm/Makefile
index ff825f7..c8f582e 100644
--- a/drivers/staging/imx-drm/Makefile
+++ b/drivers/staging/imx-drm/Makefile
@@ -3,4 +3,5 @@ imxdrm-objs := imx-drm-core.o imx-fb.o
 
 obj-$(CONFIG_DRM_IMX) += imxdrm.o
 
+obj-$(CONFIG_DRM_IMX_PARALLEL_DISPLAY) += parallel-display.o
 obj-$(CONFIG_DRM_IMX_FB_HELPER) += imx-fbdev.o
diff --git a/drivers/staging/imx-drm/parallel-display.c 
b/drivers/staging/imx-drm/parallel-display.c
new file mode 100644
index 000..e757d42
--- /dev/null
+++ b/drivers/staging/imx-drm/parallel-display.c
@@ -0,0 +1,262 @@
+/*
+ * i.MX drm driver - parallel display implementation
+ *
+ * Copyright (C) 2012 Sascha Hauer, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+
+#include linux/module.h
+#include drm/drmP.h
+#include drm/drm_fb_helper.h
+#include drm/drm_crtc_helper.h
+#include linux/videodev2.h
+
+#include imx-drm.h
+
+#define con_to_imxpd(x) container_of(x, struct imx_parallel_display, connector)
+#define enc_to_imxpd(x) container_of(x, struct imx_parallel_display, encoder)
+
+struct imx_parallel_display {
+   struct drm_connector connector;
+   struct imx_drm_connector *imx_drm_connector;
+   struct drm_encoder encoder;
+   struct imx_drm_encoder *imx_drm_encoder;
+   struct device *dev;
+   void *edid;
+   int edid_len;
+   u32 interface_pix_fmt;
+   int mode_valid;
+   struct drm_display_mode mode;
+};
+
+static enum drm_connector_status imx_pd_connector_detect(
+   struct drm_connector *connector, bool force)
+{
+   return connector_status_connected;
+}
+
+static void imx_pd_connector_destroy(struct drm_connector *connector)
+{
+   /* do not free here */
+}
+
+static int imx_pd_connector_get_modes(struct drm_connector *connector)
+{
+   struct imx_parallel_display *imxpd = con_to_imxpd(connector);
+   int num_modes = 0;
+
+   if (imxpd-edid) {
+   drm_mode_connector_update_edid_property(connector, imxpd-edid);
+   num_modes = drm_add_edid_modes(connector, imxpd-edid);
+   connector-display_info.raw_edid = NULL;
+   }
+
+   if (imxpd-mode_valid) {
+   struct drm_display_mode *mode = drm_mode_create(connector-dev);
+   drm_mode_copy(mode, imxpd-mode);
+   mode-type |= DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
+   drm_mode_probed_add(connector, mode);
+   num_modes++;
+   }
+
+   return num_modes;
+}
+
+static int imx_pd_connector_mode_valid(struct drm_connector *connector,
+ struct drm_display_mode *mode)
+{
+   return 0;
+}
+
+static struct drm_encoder *imx_pd_connector_best_encoder(
+   struct drm_connector *connector)
+{
+   struct imx_parallel_display *imxpd = con_to_imxpd(connector);
+
+   return imxpd-encoder;
+}
+
+static void imx_pd_encoder_dpms(struct drm_encoder *encoder, int mode)
+{
+}
+
+static bool imx_pd_encoder_mode_fixup(struct drm_encoder *encoder,
+  const struct drm_display_mode *mode,
+  struct drm_display_mode *adjusted_mode)
+{
+   return true;
+}
+
+static void

[PATCH 4/6] staging: drm/imx: Add i.MX IPUv3 crtc support

This adds a i.MX51/53/6 IPU (Image Processing Unit) KMS driver. The
driver has been tested on the i.MX51 babbage board, the i.MX53 LOCO
board and the i.MX6q sabrelite board in different clone mode and dual
head setups.

Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
 drivers/staging/imx-drm/Kconfig  |6 +
 drivers/staging/imx-drm/Makefile |1 +
 drivers/staging/imx-drm/ipuv3-crtc.c |  579 ++
 3 files changed, 586 insertions(+)
 create mode 100644 drivers/staging/imx-drm/ipuv3-crtc.c

diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
index 4849bfa..14b4449 100644
--- a/drivers/staging/imx-drm/Kconfig
+++ b/drivers/staging/imx-drm/Kconfig
@@ -27,3 +27,9 @@ config DRM_IMX_IPUV3_CORE
  Choose this if you have a i.MX5/6 system and want
  to use the IPU. This option only enables IPU base
  support.
+
+config DRM_IMX_IPUV3
+   tristate DRM Support for i.MX IPUv3
+   depends on DRM_IMX
+   help
+ Choose this if you have a i.MX5 or i.MX6 processor.
diff --git a/drivers/staging/imx-drm/Makefile b/drivers/staging/imx-drm/Makefile
index e3a5b6f..83a9056 100644
--- a/drivers/staging/imx-drm/Makefile
+++ b/drivers/staging/imx-drm/Makefile
@@ -6,3 +6,4 @@ obj-$(CONFIG_DRM_IMX) += imxdrm.o
 obj-$(CONFIG_DRM_IMX_PARALLEL_DISPLAY) += parallel-display.o
 obj-$(CONFIG_DRM_IMX_FB_HELPER) += imx-fbdev.o
 obj-$(CONFIG_DRM_IMX_IPUV3_CORE) += ipu-v3/
+obj-$(CONFIG_DRM_IMX_IPUV3)+= ipuv3-crtc.o
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c 
b/drivers/staging/imx-drm/ipuv3-crtc.c
new file mode 100644
index 000..78d3eda
--- /dev/null
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -0,0 +1,579 @@
+/*
+ * i.MX IPUv3 Graphics driver
+ *
+ * Copyright (C) 2011 Sascha Hauer, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
+ * MA 02110-1301, USA.
+ */
+#include linux/module.h
+#include linux/export.h
+#include linux/device.h
+#include linux/platform_device.h
+#include drm/drmP.h
+#include drm/drm_fb_helper.h
+#include drm/drm_crtc_helper.h
+#include linux/fb.h
+#include linux/clk.h
+#include drm/drm_gem_cma_helper.h
+#include drm/drm_fb_cma_helper.h
+
+#include ipu-v3/imx-ipu-v3.h
+#include imx-drm.h
+
+#define DRIVER_DESCi.MX IPUv3 Graphics
+
+struct ipu_framebuffer {
+   struct drm_framebuffer  base;
+   void*virt;
+   dma_addr_t  phys;
+   size_t  len;
+};
+
+struct ipu_crtc {
+   struct drm_fb_helperfb_helper;
+   struct ipu_framebuffer  ifb;
+   int num_crtcs;
+   struct device   *dev;
+   struct drm_crtc base;
+   struct imx_drm_crtc *imx_crtc;
+   struct ipuv3_channel*ipu_ch;
+   struct ipu_dc   *dc;
+   struct ipu_dp   *dp;
+   struct dmfc_channel *dmfc;
+   struct ipu_di   *di;
+   int enabled;
+   struct ipu_priv *ipu_priv;
+   struct drm_pending_vblank_event *page_flip_event;
+   struct drm_framebuffer  *newfb;
+   int irq;
+   u32 interface_pix_fmt;
+   unsigned long   di_clkflags;
+};
+
+#define to_ipu_crtc(x) container_of(x, struct ipu_crtc, base)
+
+static int calc_vref(struct drm_display_mode *mode)
+{
+   unsigned long htotal, vtotal;
+
+   htotal = mode-htotal;
+   vtotal = mode-vtotal;
+
+   if (!htotal || !vtotal)
+   return 60;
+
+   return mode-clock * 1000 / vtotal / htotal;
+}
+
+static int calc_bandwidth(struct drm_display_mode *mode, unsigned int vref)
+{
+   return mode-hdisplay * mode-vdisplay * vref;
+}
+
+static void ipu_fb_enable(struct ipu_crtc *ipu_crtc)
+{
+   if (ipu_crtc-enabled)
+   return;
+
+   ipu_di_enable(ipu_crtc-di);
+   ipu_dmfc_enable_channel(ipu_crtc-dmfc);
+   ipu_idmac_enable_channel(ipu_crtc-ipu_ch);
+   ipu_dc_enable_channel(ipu_crtc-dc);
+   if (ipu_crtc-dp)
+   ipu_dp_enable_channel(ipu_crtc-dp);
+
+   ipu_crtc-enabled = 1;
+}
+
+static void ipu_fb_disable(struct ipu_crtc *ipu_crtc)
+{
+   if (!ipu_crtc-enabled)
+   return;
+
+   if (ipu_crtc-dp)
+

[PATCH 6/6] staging: drm/imx: Add TODO

Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
 drivers/staging/imx-drm/TODO |   22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 drivers/staging/imx-drm/TODO

diff --git a/drivers/staging/imx-drm/TODO b/drivers/staging/imx-drm/TODO
new file mode 100644
index 000..2075646
--- /dev/null
+++ b/drivers/staging/imx-drm/TODO
@@ -0,0 +1,22 @@
+TODO:
+- get DRM Maintainer review for this code
+- Factor out more code to common helper functions
+- decide where to put the base driver. It is not specific to a subsystem
+  and would be used by DRM/KMS and media/V4L2
+- convert irq driver to irq_domain_add_linear
+
+Missing features (not necessarily for moving out out staging):
+
+- Add KMS plane support for CRTC driver
+- Add LDB (LVDS Display Bridge) support
+- Add i.MX6 HDMI support
+- Add support for IC (Image converter)
+- Add support for CSI (CMOS Sensor interface)
+- Add support for VDIC (Video Deinterlacer)
+
+Many work-in-progress patches for the above features exist. Contact
+Sascha Hauer ker...@pengutronix.de if you are interested in working
+on a specific feature.
+
+Please send any patches to Greg Kroah-Hartman g...@kroah.com and
+Sascha Hauer ker...@pengutronix.de
-- 
1.7.10.4

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

[PATCH 1/6] staging: drm/imx: Add i.MX drm core support

This patch adds the i.MX glue stuff between i.MX and drm.

Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
 drivers/staging/Kconfig|2 +
 drivers/staging/Makefile   |1 +
 drivers/staging/imx-drm/Kconfig|   17 +
 drivers/staging/imx-drm/Makefile   |6 +
 drivers/staging/imx-drm/imx-drm-core.c |  882 
 drivers/staging/imx-drm/imx-drm.h  |   58 +++
 drivers/staging/imx-drm/imx-fb.c   |   47 ++
 drivers/staging/imx-drm/imx-fbdev.c|   74 +++
 8 files changed, 1087 insertions(+)
 create mode 100644 drivers/staging/imx-drm/Kconfig
 create mode 100644 drivers/staging/imx-drm/Makefile
 create mode 100644 drivers/staging/imx-drm/imx-drm-core.c
 create mode 100644 drivers/staging/imx-drm/imx-drm.h
 create mode 100644 drivers/staging/imx-drm/imx-fb.c
 create mode 100644 drivers/staging/imx-drm/imx-fbdev.c

diff --git a/drivers/staging/Kconfig b/drivers/staging/Kconfig
index e3402d5..4a3432f 100644
--- a/drivers/staging/Kconfig
+++ b/drivers/staging/Kconfig
@@ -136,4 +136,6 @@ source drivers/staging/csr/Kconfig
 
 source drivers/staging/omap-thermal/Kconfig
 
+source drivers/staging/imx-drm/Kconfig
+
 endif # STAGING
diff --git a/drivers/staging/Makefile b/drivers/staging/Makefile
index 3be59d0..b7dc4b1 100644
--- a/drivers/staging/Makefile
+++ b/drivers/staging/Makefile
@@ -60,3 +60,4 @@ obj-$(CONFIG_USB_G_CCG)   += ccg/
 obj-$(CONFIG_WIMAX_GDM72XX)+= gdm72xx/
 obj-$(CONFIG_CSR_WIFI) += csr/
 obj-$(CONFIG_OMAP_BANDGAP) += omap-thermal/
+obj-$(CONFIG_DRM_IMX)  += imx-drm/
diff --git a/drivers/staging/imx-drm/Kconfig b/drivers/staging/imx-drm/Kconfig
new file mode 100644
index 000..2ef867b
--- /dev/null
+++ b/drivers/staging/imx-drm/Kconfig
@@ -0,0 +1,17 @@
+config DRM_IMX
+   tristate DRM Support for Freescale i.MX
+   select DRM_KMS_HELPER
+   select DRM_GEM_CMA_HELPER
+   select DRM_KMS_CMA_HELPER
+   depends on DRM  ARCH_MXC
+   help
+ enable i.MX graphics support
+
+config DRM_IMX_FB_HELPER
+   tristate provide legacy framebuffer /dev/fb0
+   select DRM_KMS_CMA_HELPER
+   depends on DRM_IMX
+   help
+ The DRM framework can provide a legacy /dev/fb0 framebuffer
+ for your device. This is necessary to get a framebuffer console
+ and also for appplications using the legacy framebuffer API
diff --git a/drivers/staging/imx-drm/Makefile b/drivers/staging/imx-drm/Makefile
new file mode 100644
index 000..ff825f7
--- /dev/null
+++ b/drivers/staging/imx-drm/Makefile
@@ -0,0 +1,6 @@
+
+imxdrm-objs := imx-drm-core.o imx-fb.o
+
+obj-$(CONFIG_DRM_IMX) += imxdrm.o
+
+obj-$(CONFIG_DRM_IMX_FB_HELPER) += imx-fbdev.o
diff --git a/drivers/staging/imx-drm/imx-drm-core.c 
b/drivers/staging/imx-drm/imx-drm-core.c
new file mode 100644
index 000..225e835
--- /dev/null
+++ b/drivers/staging/imx-drm/imx-drm-core.c
@@ -0,0 +1,882 @@
+/*
+ * Freescale i.MX drm driver
+ *
+ * Copyright (C) 2011 Sascha Hauer, Pengutronix
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/device.h
+#include linux/platform_device.h
+#include drm/drmP.h
+#include drm/drm_fb_helper.h
+#include drm/drm_crtc_helper.h
+#include linux/fb.h
+#include linux/module.h
+#include drm/drm_gem_cma_helper.h
+#include drm/drm_fb_cma_helper.h
+
+#include imx-drm.h
+
+#define MAX_CRTC   4
+
+struct crtc_cookie {
+   void *cookie;
+   int id;
+   struct list_head list;
+};
+
+struct imx_drm_device {
+   struct drm_device   *drm;
+   struct device   *dev;
+   struct list_headcrtc_list;
+   struct list_headencoder_list;
+   struct list_headconnector_list;
+   struct mutexmutex;
+   int references;
+   int pipes;
+   struct drm_fbdev_cma*fbhelper;
+};
+
+struct imx_drm_crtc {
+   struct drm_crtc *crtc;
+   struct list_headlist;
+   struct imx_drm_device   *imxdrm;
+   int pipe;
+   struct imx_drm_crtc_helper_funcsimx_drm_helper_funcs;
+   struct module   *owner;
+   struct crtc_cookie  cookie;
+};
+
+struct imx_drm_encoder {
+

[Bug 33715] demo arbocclude regression since r600g: Implement asyncronous query results.

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

--- Comment #6 from Andreas Boll andreas.boll@gmail.com 2012-09-12 
11:30:34 UTC ---
(In reply to comment #5)
 Dave Airlie wrote:
 I don't think this is a bug, its just how the demo works, it paints red if the
 results aren't ready when first asked, which is perfectly within spec from 
 what
 I can see.

I can reproduce the same result:
with softpipe all squares have the same color
with llvmpipe and r600g the bottom square is red


Should we close this bug as NOTABUG?

-- 
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 33715] demo arbocclude regression since r600g: Implement asyncronous query results.

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

--- Comment #7 from Andreas Boll andreas.boll@gmail.com 2012-09-12 
11:33:24 UTC ---
Created attachment 67045
  -- https://bugs.freedesktop.org/attachment.cgi?id=67045
screenshot with softpipe

-- 
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 33715] demo arbocclude regression since r600g: Implement asyncronous query results.