date:20120516

 -Original Message-
 From: robdcl...@gmail.com [mailto:robdcl...@gmail.com] On Behalf Of Rob
 Clark
 Sent: Tuesday, May 15, 2012 11:29 PM
 To: InKi Dae
 Cc: Inki Dae; kyungmin.p...@samsung.com; sw0312@samsung.com; dri-
 de...@lists.freedesktop.org
 Subject: Re: [PATCH 3/4] drm/exynos: added userptr feature.

 On Tue, May 15, 2012 at 7:40 AM, InKi Dae daei...@gmail.com wrote:
  2012/5/15 Rob Clark rob.cl...@linaro.org:
  On Tue, May 15, 2012 at 2:17 AM, Inki Dae inki@samsung.com wrote:
  Hi Rob,

  -Original Message-
  From: robdcl...@gmail.com [mailto:robdcl...@gmail.com] On Behalf Of
 Rob
  Clark
  Sent: Tuesday, May 15, 2012 4:35 PM
  To: Inki Dae
  Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
  kyungmin.p...@samsung.com; sw0312@samsung.com
  Subject: Re: [PATCH 3/4] drm/exynos: added userptr feature.

  On Mon, Apr 23, 2012 at 7:43 AM, Inki Dae inki@samsung.com
 wrote:
   this feature could be used to use memory region allocated by
 malloc() in
  user
   mode and mmaped memory region allocated by other memory allocators.
  userptr
   interface can identify memory type through vm_flags value and would
 get
   pages or page frame numbers to user space appropriately.

  I apologize for being a little late to jump in on this thread, but...

  I must confess to not being a huge fan of userptr.  It really is
  opening a can of worms, and seems best avoided if at all possible.
  I'm not entirely sure the use-case for which you require this, but I
  wonder if there isn't an alternative way?   I mean, the main case I
  could think of for mapping userspace memory would be something like
  texture upload.  But could that be handled in an alternative way,
  something like a pwrite or texture_upload API, which could
 temporarily
  pin the userspace memory, kick off a dma from that user buffer to a
  proper GEM buffer, and then unpin the user buffer when the DMA
  completes?

  This feature have being discussed with drm and linux-mm guys and I
 have
  posted this patch four times.
  So please, see below e-mail threads.
  http://www.spinics.net/lists/dri-devel/msg22729.html

  and then please, give me your opinions.

  Yeah, I read that and understand that the purpose is to support
  malloc()'d memory (and btw, all the other changes like limits to the
  amount of userptr buffers are good if we do decide to support userptr
  buffers).  But my question was more about why do you need to support
  malloc'd buffers... other than just because v4l2 does ;-)

  I don't really like the userptr feature in v4l2 either, and view it as
  a necessary evil because at the time there was nothing like dmabuf.
  But now that we have dmabuf to share buffers with zero copy between
  two devices, to we *really* still need userptr?

  Definitely no, as I mentioned on this email thread, we are using the
  userptr feature for pixman and evas
  backend to use gpu acceleration directly(zero-copy). as you may know,
  Evas is part of the Enlightenment Foundation Libraries(EFL) and
  Elementary for pixman. all the applicaions based on them uses user
  address to draw something so the backends(such as gpu accelerators)
  can refer to only the user address to the buffer rendered. do you
  think we can avoid memory copy to use those GPUs without such userptr
  feature? I think there is no way and only the way that the gpu uses
  the user address to render without memory copy. and as mentioned on
  this thread, this feature had been tried by i915 in the desktop world.
  for this, you can refer to Daniel's comments.

 oh, yeah, for something like pixman it is hard to accelerate.  But I
 wonder if there is still some benefit.  I don't know as much about
 evas, but pixman is assumed to be a synchronous API, so you must
 always block until the operation completes which looses a lot of the
 potential benefit of a blitter.  And also I think you have no control
 over when the client free()'s a buffer.  So you end up having to
 map/unmap the buffer to the gpu/blitter/whatever every single
 operation.  Not to mention possible need for cache operations, etc.  I
 wonder if trying to accel it in hw really brings any benefit vs just
 using NEON?

Yes, actually, we are using NEON backend of PIXMAN for best performance
also. like this, PIXMAN's NEON backend for small image and 2D GPU backend of
EXA for large image because NEON is faster than 2d gpu for small image but
not for large image.

 I thought EFL has a GLES backend..  I could be wrong about that, but
 if it does probably you'd get better performance by using the GLES
 backend vs trying to accelerate what is intended as a sw path..

Right, EFL has a GLES backend and also PIXMAN for software path. application
using Elementary can use PIXMAN for software path and also GLES for hardware
acceleration. so the purpose of using userptr feature is for buffer drawn by
any user using Evas to be rendered by gpu hardware.

Thanks,
Inki Dae

  and as you

Re: [PATCH 3/4] drm/exynos: added userptr feature.

On Wed, May 16, 2012 at 12:04 AM, Inki Dae inki@samsung.com wrote:

 -Original Message-
 From: robdcl...@gmail.com [mailto:robdcl...@gmail.com] On Behalf Of Rob
 Clark
 Sent: Tuesday, May 15, 2012 11:29 PM
 To: InKi Dae
 Cc: Inki Dae; kyungmin.p...@samsung.com; sw0312@samsung.com; dri-
 de...@lists.freedesktop.org
 Subject: Re: [PATCH 3/4] drm/exynos: added userptr feature.

 On Tue, May 15, 2012 at 7:40 AM, InKi Dae daei...@gmail.com wrote:
  2012/5/15 Rob Clark rob.cl...@linaro.org:
  On Tue, May 15, 2012 at 2:17 AM, Inki Dae inki@samsung.com wrote:
  Hi Rob,

  -Original Message-
  From: robdcl...@gmail.com [mailto:robdcl...@gmail.com] On Behalf Of
 Rob
  Clark
  Sent: Tuesday, May 15, 2012 4:35 PM
  To: Inki Dae
  Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
  kyungmin.p...@samsung.com; sw0312@samsung.com
  Subject: Re: [PATCH 3/4] drm/exynos: added userptr feature.

  On Mon, Apr 23, 2012 at 7:43 AM, Inki Dae inki@samsung.com
 wrote:
   this feature could be used to use memory region allocated by
 malloc() in
  user
   mode and mmaped memory region allocated by other memory allocators.
  userptr
   interface can identify memory type through vm_flags value and would
 get
   pages or page frame numbers to user space appropriately.

  I apologize for being a little late to jump in on this thread, but...

  I must confess to not being a huge fan of userptr.  It really is
  opening a can of worms, and seems best avoided if at all possible.
  I'm not entirely sure the use-case for which you require this, but I
  wonder if there isn't an alternative way?   I mean, the main case I
  could think of for mapping userspace memory would be something like
  texture upload.  But could that be handled in an alternative way,
  something like a pwrite or texture_upload API, which could
 temporarily
  pin the userspace memory, kick off a dma from that user buffer to a
  proper GEM buffer, and then unpin the user buffer when the DMA
  completes?

  This feature have being discussed with drm and linux-mm guys and I
 have
  posted this patch four times.
  So please, see below e-mail threads.
  http://www.spinics.net/lists/dri-devel/msg22729.html

  and then please, give me your opinions.

  Yeah, I read that and understand that the purpose is to support
  malloc()'d memory (and btw, all the other changes like limits to the
  amount of userptr buffers are good if we do decide to support userptr
  buffers).  But my question was more about why do you need to support
  malloc'd buffers... other than just because v4l2 does ;-)

  I don't really like the userptr feature in v4l2 either, and view it as
  a necessary evil because at the time there was nothing like dmabuf.
  But now that we have dmabuf to share buffers with zero copy between
  two devices, to we *really* still need userptr?

  Definitely no, as I mentioned on this email thread, we are using the
  userptr feature for pixman and evas
  backend to use gpu acceleration directly(zero-copy). as you may know,
  Evas is part of the Enlightenment Foundation Libraries(EFL) and
  Elementary for pixman. all the applicaions based on them uses user
  address to draw something so the backends(such as gpu accelerators)
  can refer to only the user address to the buffer rendered. do you
  think we can avoid memory copy to use those GPUs without such userptr
  feature? I think there is no way and only the way that the gpu uses
  the user address to render without memory copy. and as mentioned on
  this thread, this feature had been tried by i915 in the desktop world.
  for this, you can refer to Daniel's comments.

 oh, yeah, for something like pixman it is hard to accelerate.  But I
 wonder if there is still some benefit.  I don't know as much about
 evas, but pixman is assumed to be a synchronous API, so you must
 always block until the operation completes which looses a lot of the
 potential benefit of a blitter.  And also I think you have no control
 over when the client free()'s a buffer.  So you end up having to
 map/unmap the buffer to the gpu/blitter/whatever every single
 operation.  Not to mention possible need for cache operations, etc.  I
 wonder if trying to accel it in hw really brings any benefit vs just
 using NEON?

 Yes, actually, we are using NEON backend of PIXMAN for best performance
 also. like this, PIXMAN's NEON backend for small image and 2D GPU backend of
 EXA for large image because NEON is faster than 2d gpu for small image but
 not for large image.

 I thought EFL has a GLES backend..  I could be wrong about that, but
 if it does probably you'd get better performance by using the GLES
 backend vs trying to accelerate what is intended as a sw path..

 Right, EFL has a GLES backend and also PIXMAN for software path. application
 using Elementary can use PIXMAN for software path and also GLES for hardware
 acceleration. so the purpose of using userptr feature is for buffer drawn by
 any user

RE: [PATCH 2/2 v4] drm/exynos: added userptr feature.

 -Original Message-
 From: Jerome Glisse [mailto:j.gli...@gmail.com]
 Sent: Tuesday, May 15, 2012 11:31 PM
 To: Inki Dae
 Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org; linux...@kvack.org;
 minc...@kernel.org; kosaki.motoh...@gmail.com; kyungmin.p...@samsung.com;
 sw0312@samsung.com; jy0922.s...@samsung.com
 Subject: Re: [PATCH 2/2 v4] drm/exynos: added userptr feature.

 On Tue, May 15, 2012 at 12:33 AM, Inki Dae inki@samsung.com wrote:
  Hi Jerome,

  -Original Message-
  From: Jerome Glisse [mailto:j.gli...@gmail.com]
  Sent: Tuesday, May 15, 2012 4:27 AM
  To: Inki Dae
  Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
 minc...@kernel.org;
  kosaki.motoh...@gmail.com; kyungmin.p...@samsung.com;
  sw0312@samsung.com; jy0922.s...@samsung.com
  Subject: Re: [PATCH 2/2 v4] drm/exynos: added userptr feature.

  On Mon, May 14, 2012 at 2:17 AM, Inki Dae inki@samsung.com wrote:
   this feature is used to import user space region allocated by
malloc()
  or
   mmaped into a gem. for this, we uses get_user_pages() to get all the
  pages
   to VMAs within user address space. However we should pay attention to
  use
   this userptr feature like below.

   The migration issue.
   - Pages reserved by CMA for some device using DMA could be used by
   kernel and if the device driver wants to use those pages
   while being used by kernel then the pages are copied into
   other ones allocated to migrate them and then finally,
   the device driver can use the pages for itself.
   Thus, migrated, the pages being accessed by DMA could be changed
   to other so this situation may incur that DMA accesses any pages
   it doesn't want.

   The COW issue.
   - while DMA of a device is using the pages to VMAs, if current
   process was forked then the pages being accessed by the DMA
   would be copied into child's pages.(Copy On Write) so
   these pages may not have coherrency with parent's ones if
   child process wrote something on those pages so we need to
   flag VM_DONTCOPY to prevent pages from being COWed.

  Note that this is a massive change in behavior of anonymous mapping
  this effectively completely change the linux API from application
  point of view on your platform. Any application that have memory
  mapped by your ioctl will have different fork behavior that other
  application. I think this should be stressed, it's one of the thing i
  am really uncomfortable with i would rather not have the dont copy
  flag and have the page cowed and have the child not working with the
  3d/2d/drm driver. That would means that your driver (opengl
  implementation for instance) would have to detect fork and work around
  it, nvidia closed source driver do that.

  First of all, thank you for your comments.

  Right, VM_DONTCOPY flag would change original behavior of user. Do you
 think
  this way has no problem but no generic way? anyway our issue was that
 the
  pages to VMAs are copied into child's ones(COW) so we prevented those
 pages
  from being COWed with using VM_DONTCOPY flag.

  For this, I have three questions below

  1. in case of not using VM_DONTCOPY flag, you think that the application
  using our userptr feature has COW issue; parent's pages being accessed
 by
  DMA of some device would be copied into child's ones if the child wrote
  something on the pages. after that, DMA of a device could access pages
 user
  doesn't want. I'm not sure but I think such behavior has no any problem
 and
  is generic behavior and it's role of user to do fork or not. Do you
 think
  such COW behavior could create any issue I don't aware of so we have to
  prevent that somehow?

 My point is the father will keep the page that the GPU know about as
 long as the father dont destroy the associated object. But if the
 child expect to be able to use the same GPU object and still be able
 to change the content through its anonymous mapping than i would
 consider this behavior buggy (ie application have wrong expectation).
 So i am all for only the father is able to keep its memory mapped into
 GPU address space through same GEM object.

  2. so we added VM_DONTCOPY flag to prevent the pages from being COWed
 but
  this changes original behavior of user. Do you think this is not generic
 way
  or could create any issue also?

 I would say don't add the flag and consider application that do fork
 as special case in userspace. See below for how i would handle it.

  3. and last one, what is the difference between to flag VM_DONTCOPY and
 to
  detect fork? I mean the device driver should do something to need after
  detecting fork. and I'm not sure but I think the something may also
 change
  original behavior of user.

  Please let me know if there is my missing point.

 I would detect fork by storing process id along gem object. So
 something like (userspace code that could be in your pixman library):

 struct gpu_object_process {
   struct list list;
   uint32_t

[PATCH 0/2] Some additional drm properties patches

From: Rob Clark r...@ti.com

These patches apply on top of Paulo's patches to add support for generic
KMS object properties, and add support for plane properties, and a new
property type suitable for flags/bitmasks.

Rob Clark (2):
  drm: add bitmask property type
  drm: add plane properties

 drivers/gpu/drm/drm_crtc.c |   65 ++--
 include/drm/drm_crtc.h |8 ++
 include/drm/drm_mode.h |1 +
 3 files changed, 71 insertions(+), 3 deletions(-)

-- 
1.7.9.5

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

[PATCH 1/2] drm: add bitmask property type

From: Rob Clark r...@ti.com

A bitmask property is similar to an enum.  The enum value is a bit
position (0-63), and valid property values consist of a mask of
zero or more of (1  enum_val[n]).

Signed-off-by: Rob Clark r...@ti.com
---
 drivers/gpu/drm/drm_crtc.c |   46 +---
 include/drm/drm_crtc.h |3 +++
 include/drm/drm_mode.h |1 +
 3 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 75661c8..022873e 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2707,6 +2707,33 @@ struct drm_property *drm_property_create_enum(struct 
drm_device *dev, int flags,
 }
 EXPORT_SYMBOL(drm_property_create_enum);
 
+struct drm_property *drm_property_create_bitmask(struct drm_device *dev,
+int flags, const char *name,
+const struct drm_prop_enum_list 
*props, int num_values)
+{
+   struct drm_property *property;
+   int i, ret;
+
+   flags |= DRM_MODE_PROP_BITMASK;
+
+   property = drm_property_create(dev, flags, name, num_values);
+   if (!property)
+   return NULL;
+
+   for (i = 0; i  num_values; i++) {
+   ret = drm_property_add_enum(property, i,
+ props[i].type,
+ props[i].name);
+   if (ret) {
+   drm_property_destroy(dev, property);
+   return NULL;
+   }
+   }
+
+   return property;
+}
+EXPORT_SYMBOL(drm_property_create_bitmask);
+
 struct drm_property *drm_property_create_range(struct drm_device *dev, int 
flags,
 const char *name,
 uint64_t min, uint64_t max)
@@ -2731,7 +2758,14 @@ int drm_property_add_enum(struct drm_property *property, 
int index,
 {
struct drm_property_enum *prop_enum;
 
-   if (!(property-flags  DRM_MODE_PROP_ENUM))
+   if (!(property-flags  (DRM_MODE_PROP_ENUM | DRM_MODE_PROP_BITMASK)))
+   return -EINVAL;
+
+   /*
+* Bitmask enum properties have the additional constraint of values
+* from 0 to 63
+*/
+   if ((property-flags  DRM_MODE_PROP_BITMASK)  (value  63))
return -EINVAL;
 
if (!list_empty(property-enum_blob_list)) {
@@ -2875,7 +2909,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
}
property = obj_to_property(obj);
 
-   if (property-flags  DRM_MODE_PROP_ENUM) {
+   if (property-flags  (DRM_MODE_PROP_ENUM | DRM_MODE_PROP_BITMASK)) {
list_for_each_entry(prop_enum, property-enum_blob_list, head)
enum_count++;
} else if (property-flags  DRM_MODE_PROP_BLOB) {
@@ -2900,7 +2934,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
}
out_resp-count_values = value_count;
 
-   if (property-flags  DRM_MODE_PROP_ENUM) {
+   if (property-flags  (DRM_MODE_PROP_ENUM | DRM_MODE_PROP_BITMASK)) {
if ((out_resp-count_enum_blobs = enum_count)  enum_count) {
copied = 0;
enum_ptr = (struct drm_mode_property_enum __user 
*)(unsigned long)out_resp-enum_blob_ptr;
@@ -3055,6 +3089,12 @@ static bool drm_property_change_is_valid(struct 
drm_property *property,
if (value  property-values[0] || value  property-values[1])
return false;
return true;
+   } else if (property-flags  DRM_MODE_PROP_BITMASK) {
+   int i;
+   __u64 valid_mask = 0;
+   for (i = 0; i  property-num_values; i++)
+   valid_mask |= (1LL  property-values[i]);
+   return !(value  ~valid_mask);
} else {
int i;
for (i = 0; i  property-num_values; i++)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index e194c78..39e3e1c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -940,6 +940,9 @@ extern struct drm_property *drm_property_create_enum(struct 
drm_device *dev, int
 const char *name,
 const struct drm_prop_enum_list *props,
 int num_values);
+struct drm_property *drm_property_create_bitmask(struct drm_device *dev,
+int flags, const char *name,
+const struct drm_prop_enum_list 
*props, int num_values);
 struct drm_property *drm_property_create_range(struct drm_device *dev, int 
flags,
 const char *name,
 uint64_t min, uint64_t max);
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index 326f2be..5581980 100644

[PATCH 2/2] drm: add plane properties

From: Rob Clark r...@ti.com

The omapdrm driver uses this for setting per-overlay rotation.  It
is likely also useful for setting YUV-RGB colorspace conversion
matrix, etc.

Signed-off-by: Rob Clark r...@ti.com
---
 drivers/gpu/drm/drm_crtc.c |   19 +++
 include/drm/drm_crtc.h |5 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 022873e..a9b2b497 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -606,6 +606,7 @@ int drm_plane_init(struct drm_device *dev, struct drm_plane 
*plane,
if (ret)
goto out;
 
+   plane-base.properties = plane-properties;
plane-dev = dev;
plane-funcs = funcs;
plane-format_types = kmalloc(sizeof(uint32_t) * format_count,
@@ -3155,6 +3156,21 @@ static int drm_mode_crtc_set_obj_prop(struct 
drm_mode_object *obj,
return ret;
 }
 
+static int drm_mode_plane_set_obj_prop(struct drm_mode_object *obj,
+ 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);
+   if (!ret)
+   drm_object_property_set_value(obj, property, value);
+
+   return ret;
+}
+
 int drm_mode_obj_get_properties_ioctl(struct drm_device *dev, void *data,
  struct drm_file *file_priv)
 {
@@ -3256,6 +3272,9 @@ int drm_mode_obj_set_property_ioctl(struct drm_device 
*dev, void *data,
case DRM_MODE_OBJECT_CRTC:
ret = drm_mode_crtc_set_obj_prop(arg_obj, property, arg-value);
break;
+   case DRM_MODE_OBJECT_PLANE:
+   ret = drm_mode_plane_set_obj_prop(arg_obj, property, 
arg-value);
+   break;
}
 
 out:
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 39e3e1c..c23789c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -618,6 +618,9 @@ struct drm_plane_funcs {
uint32_t src_w, uint32_t src_h);
int (*disable_plane)(struct drm_plane *plane);
void (*destroy)(struct drm_plane *plane);
+
+   int (*set_property)(struct drm_plane *plane,
+   struct drm_property *property, uint64_t val);
 };
 
 /**
@@ -657,6 +660,8 @@ struct drm_plane {
 
const struct drm_plane_funcs *funcs;
void *helper_private;
+
+   struct drm_object_properties properties;
 };
 
 /**
-- 
1.7.9.5

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

[PATCH libdrm 0/3] Additional drm properties patches

From: Rob Clark r...@ti.com

Additional drm properties support, the libdrm part.  These apply on top
of Paulo's libdrm properties patches, and add support for bitmask
properties, and additional support in modetest.

Rob Clark (3):
  Add support for bitmask properties
  modetest: support bitmask properties
  modetest: support plane properties

 include/drm/drm_mode.h|1 +
 tests/modetest/modetest.c |   22 ++
 xf86drmMode.c |4 ++--
 3 files changed, 25 insertions(+), 2 deletions(-)

-- 
1.7.9.5

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

[PATCH libdrm 1/3] Add support for bitmask properties

From: Rob Clark r...@ti.com

A bitmask property is similar to an enum.  The enum value is a bit
position (0-63), and valid property values consist of a mask of
zero or more of (1  enum_val[n]).

Signed-off-by: Rob Clark r...@ti.com
---
 include/drm/drm_mode.h |1 +
 xf86drmMode.c  |4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index f303d94..62ba997 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -226,6 +226,7 @@ struct drm_mode_get_connector {
 #define DRM_MODE_PROP_IMMUTABLE(12)
 #define DRM_MODE_PROP_ENUM (13) /* enumerated type with text strings */
 #define DRM_MODE_PROP_BLOB (14)
+#define DRM_MODE_PROP_BITMASK  (15) /* bitmask of enumerated types */
 
 struct drm_mode_property_enum {
__u64 value;
diff --git a/xf86drmMode.c b/xf86drmMode.c
index a60c7cb..04fdf1f 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -575,7 +575,7 @@ drmModePropertyPtr drmModeGetProperty(int fd, uint32_t 
property_id)
if (prop.count_values)
prop.values_ptr = VOID2U64(drmMalloc(prop.count_values * 
sizeof(uint64_t)));
 
-   if (prop.count_enum_blobs  (prop.flags  DRM_MODE_PROP_ENUM))
+   if (prop.count_enum_blobs  (prop.flags  (DRM_MODE_PROP_ENUM | 
DRM_MODE_PROP_BITMASK)))
prop.enum_blob_ptr = VOID2U64(drmMalloc(prop.count_enum_blobs * 
sizeof(struct drm_mode_property_enum)));
 
if (prop.count_enum_blobs  (prop.flags  DRM_MODE_PROP_BLOB)) {
@@ -597,7 +597,7 @@ drmModePropertyPtr drmModeGetProperty(int fd, uint32_t 
property_id)
r-flags = prop.flags;
if (prop.count_values)
r-values = drmAllocCpy(U642VOID(prop.values_ptr), 
prop.count_values, sizeof(uint64_t));
-   if (prop.flags  DRM_MODE_PROP_ENUM) {
+   if (prop.flags  (DRM_MODE_PROP_ENUM | DRM_MODE_PROP_BITMASK)) {
r-count_enums = prop.count_enum_blobs;
r-enums = drmAllocCpy(U642VOID(prop.enum_blob_ptr), 
prop.count_enum_blobs, sizeof(struct drm_mode_property_enum));
} else if (prop.flags  DRM_MODE_PROP_BLOB) {
-- 
1.7.9.5

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

[PATCH libdrm 2/3] modetest: support bitmask properties

From: Rob Clark r...@ti.com

Add support to display bitmask properties.

Signed-off-by: Rob Clark r...@ti.com
---
 tests/modetest/modetest.c |8 
 1 file changed, 8 insertions(+)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index ce57e65..dea271a 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -207,6 +207,8 @@ dump_prop(uint32_t prop_id, uint64_t value)
printf( immutable);
if (prop-flags  DRM_MODE_PROP_ENUM)
printf( enum);
+   if (prop-flags  DRM_MODE_PROP_BITMASK)
+   printf( bitmask);
if (prop-flags  DRM_MODE_PROP_BLOB)
printf( blob);
printf(\n);
@@ -224,6 +226,12 @@ dump_prop(uint32_t prop_id, uint64_t value)
printf( %s=%llu, prop-enums[i].name,
   prop-enums[i].value);
printf(\n);
+   } else if (prop-flags  DRM_MODE_PROP_BITMASK) {
+   printf(\t\tvalues:);
+   for (i = 0; i  prop-count_enums; i++)
+   printf( %s=0x%llx, prop-enums[i].name,
+  (1LL  prop-enums[i].value));
+   printf(\n);
} else {
assert(prop-count_enums == 0);
}
-- 
1.7.9.5

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

[PATCH libdrm 3/3] modetest: support plane properties

From: Rob Clark r...@ti.com

Add support to display plane properties.

Signed-off-by: Rob Clark r...@ti.com
---
 tests/modetest/modetest.c |   14 ++
 1 file changed, 14 insertions(+)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index dea271a..dc84cf3 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -369,6 +369,7 @@ void dump_framebuffers(void)
 
 static void dump_planes(void)
 {
+   drmModeObjectPropertiesPtr props;
drmModePlaneRes *plane_resources;
drmModePlane *ovr;
unsigned int i, j;
@@ -403,6 +404,19 @@ static void dump_planes(void)
printf( %4.4s, (char *)ovr-formats[j]);
printf(\n);
 
+   printf(  props:\n);
+   props = drmModeObjectGetProperties(fd, ovr-plane_id,
+  DRM_MODE_OBJECT_PLANE);
+   if (props) {
+   for (j = 0; j  props-count_props; j++)
+   dump_prop(props-props[j],
+ props-prop_values[j]);
+   drmModeFreeObjectProperties(props);
+   } else {
+   printf(\tcould not get plane properties: %s\n,
+  strerror(errno));
+   }
+
drmModeFreePlane(ovr);
}
printf(\n);
-- 
1.7.9.5

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

Re: [PATCH 3/4] drm/exynos: added userptr feature.

2012-05-16 Thread Dave Airlie

On Tue, May 15, 2012 at 8:34 AM, Rob Clark rob.cl...@linaro.org wrote:
 On Mon, Apr 23, 2012 at 7:43 AM, Inki Dae inki@samsung.com wrote:
 this feature could be used to use memory region allocated by malloc() in user
 mode and mmaped memory region allocated by other memory allocators. userptr
 interface can identify memory type through vm_flags value and would get
 pages or page frame numbers to user space appropriately.

 I apologize for being a little late to jump in on this thread, but...

 I must confess to not being a huge fan of userptr.  It really is
 opening a can of worms, and seems best avoided if at all possible.
 I'm not entirely sure the use-case for which you require this, but I
 wonder if there isn't an alternative way?   I mean, the main case I
 could think of for mapping userspace memory would be something like
 texture upload.  But could that be handled in an alternative way,
 something like a pwrite or texture_upload API, which could temporarily
 pin the userspace memory, kick off a dma from that user buffer to a
 proper GEM buffer, and then unpin the user buffer when the DMA
 completes?

I'm with Rob on this, I really hate the userptr idea, and my problem
with letting it into exynos is it sets a benchmark for others to do
things the same way. I'm still not 100% sure how its going to be used
even with all your explainations.

Since we've agreed only the X server can access the interface, it
makes 0 sense to me to exist at all, as the X server can avoid malloc
memory for all objects it accesses.

I don't think pixman is at the level where you should be acceleration
it directly. I thought the point of pixman was a fast SW engine, not
something to be trunked down to a hw engine. The idea being you use
cairo and backend it onto something.

I know ssp had some ideas for making pixman be able to do hw accel,
but userptr doesn't seem like the proper solution, it seems like a
hack that needs a lot more VM work to operate properly, and by setting
a precedent for one GPU driver, I'll have 20 implementations of this
from ARM vendors and nobody will ever go back and fix things properly.

So I'm really not sure the best way to move this forward, maybe a very
clear set of use cases of where stuff plugs into this, and why dma-buf
or some other method isn't sufficient, but I'm having trouble getting
past the fact its setting a dangerous precedent.

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

RE: [PATCH 3/4] drm/exynos: added userptr feature.

 -Original Message-
 From: Dave Airlie [mailto:airl...@gmail.com]
 Sent: Wednesday, May 16, 2012 6:23 PM
 To: Rob Clark
 Cc: Inki Dae; kyungmin.p...@samsung.com; sw0312@samsung.com; dri-
 de...@lists.freedesktop.org
 Subject: Re: [PATCH 3/4] drm/exynos: added userptr feature.

 On Tue, May 15, 2012 at 8:34 AM, Rob Clark rob.cl...@linaro.org wrote:
  On Mon, Apr 23, 2012 at 7:43 AM, Inki Dae inki@samsung.com wrote:
  this feature could be used to use memory region allocated by malloc()
 in user
  mode and mmaped memory region allocated by other memory allocators.
 userptr
  interface can identify memory type through vm_flags value and would get
  pages or page frame numbers to user space appropriately.

  I apologize for being a little late to jump in on this thread, but...

  I must confess to not being a huge fan of userptr.  It really is
  opening a can of worms, and seems best avoided if at all possible.
  I'm not entirely sure the use-case for which you require this, but I
  wonder if there isn't an alternative way?   I mean, the main case I
  could think of for mapping userspace memory would be something like
  texture upload.  But could that be handled in an alternative way,
  something like a pwrite or texture_upload API, which could temporarily
  pin the userspace memory, kick off a dma from that user buffer to a
  proper GEM buffer, and then unpin the user buffer when the DMA
  completes?

 I'm with Rob on this, I really hate the userptr idea, and my problem
 with letting it into exynos is it sets a benchmark for others to do
 things the same way. I'm still not 100% sure how its going to be used
 even with all your explainations.

 Since we've agreed only the X server can access the interface, it
 makes 0 sense to me to exist at all, as the X server can avoid malloc
 memory for all objects it accesses.

 I don't think pixman is at the level where you should be acceleration
 it directly. I thought the point of pixman was a fast SW engine, not
 something to be trunked down to a hw engine. The idea being you use
 cairo and backend it onto something.

For more understanding, PIXMAN draws something on shmem and next id of the
shmem is sent to X and next X gets user address to the id and next EXA's gpu
backend does BitBLT using gpu hardware. However, the gpu backend doesn't
aware of the user address so the purpose of using userptr is to import the
shmem into a gem object for gpu to aware of the memory region as source. so
pixman would use SW engine as is.

 I know ssp had some ideas for making pixman be able to do hw accel,
 but userptr doesn't seem like the proper solution, it seems like a
 hack that needs a lot more VM work to operate properly, and by setting
 a precedent for one GPU driver, I'll have 20 implementations of this
 from ARM vendors and nobody will ever go back and fix things properly.

I'm not sure that this is a hack or not but thing similar to this is being
used at via driver. you can refer to via_lock_all_dma_pages function of
via_dmablit.c file and this driver also uses get_user_pages() to lock all
the pages to the user space for DMA to access the memory region, maybe for
BitBLT. And I really wonder you think just using get_user_pages() is a hack
or importing user address into a gem object. there may be my
misunderstanding so give me any comments.

Thanks,
Inki Dae

 So I'm really not sure the best way to move this forward, maybe a very
 clear set of use cases of where stuff plugs into this, and why dma-buf
 or some other method isn't sufficient, but I'm having trouble getting
 past the fact its setting a dangerous precedent.

 Dave.

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

RE: [PATCH 3/4] drm/exynos: added userptr feature.

 -Original Message-
 From: robdcl...@gmail.com [mailto:robdcl...@gmail.com] On Behalf Of Rob
 Clark
 Sent: Wednesday, May 16, 2012 5:43 PM
 To: Inki Dae
 Cc: InKi Dae; kyungmin.p...@samsung.com; sw0312@samsung.com; dri-
 de...@lists.freedesktop.org
 Subject: Re: [PATCH 3/4] drm/exynos: added userptr feature.

 On Wed, May 16, 2012 at 12:04 AM, Inki Dae inki@samsung.com wrote:

  -Original Message-
  From: robdcl...@gmail.com [mailto:robdcl...@gmail.com] On Behalf Of Rob
  Clark
  Sent: Tuesday, May 15, 2012 11:29 PM
  To: InKi Dae
  Cc: Inki Dae; kyungmin.p...@samsung.com; sw0312@samsung.com; dri-
  de...@lists.freedesktop.org
  Subject: Re: [PATCH 3/4] drm/exynos: added userptr feature.

  On Tue, May 15, 2012 at 7:40 AM, InKi Dae daei...@gmail.com wrote:
   2012/5/15 Rob Clark rob.cl...@linaro.org:
   On Tue, May 15, 2012 at 2:17 AM, Inki Dae inki@samsung.com
 wrote:
   Hi Rob,

   -Original Message-
   From: robdcl...@gmail.com [mailto:robdcl...@gmail.com] On Behalf
 Of
  Rob
   Clark
   Sent: Tuesday, May 15, 2012 4:35 PM
   To: Inki Dae
   Cc: airl...@linux.ie; dri-devel@lists.freedesktop.org;
   kyungmin.p...@samsung.com; sw0312@samsung.com
   Subject: Re: [PATCH 3/4] drm/exynos: added userptr feature.

   On Mon, Apr 23, 2012 at 7:43 AM, Inki Dae inki@samsung.com
  wrote:
this feature could be used to use memory region allocated by
  malloc() in
   user
mode and mmaped memory region allocated by other memory
 allocators.
   userptr
interface can identify memory type through vm_flags value and
 would
  get
pages or page frame numbers to user space appropriately.

   I apologize for being a little late to jump in on this thread,
 but...

   I must confess to not being a huge fan of userptr.  It really is
   opening a can of worms, and seems best avoided if at all possible.
   I'm not entirely sure the use-case for which you require this, but
 I
   wonder if there isn't an alternative way?   I mean, the main case
 I
   could think of for mapping userspace memory would be something
 like
   texture upload.  But could that be handled in an alternative way,
   something like a pwrite or texture_upload API, which could
  temporarily
   pin the userspace memory, kick off a dma from that user buffer to
 a
   proper GEM buffer, and then unpin the user buffer when the DMA
   completes?

   This feature have being discussed with drm and linux-mm guys and I
  have
   posted this patch four times.
   So please, see below e-mail threads.
   http://www.spinics.net/lists/dri-devel/msg22729.html

   and then please, give me your opinions.

   Yeah, I read that and understand that the purpose is to support
   malloc()'d memory (and btw, all the other changes like limits to the
   amount of userptr buffers are good if we do decide to support
 userptr
   buffers).  But my question was more about why do you need to support
   malloc'd buffers... other than just because v4l2 does ;-)

   I don't really like the userptr feature in v4l2 either, and view it
 as
   a necessary evil because at the time there was nothing like dmabuf.
   But now that we have dmabuf to share buffers with zero copy between
   two devices, to we *really* still need userptr?

   Definitely no, as I mentioned on this email thread, we are using the
   userptr feature for pixman and evas
   backend to use gpu acceleration directly(zero-copy). as you may know,
   Evas is part of the Enlightenment Foundation Libraries(EFL) and
   Elementary for pixman. all the applicaions based on them uses user
   address to draw something so the backends(such as gpu accelerators)
   can refer to only the user address to the buffer rendered. do you
   think we can avoid memory copy to use those GPUs without such userptr
   feature? I think there is no way and only the way that the gpu uses
   the user address to render without memory copy. and as mentioned on
   this thread, this feature had been tried by i915 in the desktop
world.
   for this, you can refer to Daniel's comments.

  oh, yeah, for something like pixman it is hard to accelerate.  But I
  wonder if there is still some benefit.  I don't know as much about
  evas, but pixman is assumed to be a synchronous API, so you must
  always block until the operation completes which looses a lot of the
  potential benefit of a blitter.  And also I think you have no control
  over when the client free()'s a buffer.  So you end up having to
  map/unmap the buffer to the gpu/blitter/whatever every single
  operation.  Not to mention possible need for cache operations, etc.  I
  wonder if trying to accel it in hw really brings any benefit vs just
  using NEON?

  Yes, actually, we are using NEON backend of PIXMAN for best performance
  also. like this, PIXMAN's NEON backend for small image and 2D GPU
 backend of
  EXA for large image because NEON is faster than 2d gpu for small image
 but
  not for large image.

  I

Re: [PATCH 3/4] drm/exynos: added userptr feature.

On Wed, May 16, 2012 at 4:20 AM, Inki Dae inki@samsung.com wrote:

 -Original Message-
 From: Dave Airlie [mailto:airl...@gmail.com]
 Sent: Wednesday, May 16, 2012 6:23 PM
 To: Rob Clark
 Cc: Inki Dae; kyungmin.p...@samsung.com; sw0312@samsung.com; dri-
 de...@lists.freedesktop.org
 Subject: Re: [PATCH 3/4] drm/exynos: added userptr feature.

 On Tue, May 15, 2012 at 8:34 AM, Rob Clark rob.cl...@linaro.org wrote:
  On Mon, Apr 23, 2012 at 7:43 AM, Inki Dae inki@samsung.com wrote:
  this feature could be used to use memory region allocated by malloc()
 in user
  mode and mmaped memory region allocated by other memory allocators.
 userptr
  interface can identify memory type through vm_flags value and would get
  pages or page frame numbers to user space appropriately.

  I apologize for being a little late to jump in on this thread, but...

  I must confess to not being a huge fan of userptr.  It really is
  opening a can of worms, and seems best avoided if at all possible.
  I'm not entirely sure the use-case for which you require this, but I
  wonder if there isn't an alternative way?   I mean, the main case I
  could think of for mapping userspace memory would be something like
  texture upload.  But could that be handled in an alternative way,
  something like a pwrite or texture_upload API, which could temporarily
  pin the userspace memory, kick off a dma from that user buffer to a
  proper GEM buffer, and then unpin the user buffer when the DMA
  completes?

 I'm with Rob on this, I really hate the userptr idea, and my problem
 with letting it into exynos is it sets a benchmark for others to do
 things the same way. I'm still not 100% sure how its going to be used
 even with all your explainations.

 Since we've agreed only the X server can access the interface, it
 makes 0 sense to me to exist at all, as the X server can avoid malloc
 memory for all objects it accesses.

 I don't think pixman is at the level where you should be acceleration
 it directly. I thought the point of pixman was a fast SW engine, not
 something to be trunked down to a hw engine. The idea being you use
 cairo and backend it onto something.

 For more understanding, PIXMAN draws something on shmem and next id of the
 shmem is sent to X and next X gets user address to the id and next EXA's gpu
 backend does BitBLT using gpu hardware. However, the gpu backend doesn't
 aware of the user address so the purpose of using userptr is to import the
 shmem into a gem object for gpu to aware of the memory region as source. so
 pixman would use SW engine as is.

if this is all just for X/EXA, wouldn't it make more sense to handle
the operation at the EXA layer before falling back to sw (which would
go to pixman)?

 I know ssp had some ideas for making pixman be able to do hw accel,
 but userptr doesn't seem like the proper solution, it seems like a
 hack that needs a lot more VM work to operate properly, and by setting
 a precedent for one GPU driver, I'll have 20 implementations of this
 from ARM vendors and nobody will ever go back and fix things properly.

 I'm not sure that this is a hack or not but thing similar to this is being
 used at via driver. you can refer to via_lock_all_dma_pages function of
 via_dmablit.c file and this driver also uses get_user_pages() to lock all
 the pages to the user space for DMA to access the memory region, maybe for
 BitBLT. And I really wonder you think just using get_user_pages() is a hack
 or importing user address into a gem object. there may be my
 misunderstanding so give me any comments.

My objection is not really the get_user_pages(), but rather converting
that into a GEM object, which might exist for longer period of time,
be exported to dmabuf and passed to other driver, etc.  (Not to
mention you don't really have control if userspace does free(ptr)
while the GEM object still exists..)

From a quick look at the via code, it appears to return while the blit
is still queued, which I don't completely like but at least the
pinning and hw use of the userspace buffer is just temporary and not
able to exist for an indefinite amount of time.

BR,
-R

 Thanks,
 Inki Dae

 So I'm really not sure the best way to move this forward, maybe a very
 clear set of use cases of where stuff plugs into this, and why dma-buf
 or some other method isn't sufficient, but I'm having trouble getting
 past the fact its setting a dangerous precedent.

 Dave.

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

RE: [PATCH 3/4] drm/exynos: added userptr feature.

 -Original Message-
 From: robdcl...@gmail.com [mailto:robdcl...@gmail.com] On Behalf Of Rob
 Clark
 Sent: Wednesday, May 16, 2012 9:13 PM
 To: Inki Dae
 Cc: Dave Airlie; kyungmin.p...@samsung.com; sw0312@samsung.com; dri-
 de...@lists.freedesktop.org
 Subject: Re: [PATCH 3/4] drm/exynos: added userptr feature.

 On Wed, May 16, 2012 at 4:20 AM, Inki Dae inki@samsung.com wrote:

  -Original Message-
  From: Dave Airlie [mailto:airl...@gmail.com]
  Sent: Wednesday, May 16, 2012 6:23 PM
  To: Rob Clark
  Cc: Inki Dae; kyungmin.p...@samsung.com; sw0312@samsung.com; dri-
  de...@lists.freedesktop.org
  Subject: Re: [PATCH 3/4] drm/exynos: added userptr feature.

  On Tue, May 15, 2012 at 8:34 AM, Rob Clark rob.cl...@linaro.org
wrote:
   On Mon, Apr 23, 2012 at 7:43 AM, Inki Dae inki@samsung.com
 wrote:
   this feature could be used to use memory region allocated by
malloc()
  in user
   mode and mmaped memory region allocated by other memory allocators.
  userptr
   interface can identify memory type through vm_flags value and would
 get
   pages or page frame numbers to user space appropriately.

   I apologize for being a little late to jump in on this thread, but...

   I must confess to not being a huge fan of userptr.  It really is
   opening a can of worms, and seems best avoided if at all possible.
   I'm not entirely sure the use-case for which you require this, but I
   wonder if there isn't an alternative way?   I mean, the main case I
   could think of for mapping userspace memory would be something like
   texture upload.  But could that be handled in an alternative way,
   something like a pwrite or texture_upload API, which could
 temporarily
   pin the userspace memory, kick off a dma from that user buffer to a
   proper GEM buffer, and then unpin the user buffer when the DMA
   completes?

  I'm with Rob on this, I really hate the userptr idea, and my problem
  with letting it into exynos is it sets a benchmark for others to do
  things the same way. I'm still not 100% sure how its going to be used
  even with all your explainations.

  Since we've agreed only the X server can access the interface, it
  makes 0 sense to me to exist at all, as the X server can avoid malloc
  memory for all objects it accesses.

  I don't think pixman is at the level where you should be acceleration
  it directly. I thought the point of pixman was a fast SW engine, not
  something to be trunked down to a hw engine. The idea being you use
  cairo and backend it onto something.

  For more understanding, PIXMAN draws something on shmem and next id of
 the
  shmem is sent to X and next X gets user address to the id and next EXA's
 gpu
  backend does BitBLT using gpu hardware. However, the gpu backend doesn't
  aware of the user address so the purpose of using userptr is to import
 the
  shmem into a gem object for gpu to aware of the memory region as source.
 so
  pixman would use SW engine as is.

 if this is all just for X/EXA, wouldn't it make more sense to handle
 the operation at the EXA layer before falling back to sw (which would
 go to pixman)?

Note that PIXMAN is also used as backend of Evas amd the shmem is sent to
EXA backend of X to use gpu.(not same process)

  I know ssp had some ideas for making pixman be able to do hw accel,
  but userptr doesn't seem like the proper solution, it seems like a
  hack that needs a lot more VM work to operate properly, and by setting
  a precedent for one GPU driver, I'll have 20 implementations of this
  from ARM vendors and nobody will ever go back and fix things properly.

  I'm not sure that this is a hack or not but thing similar to this is
 being
  used at via driver. you can refer to via_lock_all_dma_pages function of
  via_dmablit.c file and this driver also uses get_user_pages() to lock
 all
  the pages to the user space for DMA to access the memory region, maybe
 for
  BitBLT. And I really wonder you think just using get_user_pages() is a
 hack
  or importing user address into a gem object. there may be my
  misunderstanding so give me any comments.

 My objection is not really the get_user_pages(), but rather converting
 that into a GEM object, which might exist for longer period of time,
 be exported to dmabuf and passed to other driver, etc.  (Not to
 mention you don't really have control if userspace does free(ptr)
 while the GEM object still exists..)

Hm...Good point. ok, got it. I gonna stop it forward. Instead, we will
follow the via way for next so do you agree that the via way has no any
problem?

Thanks,
Inki Dae

 From a quick look at the via code, it appears to return while the blit
 is still queued, which I don't completely like but at least the
 pinning and hw use of the userspace buffer is just temporary and not
 able to exist for an indefinite amount of time.

 BR,
 -R

  Thanks,
  Inki Dae

  So I'm really not sure the best way to move this forward, maybe a very
  clear set of use

[Bug 49794] HD5850 clocks are always limited to 400/900

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

--- Comment #6 from ddfs 32...@bk.ru 2012-05-16 06:47:41 PDT ---
Any updates on this? Did the attached bios help?

-- 
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] drm: gma500: Kill the GEM glue layer

The private gem_create_mmap_offset() function is now implemented in the
DRM core as drm_gem_create_mmap_offset(). Use it and kill the private
copy.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/gpu/drm/gma500/Makefile   |2 +-
 drivers/gpu/drm/gma500/gem.c  |9 +++-
 drivers/gpu/drm/gma500/gem_glue.c |   90 -
 drivers/gpu/drm/gma500/gem_glue.h |2 -
 drivers/gpu/drm/gma500/psb_drv.h  |1 -
 5 files changed, 8 insertions(+), 96 deletions(-)
 delete mode 100644 drivers/gpu/drm/gma500/gem_glue.c
 delete mode 100644 drivers/gpu/drm/gma500/gem_glue.h

The patch has been compile-tested only due to lack of test hardware.

diff --git a/drivers/gpu/drm/gma500/Makefile b/drivers/gpu/drm/gma500/Makefile
index 1583982..85b7449 100644
--- a/drivers/gpu/drm/gma500/Makefile
+++ b/drivers/gpu/drm/gma500/Makefile
@@ -3,7 +3,7 @@
 #
 ccflags-y += -Iinclude/drm
 
-gma500_gfx-y += gem_glue.o \
+gma500_gfx-y += \
  accel_2d.o \
  backlight.o \
  framebuffer.o \
diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index 9fbb868..f2a2e9b 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -36,7 +36,12 @@ int psb_gem_init_object(struct drm_gem_object *obj)
 void psb_gem_free_object(struct drm_gem_object *obj)
 {
struct gtt_range *gtt = container_of(obj, struct gtt_range, gem);
-   drm_gem_object_release_wrap(obj);
+
+   /* Remove the list map if one is present */
+   if (obj-map_list.map)
+   drm_gem_free_mmap_offset(obj);
+   drm_gem_object_release(obj);
+
/* This must occur last as it frees up the memory of the GEM object */
psb_gtt_free_range(obj-dev, gtt);
 }
@@ -77,7 +82,7 @@ int psb_gem_dumb_map_gtt(struct drm_file *file, struct 
drm_device *dev,
 
/* Make it mmapable */
if (!obj-map_list.map) {
-   ret = gem_create_mmap_offset(obj);
+   ret = drm_gem_create_mmap_offset(obj);
if (ret)
goto out;
}
diff --git a/drivers/gpu/drm/gma500/gem_glue.c 
b/drivers/gpu/drm/gma500/gem_glue.c
deleted file mode 100644
index 3c17634..000
--- a/drivers/gpu/drm/gma500/gem_glue.c
+++ /dev/null
@@ -1,90 +0,0 @@
-/**
- * Copyright (c) 2011, Intel Corporation.
- * All Rights Reserved.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope 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 St - Fifth Floor, Boston, MA 02110-1301 USA.
- *
- **/
-
-#include drm/drmP.h
-#include drm/drm.h
-#include gem_glue.h
-
-void drm_gem_object_release_wrap(struct drm_gem_object *obj)
-{
-   /* Remove the list map if one is present */
-   if (obj-map_list.map) {
-   struct drm_gem_mm *mm = obj-dev-mm_private;
-   struct drm_map_list *list = obj-map_list;
-   drm_ht_remove_item(mm-offset_hash, list-hash);
-   drm_mm_put_block(list-file_offset_node);
-   kfree(list-map);
-   list-map = NULL;
-   }
-   drm_gem_object_release(obj);
-}
-
-/**
- * gem_create_mmap_offset  -   invent an mmap offset
- * @obj: our object
- *
- * Standard implementation of offset generation for mmap as is
- * duplicated in several drivers. This belongs in GEM.
- */
-int gem_create_mmap_offset(struct drm_gem_object *obj)
-{
-   struct drm_device *dev = obj-dev;
-   struct drm_gem_mm *mm = dev-mm_private;
-   struct drm_map_list *list;
-   struct drm_local_map *map;
-   int ret;
-
-   list = obj-map_list;
-   list-map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
-   if (list-map == NULL)
-   return -ENOMEM;
-   map = list-map;
-   map-type = _DRM_GEM;
-   map-size = obj-size;
-   map-handle = obj;
-
-   list-file_offset_node = drm_mm_search_free(mm-offset_manager,
-   obj-size / PAGE_SIZE, 0, 0);
-   if (!list-file_offset_node) {
-   dev_err(dev-dev, failed to allocate offset for bo %d\n,
-   obj-name);
-   ret = -ENOSPC;
-   goto free_it;
-   }
-   list-file_offset_node = drm_mm_get_block(list-file_offset_node,

Re: [PATCH] drm: gma500: Kill the GEM glue layer

2012-05-16 Thread Alan Cox

On Wed, 16 May 2012 16:59:44 +0200
Laurent Pinchart laurent.pinch...@ideasonboard.com wrote:

 The private gem_create_mmap_offset() function is now implemented in the
 DRM core as drm_gem_create_mmap_offset(). Use it and kill the private
 copy.
 

That was always then plan so yes - I'll fold this into my tree and test
it.

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

[PATCH 0/4] Miscellaneous Exynos DRM patches

Hello,

While studying the DRM core I came across a couple of issues or strange
constructs in the Exynos DRM driver. Here are 4 patches that fix them.

The patches have only been compile-tested for lack of testing hardware. I
apologize in advance if my lack of experience with the DRM subsystem resulted
in any wrong patch.

Laurent Pinchart (4):
  drm: exynos: DRIVER_BUS_PLATFORM is not a driver feature
  drm: exynos: Remove dummy encoder get_crtc operation implementation
  drm: exynos: Don't cast GEM object to Exynos GEM object when not
needed
  drm: exynos: Keep a reference to frame buffer GEM objects

 drivers/gpu/drm/exynos/exynos_drm_drv.c |3 +--
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |7 ---
 drivers/gpu/drm/exynos/exynos_drm_fb.c  |   19 ++-
 drivers/gpu/drm/exynos/exynos_drm_gem.c |9 +++--
 4 files changed, 18 insertions(+), 20 deletions(-)

-- 
Regards,

Laurent Pinchart

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

[PATCH 1/4] drm: exynos: DRIVER_BUS_PLATFORM is not a driver feature

DRIVER_BUS_PLATFORM is a bus type used internally in the DRM core, not a
flag for the drm_driver::driver_features field.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 67a67b0..0080102 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -224,8 +224,7 @@ static const struct file_operations exynos_drm_driver_fops 
= {
 };
 
 static struct drm_driver exynos_drm_driver = {
-   .driver_features= DRIVER_HAVE_IRQ | DRIVER_BUS_PLATFORM |
- DRIVER_MODESET | DRIVER_GEM,
+   .driver_features= DRIVER_HAVE_IRQ | DRIVER_MODESET | DRIVER_GEM,
.load   = exynos_drm_load,
.unload = exynos_drm_unload,
.open   = exynos_drm_open,
-- 
1.7.3.4

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

[PATCH 3/4] drm: exynos: Don't cast GEM object to Exynos GEM object when not needed

The exynos_drm_gem_dumb_map_offset() doesn't need to access any
Exynos-specific GEM object fields, don't cast the GEM object.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c |9 +++--
 1 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 1dffa83..a3362c9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -638,7 +638,6 @@ int exynos_drm_gem_dumb_map_offset(struct drm_file 
*file_priv,
   struct drm_device *dev, uint32_t handle,
   uint64_t *offset)
 {
-   struct exynos_drm_gem_obj *exynos_gem_obj;
struct drm_gem_object *obj;
int ret = 0;
 
@@ -659,15 +658,13 @@ int exynos_drm_gem_dumb_map_offset(struct drm_file 
*file_priv,
goto unlock;
}
 
-   exynos_gem_obj = to_exynos_gem_obj(obj);
-
-   if (!exynos_gem_obj-base.map_list.map) {
-   ret = drm_gem_create_mmap_offset(exynos_gem_obj-base);
+   if (!obj-map_list.map) {
+   ret = drm_gem_create_mmap_offset(obj);
if (ret)
goto out;
}
 
-   *offset = (u64)exynos_gem_obj-base.map_list.hash.key  PAGE_SHIFT;
+   *offset = (u64)obj-map_list.hash.key  PAGE_SHIFT;
DRM_DEBUG_KMS(offset = 0x%lx\n, (unsigned long)*offset);
 
 out:
-- 
1.7.3.4

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

[PATCH 2/4] drm: exynos: Remove dummy encoder get_crtc operation implementation

The encoder get_crtc operation is called to retrieve a pointer to the
CRTC the encoder is currenctly connected to, right after setting the
encoder::crtc field to the new CRTC. The implementation of this
operation returns the pointer to the new CRTC, which is then pointlessly
compared to itself.

As the operation is not mandatory, don't implement it.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |7 ---
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 6e9ac7b..23d5ad3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -172,19 +172,12 @@ static void exynos_drm_encoder_commit(struct drm_encoder 
*encoder)
manager_ops-commit(manager-dev);
 }
 
-static struct drm_crtc *
-exynos_drm_encoder_get_crtc(struct drm_encoder *encoder)
-{
-   return encoder-crtc;
-}
-
 static struct drm_encoder_helper_funcs exynos_encoder_helper_funcs = {
.dpms   = exynos_drm_encoder_dpms,
.mode_fixup = exynos_drm_encoder_mode_fixup,
.mode_set   = exynos_drm_encoder_mode_set,
.prepare= exynos_drm_encoder_prepare,
.commit = exynos_drm_encoder_commit,
-   .get_crtc   = exynos_drm_encoder_get_crtc,
 };
 
 static void exynos_drm_encoder_destroy(struct drm_encoder *encoder)
-- 
1.7.3.4

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

[PATCH 4/4] drm: exynos: Keep a reference to frame buffer GEM objects

GEM objects used by frame buffers must be referenced for the whole life
of the frame buffer. Release the references in the frame buffer
destructor instead of its constructor.

Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c |   19 ++-
 1 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index f82a299..4ccfe43 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -51,11 +51,22 @@ struct exynos_drm_fb {
 static void exynos_drm_fb_destroy(struct drm_framebuffer *fb)
 {
struct exynos_drm_fb *exynos_fb = to_exynos_fb(fb);
+   unsigned int i;
 
DRM_DEBUG_KMS(%s\n, __FILE__);
 
drm_framebuffer_cleanup(fb);
 
+   for (i = 0; i  ARRAY_SIZE(exynos_fb-exynos_gem_obj); i++) {
+   struct drm_gem_object *obj;
+
+   if (exynos_fb-exynos_gem_obj[i] == NULL)
+   continue;
+
+   obj = exynos_fb-exynos_gem_obj[i]-base;
+   drm_gem_object_unreference_unlocked(obj);
+   }
+
kfree(exynos_fb);
exynos_fb = NULL;
 }
@@ -134,11 +145,11 @@ exynos_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,
return ERR_PTR(-ENOENT);
}
 
-   drm_gem_object_unreference_unlocked(obj);
-
fb = exynos_drm_framebuffer_init(dev, mode_cmd, obj);
-   if (IS_ERR(fb))
+   if (IS_ERR(fb)) {
+   drm_gem_object_unreference_unlocked(obj);
return fb;
+   }
 
exynos_fb = to_exynos_fb(fb);
nr = exynos_drm_format_num_buffers(fb-pixel_format);
@@ -152,8 +163,6 @@ exynos_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,
return ERR_PTR(-ENOENT);
}
 
-   drm_gem_object_unreference_unlocked(obj);
-
exynos_fb-exynos_gem_obj[i] = to_exynos_gem_obj(obj);
}
 
-- 
1.7.3.4

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

[Bug 49794] HD5850 clocks are always limited to 400/900

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

--- Comment #7 from dr.an...@gmail.com 2012-05-16 08:47:51 PDT ---
Created attachment 61719
  -- https://bugs.freedesktop.org/attachment.cgi?id=61719
Overclocked Radeon HD 5850 BIOS

Same problem here. The only difference is in vendor of videocard and
frequencies(I have HIS Radeon HD 5850 with 850/1200, BIOS attached). System
uses only limited 400/900(30 kHz/90 kHz to be correct).

kernel: 3.3.6
xf86-video-ati: 6.14.4

-- 
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 48747] regression [bisected]: display corruption in google earth/glxgears using git r600g on RS780M

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

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

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #9 from Michel Dänzer mic...@daenzer.net 2012-05-16 09:59:25 PDT 
---
Commit: 11f056a3f0b87e86267efa8b5ac9d36a343c9dc1
Author: Michel Dänzer michel.daen...@amd.com
Date:   Wed May 16 17:45:17 2012 +0200

r600g: Set tiling information for BOs being shared.

-- 
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 50014] New: kwin with desktop effects crashes in r100_cs_track_texture_check on Radeon Mobility M6 LY

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

 Bug #: 50014
   Summary: kwin with desktop effects crashes in
r100_cs_track_texture_check on Radeon Mobility M6 LY
Classification: Unclassified
   Product: Mesa
   Version: 8.0
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: or...@cora.nwra.com


Created attachment 61728
  -- https://bugs.freedesktop.org/attachment.cgi?id=61728
dmesg

Running F17 pre-release:

mesa-dri-drivers-8.0.2-2.fc17.i686
xorg-x11-server-Xorg-1.12.0-5.fc17.i686
kernel-3.3.4-5.fc17.i686

Shortly after login kwin exits and I see the following in dmesg:

[78710.577862] [drm:r100_cs_track_texture_check] *ERROR* Texture of unit 0
needs 273439296 bytes but is 3145728
[78710.577869] [drm:r100_cs_track_texture_print] *ERROR* pitch 
16536
[78710.577873] [drm:r100_cs_track_texture_print] *ERROR* use_pitch 
1
[78710.577876] [drm:r100_cs_track_texture_print] *ERROR* width 
16536
[78710.577879] [drm:r100_cs_track_texture_print] *ERROR* width_11  
2048
[78710.577882] [drm:r100_cs_track_texture_print] *ERROR* height
16536
[78710.577885] [drm:r100_cs_track_texture_print] *ERROR* height_11 
2048
[78710.577888] [drm:r100_cs_track_texture_print] *ERROR* num levels
0
[78710.577891] [drm:r100_cs_track_texture_print] *ERROR* depth 
0
[78710.577894] [drm:r100_cs_track_texture_print] *ERROR* bpp   
4
[78710.577897] [drm:r100_cs_track_texture_print] *ERROR* coordinate type   
0
[78710.577900] [drm:r100_cs_track_texture_print] *ERROR* width round to power
of 2  0
[78710.577903] [drm:r100_cs_track_texture_print] *ERROR* height round to power
of 2 0
[78710.577905] [drm:r100_cs_track_texture_print] *ERROR* compress format   
0
[78710.577909] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[79054.090196] [drm:r100_cs_track_texture_check] *ERROR* Texture of unit 0
needs 273439296 bytes but is 3145728
[79054.090204] [drm:r100_cs_track_texture_print] *ERROR* pitch 
16536
[79054.090207] [drm:r100_cs_track_texture_print] *ERROR* use_pitch 
1
[79054.090210] [drm:r100_cs_track_texture_print] *ERROR* width 
16536
[79054.090213] [drm:r100_cs_track_texture_print] *ERROR* width_11  
2048
[79054.090216] [drm:r100_cs_track_texture_print] *ERROR* height
16536
[79054.090219] [drm:r100_cs_track_texture_print] *ERROR* height_11 
2048
[79054.090222] [drm:r100_cs_track_texture_print] *ERROR* num levels
0
[79054.090225] [drm:r100_cs_track_texture_print] *ERROR* depth 
0
[79054.090228] [drm:r100_cs_track_texture_print] *ERROR* bpp   
4
[79054.090231] [drm:r100_cs_track_texture_print] *ERROR* coordinate type   
0
[79054.090234] [drm:r100_cs_track_texture_print] *ERROR* width round to power
of 2  0
[79054.090237] [drm:r100_cs_track_texture_print] *ERROR* height round to power
of 2 0
[79054.090239] [drm:r100_cs_track_texture_print] *ERROR* compress format   
0
[79054.090243] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !

-- 
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 50014] kwin with desktop effects crashes in r100_cs_track_texture_check on Radeon Mobility M6 LY

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

--- Comment #1 from Orion Poplawski or...@cora.nwra.com 2012-05-16 10:17:01 
PDT ---
Created attachment 61729
  -- https://bugs.freedesktop.org/attachment.cgi?id=61729
Xorg.0.log

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

Re: [PATCH 2/2] drm: add plane properties

2012/5/16 Rob Clark rob.cl...@linaro.org:
 From: Rob Clark r...@ti.com

 The omapdrm driver uses this for setting per-overlay rotation.  It
 is likely also useful for setting YUV-RGB colorspace conversion
 matrix, etc.

 Signed-off-by: Rob Clark r...@ti.com

Please add comments inside include/drm/drm_crtc.h documenting the new
added fields of drm_plane_funcs and drm_funcs (we already have
descriptions of all the other fields).

With that:
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com

 ---
  drivers/gpu/drm/drm_crtc.c |   19 +++
  include/drm/drm_crtc.h     |    5 +
  2 files changed, 24 insertions(+)

 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index 022873e..a9b2b497 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -606,6 +606,7 @@ int drm_plane_init(struct drm_device *dev, struct 
 drm_plane *plane,
        if (ret)
                goto out;

 +       plane-base.properties = plane-properties;
        plane-dev = dev;
        plane-funcs = funcs;
        plane-format_types = kmalloc(sizeof(uint32_t) * format_count,
 @@ -3155,6 +3156,21 @@ static int drm_mode_crtc_set_obj_prop(struct 
 drm_mode_object *obj,
        return ret;
  }

 +static int drm_mode_plane_set_obj_prop(struct drm_mode_object *obj,
 +                                     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);
 +       if (!ret)
 +               drm_object_property_set_value(obj, property, value);
 +
 +       return ret;
 +}
 +
  int drm_mode_obj_get_properties_ioctl(struct drm_device *dev, void *data,
                                      struct drm_file *file_priv)
  {
 @@ -3256,6 +3272,9 @@ int drm_mode_obj_set_property_ioctl(struct drm_device 
 *dev, void *data,
        case DRM_MODE_OBJECT_CRTC:
                ret = drm_mode_crtc_set_obj_prop(arg_obj, property, 
 arg-value);
                break;
 +       case DRM_MODE_OBJECT_PLANE:
 +               ret = drm_mode_plane_set_obj_prop(arg_obj, property, 
 arg-value);
 +               break;
        }

  out:
 diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
 index 39e3e1c..c23789c 100644
 --- a/include/drm/drm_crtc.h
 +++ b/include/drm/drm_crtc.h
 @@ -618,6 +618,9 @@ struct drm_plane_funcs {
                            uint32_t src_w, uint32_t src_h);
        int (*disable_plane)(struct drm_plane *plane);
        void (*destroy)(struct drm_plane *plane);
 +
 +       int (*set_property)(struct drm_plane *plane,
 +                           struct drm_property *property, uint64_t val);
  };

  /**
 @@ -657,6 +660,8 @@ struct drm_plane {

        const struct drm_plane_funcs *funcs;
        void *helper_private;
 +
 +       struct drm_object_properties properties;
  };

  /**
 --
 1.7.9.5

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



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

Re: [PATCH 1/2] drm: add bitmask property type

2012/5/16 Rob Clark rob.cl...@linaro.org:
 From: Rob Clark r...@ti.com

 A bitmask property is similar to an enum.  The enum value is a bit
 position (0-63), and valid property values consist of a mask of
 zero or more of (1  enum_val[n]).

 Signed-off-by: Rob Clark r...@ti.com

Bikeshedding
int num_values appears after column 80 in 2 places
/Bikeshedding

Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com

 ---
  drivers/gpu/drm/drm_crtc.c |   46 
 +---
  include/drm/drm_crtc.h     |    3 +++
  include/drm/drm_mode.h     |    1 +
  3 files changed, 47 insertions(+), 3 deletions(-)

 diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
 index 75661c8..022873e 100644
 --- a/drivers/gpu/drm/drm_crtc.c
 +++ b/drivers/gpu/drm/drm_crtc.c
 @@ -2707,6 +2707,33 @@ struct drm_property *drm_property_create_enum(struct 
 drm_device *dev, int flags,
  }
  EXPORT_SYMBOL(drm_property_create_enum);

 +struct drm_property *drm_property_create_bitmask(struct drm_device *dev,
 +                                        int flags, const char *name,
 +                                        const struct drm_prop_enum_list 
 *props, int num_values)
 +{
 +       struct drm_property *property;
 +       int i, ret;
 +
 +       flags |= DRM_MODE_PROP_BITMASK;
 +
 +       property = drm_property_create(dev, flags, name, num_values);
 +       if (!property)
 +               return NULL;
 +
 +       for (i = 0; i  num_values; i++) {
 +               ret = drm_property_add_enum(property, i,
 +                                     props[i].type,
 +                                     props[i].name);
 +               if (ret) {
 +                       drm_property_destroy(dev, property);
 +                       return NULL;
 +               }
 +       }
 +
 +       return property;
 +}
 +EXPORT_SYMBOL(drm_property_create_bitmask);
 +
  struct drm_property *drm_property_create_range(struct drm_device *dev, int 
 flags,
                                         const char *name,
                                         uint64_t min, uint64_t max)
 @@ -2731,7 +2758,14 @@ int drm_property_add_enum(struct drm_property 
 *property, int index,
  {
        struct drm_property_enum *prop_enum;

 -       if (!(property-flags  DRM_MODE_PROP_ENUM))
 +       if (!(property-flags  (DRM_MODE_PROP_ENUM | DRM_MODE_PROP_BITMASK)))
 +               return -EINVAL;
 +
 +       /*
 +        * Bitmask enum properties have the additional constraint of values
 +        * from 0 to 63
 +        */
 +       if ((property-flags  DRM_MODE_PROP_BITMASK)  (value  63))
                return -EINVAL;

        if (!list_empty(property-enum_blob_list)) {
 @@ -2875,7 +2909,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
        }
        property = obj_to_property(obj);

 -       if (property-flags  DRM_MODE_PROP_ENUM) {
 +       if (property-flags  (DRM_MODE_PROP_ENUM | DRM_MODE_PROP_BITMASK)) {
                list_for_each_entry(prop_enum, property-enum_blob_list, head)
                        enum_count++;
        } else if (property-flags  DRM_MODE_PROP_BLOB) {
 @@ -2900,7 +2934,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
        }
        out_resp-count_values = value_count;

 -       if (property-flags  DRM_MODE_PROP_ENUM) {
 +       if (property-flags  (DRM_MODE_PROP_ENUM | DRM_MODE_PROP_BITMASK)) {
                if ((out_resp-count_enum_blobs = enum_count)  enum_count) {
                        copied = 0;
                        enum_ptr = (struct drm_mode_property_enum __user 
 *)(unsigned long)out_resp-enum_blob_ptr;
 @@ -3055,6 +3089,12 @@ static bool drm_property_change_is_valid(struct 
 drm_property *property,
                if (value  property-values[0] || value  property-values[1])
                        return false;
                return true;
 +       } else if (property-flags  DRM_MODE_PROP_BITMASK) {
 +               int i;
 +               __u64 valid_mask = 0;
 +               for (i = 0; i  property-num_values; i++)
 +                       valid_mask |= (1LL  property-values[i]);
 +               return !(value  ~valid_mask);
        } else {
                int i;
                for (i = 0; i  property-num_values; i++)
 diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
 index e194c78..39e3e1c 100644
 --- a/include/drm/drm_crtc.h
 +++ b/include/drm/drm_crtc.h
 @@ -940,6 +940,9 @@ extern struct drm_property 
 *drm_property_create_enum(struct drm_device *dev, int
                                         const char *name,
                                         const struct drm_prop_enum_list 
 *props,
                                         int num_values);
 +struct drm_property *drm_property_create_bitmask(struct drm_device *dev,
 +                                        int flags, const char *name,
 +                                        const struct drm_prop_enum_list 
 *props, int num_values);
  struct drm_property

[Bug 49794] HD5850 clocks are always limited to 400/900

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

--- Comment #8 from Andrey dr.an...@gmail.com 2012-05-16 11:40:21 PDT ---
Created attachment 61732
  -- https://bugs.freedesktop.org/attachment.cgi?id=61732
HIS Radeon HD 5850 BIOS

Oops, attached correct rom

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

Re: [PATCH libdrm 0/3] Additional drm properties patches

2012/5/16 Rob Clark rob.cl...@linaro.org:
 From: Rob Clark r...@ti.com

 Additional drm properties support, the libdrm part.  These apply on top
 of Paulo's libdrm properties patches, and add support for bitmask
 properties, and additional support in modetest.

 Rob Clark (3):
  Add support for bitmask properties
  modetest: support bitmask properties
  modetest: support plane properties


For the 3 patches:
Reviewed-by: Paulo Zanoni paulo.r.zan...@intel.com

You might want to create patch 0004 adding support for the proptest
tool... It might help you test stuff.


  include/drm/drm_mode.h    |    1 +
  tests/modetest/modetest.c |   22 ++
  xf86drmMode.c             |    4 ++--
  3 files changed, 25 insertions(+), 2 deletions(-)

 --
 1.7.9.5

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



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

[Bug 50021] New: src/gallium/drivers/r300/r300_state.c:716:17: error: incompatible type for argument 2 of ‘r300-rws-buffer_set_tiling’

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

 Bug #: 50021
   Summary: src/gallium/drivers/r300/r300_state.c:716:17: error:
incompatible type for argument 2 of
‘r300-rws-buffer_set_tiling’
Classification: Unclassified
   Product: Mesa
   Version: unspecified
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: blocker
  Priority: medium
 Component: Drivers/DRI/r300
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: v...@freedesktop.org
CC: mic...@daenzer.net


mesa: 03e3bc4ba56f1021899a5f773b6ec21893619e3a (master)

$ scons
[...]
  Compiling src/gallium/drivers/r300/r300_state.c ...
src/gallium/drivers/r300/r300_state.c: In function ‘r300_tex_set_tiling_flags’:
src/gallium/drivers/r300/r300_state.c:716:17: error: incompatible type for
argument 2 of ‘r300-rws-buffer_set_tiling’
src/gallium/drivers/r300/r300_state.c:716:17: note: expected ‘enum
radeon_bo_layout’ but argument is of type ‘struct radeon_winsys_cs *’
src/gallium/drivers/r300/r300_state.c:716:17: error: too few arguments to
function ‘r300-rws-buffer_set_tiling’
scons: *** [build/linux-x86_64-debug/gallium/drivers/r300/r300_state.os] Error
1
scons: building terminated because of errors.


11f056a3f0b87e86267efa8b5ac9d36a343c9dc1 is the first bad commit
commit 11f056a3f0b87e86267efa8b5ac9d36a343c9dc1
Author: Michel Dänzer michel.daen...@amd.com
Date:   Wed May 16 17:45:17 2012 +0200

r600g: Set tiling information for BOs being shared.

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

:04 04 50daa6d7aceccb5f0697d46b9aa0ab03a13eae43
2b7c8f9c7f46546a6cf1159c741937160010d0d4 Msrc

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

Re: [PATCH] gma500: Fix hardware cursor support for poulsbo

2012-05-16 Thread Guillaume Clément

Le dimanche 13 mai 2012 15:07:46 Patrik Jakobsson a écrit :
 Poulsbo needs a physical address in the cursor base register. We allocate a
 stolen memory buffer and copy the cursor image provided by userspace into
 it. When/If we get our own userspace driver we can map this stolen memory
 directly. The patch also adds a mark in chip ops so we can identify devices
 that has this requirement.
 

Hello,


This patch works overall for me, (applied it to linux-3.4-rc7) but I'm 
experiencing a kernel error if I do some specific actions (like beginning a 
dragdrop from the KDE menu)

The error corresponds to 
BUG_ON(!vaddr);
on kunmap (see below for the full stack trace).

It looks like on others parts of the kernel, kunmap is fed the same input as 
kmap and not the return value of kmap.

By switching in psb_intel_crtc_cursor_set : 

+   kunmap(tmp_src);

to :

+   kunmap(gt-pages[i]);


I don't experience the problem anymore.




The stack trace for reference :



ay 16 22:35:55 thor kernel: [   98.169193] [ cut here 
]
May 16 22:35:55 thor kernel: [   98.169212] kernel BUG at mm/highmem.c:268!
May 16 22:35:55 thor kernel: [   98.169227] invalid opcode:  [#1] PREEMPT 
SMP 
May 16 22:35:55 thor kernel: [   98.169248] Modules linked in: nfsd exportfs 
nfs nfs_acl lockd auth_rpcgss fscache sunrpc joydev hid_multitouch usbhid hid 
arc4 eeepc_wmi asus_wmi pci_hotplug sparse_keymap ath9k ath9k_common 
snd_hda_codec_realtek ath9k_hw ath mac80211 gma500_gfx(O) snd_hda_intel 
i2c_algo_bit drm_kms_helper snd_hda_codec drm snd_pcm snd_page_alloc snd_hwdep 
snd_timer uhci_hcd serio_raw cfg80211 snd agpgart acpi_cpufreq microcode 
ehci_hcd coretemp usbcore psmouse pcspkr rfkill atl1c lpc_sch i2c_core 
usb_common soundcore thermal evdev mperf battery processor wmi video ac ext4 
jbd2 mbcache crc16 sd_mod pata_acpi ata_generic pata_sch libata scsi_mod 
button
May 16 22:35:55 thor kernel: [   98.169529] 
May 16 22:35:55 thor kernel: [   98.169549] Pid: 641, comm: X Tainted: G
   
O 3.4.0-1-mainline #1 ASUSTeK Computer INC. T91MT/T91MT
May 16 22:35:55 thor kernel: [   98.169578] EIP: 0060:[c01fce99] EFLAGS: 
00013246 CPU: 1 
 
May 16 22:35:55 thor kernel: [   98.169603] EIP is at kunmap_high+0xa9/0xb0 


May 16 22:35:55 thor kernel: [   98.169618] EAX:  EBX: ff9c8000 ECX: 
c0777680 EDX: 3206  
   
May 16 22:35:55 thor kernel: [   98.169634] ESI: ff9c9000 EDI: f9405000 EBP: 
f4237d94 ESP: f4237d8c  
   
May 16 22:35:55 thor kernel: [   98.169652]  DS: 007b ES: 007b FS: 00d8 GS: 
00e0 SS: 0068
May 16 22:35:55 thor kernel: [   98.169669] CR0: 80050033 CR2: b622a680 CR3: 
3733b000 CR4: 07d0
May 16 22:35:55 thor kernel: [   98.169686] DR0:  DR1:  DR2: 
 DR3: 
May 16 22:35:55 thor kernel: [   98.169700] DR6: 0ff0 DR7: 0400
May 16 22:35:55 thor kernel: [   98.169717] Process X (pid: 641, ti=f4236000 
task=f4215500 task.ti=f4236000)
May 16 22:35:55 thor kernel: [   98.169731] Stack:
May 16 22:35:55 thor kernel: [   98.169740]  c03894bb ff9c8000 f4237d9c 
c012fccd f4237dec f896fc60 f8985201 f4c39860
May 16 22:35:55 thor kernel: [   98.169784]  f8985237  ff9c8000 
 0001 0004 000700c0 000700c4
May 16 22:35:55 thor kernel: [   98.169827]  f72b11a0 f73e3800 f6c9c800 
f9404000  f4237e74 f73e380c f896faf0
May 16 22:35:55 thor kernel: [   98.169873] Call Trace:
May 16 22:35:55 thor kernel: [   98.169901]  [c03894bb] ? 
dev_printk+0x2b/0x30
May 16 22:35:55 thor kernel: [   98.169928]  [c012fccd] kunmap+0x3d/0x50
May 16 22:35:55 thor kernel: [   98.169980]  [f896fc60] 
psb_intel_crtc_cursor_set+0x170/0x480 [gma500_gfx]
May 16 22:35:55 thor kernel: [   98.170027]  [f896faf0] ? 
psb_intel_crtc_cursor_move+0x100/0x100 [gma500_gfx]
May 16 22:35:55 thor kernel: [   98.170066]  [f87a798f] 
drm_mode_cursor_ioctl+0xdf/0x140 [drm]
May 16 22:35:55 thor kernel: [   98.170096]  [f896faf0] ? 
psb_intel_crtc_cursor_move+0x100/0x100 [gma500_gfx]
May 16 22:35:55 thor kernel: [   98.170130]  [f87a78b0] ? 
drm_mode_setcrtc+0x540/0x540 [drm]
May 16 22:35:55 thor kernel: [   98.170160]  [f8799cd2] 
drm_ioctl+0x422/0x480 [drm]
May 16 22:35:55 thor kernel: [   98.170183]  [c01c64a3] ? 
wakeup_graph_return+0x43/0x70
May 16 22:35:55 thor kernel: [   98.170217]  [f87a78b0] ? 
drm_mode_setcrtc+0x540/0x540 [drm]
May 16 22:35:55 thor kernel: [   98.170237]  [c01c64a3] ? 
wakeup_graph_return+0x43/0x70
May 16 22:35:55 thor kernel: [   98.170256]  [c0265254] ? 
inotify_free_event_priv+0x14/0x20
May 16

[RFC] radeon faulty command stream dumping

2012-05-16 Thread j . glisse

Attached is 2 patch for dumping everything needed to replay faulty
command stream. I haven't add a module option in the radeon patch
but the idea would be to enable the dumping only if it's requested.

I know AMD folks would like to reuse AMD internal format, but unless
we can quickly get ACK to release it i would rather have this facility
in and then latter add a userspace tools that can convert btw this
format and the AMD format.

The format is described in rati.h, it would be come some kind of API.
That's the reason why i changed the whole radeon family files, so it
can be share btw kernel and userspace.

The replayer is available at:
git://people.freedesktop.org/~glisse/joujou

replayx replay a rati file under X and show the front buffer of the
replayed command stream. It's not yet fully functional but i will
work on r6xx with :
http://people.freedesktop.org/~glisse/lockup/dump-.rati

tati convert a rati file to text version so human can alter command
stream or buffer to try to find the issue. It's not yet done either
idea is to add comment to print register offset next to packet to
make it easier.

I tested the kernel bits against couple variation of faulty command
stream (bad shader, bad vertex count, bad index count, ...) and it
seems to work ok.

The userspace tools need to grow the unrelocate capacity before
being able to replay kernel captured command stream.

Mesa patch to dump command stream in same format as kernel:
http://people.freedesktop.org/~glisse/lockup/0001-radeong-add-rati-command-stream-dumping.patch

libdrm patch needed to either build the joujou or mesa with
the patch
http://people.freedesktop.org/~glisse/lockup/0001-radeon-add-rati-dumping-helper.patch

(Also a bonus is that i regenerated cleanier header definition for
r6xx see replayx_r6xxd.h)

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

[PATCH 1/2] drm/debugfs: allow driver to provide a custom read callback

2012-05-16 Thread j . glisse

From: Jerome Glisse jgli...@redhat.com

Allow driver to provide a custom read callback for debugfs file.
Usefull if driver try to dump big buffer, avoid double buffering.

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/drm_debugfs.c |   19 ---
 drivers/gpu/drm/i915/i915_debugfs.c   |2 +-
 drivers/gpu/drm/nouveau/nouveau_debugfs.c |4 ++--
 drivers/gpu/drm/radeon/radeon_device.c|4 ++--
 include/drm/drmP.h|8 +++-
 5 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 1c7a1c0..d5194e6 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -63,11 +63,22 @@ static int drm_debugfs_open(struct inode *inode, struct 
file *file)
return single_open(file, node-info_ent-show, node);
 }
 
+static ssize_t drm_debugfs_read(struct file *filp, char __user *ubuf,
+   size_t max, loff_t *ppos)
+{
+   struct seq_file *m = filp-private_data;
+   struct drm_info_node *node = (struct drm_info_node *) m-private;
+
+   if (node-read) {
+   return node-read(filp, ubuf, max, ppos);
+   }
+   return seq_read(filp, ubuf, max, ppos);
+}
 
 static const struct file_operations drm_debugfs_fops = {
.owner = THIS_MODULE,
.open = drm_debugfs_open,
-   .read = seq_read,
+   .read = drm_debugfs_read,
.llseek = seq_lseek,
.release = single_release,
 };
@@ -86,7 +97,8 @@ static const struct file_operations drm_debugfs_fops = {
  * gdm_debugfs_lists in the given root directory.
  */
 int drm_debugfs_create_files(struct drm_info_list *files, int count,
-struct dentry *root, struct drm_minor *minor)
+struct dentry *root, struct drm_minor *minor,
+drm_debugfs_read_t read)
 {
struct drm_device *dev = minor-dev;
struct dentry *ent;
@@ -118,6 +130,7 @@ int drm_debugfs_create_files(struct drm_info_list *files, 
int count,
tmp-minor = minor;
tmp-dent = ent;
tmp-info_ent = files[i];
+   tmp-read = read;
 
mutex_lock(minor-debugfs_lock);
list_add(tmp-list, minor-debugfs_list);
@@ -159,7 +172,7 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
}
 
ret = drm_debugfs_create_files(drm_debugfs_list, DRM_DEBUGFS_ENTRIES,
-  minor-debugfs_root, minor);
+  minor-debugfs_root, minor, NULL);
if (ret) {
debugfs_remove(minor-debugfs_root);
minor-debugfs_root = NULL;
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 950f72a..636c4f4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2018,7 +2018,7 @@ int i915_debugfs_init(struct drm_minor *minor)
 
return drm_debugfs_create_files(i915_debugfs_list,
I915_DEBUGFS_ENTRIES,
-   minor-debugfs_root, minor);
+   minor-debugfs_root, minor, NULL);
 }
 
 void i915_debugfs_cleanup(struct drm_minor *minor)
diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c 
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index fa2ec49..12cbc5c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -94,7 +94,7 @@ nouveau_debugfs_channel_init(struct nouveau_channel *chan)
 
ret = drm_debugfs_create_files(chan-debugfs.info, 1,
   dev_priv-debugfs.channel_root,
-  chan-dev-primary);
+  chan-dev-primary, NULL);
if (ret == 0)
chan-debugfs.active = true;
return ret;
@@ -186,7 +186,7 @@ int
 nouveau_debugfs_init(struct drm_minor *minor)
 {
drm_debugfs_create_files(nouveau_debugfs_list, NOUVEAU_DEBUGFS_ENTRIES,
-minor-debugfs_root, minor);
+minor-debugfs_root, minor, NULL);
return 0;
 }
 
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 3d41525..944ac11 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1039,10 +1039,10 @@ int radeon_debugfs_add_files(struct radeon_device *rdev,
 #if defined(CONFIG_DEBUG_FS)
drm_debugfs_create_files(files, nfiles,
 rdev-ddev-control-debugfs_root,
-rdev-ddev-control);
+rdev-ddev-control, NULL);
drm_debugfs_create_files(files, nfiles,
 rdev-ddev-primary-debugfs_root,
-

[PATCH 2/2] drm/radeon: add lockup faulty command recording

2012-05-16 Thread j . glisse

From: Jerome Glisse jgli...@redhat.com

This try to identify the faulty user command stream that caused
lockup. If it finds one it create big blob that contains all
information needed to replay the faulty command stream.

Signed-off-by: Jerome Glisse jgli...@redhat.com
---
 drivers/gpu/drm/radeon/r100.c  |6 +-
 drivers/gpu/drm/radeon/r300.c  |2 +-
 drivers/gpu/drm/radeon/r420.c  |2 +-
 drivers/gpu/drm/radeon/r600.c  |2 +-
 drivers/gpu/drm/radeon/r600_cs.c   |4 +-
 drivers/gpu/drm/radeon/radeon.h|   72 +-
 drivers/gpu/drm/radeon/radeon_cs.c |   68 --
 drivers/gpu/drm/radeon/radeon_device.c |   25 +-
 drivers/gpu/drm/radeon/radeon_family.h |  145 ++--
 drivers/gpu/drm/radeon/radeon_fence.c  |2 +-
 drivers/gpu/drm/radeon/radeon_gart.c   |   10 ++-
 drivers/gpu/drm/radeon/radeon_object.h |   12 ++-
 drivers/gpu/drm/radeon/radeon_pm.c |2 +-
 drivers/gpu/drm/radeon/radeon_ring.c   |   21 -
 drivers/gpu/drm/radeon/radeon_sa.c |  112 ++
 drivers/gpu/drm/radeon/radeon_ttm.c|2 +-
 drivers/gpu/drm/radeon/rs400.c |2 +-
 drivers/gpu/drm/radeon/rv515.c |4 +-
 include/drm/rati.h |  163 
 19 files changed, 524 insertions(+), 132 deletions(-)
 create mode 100644 include/drm/rati.h

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 0874a6d..8ed365f 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -2694,7 +2694,7 @@ static struct drm_info_list r100_debugfs_mc_info_list[] = 
{
 int r100_debugfs_rbbm_init(struct radeon_device *rdev)
 {
 #if defined(CONFIG_DEBUG_FS)
-   return radeon_debugfs_add_files(rdev, r100_debugfs_rbbm_list, 1);
+   return radeon_debugfs_add_files(rdev, r100_debugfs_rbbm_list, 1, NULL);
 #else
return 0;
 #endif
@@ -2703,7 +2703,7 @@ int r100_debugfs_rbbm_init(struct radeon_device *rdev)
 int r100_debugfs_cp_init(struct radeon_device *rdev)
 {
 #if defined(CONFIG_DEBUG_FS)
-   return radeon_debugfs_add_files(rdev, r100_debugfs_cp_list, 2);
+   return radeon_debugfs_add_files(rdev, r100_debugfs_cp_list, 2, NULL);
 #else
return 0;
 #endif
@@ -2712,7 +2712,7 @@ int r100_debugfs_cp_init(struct radeon_device *rdev)
 int r100_debugfs_mc_info_init(struct radeon_device *rdev)
 {
 #if defined(CONFIG_DEBUG_FS)
-   return radeon_debugfs_add_files(rdev, r100_debugfs_mc_info_list, 1);
+   return radeon_debugfs_add_files(rdev, r100_debugfs_mc_info_list, 1, 
NULL);
 #else
return 0;
 #endif
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 97722a3..edb9eeb 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -586,7 +586,7 @@ static struct drm_info_list rv370_pcie_gart_info_list[] = {
 static int rv370_debugfs_pcie_gart_info_init(struct radeon_device *rdev)
 {
 #if defined(CONFIG_DEBUG_FS)
-   return radeon_debugfs_add_files(rdev, rv370_pcie_gart_info_list, 1);
+   return radeon_debugfs_add_files(rdev, rv370_pcie_gart_info_list, 1, 
NULL);
 #else
return 0;
 #endif
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index 99137be..4eddcfc 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -491,7 +491,7 @@ static struct drm_info_list r420_pipes_info_list[] = {
 int r420_debugfs_pipes_info_init(struct radeon_device *rdev)
 {
 #if defined(CONFIG_DEBUG_FS)
-   return radeon_debugfs_add_files(rdev, r420_pipes_info_list, 1);
+   return radeon_debugfs_add_files(rdev, r420_pipes_info_list, 1, NULL);
 #else
return 0;
 #endif
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 4c0d8c9..afc458a 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3589,7 +3589,7 @@ static struct drm_info_list r600_mc_info_list[] = {
 int r600_debugfs_mc_info_init(struct radeon_device *rdev)
 {
 #if defined(CONFIG_DEBUG_FS)
-   return radeon_debugfs_add_files(rdev, r600_mc_info_list, 
ARRAY_SIZE(r600_mc_info_list));
+   return radeon_debugfs_add_files(rdev, r600_mc_info_list, 
ARRAY_SIZE(r600_mc_info_list), NULL);
 #else
return 0;
 #endif
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 0133f5f..0518c45 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -97,7 +97,7 @@ struct gpu_formats {
unsigned blockheight;
unsigned blocksize;
unsigned valid_color;
-   enum radeon_family min_family;
+   unsigned min_family;
 };
 
 static const struct gpu_formats color_formats_table[] = {
@@ -185,7 +185,7 @@ bool r600_fmt_is_valid_color(u32 format)
return false;
 }
 
-bool r600_fmt_is_valid_texture(u32 format, enum radeon_family family)
+bool r600_fmt_is_valid_texture(u32 format, unsigned

Re: [PATCH] gma500: Fix hardware cursor support for poulsbo

2012-05-16 Thread Patrik Jakobsson

On Wed, May 16, 2012 at 11:01 PM, Guillaume Clément gclem...@baobob.org wrote:
 It looks like on others parts of the kernel, kunmap is fed the same input as
 kmap and not the return value of kmap.

Good catch and thank you for testing, I blindly assumed the alloc /
free semantics.

Alan, I'll send you a new version with the fix included.

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

[Bug 50021] src/gallium/drivers/r300/r300_state.c:716:17: error: incompatible type for argument 2 of ‘r300-rws-buffer_set_tiling’

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

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

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED
  Component|Drivers/DRI/r300|Drivers/Gallium/r300

--- Comment #1 from Michel Dänzer mic...@daenzer.net 2012-05-16 15:15:48 PDT 
---
Commit: 7446a0407d4e61a826385c11ed6c401837baf095
Author: Michel Dänzer michel.daen...@amd.com
Date:   Wed May 16 23:52:19 2012 +0200

gallium/radeon: Fix r300g tiling breakage.

Commit 11f056a3f0b87e86267efa8b5ac9d36a343c9dc1 broke the r300g build. Fix it
up, and reinstate some code which isn't needed by r600g and radeonsi but is
by r300g.

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

drm/gma500 : Suspend/resume issues

2012-05-16 Thread Guillaume Clément

Hello,

On my Poulsbo-enabled machine, I cannot do suspend/resume since the gma500_gfx 
has left staging. I'm currently testing on linux-3.4-rc7.

After some debugging, I found out what the issue is. The crash occurs in 
psb_save_display_registers at the following lines : 

list_for_each_entry(connector, dev-mode_config.connector_list, head){
connector-funcs-save(connector);
}



It appears that connector-funcs-save is NULL : 

static const struct drm_connector_funcs psb_intel_sdvo_connector_funcs = {  


.dpms = drm_helper_connector_dpms,  


.detect = psb_intel_sdvo_detect,


.fill_modes = drm_helper_probe_single_connector_modes,  


.set_property = psb_intel_sdvo_set_property,


.destroy = psb_intel_sdvo_destroy,  


};  



The staging version used to define a save function (psb_intel_sdvo_save). Was 
it broken ? If not, should we insert it back ? 


Either way, if I add an empty save function, suspend works again (but at the 
moment, resume still doesn't work, I'm still trying to work on that).

If I just add a if (connector-funcs-save), this also fixes the crash.



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

Re: drm/gma500 : Suspend/resume issues

2012-05-16 Thread Guillaume Clément


 Either way, if I add an empty save function, suspend works again (but at
 the moment, resume still doesn't work, I'm still trying to work on that).
 
 If I just add a if (connector-funcs-save), this also fixes the crash.
 

Actually, the resume problem is exactly the same as the suspend problem.

After adding an empty resume function in the connector function, suspend and 
resume both work properly.


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

Re: 3.4-rc7 backlight regression on Dell XPS M1710

2012-05-16 Thread Ben Skeggs

Am Mittwoch, den 16.05.2012, 12:17 -0600 schrieb Tim Gardner:
 commit b99da31ed8521eb78d5d6930f3128f8ecdb75fae causes the backlight in
 my Dell XPS M1710 to stop working. Symptoms are dim display and won't
 respond to key brightness events. I bisected and confirmed that
 reverting this single patch on top of 3.4-rc7 fixes the problem.
That commit is correct, it may have uncovered a bug elsewhere though.

Cheers,
Ben.

 
 01:00.0 VGA compatible controller [0300]: nVidia Corporation G71
 [GeForce Go 7900 GS] [10de:0298] (rev a1)
   Subsystem: Dell Device [1028:019b]
   Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
 Stepping- SERR- FastB2B- DisINTx-
   Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort-
 MAbort- SERR- PERR- INTx-
   Latency: 0, Cache Line Size: 64 bytes
   Interrupt: pin A routed to IRQ 16
   Region 0: Memory at ed00 (32-bit, non-prefetchable) [size=16M]
   Region 1: Memory at d000 (64-bit, prefetchable) [size=256M]
   Region 3: Memory at ee00 (64-bit, non-prefetchable) [size=16M]
   Region 5: I/O ports at ef00 [size=128]
   Expansion ROM at efe0 [disabled] [size=128K]
   Capabilities: access denied
   Kernel driver in use: nouveau
   Kernel modules: nouveau, nvidiafb
 
 rtg


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

[Bug 48747] regression [bisected]: display corruption in google earth/glxgears using git r600g on RS780M

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

--- Comment #10 from Jos van Wolput wol...@onsneteindhoven.nl 2012-05-16 
21:48:31 PDT ---
(In reply to comment #9)
 Commit: 11f056a3f0b87e86267efa8b5ac9d36a343c9dc1
 Author: Michel Dänzer michel.daen...@amd.com
 Date:   Wed May 16 17:45:17 2012 +0200
 
 r600g: Set tiling information for BOs being shared.

Indeed no more display corruption, thanks.

-- 
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 38465] Display flickers when setting power_profile

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

--- Comment #2 from Erdem U. Altinyurt  2012-05-15 
17:25:36 PDT ---
I have this flickering issue too on my HD8650.
But not only moving to high to low profile. It flickers low to high profile
too! This doesn't let us use "dynpm"...

Using Kernel 3.3.5 with mesa/radeon/drm trunk.

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

[Bug 49981] On HD6850, Power Profile doesn't change if 2 screen is attached.

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

Erdem U. Altinyurt  changed:

   What|Removed |Added

 AssignedTo|xorg-driver-ati at lists.x.org |dri-devel at 
lists.freedesktop
   ||.org
  QAContact|xorg-team at lists.x.org   |
Product|xorg|DRI
Version|unspecified |DRI CVS
  Component|Driver/Radeon   |DRM/Radeon

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

[PATCH 3/4] drm/exynos: added userptr feature.



> -Original Message-
> From: robdclark at gmail.com [mailto:robdclark at gmail.com] On Behalf Of Rob
> Clark
> Sent: Tuesday, May 15, 2012 11:29 PM
> To: InKi Dae
> Cc: Inki Dae; kyungmin.park at samsung.com; sw0312.kim at samsung.com; dri-
> devel at lists.freedesktop.org
> Subject: Re: [PATCH 3/4] drm/exynos: added userptr feature.
> 
> On Tue, May 15, 2012 at 7:40 AM, InKi Dae  wrote:
> > 2012/5/15 Rob Clark :
> >> On Tue, May 15, 2012 at 2:17 AM, Inki Dae  wrote:
> >>> Hi Rob,
> >>>
>  -Original Message-
>  From: robdclark at gmail.com [mailto:robdclark at gmail.com] On Behalf Of
> Rob
>  Clark
>  Sent: Tuesday, May 15, 2012 4:35 PM
>  To: Inki Dae
>  Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
>  kyungmin.park at samsung.com; sw0312.kim at samsung.com
>  Subject: Re: [PATCH 3/4] drm/exynos: added userptr feature.
> 
>  On Mon, Apr 23, 2012 at 7:43 AM, Inki Dae 
> wrote:
>  > this feature could be used to use memory region allocated by
> malloc() in
>  user
>  > mode and mmaped memory region allocated by other memory allocators.
>  userptr
>  > interface can identify memory type through vm_flags value and would
> get
>  > pages or page frame numbers to user space appropriately.
> 
>  I apologize for being a little late to jump in on this thread, but...
> 
>  I must confess to not being a huge fan of userptr. ?It really is
>  opening a can of worms, and seems best avoided if at all possible.
>  I'm not entirely sure the use-case for which you require this, but I
>  wonder if there isn't an alternative way? ? I mean, the main case I
>  could think of for mapping userspace memory would be something like
>  texture upload. ?But could that be handled in an alternative way,
>  something like a pwrite or texture_upload API, which could
> temporarily
>  pin the userspace memory, kick off a dma from that user buffer to a
>  proper GEM buffer, and then unpin the user buffer when the DMA
>  completes?
> 
> >>>
> >>> This feature have being discussed with drm and linux-mm guys and I
> have
> >>> posted this patch four times.
> >>> So please, see below e-mail threads.
> >>> http://www.spinics.net/lists/dri-devel/msg22729.html
> >>>
> >>> and then please, give me your opinions.
> >>
> >>
> >> Yeah, I read that and understand that the purpose is to support
> >> malloc()'d memory (and btw, all the other changes like limits to the
> >> amount of userptr buffers are good if we do decide to support userptr
> >> buffers). ?But my question was more about why do you need to support
> >> malloc'd buffers... other than "just because v4l2 does" ;-)
> >>
> >> I don't really like the userptr feature in v4l2 either, and view it as
> >> a necessary evil because at the time there was nothing like dmabuf.
> >> But now that we have dmabuf to share buffers with zero copy between
> >> two devices, to we *really* still need userptr?
> >>
> >
> > Definitely no, as I mentioned on this email thread, we are using the
> > userptr feature for pixman and evas
> > backend to use gpu acceleration directly(zero-copy). as you may know,
> > Evas is part of the Enlightenment Foundation Libraries(EFL) and
> > Elementary for pixman. all the applicaions based on them uses user
> > address to draw something so the backends(such as gpu accelerators)
> > can refer to only the user address to the buffer rendered. do you
> > think we can avoid memory copy to use those GPUs without such userptr
> > feature? I think there is no way and only the way that the gpu uses
> > the user address to render without memory copy. and as mentioned on
> > this thread, this feature had been tried by i915 in the desktop world.
> > for this, you can refer to Daniel's comments.
> 
> oh, yeah, for something like pixman it is hard to accelerate.  But I
> wonder if there is still some benefit.  I don't know as much about
> evas, but pixman is assumed to be a synchronous API, so you must
> always block until the operation completes which looses a lot of the
> potential benefit of a blitter.  And also I think you have no control
> over when the client free()'s a buffer.  So you end up having to
> map/unmap the buffer to the gpu/blitter/whatever every single
> operation.  Not to mention possible need for cache operations, etc.  I
> wonder if trying to accel it in hw really brings any benefit vs just
> using NEON?
> 

Yes, actually, we are using NEON backend of PIXMAN for best performance
also. like this, PIXMAN's NEON backend for small image and 2D GPU backend of
EXA for large image because NEON is faster than 2d gpu for small image but
not for large image.

> I thought EFL has a GLES backend..  I could be wrong about that, but
> if it does probably you'd get better performance by using the GLES
> backend vs trying to accelerate what is intended as a sw path..
> 
Right, EFL has a GLES backend and also PIXMAN for software path.

[PATCH 2/2 v4] drm/exynos: added userptr feature.



> -Original Message-
> From: Jerome Glisse [mailto:j.glisse at gmail.com]
> Sent: Tuesday, May 15, 2012 11:31 PM
> To: Inki Dae
> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org; linux-mm at 
> kvack.org;
> minchan at kernel.org; kosaki.motohiro at gmail.com; kyungmin.park at 
> samsung.com;
> sw0312.kim at samsung.com; jy0922.shim at samsung.com
> Subject: Re: [PATCH 2/2 v4] drm/exynos: added userptr feature.
> 
> On Tue, May 15, 2012 at 12:33 AM, Inki Dae  wrote:
> > Hi Jerome,
> >
> >> -Original Message-
> >> From: Jerome Glisse [mailto:j.glisse at gmail.com]
> >> Sent: Tuesday, May 15, 2012 4:27 AM
> >> To: Inki Dae
> >> Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
> minchan at kernel.org;
> >> kosaki.motohiro at gmail.com; kyungmin.park at samsung.com;
> >> sw0312.kim at samsung.com; jy0922.shim at samsung.com
> >> Subject: Re: [PATCH 2/2 v4] drm/exynos: added userptr feature.
> >>
> >> On Mon, May 14, 2012 at 2:17 AM, Inki Dae  wrote:
> >> > this feature is used to import user space region allocated by
malloc()
> >> or
> >> > mmaped into a gem. for this, we uses get_user_pages() to get all the
> >> pages
> >> > to VMAs within user address space. However we should pay attention to
> >> use
> >> > this userptr feature like below.
> >> >
> >> > The migration issue.
> >> > - Pages reserved by CMA for some device using DMA could be used by
> >> > kernel and if the device driver wants to use those pages
> >> > while being used by kernel then the pages are copied into
> >> > other ones allocated to migrate them and then finally,
> >> > the device driver can use the pages for itself.
> >> > Thus, migrated, the pages being accessed by DMA could be changed
> >> > to other so this situation may incur that DMA accesses any pages
> >> > it doesn't want.
> >> >
> >> > The COW issue.
> >> > - while DMA of a device is using the pages to VMAs, if current
> >> > process was forked then the pages being accessed by the DMA
> >> > would be copied into child's pages.(Copy On Write) so
> >> > these pages may not have coherrency with parent's ones if
> >> > child process wrote something on those pages so we need to
> >> > flag VM_DONTCOPY to prevent pages from being COWed.
> >>
> >> Note that this is a massive change in behavior of anonymous mapping
> >> this effectively completely change the linux API from application
> >> point of view on your platform. Any application that have memory
> >> mapped by your ioctl will have different fork behavior that other
> >> application. I think this should be stressed, it's one of the thing i
> >> am really uncomfortable with i would rather not have the dont copy
> >> flag and have the page cowed and have the child not working with the
> >> 3d/2d/drm driver. That would means that your driver (opengl
> >> implementation for instance) would have to detect fork and work around
> >> it, nvidia closed source driver do that.
> >>
> >
> > First of all, thank you for your comments.
> >
> > Right, VM_DONTCOPY flag would change original behavior of user. Do you
> think
> > this way has no problem but no generic way? anyway our issue was that
> the
> > pages to VMAs are copied into child's ones(COW) so we prevented those
> pages
> > from being COWed with using VM_DONTCOPY flag.
> >
> > For this, I have three questions below
> >
> > 1. in case of not using VM_DONTCOPY flag, you think that the application
> > using our userptr feature has COW issue; parent's pages being accessed
> by
> > DMA of some device would be copied into child's ones if the child wrote
> > something on the pages. after that, DMA of a device could access pages
> user
> > doesn't want. I'm not sure but I think such behavior has no any problem
> and
> > is generic behavior and it's role of user to do fork or not. Do you
> think
> > such COW behavior could create any issue I don't aware of so we have to
> > prevent that somehow?
> 
> My point is the father will keep the page that the GPU know about as
> long as the father dont destroy the associated object. But if the
> child expect to be able to use the same GPU object and still be able
> to change the content through its anonymous mapping than i would
> consider this behavior buggy (ie application have wrong expectation).
> So i am all for only the father is able to keep its memory mapped into
> GPU address space through same GEM object.
> 
> > 2. so we added VM_DONTCOPY flag to prevent the pages from being COWed
> but
> > this changes original behavior of user. Do you think this is not generic
> way
> > or could create any issue also?
> 
> I would say don't add the flag and consider application that do fork
> as special case in userspace. See below for how i would handle it.
> 
> > 3. and last one, what is the difference between to flag VM_DONTCOPY and
> to
> > detect fork? I mean the device driver should do something to need after
> > detecting fork. and I'm not sure but I think the something may also
> change
> > original

[PATCH 0/2] Some additional drm properties patches

From: Rob Clark 

These patches apply on top of Paulo's patches to add support for generic
KMS object properties, and add support for plane properties, and a new
property type suitable for flags/bitmasks.

Rob Clark (2):
  drm: add bitmask property type
  drm: add plane properties

 drivers/gpu/drm/drm_crtc.c |   65 ++--
 include/drm/drm_crtc.h |8 ++
 include/drm/drm_mode.h |1 +
 3 files changed, 71 insertions(+), 3 deletions(-)

-- 
1.7.9.5

[PATCH 1/2] drm: add bitmask property type

From: Rob Clark 

A bitmask property is similar to an enum.  The enum value is a bit
position (0-63), and valid property values consist of a mask of
zero or more of (1 << enum_val[n]).

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_crtc.c |   46 +---
 include/drm/drm_crtc.h |3 +++
 include/drm/drm_mode.h |1 +
 3 files changed, 47 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 75661c8..022873e 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2707,6 +2707,33 @@ struct drm_property *drm_property_create_enum(struct 
drm_device *dev, int flags,
 }
 EXPORT_SYMBOL(drm_property_create_enum);

+struct drm_property *drm_property_create_bitmask(struct drm_device *dev,
+int flags, const char *name,
+const struct drm_prop_enum_list 
*props, int num_values)
+{
+   struct drm_property *property;
+   int i, ret;
+
+   flags |= DRM_MODE_PROP_BITMASK;
+
+   property = drm_property_create(dev, flags, name, num_values);
+   if (!property)
+   return NULL;
+
+   for (i = 0; i < num_values; i++) {
+   ret = drm_property_add_enum(property, i,
+ props[i].type,
+ props[i].name);
+   if (ret) {
+   drm_property_destroy(dev, property);
+   return NULL;
+   }
+   }
+
+   return property;
+}
+EXPORT_SYMBOL(drm_property_create_bitmask);
+
 struct drm_property *drm_property_create_range(struct drm_device *dev, int 
flags,
 const char *name,
 uint64_t min, uint64_t max)
@@ -2731,7 +2758,14 @@ int drm_property_add_enum(struct drm_property *property, 
int index,
 {
struct drm_property_enum *prop_enum;

-   if (!(property->flags & DRM_MODE_PROP_ENUM))
+   if (!(property->flags & (DRM_MODE_PROP_ENUM | DRM_MODE_PROP_BITMASK)))
+   return -EINVAL;
+
+   /*
+* Bitmask enum properties have the additional constraint of values
+* from 0 to 63
+*/
+   if ((property->flags & DRM_MODE_PROP_BITMASK) && (value > 63))
return -EINVAL;

if (!list_empty(>enum_blob_list)) {
@@ -2875,7 +2909,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
}
property = obj_to_property(obj);

-   if (property->flags & DRM_MODE_PROP_ENUM) {
+   if (property->flags & (DRM_MODE_PROP_ENUM | DRM_MODE_PROP_BITMASK)) {
list_for_each_entry(prop_enum, >enum_blob_list, head)
enum_count++;
} else if (property->flags & DRM_MODE_PROP_BLOB) {
@@ -2900,7 +2934,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
}
out_resp->count_values = value_count;

-   if (property->flags & DRM_MODE_PROP_ENUM) {
+   if (property->flags & (DRM_MODE_PROP_ENUM | DRM_MODE_PROP_BITMASK)) {
if ((out_resp->count_enum_blobs >= enum_count) && enum_count) {
copied = 0;
enum_ptr = (struct drm_mode_property_enum __user 
*)(unsigned long)out_resp->enum_blob_ptr;
@@ -3055,6 +3089,12 @@ static bool drm_property_change_is_valid(struct 
drm_property *property,
if (value < property->values[0] || value > property->values[1])
return false;
return true;
+   } else if (property->flags & DRM_MODE_PROP_BITMASK) {
+   int i;
+   __u64 valid_mask = 0;
+   for (i = 0; i < property->num_values; i++)
+   valid_mask |= (1LL << property->values[i]);
+   return !(value & ~valid_mask);
} else {
int i;
for (i = 0; i < property->num_values; i++)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index e194c78..39e3e1c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -940,6 +940,9 @@ extern struct drm_property *drm_property_create_enum(struct 
drm_device *dev, int
 const char *name,
 const struct drm_prop_enum_list *props,
 int num_values);
+struct drm_property *drm_property_create_bitmask(struct drm_device *dev,
+int flags, const char *name,
+const struct drm_prop_enum_list 
*props, int num_values);
 struct drm_property *drm_property_create_range(struct drm_device *dev, int 
flags,
 const char *name,
 uint64_t min, uint64_t max);
diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index

[PATCH 2/2] drm: add plane properties

From: Rob Clark 

The omapdrm driver uses this for setting per-overlay rotation.  It
is likely also useful for setting YUV->RGB colorspace conversion
matrix, etc.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_crtc.c |   19 +++
 include/drm/drm_crtc.h |5 +
 2 files changed, 24 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 022873e..a9b2b497 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -606,6 +606,7 @@ int drm_plane_init(struct drm_device *dev, struct drm_plane 
*plane,
if (ret)
goto out;

+   plane->base.properties = >properties;
plane->dev = dev;
plane->funcs = funcs;
plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
@@ -3155,6 +3156,21 @@ static int drm_mode_crtc_set_obj_prop(struct 
drm_mode_object *obj,
return ret;
 }

+static int drm_mode_plane_set_obj_prop(struct drm_mode_object *obj,
+ 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);
+   if (!ret)
+   drm_object_property_set_value(obj, property, value);
+
+   return ret;
+}
+
 int drm_mode_obj_get_properties_ioctl(struct drm_device *dev, void *data,
  struct drm_file *file_priv)
 {
@@ -3256,6 +3272,9 @@ int drm_mode_obj_set_property_ioctl(struct drm_device 
*dev, void *data,
case DRM_MODE_OBJECT_CRTC:
ret = drm_mode_crtc_set_obj_prop(arg_obj, property, arg->value);
break;
+   case DRM_MODE_OBJECT_PLANE:
+   ret = drm_mode_plane_set_obj_prop(arg_obj, property, 
arg->value);
+   break;
}

 out:
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 39e3e1c..c23789c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -618,6 +618,9 @@ struct drm_plane_funcs {
uint32_t src_w, uint32_t src_h);
int (*disable_plane)(struct drm_plane *plane);
void (*destroy)(struct drm_plane *plane);
+
+   int (*set_property)(struct drm_plane *plane,
+   struct drm_property *property, uint64_t val);
 };

 /**
@@ -657,6 +660,8 @@ struct drm_plane {

const struct drm_plane_funcs *funcs;
void *helper_private;
+
+   struct drm_object_properties properties;
 };

 /**
-- 
1.7.9.5

[PATCH libdrm 0/3] Additional drm properties patches

From: Rob Clark 

Additional drm properties support, the libdrm part.  These apply on top
of Paulo's libdrm properties patches, and add support for bitmask
properties, and additional support in modetest.

Rob Clark (3):
  Add support for bitmask properties
  modetest: support bitmask properties
  modetest: support plane properties

 include/drm/drm_mode.h|1 +
 tests/modetest/modetest.c |   22 ++
 xf86drmMode.c |4 ++--
 3 files changed, 25 insertions(+), 2 deletions(-)

-- 
1.7.9.5

[PATCH libdrm 1/3] Add support for bitmask properties

From: Rob Clark 

A bitmask property is similar to an enum.  The enum value is a bit
position (0-63), and valid property values consist of a mask of
zero or more of (1 << enum_val[n]).

Signed-off-by: Rob Clark 
---
 include/drm/drm_mode.h |1 +
 xf86drmMode.c  |4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
index f303d94..62ba997 100644
--- a/include/drm/drm_mode.h
+++ b/include/drm/drm_mode.h
@@ -226,6 +226,7 @@ struct drm_mode_get_connector {
 #define DRM_MODE_PROP_IMMUTABLE(1<<2)
 #define DRM_MODE_PROP_ENUM (1<<3) /* enumerated type with text strings */
 #define DRM_MODE_PROP_BLOB (1<<4)
+#define DRM_MODE_PROP_BITMASK  (1<<5) /* bitmask of enumerated types */

 struct drm_mode_property_enum {
__u64 value;
diff --git a/xf86drmMode.c b/xf86drmMode.c
index a60c7cb..04fdf1f 100644
--- a/xf86drmMode.c
+++ b/xf86drmMode.c
@@ -575,7 +575,7 @@ drmModePropertyPtr drmModeGetProperty(int fd, uint32_t 
property_id)
if (prop.count_values)
prop.values_ptr = VOID2U64(drmMalloc(prop.count_values * 
sizeof(uint64_t)));

-   if (prop.count_enum_blobs && (prop.flags & DRM_MODE_PROP_ENUM))
+   if (prop.count_enum_blobs && (prop.flags & (DRM_MODE_PROP_ENUM | 
DRM_MODE_PROP_BITMASK)))
prop.enum_blob_ptr = VOID2U64(drmMalloc(prop.count_enum_blobs * 
sizeof(struct drm_mode_property_enum)));

if (prop.count_enum_blobs && (prop.flags & DRM_MODE_PROP_BLOB)) {
@@ -597,7 +597,7 @@ drmModePropertyPtr drmModeGetProperty(int fd, uint32_t 
property_id)
r->flags = prop.flags;
if (prop.count_values)
r->values = drmAllocCpy(U642VOID(prop.values_ptr), 
prop.count_values, sizeof(uint64_t));
-   if (prop.flags & DRM_MODE_PROP_ENUM) {
+   if (prop.flags & (DRM_MODE_PROP_ENUM | DRM_MODE_PROP_BITMASK)) {
r->count_enums = prop.count_enum_blobs;
r->enums = drmAllocCpy(U642VOID(prop.enum_blob_ptr), 
prop.count_enum_blobs, sizeof(struct drm_mode_property_enum));
} else if (prop.flags & DRM_MODE_PROP_BLOB) {
-- 
1.7.9.5

[PATCH libdrm 2/3] modetest: support bitmask properties

From: Rob Clark 

Add support to display bitmask properties.

Signed-off-by: Rob Clark 
---
 tests/modetest/modetest.c |8 
 1 file changed, 8 insertions(+)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index ce57e65..dea271a 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -207,6 +207,8 @@ dump_prop(uint32_t prop_id, uint64_t value)
printf(" immutable");
if (prop->flags & DRM_MODE_PROP_ENUM)
printf(" enum");
+   if (prop->flags & DRM_MODE_PROP_BITMASK)
+   printf(" bitmask");
if (prop->flags & DRM_MODE_PROP_BLOB)
printf(" blob");
printf("\n");
@@ -224,6 +226,12 @@ dump_prop(uint32_t prop_id, uint64_t value)
printf(" %s=%llu", prop->enums[i].name,
   prop->enums[i].value);
printf("\n");
+   } else if (prop->flags & DRM_MODE_PROP_BITMASK) {
+   printf("\t\tvalues:");
+   for (i = 0; i < prop->count_enums; i++)
+   printf(" %s=0x%llx", prop->enums[i].name,
+  (1LL << prop->enums[i].value));
+   printf("\n");
} else {
assert(prop->count_enums == 0);
}
-- 
1.7.9.5

[PATCH libdrm 3/3] modetest: support plane properties

From: Rob Clark 

Add support to display plane properties.

Signed-off-by: Rob Clark 
---
 tests/modetest/modetest.c |   14 ++
 1 file changed, 14 insertions(+)

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index dea271a..dc84cf3 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -369,6 +369,7 @@ void dump_framebuffers(void)

 static void dump_planes(void)
 {
+   drmModeObjectPropertiesPtr props;
drmModePlaneRes *plane_resources;
drmModePlane *ovr;
unsigned int i, j;
@@ -403,6 +404,19 @@ static void dump_planes(void)
printf(" %4.4s", (char *)>formats[j]);
printf("\n");

+   printf("  props:\n");
+   props = drmModeObjectGetProperties(fd, ovr->plane_id,
+  DRM_MODE_OBJECT_PLANE);
+   if (props) {
+   for (j = 0; j < props->count_props; j++)
+   dump_prop(props->props[j],
+ props->prop_values[j]);
+   drmModeFreeObjectProperties(props);
+   } else {
+   printf("\tcould not get plane properties: %s\n",
+  strerror(errno));
+   }
+
drmModeFreePlane(ovr);
}
printf("\n");
-- 
1.7.9.5

[PATCH 3/4] drm/exynos: added userptr feature.

2012-05-16 Thread Dave Airlie

On Tue, May 15, 2012 at 8:34 AM, Rob Clark  wrote:
> On Mon, Apr 23, 2012 at 7:43 AM, Inki Dae  wrote:
>> this feature could be used to use memory region allocated by malloc() in user
>> mode and mmaped memory region allocated by other memory allocators. userptr
>> interface can identify memory type through vm_flags value and would get
>> pages or page frame numbers to user space appropriately.
>
> I apologize for being a little late to jump in on this thread, but...
>
> I must confess to not being a huge fan of userptr. ?It really is
> opening a can of worms, and seems best avoided if at all possible.
> I'm not entirely sure the use-case for which you require this, but I
> wonder if there isn't an alternative way? ? I mean, the main case I
> could think of for mapping userspace memory would be something like
> texture upload. ?But could that be handled in an alternative way,
> something like a pwrite or texture_upload API, which could temporarily
> pin the userspace memory, kick off a dma from that user buffer to a
> proper GEM buffer, and then unpin the user buffer when the DMA
> completes?

I'm with Rob on this, I really hate the userptr idea, and my problem
with letting it into exynos is it sets a benchmark for others to do
things the same way. I'm still not 100% sure how its going to be used
even with all your explainations.

Since we've agreed only the X server can access the interface, it
makes 0 sense to me to exist at all, as the X server can avoid malloc
memory for all objects it accesses.

I don't think pixman is at the level where you should be acceleration
it directly. I thought the point of pixman was a fast SW engine, not
something to be trunked down to a hw engine. The idea being you use
cairo and backend it onto something.

I know ssp had some ideas for making pixman be able to do hw accel,
but userptr doesn't seem like the proper solution, it seems like a
hack that needs a lot more VM work to operate properly, and by setting
a precedent for one GPU driver, I'll have 20 implementations of this
from ARM vendors and nobody will ever go back and fix things properly.

So I'm really not sure the best way to move this forward, maybe a very
clear set of use cases of where stuff plugs into this, and why dma-buf
or some other method isn't sufficient, but I'm having trouble getting
past the fact its setting a dangerous precedent.

Dave.

[PATCH 3/4] drm/exynos: added userptr feature.



> -Original Message-
> From: Dave Airlie [mailto:airlied at gmail.com]
> Sent: Wednesday, May 16, 2012 6:23 PM
> To: Rob Clark
> Cc: Inki Dae; kyungmin.park at samsung.com; sw0312.kim at samsung.com; dri-
> devel at lists.freedesktop.org
> Subject: Re: [PATCH 3/4] drm/exynos: added userptr feature.
> 
> On Tue, May 15, 2012 at 8:34 AM, Rob Clark  wrote:
> > On Mon, Apr 23, 2012 at 7:43 AM, Inki Dae  wrote:
> >> this feature could be used to use memory region allocated by malloc()
> in user
> >> mode and mmaped memory region allocated by other memory allocators.
> userptr
> >> interface can identify memory type through vm_flags value and would get
> >> pages or page frame numbers to user space appropriately.
> >
> > I apologize for being a little late to jump in on this thread, but...
> >
> > I must confess to not being a huge fan of userptr. ?It really is
> > opening a can of worms, and seems best avoided if at all possible.
> > I'm not entirely sure the use-case for which you require this, but I
> > wonder if there isn't an alternative way? ? I mean, the main case I
> > could think of for mapping userspace memory would be something like
> > texture upload. ?But could that be handled in an alternative way,
> > something like a pwrite or texture_upload API, which could temporarily
> > pin the userspace memory, kick off a dma from that user buffer to a
> > proper GEM buffer, and then unpin the user buffer when the DMA
> > completes?
> 
> I'm with Rob on this, I really hate the userptr idea, and my problem
> with letting it into exynos is it sets a benchmark for others to do
> things the same way. I'm still not 100% sure how its going to be used
> even with all your explainations.
> 
> Since we've agreed only the X server can access the interface, it
> makes 0 sense to me to exist at all, as the X server can avoid malloc
> memory for all objects it accesses.
> 
> I don't think pixman is at the level where you should be acceleration
> it directly. I thought the point of pixman was a fast SW engine, not
> something to be trunked down to a hw engine. The idea being you use
> cairo and backend it onto something.
> 

For more understanding, PIXMAN draws something on shmem and next id of the
shmem is sent to X and next X gets user address to the id and next EXA's gpu
backend does BitBLT using gpu hardware. However, the gpu backend doesn't
aware of the user address so the purpose of using userptr is to import the
shmem into a gem object for gpu to aware of the memory region as source. so
pixman would use SW engine as is.

> I know ssp had some ideas for making pixman be able to do hw accel,
> but userptr doesn't seem like the proper solution, it seems like a
> hack that needs a lot more VM work to operate properly, and by setting
> a precedent for one GPU driver, I'll have 20 implementations of this
> from ARM vendors and nobody will ever go back and fix things properly.
> 

I'm not sure that this is a hack or not but thing similar to this is being
used at via driver. you can refer to via_lock_all_dma_pages function of
via_dmablit.c file and this driver also uses get_user_pages() to lock all
the pages to the user space for DMA to access the memory region, maybe for
BitBLT. And I really wonder you think just using get_user_pages() is a hack
or importing user address into a gem object. there may be my
misunderstanding so give me any comments.

Thanks,
Inki Dae

> So I'm really not sure the best way to move this forward, maybe a very
> clear set of use cases of where stuff plugs into this, and why dma-buf
> or some other method isn't sufficient, but I'm having trouble getting
> past the fact its setting a dangerous precedent.
> 
> Dave.

[PATCH 3/4] drm/exynos: added userptr feature.



> -Original Message-
> From: robdclark at gmail.com [mailto:robdclark at gmail.com] On Behalf Of Rob
> Clark
> Sent: Wednesday, May 16, 2012 5:43 PM
> To: Inki Dae
> Cc: InKi Dae; kyungmin.park at samsung.com; sw0312.kim at samsung.com; dri-
> devel at lists.freedesktop.org
> Subject: Re: [PATCH 3/4] drm/exynos: added userptr feature.
> 
> On Wed, May 16, 2012 at 12:04 AM, Inki Dae  wrote:
> >
> >
> >> -Original Message-
> >> From: robdclark at gmail.com [mailto:robdclark at gmail.com] On Behalf Of 
> >> Rob
> >> Clark
> >> Sent: Tuesday, May 15, 2012 11:29 PM
> >> To: InKi Dae
> >> Cc: Inki Dae; kyungmin.park at samsung.com; sw0312.kim at samsung.com; dri-
> >> devel at lists.freedesktop.org
> >> Subject: Re: [PATCH 3/4] drm/exynos: added userptr feature.
> >>
> >> On Tue, May 15, 2012 at 7:40 AM, InKi Dae  wrote:
> >> > 2012/5/15 Rob Clark :
> >> >> On Tue, May 15, 2012 at 2:17 AM, Inki Dae 
> wrote:
> >> >>> Hi Rob,
> >> >>>
> >>  -Original Message-
> >>  From: robdclark at gmail.com [mailto:robdclark at gmail.com] On Behalf
> Of
> >> Rob
> >>  Clark
> >>  Sent: Tuesday, May 15, 2012 4:35 PM
> >>  To: Inki Dae
> >>  Cc: airlied at linux.ie; dri-devel at lists.freedesktop.org;
> >>  kyungmin.park at samsung.com; sw0312.kim at samsung.com
> >>  Subject: Re: [PATCH 3/4] drm/exynos: added userptr feature.
> >> 
> >>  On Mon, Apr 23, 2012 at 7:43 AM, Inki Dae 
> >> wrote:
> >>  > this feature could be used to use memory region allocated by
> >> malloc() in
> >>  user
> >>  > mode and mmaped memory region allocated by other memory
> allocators.
> >>  userptr
> >>  > interface can identify memory type through vm_flags value and
> would
> >> get
> >>  > pages or page frame numbers to user space appropriately.
> >> 
> >>  I apologize for being a little late to jump in on this thread,
> but...
> >> 
> >>  I must confess to not being a huge fan of userptr. ?It really is
> >>  opening a can of worms, and seems best avoided if at all possible.
> >>  I'm not entirely sure the use-case for which you require this, but
> I
> >>  wonder if there isn't an alternative way? ? I mean, the main case
> I
> >>  could think of for mapping userspace memory would be something
> like
> >>  texture upload. ?But could that be handled in an alternative way,
> >>  something like a pwrite or texture_upload API, which could
> >> temporarily
> >>  pin the userspace memory, kick off a dma from that user buffer to
> a
> >>  proper GEM buffer, and then unpin the user buffer when the DMA
> >>  completes?
> >> 
> >> >>>
> >> >>> This feature have being discussed with drm and linux-mm guys and I
> >> have
> >> >>> posted this patch four times.
> >> >>> So please, see below e-mail threads.
> >> >>> http://www.spinics.net/lists/dri-devel/msg22729.html
> >> >>>
> >> >>> and then please, give me your opinions.
> >> >>
> >> >>
> >> >> Yeah, I read that and understand that the purpose is to support
> >> >> malloc()'d memory (and btw, all the other changes like limits to the
> >> >> amount of userptr buffers are good if we do decide to support
> userptr
> >> >> buffers). ?But my question was more about why do you need to support
> >> >> malloc'd buffers... other than "just because v4l2 does" ;-)
> >> >>
> >> >> I don't really like the userptr feature in v4l2 either, and view it
> as
> >> >> a necessary evil because at the time there was nothing like dmabuf.
> >> >> But now that we have dmabuf to share buffers with zero copy between
> >> >> two devices, to we *really* still need userptr?
> >> >>
> >> >
> >> > Definitely no, as I mentioned on this email thread, we are using the
> >> > userptr feature for pixman and evas
> >> > backend to use gpu acceleration directly(zero-copy). as you may know,
> >> > Evas is part of the Enlightenment Foundation Libraries(EFL) and
> >> > Elementary for pixman. all the applicaions based on them uses user
> >> > address to draw something so the backends(such as gpu accelerators)
> >> > can refer to only the user address to the buffer rendered. do you
> >> > think we can avoid memory copy to use those GPUs without such userptr
> >> > feature? I think there is no way and only the way that the gpu uses
> >> > the user address to render without memory copy. and as mentioned on
> >> > this thread, this feature had been tried by i915 in the desktop
world.
> >> > for this, you can refer to Daniel's comments.
> >>
> >> oh, yeah, for something like pixman it is hard to accelerate. ?But I
> >> wonder if there is still some benefit. ?I don't know as much about
> >> evas, but pixman is assumed to be a synchronous API, so you must
> >> always block until the operation completes which looses a lot of the
> >> potential benefit of a blitter. ?And also I think you have no control
> >> over when the client free()'s a buffer. ?So you end up having to
> >> map/unmap the buffer to the

[PATCH 3/4] drm/exynos: added userptr feature.

On Wed, May 16, 2012 at 4:20 AM, Inki Dae  wrote:
>
>
>> -Original Message-
>> From: Dave Airlie [mailto:airlied at gmail.com]
>> Sent: Wednesday, May 16, 2012 6:23 PM
>> To: Rob Clark
>> Cc: Inki Dae; kyungmin.park at samsung.com; sw0312.kim at samsung.com; dri-
>> devel at lists.freedesktop.org
>> Subject: Re: [PATCH 3/4] drm/exynos: added userptr feature.
>>
>> On Tue, May 15, 2012 at 8:34 AM, Rob Clark  wrote:
>> > On Mon, Apr 23, 2012 at 7:43 AM, Inki Dae  wrote:
>> >> this feature could be used to use memory region allocated by malloc()
>> in user
>> >> mode and mmaped memory region allocated by other memory allocators.
>> userptr
>> >> interface can identify memory type through vm_flags value and would get
>> >> pages or page frame numbers to user space appropriately.
>> >
>> > I apologize for being a little late to jump in on this thread, but...
>> >
>> > I must confess to not being a huge fan of userptr. ?It really is
>> > opening a can of worms, and seems best avoided if at all possible.
>> > I'm not entirely sure the use-case for which you require this, but I
>> > wonder if there isn't an alternative way? ? I mean, the main case I
>> > could think of for mapping userspace memory would be something like
>> > texture upload. ?But could that be handled in an alternative way,
>> > something like a pwrite or texture_upload API, which could temporarily
>> > pin the userspace memory, kick off a dma from that user buffer to a
>> > proper GEM buffer, and then unpin the user buffer when the DMA
>> > completes?
>>
>> I'm with Rob on this, I really hate the userptr idea, and my problem
>> with letting it into exynos is it sets a benchmark for others to do
>> things the same way. I'm still not 100% sure how its going to be used
>> even with all your explainations.
>>
>> Since we've agreed only the X server can access the interface, it
>> makes 0 sense to me to exist at all, as the X server can avoid malloc
>> memory for all objects it accesses.
>>
>> I don't think pixman is at the level where you should be acceleration
>> it directly. I thought the point of pixman was a fast SW engine, not
>> something to be trunked down to a hw engine. The idea being you use
>> cairo and backend it onto something.
>>
>
> For more understanding, PIXMAN draws something on shmem and next id of the
> shmem is sent to X and next X gets user address to the id and next EXA's gpu
> backend does BitBLT using gpu hardware. However, the gpu backend doesn't
> aware of the user address so the purpose of using userptr is to import the
> shmem into a gem object for gpu to aware of the memory region as source. so
> pixman would use SW engine as is.

if this is all just for X/EXA, wouldn't it make more sense to handle
the operation at the EXA layer before falling back to sw (which would
go to pixman)?

>> I know ssp had some ideas for making pixman be able to do hw accel,
>> but userptr doesn't seem like the proper solution, it seems like a
>> hack that needs a lot more VM work to operate properly, and by setting
>> a precedent for one GPU driver, I'll have 20 implementations of this
>> from ARM vendors and nobody will ever go back and fix things properly.
>>
>
> I'm not sure that this is a hack or not but thing similar to this is being
> used at via driver. you can refer to via_lock_all_dma_pages function of
> via_dmablit.c file and this driver also uses get_user_pages() to lock all
> the pages to the user space for DMA to access the memory region, maybe for
> BitBLT. And I really wonder you think just using get_user_pages() is a hack
> or importing user address into a gem object. there may be my
> misunderstanding so give me any comments.

My objection is not really the get_user_pages(), but rather converting
that into a GEM object, which might exist for longer period of time,
be exported to dmabuf and passed to other driver, etc.  (Not to
mention you don't really have control if userspace does free(ptr)
while the GEM object still exists..)

No subject

2012-05-16 Thread

is still queued, which I don't completely like but at least the
pinning and hw use of the userspace buffer is just temporary and not
able to exist for an indefinite amount of time.

BR,
-R

> Thanks,
> Inki Dae
>
>> So I'm really not sure the best way to move this forward, maybe a very
>> clear set of use cases of where stuff plugs into this, and why dma-buf
>> or some other method isn't sufficient, but I'm having trouble getting
>> past the fact its setting a dangerous precedent.
>>
>> Dave.
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/4] drm/exynos: added userptr feature.



> -Original Message-
> From: robdclark at gmail.com [mailto:robdclark at gmail.com] On Behalf Of Rob
> Clark
> Sent: Wednesday, May 16, 2012 9:13 PM
> To: Inki Dae
> Cc: Dave Airlie; kyungmin.park at samsung.com; sw0312.kim at samsung.com; dri-
> devel at lists.freedesktop.org
> Subject: Re: [PATCH 3/4] drm/exynos: added userptr feature.
> 
> On Wed, May 16, 2012 at 4:20 AM, Inki Dae  wrote:
> >
> >
> >> -Original Message-
> >> From: Dave Airlie [mailto:airlied at gmail.com]
> >> Sent: Wednesday, May 16, 2012 6:23 PM
> >> To: Rob Clark
> >> Cc: Inki Dae; kyungmin.park at samsung.com; sw0312.kim at samsung.com; dri-
> >> devel at lists.freedesktop.org
> >> Subject: Re: [PATCH 3/4] drm/exynos: added userptr feature.
> >>
> >> On Tue, May 15, 2012 at 8:34 AM, Rob Clark 
wrote:
> >> > On Mon, Apr 23, 2012 at 7:43 AM, Inki Dae 
> wrote:
> >> >> this feature could be used to use memory region allocated by
malloc()
> >> in user
> >> >> mode and mmaped memory region allocated by other memory allocators.
> >> userptr
> >> >> interface can identify memory type through vm_flags value and would
> get
> >> >> pages or page frame numbers to user space appropriately.
> >> >
> >> > I apologize for being a little late to jump in on this thread, but...
> >> >
> >> > I must confess to not being a huge fan of userptr. ?It really is
> >> > opening a can of worms, and seems best avoided if at all possible.
> >> > I'm not entirely sure the use-case for which you require this, but I
> >> > wonder if there isn't an alternative way? ? I mean, the main case I
> >> > could think of for mapping userspace memory would be something like
> >> > texture upload. ?But could that be handled in an alternative way,
> >> > something like a pwrite or texture_upload API, which could
> temporarily
> >> > pin the userspace memory, kick off a dma from that user buffer to a
> >> > proper GEM buffer, and then unpin the user buffer when the DMA
> >> > completes?
> >>
> >> I'm with Rob on this, I really hate the userptr idea, and my problem
> >> with letting it into exynos is it sets a benchmark for others to do
> >> things the same way. I'm still not 100% sure how its going to be used
> >> even with all your explainations.
> >>
> >> Since we've agreed only the X server can access the interface, it
> >> makes 0 sense to me to exist at all, as the X server can avoid malloc
> >> memory for all objects it accesses.
> >>
> >> I don't think pixman is at the level where you should be acceleration
> >> it directly. I thought the point of pixman was a fast SW engine, not
> >> something to be trunked down to a hw engine. The idea being you use
> >> cairo and backend it onto something.
> >>
> >
> > For more understanding, PIXMAN draws something on shmem and next id of
> the
> > shmem is sent to X and next X gets user address to the id and next EXA's
> gpu
> > backend does BitBLT using gpu hardware. However, the gpu backend doesn't
> > aware of the user address so the purpose of using userptr is to import
> the
> > shmem into a gem object for gpu to aware of the memory region as source.
> so
> > pixman would use SW engine as is.
> 
> if this is all just for X/EXA, wouldn't it make more sense to handle
> the operation at the EXA layer before falling back to sw (which would
> go to pixman)?
> 

Note that PIXMAN is also used as backend of Evas amd the shmem is sent to
EXA backend of X to use gpu.(not same process)

> >> I know ssp had some ideas for making pixman be able to do hw accel,
> >> but userptr doesn't seem like the proper solution, it seems like a
> >> hack that needs a lot more VM work to operate properly, and by setting
> >> a precedent for one GPU driver, I'll have 20 implementations of this
> >> from ARM vendors and nobody will ever go back and fix things properly.
> >>
> >
> > I'm not sure that this is a hack or not but thing similar to this is
> being
> > used at via driver. you can refer to via_lock_all_dma_pages function of
> > via_dmablit.c file and this driver also uses get_user_pages() to lock
> all
> > the pages to the user space for DMA to access the memory region, maybe
> for
> > BitBLT. And I really wonder you think just using get_user_pages() is a
> hack
> > or importing user address into a gem object. there may be my
> > misunderstanding so give me any comments.
> 
> My objection is not really the get_user_pages(), but rather converting
> that into a GEM object, which might exist for longer period of time,
> be exported to dmabuf and passed to other driver, etc.  (Not to
> mention you don't really have control if userspace does free(ptr)
> while the GEM object still exists..)
> 

Hm...Good point. ok, got it. I gonna stop it forward. Instead, we will
follow the via way for next so do you agree that the via way has no any
problem?

Thanks,
Inki Dae

> From a quick look at the via code, it appears to return while the blit
> is still queued, which I don't completely like but at least the
> pinning and hw use of the userspace

[Bug 49794] HD5850 clocks are always limited to 400/900

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

--- Comment #6 from ddfs <32167 at bk.ru> 2012-05-16 06:47:41 PDT ---
Any updates on this? Did the attached bios help?

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

[PATCH] drm: gma500: Kill the GEM glue layer

The private gem_create_mmap_offset() function is now implemented in the
DRM core as drm_gem_create_mmap_offset(). Use it and kill the private
copy.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/gma500/Makefile   |2 +-
 drivers/gpu/drm/gma500/gem.c  |9 +++-
 drivers/gpu/drm/gma500/gem_glue.c |   90 -
 drivers/gpu/drm/gma500/gem_glue.h |2 -
 drivers/gpu/drm/gma500/psb_drv.h  |1 -
 5 files changed, 8 insertions(+), 96 deletions(-)
 delete mode 100644 drivers/gpu/drm/gma500/gem_glue.c
 delete mode 100644 drivers/gpu/drm/gma500/gem_glue.h

The patch has been compile-tested only due to lack of test hardware.

diff --git a/drivers/gpu/drm/gma500/Makefile b/drivers/gpu/drm/gma500/Makefile
index 1583982..85b7449 100644
--- a/drivers/gpu/drm/gma500/Makefile
+++ b/drivers/gpu/drm/gma500/Makefile
@@ -3,7 +3,7 @@
 #
 ccflags-y += -Iinclude/drm

-gma500_gfx-y += gem_glue.o \
+gma500_gfx-y += \
  accel_2d.o \
  backlight.o \
  framebuffer.o \
diff --git a/drivers/gpu/drm/gma500/gem.c b/drivers/gpu/drm/gma500/gem.c
index 9fbb868..f2a2e9b 100644
--- a/drivers/gpu/drm/gma500/gem.c
+++ b/drivers/gpu/drm/gma500/gem.c
@@ -36,7 +36,12 @@ int psb_gem_init_object(struct drm_gem_object *obj)
 void psb_gem_free_object(struct drm_gem_object *obj)
 {
struct gtt_range *gtt = container_of(obj, struct gtt_range, gem);
-   drm_gem_object_release_wrap(obj);
+
+   /* Remove the list map if one is present */
+   if (obj->map_list.map)
+   drm_gem_free_mmap_offset(obj);
+   drm_gem_object_release(obj);
+
/* This must occur last as it frees up the memory of the GEM object */
psb_gtt_free_range(obj->dev, gtt);
 }
@@ -77,7 +82,7 @@ int psb_gem_dumb_map_gtt(struct drm_file *file, struct 
drm_device *dev,

/* Make it mmapable */
if (!obj->map_list.map) {
-   ret = gem_create_mmap_offset(obj);
+   ret = drm_gem_create_mmap_offset(obj);
if (ret)
goto out;
}
diff --git a/drivers/gpu/drm/gma500/gem_glue.c 
b/drivers/gpu/drm/gma500/gem_glue.c
deleted file mode 100644
index 3c17634..000
--- a/drivers/gpu/drm/gma500/gem_glue.c
+++ /dev/null
@@ -1,90 +0,0 @@
-/**
- * Copyright (c) 2011, Intel Corporation.
- * All Rights Reserved.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * version 2, as published by the Free Software Foundation.
- *
- * This program is distributed in the hope 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 St - Fifth Floor, Boston, MA 02110-1301 USA.
- *
- **/
-
-#include 
-#include 
-#include "gem_glue.h"
-
-void drm_gem_object_release_wrap(struct drm_gem_object *obj)
-{
-   /* Remove the list map if one is present */
-   if (obj->map_list.map) {
-   struct drm_gem_mm *mm = obj->dev->mm_private;
-   struct drm_map_list *list = >map_list;
-   drm_ht_remove_item(>offset_hash, >hash);
-   drm_mm_put_block(list->file_offset_node);
-   kfree(list->map);
-   list->map = NULL;
-   }
-   drm_gem_object_release(obj);
-}
-
-/**
- * gem_create_mmap_offset  -   invent an mmap offset
- * @obj: our object
- *
- * Standard implementation of offset generation for mmap as is
- * duplicated in several drivers. This belongs in GEM.
- */
-int gem_create_mmap_offset(struct drm_gem_object *obj)
-{
-   struct drm_device *dev = obj->dev;
-   struct drm_gem_mm *mm = dev->mm_private;
-   struct drm_map_list *list;
-   struct drm_local_map *map;
-   int ret;
-
-   list = >map_list;
-   list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
-   if (list->map == NULL)
-   return -ENOMEM;
-   map = list->map;
-   map->type = _DRM_GEM;
-   map->size = obj->size;
-   map->handle = obj;
-
-   list->file_offset_node = drm_mm_search_free(>offset_manager,
-   obj->size / PAGE_SIZE, 0, 0);
-   if (!list->file_offset_node) {
-   dev_err(dev->dev, "failed to allocate offset for bo %d\n",
-   obj->name);
-   ret = -ENOSPC;
-   goto free_it;
-   }
-   list->file_offset_node = drm_mm_get_block(list->file_offset_node,
-

[PATCH] drm: gma500: Kill the GEM glue layer

2012-05-16 Thread Alan Cox

On Wed, 16 May 2012 16:59:44 +0200
Laurent Pinchart  wrote:

> The private gem_create_mmap_offset() function is now implemented in the
> DRM core as drm_gem_create_mmap_offset(). Use it and kill the private
> copy.
> 

That was always then plan so yes - I'll fold this into my tree and test
it.

Alan

[PATCH 0/4] Miscellaneous Exynos DRM patches

Hello,

While studying the DRM core I came across a couple of issues or strange
constructs in the Exynos DRM driver. Here are 4 patches that fix them.

The patches have only been compile-tested for lack of testing hardware. I
apologize in advance if my lack of experience with the DRM subsystem resulted
in any wrong patch.

Laurent Pinchart (4):
  drm: exynos: DRIVER_BUS_PLATFORM is not a driver feature
  drm: exynos: Remove dummy encoder get_crtc operation implementation
  drm: exynos: Don't cast GEM object to Exynos GEM object when not
needed
  drm: exynos: Keep a reference to frame buffer GEM objects

 drivers/gpu/drm/exynos/exynos_drm_drv.c |3 +--
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |7 ---
 drivers/gpu/drm/exynos/exynos_drm_fb.c  |   19 ++-
 drivers/gpu/drm/exynos/exynos_drm_gem.c |9 +++--
 4 files changed, 18 insertions(+), 20 deletions(-)

-- 
Regards,

Laurent Pinchart

[PATCH 1/4] drm: exynos: DRIVER_BUS_PLATFORM is not a driver feature

DRIVER_BUS_PLATFORM is a bus type used internally in the DRM core, not a
flag for the drm_driver::driver_features field.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/exynos/exynos_drm_drv.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 67a67b0..0080102 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -224,8 +224,7 @@ static const struct file_operations exynos_drm_driver_fops 
= {
 };

 static struct drm_driver exynos_drm_driver = {
-   .driver_features= DRIVER_HAVE_IRQ | DRIVER_BUS_PLATFORM |
- DRIVER_MODESET | DRIVER_GEM,
+   .driver_features= DRIVER_HAVE_IRQ | DRIVER_MODESET | DRIVER_GEM,
.load   = exynos_drm_load,
.unload = exynos_drm_unload,
.open   = exynos_drm_open,
-- 
1.7.3.4

[PATCH 3/4] drm: exynos: Don't cast GEM object to Exynos GEM object when not needed

The exynos_drm_gem_dumb_map_offset() doesn't need to access any
Exynos-specific GEM object fields, don't cast the GEM object.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/exynos/exynos_drm_gem.c |9 +++--
 1 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c 
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index 1dffa83..a3362c9 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -638,7 +638,6 @@ int exynos_drm_gem_dumb_map_offset(struct drm_file 
*file_priv,
   struct drm_device *dev, uint32_t handle,
   uint64_t *offset)
 {
-   struct exynos_drm_gem_obj *exynos_gem_obj;
struct drm_gem_object *obj;
int ret = 0;

@@ -659,15 +658,13 @@ int exynos_drm_gem_dumb_map_offset(struct drm_file 
*file_priv,
goto unlock;
}

-   exynos_gem_obj = to_exynos_gem_obj(obj);
-
-   if (!exynos_gem_obj->base.map_list.map) {
-   ret = drm_gem_create_mmap_offset(_gem_obj->base);
+   if (!obj->map_list.map) {
+   ret = drm_gem_create_mmap_offset(obj);
if (ret)
goto out;
}

-   *offset = (u64)exynos_gem_obj->base.map_list.hash.key << PAGE_SHIFT;
+   *offset = (u64)obj->map_list.hash.key << PAGE_SHIFT;
DRM_DEBUG_KMS("offset = 0x%lx\n", (unsigned long)*offset);

 out:
-- 
1.7.3.4

[PATCH 2/4] drm: exynos: Remove dummy encoder get_crtc operation implementation

The encoder get_crtc operation is called to retrieve a pointer to the
CRTC the encoder is currenctly connected to, right after setting the
encoder::crtc field to the new CRTC. The implementation of this
operation returns the pointer to the new CRTC, which is then pointlessly
compared to itself.

As the operation is not mandatory, don't implement it.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |7 ---
 1 files changed, 0 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_encoder.c 
b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
index 6e9ac7b..23d5ad3 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_encoder.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_encoder.c
@@ -172,19 +172,12 @@ static void exynos_drm_encoder_commit(struct drm_encoder 
*encoder)
manager_ops->commit(manager->dev);
 }

-static struct drm_crtc *
-exynos_drm_encoder_get_crtc(struct drm_encoder *encoder)
-{
-   return encoder->crtc;
-}
-
 static struct drm_encoder_helper_funcs exynos_encoder_helper_funcs = {
.dpms   = exynos_drm_encoder_dpms,
.mode_fixup = exynos_drm_encoder_mode_fixup,
.mode_set   = exynos_drm_encoder_mode_set,
.prepare= exynos_drm_encoder_prepare,
.commit = exynos_drm_encoder_commit,
-   .get_crtc   = exynos_drm_encoder_get_crtc,
 };

 static void exynos_drm_encoder_destroy(struct drm_encoder *encoder)
-- 
1.7.3.4

[PATCH 4/4] drm: exynos: Keep a reference to frame buffer GEM objects

GEM objects used by frame buffers must be referenced for the whole life
of the frame buffer. Release the references in the frame buffer
destructor instead of its constructor.

Signed-off-by: Laurent Pinchart 
---
 drivers/gpu/drm/exynos/exynos_drm_fb.c |   19 ++-
 1 files changed, 14 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c 
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index f82a299..4ccfe43 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -51,11 +51,22 @@ struct exynos_drm_fb {
 static void exynos_drm_fb_destroy(struct drm_framebuffer *fb)
 {
struct exynos_drm_fb *exynos_fb = to_exynos_fb(fb);
+   unsigned int i;

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

drm_framebuffer_cleanup(fb);

+   for (i = 0; i < ARRAY_SIZE(exynos_fb->exynos_gem_obj); i++) {
+   struct drm_gem_object *obj;
+
+   if (exynos_fb->exynos_gem_obj[i] == NULL)
+   continue;
+
+   obj = _fb->exynos_gem_obj[i]->base;
+   drm_gem_object_unreference_unlocked(obj);
+   }
+
kfree(exynos_fb);
exynos_fb = NULL;
 }
@@ -134,11 +145,11 @@ exynos_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,
return ERR_PTR(-ENOENT);
}

-   drm_gem_object_unreference_unlocked(obj);
-
fb = exynos_drm_framebuffer_init(dev, mode_cmd, obj);
-   if (IS_ERR(fb))
+   if (IS_ERR(fb)) {
+   drm_gem_object_unreference_unlocked(obj);
return fb;
+   }

exynos_fb = to_exynos_fb(fb);
nr = exynos_drm_format_num_buffers(fb->pixel_format);
@@ -152,8 +163,6 @@ exynos_user_fb_create(struct drm_device *dev, struct 
drm_file *file_priv,
return ERR_PTR(-ENOENT);
}

-   drm_gem_object_unreference_unlocked(obj);
-
exynos_fb->exynos_gem_obj[i] = to_exynos_gem_obj(obj);
}

-- 
1.7.3.4

[Bug 49794] HD5850 clocks are always limited to 400/900

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

--- Comment #7 from dr.andru at gmail.com 2012-05-16 08:47:51 PDT ---
Created attachment 61719
  --> https://bugs.freedesktop.org/attachment.cgi?id=61719
Overclocked Radeon HD 5850 BIOS

Same problem here. The only difference is in vendor of videocard and
frequencies(I have HIS Radeon HD 5850 with 850/1200, BIOS attached). System
uses only limited 400/900(30 kHz/90 kHz to be correct).

kernel: 3.3.6
xf86-video-ati: 6.14.4

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

[Bug 48747] regression [bisected]: display corruption in google earth/glxgears using git r600g on RS780M

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

Michel D?nzer  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #9 from Michel D?nzer  2012-05-16 09:59:25 
PDT ---
Commit: 11f056a3f0b87e86267efa8b5ac9d36a343c9dc1
Author: Michel D?nzer 
Date:   Wed May 16 17:45:17 2012 +0200

r600g: Set tiling information for BOs being shared.

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

[Bug 50014] New: kwin with desktop effects crashes in r100_cs_track_texture_check on Radeon Mobility M6 LY

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

 Bug #: 50014
   Summary: kwin with desktop effects crashes in
r100_cs_track_texture_check on Radeon Mobility M6 LY
Classification: Unclassified
   Product: Mesa
   Version: 8.0
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: orion at cora.nwra.com


Created attachment 61728
  --> https://bugs.freedesktop.org/attachment.cgi?id=61728
dmesg

Running F17 pre-release:

mesa-dri-drivers-8.0.2-2.fc17.i686
xorg-x11-server-Xorg-1.12.0-5.fc17.i686
kernel-3.3.4-5.fc17.i686

Shortly after login kwin exits and I see the following in dmesg:

[78710.577862] [drm:r100_cs_track_texture_check] *ERROR* Texture of unit 0
needs 273439296 bytes but is 3145728
[78710.577869] [drm:r100_cs_track_texture_print] *ERROR* pitch 
16536
[78710.577873] [drm:r100_cs_track_texture_print] *ERROR* use_pitch 
1
[78710.577876] [drm:r100_cs_track_texture_print] *ERROR* width 
16536
[78710.577879] [drm:r100_cs_track_texture_print] *ERROR* width_11  
2048
[78710.577882] [drm:r100_cs_track_texture_print] *ERROR* height
16536
[78710.577885] [drm:r100_cs_track_texture_print] *ERROR* height_11 
2048
[78710.577888] [drm:r100_cs_track_texture_print] *ERROR* num levels
0
[78710.577891] [drm:r100_cs_track_texture_print] *ERROR* depth 
0
[78710.577894] [drm:r100_cs_track_texture_print] *ERROR* bpp   
4
[78710.577897] [drm:r100_cs_track_texture_print] *ERROR* coordinate type   
0
[78710.577900] [drm:r100_cs_track_texture_print] *ERROR* width round to power
of 2  0
[78710.577903] [drm:r100_cs_track_texture_print] *ERROR* height round to power
of 2 0
[78710.577905] [drm:r100_cs_track_texture_print] *ERROR* compress format   
0
[78710.577909] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !
[79054.090196] [drm:r100_cs_track_texture_check] *ERROR* Texture of unit 0
needs 273439296 bytes but is 3145728
[79054.090204] [drm:r100_cs_track_texture_print] *ERROR* pitch 
16536
[79054.090207] [drm:r100_cs_track_texture_print] *ERROR* use_pitch 
1
[79054.090210] [drm:r100_cs_track_texture_print] *ERROR* width 
16536
[79054.090213] [drm:r100_cs_track_texture_print] *ERROR* width_11  
2048
[79054.090216] [drm:r100_cs_track_texture_print] *ERROR* height
16536
[79054.090219] [drm:r100_cs_track_texture_print] *ERROR* height_11 
2048
[79054.090222] [drm:r100_cs_track_texture_print] *ERROR* num levels
0
[79054.090225] [drm:r100_cs_track_texture_print] *ERROR* depth 
0
[79054.090228] [drm:r100_cs_track_texture_print] *ERROR* bpp   
4
[79054.090231] [drm:r100_cs_track_texture_print] *ERROR* coordinate type   
0
[79054.090234] [drm:r100_cs_track_texture_print] *ERROR* width round to power
of 2  0
[79054.090237] [drm:r100_cs_track_texture_print] *ERROR* height round to power
of 2 0
[79054.090239] [drm:r100_cs_track_texture_print] *ERROR* compress format   
0
[79054.090243] [drm:radeon_cs_ib_chunk] *ERROR* Invalid command stream !

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

[Bug 50014] kwin with desktop effects crashes in r100_cs_track_texture_check on Radeon Mobility M6 LY

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

--- Comment #1 from Orion Poplawski  2012-05-16 
10:17:01 PDT ---
Created attachment 61729
  --> https://bugs.freedesktop.org/attachment.cgi?id=61729
Xorg.0.log

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

[PATCH 2/2] drm: add plane properties

2012/5/16 Rob Clark :
> From: Rob Clark 
>
> The omapdrm driver uses this for setting per-overlay rotation. ?It
> is likely also useful for setting YUV->RGB colorspace conversion
> matrix, etc.
>
> Signed-off-by: Rob Clark 

Please add comments inside include/drm/drm_crtc.h documenting the new
added fields of drm_plane_funcs and drm_funcs (we already have
descriptions of all the other fields).

With that:
Reviewed-by: Paulo Zanoni 

> ---
> ?drivers/gpu/drm/drm_crtc.c | ? 19 +++
> ?include/drm/drm_crtc.h ? ? | ? ?5 +
> ?2 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 022873e..a9b2b497 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -606,6 +606,7 @@ int drm_plane_init(struct drm_device *dev, struct 
> drm_plane *plane,
> ? ? ? ?if (ret)
> ? ? ? ? ? ? ? ?goto out;
>
> + ? ? ? plane->base.properties = >properties;
> ? ? ? ?plane->dev = dev;
> ? ? ? ?plane->funcs = funcs;
> ? ? ? ?plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
> @@ -3155,6 +3156,21 @@ static int drm_mode_crtc_set_obj_prop(struct 
> drm_mode_object *obj,
> ? ? ? ?return ret;
> ?}
>
> +static int drm_mode_plane_set_obj_prop(struct drm_mode_object *obj,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 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);
> + ? ? ? if (!ret)
> + ? ? ? ? ? ? ? drm_object_property_set_value(obj, property, value);
> +
> + ? ? ? return ret;
> +}
> +
> ?int drm_mode_obj_get_properties_ioctl(struct drm_device *dev, void *data,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?struct drm_file *file_priv)
> ?{
> @@ -3256,6 +3272,9 @@ int drm_mode_obj_set_property_ioctl(struct drm_device 
> *dev, void *data,
> ? ? ? ?case DRM_MODE_OBJECT_CRTC:
> ? ? ? ? ? ? ? ?ret = drm_mode_crtc_set_obj_prop(arg_obj, property, 
> arg->value);
> ? ? ? ? ? ? ? ?break;
> + ? ? ? case DRM_MODE_OBJECT_PLANE:
> + ? ? ? ? ? ? ? ret = drm_mode_plane_set_obj_prop(arg_obj, property, 
> arg->value);
> + ? ? ? ? ? ? ? break;
> ? ? ? ?}
>
> ?out:
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 39e3e1c..c23789c 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -618,6 +618,9 @@ struct drm_plane_funcs {
> ? ? ? ? ? ? ? ? ? ? ? ? ? ?uint32_t src_w, uint32_t src_h);
> ? ? ? ?int (*disable_plane)(struct drm_plane *plane);
> ? ? ? ?void (*destroy)(struct drm_plane *plane);
> +
> + ? ? ? int (*set_property)(struct drm_plane *plane,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? struct drm_property *property, uint64_t val);
> ?};
>
> ?/**
> @@ -657,6 +660,8 @@ struct drm_plane {
>
> ? ? ? ?const struct drm_plane_funcs *funcs;
> ? ? ? ?void *helper_private;
> +
> + ? ? ? struct drm_object_properties properties;
> ?};
>
> ?/**
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Paulo Zanoni

[PATCH 1/2] drm: add bitmask property type

2012/5/16 Rob Clark :
> From: Rob Clark 
>
> A bitmask property is similar to an enum. ?The enum value is a bit
> position (0-63), and valid property values consist of a mask of
> zero or more of (1 << enum_val[n]).
>
> Signed-off-by: Rob Clark 


"int num_values" appears after column 80 in 2 places


Reviewed-by: Paulo Zanoni 

> ---
> ?drivers/gpu/drm/drm_crtc.c | ? 46 
> +---
> ?include/drm/drm_crtc.h ? ? | ? ?3 +++
> ?include/drm/drm_mode.h ? ? | ? ?1 +
> ?3 files changed, 47 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 75661c8..022873e 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -2707,6 +2707,33 @@ struct drm_property *drm_property_create_enum(struct 
> drm_device *dev, int flags,
> ?}
> ?EXPORT_SYMBOL(drm_property_create_enum);
>
> +struct drm_property *drm_property_create_bitmask(struct drm_device *dev,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?int flags, const char *name,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?const struct drm_prop_enum_list 
> *props, int num_values)
> +{
> + ? ? ? struct drm_property *property;
> + ? ? ? int i, ret;
> +
> + ? ? ? flags |= DRM_MODE_PROP_BITMASK;
> +
> + ? ? ? property = drm_property_create(dev, flags, name, num_values);
> + ? ? ? if (!property)
> + ? ? ? ? ? ? ? return NULL;
> +
> + ? ? ? for (i = 0; i < num_values; i++) {
> + ? ? ? ? ? ? ? ret = drm_property_add_enum(property, i,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? props[i].type,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? props[i].name);
> + ? ? ? ? ? ? ? if (ret) {
> + ? ? ? ? ? ? ? ? ? ? ? drm_property_destroy(dev, property);
> + ? ? ? ? ? ? ? ? ? ? ? return NULL;
> + ? ? ? ? ? ? ? }
> + ? ? ? }
> +
> + ? ? ? return property;
> +}
> +EXPORT_SYMBOL(drm_property_create_bitmask);
> +
> ?struct drm_property *drm_property_create_range(struct drm_device *dev, int 
> flags,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? const char *name,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? uint64_t min, uint64_t max)
> @@ -2731,7 +2758,14 @@ int drm_property_add_enum(struct drm_property 
> *property, int index,
> ?{
> ? ? ? ?struct drm_property_enum *prop_enum;
>
> - ? ? ? if (!(property->flags & DRM_MODE_PROP_ENUM))
> + ? ? ? if (!(property->flags & (DRM_MODE_PROP_ENUM | DRM_MODE_PROP_BITMASK)))
> + ? ? ? ? ? ? ? return -EINVAL;
> +
> + ? ? ? /*
> + ? ? ? ?* Bitmask enum properties have the additional constraint of values
> + ? ? ? ?* from 0 to 63
> + ? ? ? ?*/
> + ? ? ? if ((property->flags & DRM_MODE_PROP_BITMASK) && (value > 63))
> ? ? ? ? ? ? ? ?return -EINVAL;
>
> ? ? ? ?if (!list_empty(>enum_blob_list)) {
> @@ -2875,7 +2909,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
> ? ? ? ?}
> ? ? ? ?property = obj_to_property(obj);
>
> - ? ? ? if (property->flags & DRM_MODE_PROP_ENUM) {
> + ? ? ? if (property->flags & (DRM_MODE_PROP_ENUM | DRM_MODE_PROP_BITMASK)) {
> ? ? ? ? ? ? ? ?list_for_each_entry(prop_enum, >enum_blob_list, head)
> ? ? ? ? ? ? ? ? ? ? ? ?enum_count++;
> ? ? ? ?} else if (property->flags & DRM_MODE_PROP_BLOB) {
> @@ -2900,7 +2934,7 @@ int drm_mode_getproperty_ioctl(struct drm_device *dev,
> ? ? ? ?}
> ? ? ? ?out_resp->count_values = value_count;
>
> - ? ? ? if (property->flags & DRM_MODE_PROP_ENUM) {
> + ? ? ? if (property->flags & (DRM_MODE_PROP_ENUM | DRM_MODE_PROP_BITMASK)) {
> ? ? ? ? ? ? ? ?if ((out_resp->count_enum_blobs >= enum_count) && enum_count) {
> ? ? ? ? ? ? ? ? ? ? ? ?copied = 0;
> ? ? ? ? ? ? ? ? ? ? ? ?enum_ptr = (struct drm_mode_property_enum __user 
> *)(unsigned long)out_resp->enum_blob_ptr;
> @@ -3055,6 +3089,12 @@ static bool drm_property_change_is_valid(struct 
> drm_property *property,
> ? ? ? ? ? ? ? ?if (value < property->values[0] || value > property->values[1])
> ? ? ? ? ? ? ? ? ? ? ? ?return false;
> ? ? ? ? ? ? ? ?return true;
> + ? ? ? } else if (property->flags & DRM_MODE_PROP_BITMASK) {
> + ? ? ? ? ? ? ? int i;
> + ? ? ? ? ? ? ? __u64 valid_mask = 0;
> + ? ? ? ? ? ? ? for (i = 0; i < property->num_values; i++)
> + ? ? ? ? ? ? ? ? ? ? ? valid_mask |= (1LL << property->values[i]);
> + ? ? ? ? ? ? ? return !(value & ~valid_mask);
> ? ? ? ?} else {
> ? ? ? ? ? ? ? ?int i;
> ? ? ? ? ? ? ? ?for (i = 0; i < property->num_values; i++)
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index e194c78..39e3e1c 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -940,6 +940,9 @@ extern struct drm_property 
> *drm_property_create_enum(struct drm_device *dev, int
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? const char *name,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? const struct drm_prop_enum_list 
> *props,
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? int num_values);
> +struct drm_property *drm_property_create_bitmask(struct drm_device *dev,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?int flags, const char *name,
> + ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?const struct drm_prop_enum_list 
> *props, int

[Bug 49794] HD5850 clocks are always limited to 400/900

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

--- Comment #8 from Andrey  2012-05-16 11:40:21 PDT ---
Created attachment 61732
  --> https://bugs.freedesktop.org/attachment.cgi?id=61732
HIS Radeon HD 5850 BIOS

Oops, attached correct rom

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

[PATCH libdrm 0/3] Additional drm properties patches

2012/5/16 Rob Clark :
> From: Rob Clark 
>
> Additional drm properties support, the libdrm part. ?These apply on top
> of Paulo's libdrm properties patches, and add support for bitmask
> properties, and additional support in modetest.
>
> Rob Clark (3):
> ?Add support for bitmask properties
> ?modetest: support bitmask properties
> ?modetest: support plane properties


For the 3 patches:
Reviewed-by: Paulo Zanoni 

You might want to create patch 0004 adding support for the proptest
tool... It might help you test stuff.

>
> ?include/drm/drm_mode.h ? ?| ? ?1 +
> ?tests/modetest/modetest.c | ? 22 ++
> ?xf86drmMode.c ? ? ? ? ? ? | ? ?4 ++--
> ?3 files changed, 25 insertions(+), 2 deletions(-)
>
> --
> 1.7.9.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Paulo Zanoni

[Bug 50021] New: src/gallium/drivers/r300/r300_state.c:716:17: error: incompatible type for argument 2 of ‘r300->rws->buffer_set_tiling’

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

 Bug #: 50021
   Summary: src/gallium/drivers/r300/r300_state.c:716:17: error:
incompatible type for argument 2 of
?r300->rws->buffer_set_tiling?
Classification: Unclassified
   Product: Mesa
   Version: unspecified
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: blocker
  Priority: medium
 Component: Drivers/DRI/r300
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: vlee at freedesktop.org
CC: michel at daenzer.net


mesa: 03e3bc4ba56f1021899a5f773b6ec21893619e3a (master)

$ scons
[...]
  Compiling src/gallium/drivers/r300/r300_state.c ...
src/gallium/drivers/r300/r300_state.c: In function ?r300_tex_set_tiling_flags?:
src/gallium/drivers/r300/r300_state.c:716:17: error: incompatible type for
argument 2 of ?r300->rws->buffer_set_tiling?
src/gallium/drivers/r300/r300_state.c:716:17: note: expected ?enum
radeon_bo_layout? but argument is of type ?struct radeon_winsys_cs *?
src/gallium/drivers/r300/r300_state.c:716:17: error: too few arguments to
function ?r300->rws->buffer_set_tiling?
scons: *** [build/linux-x86_64-debug/gallium/drivers/r300/r300_state.os] Error
1
scons: building terminated because of errors.


11f056a3f0b87e86267efa8b5ac9d36a343c9dc1 is the first bad commit
commit 11f056a3f0b87e86267efa8b5ac9d36a343c9dc1
Author: Michel D?nzer 
Date:   Wed May 16 17:45:17 2012 +0200

r600g: Set tiling information for BOs being shared.

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

:04 04 50daa6d7aceccb5f0697d46b9aa0ab03a13eae43
2b7c8f9c7f46546a6cf1159c741937160010d0d4 Msrc

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

[RFC] radeon faulty command stream dumping

2012-05-16 Thread j.gli...@gmail.com

The format is described in rati.h, it would be come some kind of API.
That's the reason why i changed the whole radeon family files, so it
can be share btw kernel and userspace.

The replayer is available at:
git://people.freedesktop.org/~glisse/joujou

I tested the kernel bits against couple variation of faulty command
stream (bad shader, bad vertex count, bad index count, ...) and it
seems to work ok.

The userspace tools need to grow the unrelocate capacity before
being able to replay kernel captured command stream.

Mesa patch to dump command stream in same format as kernel:
http://people.freedesktop.org/~glisse/lockup/0001-radeong-add-rati-command-stream-dumping.patch

libdrm patch needed to either build the joujou or mesa with
the patch
http://people.freedesktop.org/~glisse/lockup/0001-radeon-add-rati-dumping-helper.patch

(Also a bonus is that i regenerated cleanier header definition for
r6xx see replayx_r6xxd.h)

Cheers,
Jerome

[PATCH 1/2] drm/debugfs: allow driver to provide a custom read callback

2012-05-16 Thread j.gli...@gmail.com

From: Jerome Glisse 

Allow driver to provide a custom read callback for debugfs file.
Usefull if driver try to dump big buffer, avoid double buffering.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/drm_debugfs.c |   19 ---
 drivers/gpu/drm/i915/i915_debugfs.c   |2 +-
 drivers/gpu/drm/nouveau/nouveau_debugfs.c |4 ++--
 drivers/gpu/drm/radeon/radeon_device.c|4 ++--
 include/drm/drmP.h|8 +++-
 5 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
index 1c7a1c0..d5194e6 100644
--- a/drivers/gpu/drm/drm_debugfs.c
+++ b/drivers/gpu/drm/drm_debugfs.c
@@ -63,11 +63,22 @@ static int drm_debugfs_open(struct inode *inode, struct 
file *file)
return single_open(file, node->info_ent->show, node);
 }

+static ssize_t drm_debugfs_read(struct file *filp, char __user *ubuf,
+   size_t max, loff_t *ppos)
+{
+   struct seq_file *m = filp->private_data;
+   struct drm_info_node *node = (struct drm_info_node *) m->private;
+
+   if (node->read) {
+   return node->read(filp, ubuf, max, ppos);
+   }
+   return seq_read(filp, ubuf, max, ppos);
+}

 static const struct file_operations drm_debugfs_fops = {
.owner = THIS_MODULE,
.open = drm_debugfs_open,
-   .read = seq_read,
+   .read = drm_debugfs_read,
.llseek = seq_lseek,
.release = single_release,
 };
@@ -86,7 +97,8 @@ static const struct file_operations drm_debugfs_fops = {
  * gdm_debugfs_lists in the given root directory.
  */
 int drm_debugfs_create_files(struct drm_info_list *files, int count,
-struct dentry *root, struct drm_minor *minor)
+struct dentry *root, struct drm_minor *minor,
+drm_debugfs_read_t read)
 {
struct drm_device *dev = minor->dev;
struct dentry *ent;
@@ -118,6 +130,7 @@ int drm_debugfs_create_files(struct drm_info_list *files, 
int count,
tmp->minor = minor;
tmp->dent = ent;
tmp->info_ent = [i];
+   tmp->read = read;

mutex_lock(>debugfs_lock);
list_add(>list, >debugfs_list);
@@ -159,7 +172,7 @@ int drm_debugfs_init(struct drm_minor *minor, int minor_id,
}

ret = drm_debugfs_create_files(drm_debugfs_list, DRM_DEBUGFS_ENTRIES,
-  minor->debugfs_root, minor);
+  minor->debugfs_root, minor, NULL);
if (ret) {
debugfs_remove(minor->debugfs_root);
minor->debugfs_root = NULL;
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 950f72a..636c4f4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2018,7 +2018,7 @@ int i915_debugfs_init(struct drm_minor *minor)

return drm_debugfs_create_files(i915_debugfs_list,
I915_DEBUGFS_ENTRIES,
-   minor->debugfs_root, minor);
+   minor->debugfs_root, minor, NULL);
 }

 void i915_debugfs_cleanup(struct drm_minor *minor)
diff --git a/drivers/gpu/drm/nouveau/nouveau_debugfs.c 
b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
index fa2ec49..12cbc5c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_debugfs.c
+++ b/drivers/gpu/drm/nouveau/nouveau_debugfs.c
@@ -94,7 +94,7 @@ nouveau_debugfs_channel_init(struct nouveau_channel *chan)

ret = drm_debugfs_create_files(>debugfs.info, 1,
   dev_priv->debugfs.channel_root,
-  chan->dev->primary);
+  chan->dev->primary, NULL);
if (ret == 0)
chan->debugfs.active = true;
return ret;
@@ -186,7 +186,7 @@ int
 nouveau_debugfs_init(struct drm_minor *minor)
 {
drm_debugfs_create_files(nouveau_debugfs_list, NOUVEAU_DEBUGFS_ENTRIES,
-minor->debugfs_root, minor);
+minor->debugfs_root, minor, NULL);
return 0;
 }

diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index 3d41525..944ac11 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1039,10 +1039,10 @@ int radeon_debugfs_add_files(struct radeon_device *rdev,
 #if defined(CONFIG_DEBUG_FS)
drm_debugfs_create_files(files, nfiles,
 rdev->ddev->control->debugfs_root,
-rdev->ddev->control);
+rdev->ddev->control, NULL);
drm_debugfs_create_files(files, nfiles,
 rdev->ddev->primary->debugfs_root,
-

[PATCH 2/2] drm/radeon: add lockup faulty command recording

2012-05-16 Thread j.gli...@gmail.com

From: Jerome Glisse 

This try to identify the faulty user command stream that caused
lockup. If it finds one it create big blob that contains all
information needed to replay the faulty command stream.

Signed-off-by: Jerome Glisse 
---
 drivers/gpu/drm/radeon/r100.c  |6 +-
 drivers/gpu/drm/radeon/r300.c  |2 +-
 drivers/gpu/drm/radeon/r420.c  |2 +-
 drivers/gpu/drm/radeon/r600.c  |2 +-
 drivers/gpu/drm/radeon/r600_cs.c   |4 +-
 drivers/gpu/drm/radeon/radeon.h|   72 +-
 drivers/gpu/drm/radeon/radeon_cs.c |   68 --
 drivers/gpu/drm/radeon/radeon_device.c |   25 +-
 drivers/gpu/drm/radeon/radeon_family.h |  145 ++--
 drivers/gpu/drm/radeon/radeon_fence.c  |2 +-
 drivers/gpu/drm/radeon/radeon_gart.c   |   10 ++-
 drivers/gpu/drm/radeon/radeon_object.h |   12 ++-
 drivers/gpu/drm/radeon/radeon_pm.c |2 +-
 drivers/gpu/drm/radeon/radeon_ring.c   |   21 -
 drivers/gpu/drm/radeon/radeon_sa.c |  112 ++
 drivers/gpu/drm/radeon/radeon_ttm.c|2 +-
 drivers/gpu/drm/radeon/rs400.c |2 +-
 drivers/gpu/drm/radeon/rv515.c |4 +-
 include/drm/rati.h |  163 
 19 files changed, 524 insertions(+), 132 deletions(-)
 create mode 100644 include/drm/rati.h

diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 0874a6d..8ed365f 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -2694,7 +2694,7 @@ static struct drm_info_list r100_debugfs_mc_info_list[] = 
{
 int r100_debugfs_rbbm_init(struct radeon_device *rdev)
 {
 #if defined(CONFIG_DEBUG_FS)
-   return radeon_debugfs_add_files(rdev, r100_debugfs_rbbm_list, 1);
+   return radeon_debugfs_add_files(rdev, r100_debugfs_rbbm_list, 1, NULL);
 #else
return 0;
 #endif
@@ -2703,7 +2703,7 @@ int r100_debugfs_rbbm_init(struct radeon_device *rdev)
 int r100_debugfs_cp_init(struct radeon_device *rdev)
 {
 #if defined(CONFIG_DEBUG_FS)
-   return radeon_debugfs_add_files(rdev, r100_debugfs_cp_list, 2);
+   return radeon_debugfs_add_files(rdev, r100_debugfs_cp_list, 2, NULL);
 #else
return 0;
 #endif
@@ -2712,7 +2712,7 @@ int r100_debugfs_cp_init(struct radeon_device *rdev)
 int r100_debugfs_mc_info_init(struct radeon_device *rdev)
 {
 #if defined(CONFIG_DEBUG_FS)
-   return radeon_debugfs_add_files(rdev, r100_debugfs_mc_info_list, 1);
+   return radeon_debugfs_add_files(rdev, r100_debugfs_mc_info_list, 1, 
NULL);
 #else
return 0;
 #endif
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 97722a3..edb9eeb 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -586,7 +586,7 @@ static struct drm_info_list rv370_pcie_gart_info_list[] = {
 static int rv370_debugfs_pcie_gart_info_init(struct radeon_device *rdev)
 {
 #if defined(CONFIG_DEBUG_FS)
-   return radeon_debugfs_add_files(rdev, rv370_pcie_gart_info_list, 1);
+   return radeon_debugfs_add_files(rdev, rv370_pcie_gart_info_list, 1, 
NULL);
 #else
return 0;
 #endif
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index 99137be..4eddcfc 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -491,7 +491,7 @@ static struct drm_info_list r420_pipes_info_list[] = {
 int r420_debugfs_pipes_info_init(struct radeon_device *rdev)
 {
 #if defined(CONFIG_DEBUG_FS)
-   return radeon_debugfs_add_files(rdev, r420_pipes_info_list, 1);
+   return radeon_debugfs_add_files(rdev, r420_pipes_info_list, 1, NULL);
 #else
return 0;
 #endif
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 4c0d8c9..afc458a 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -3589,7 +3589,7 @@ static struct drm_info_list r600_mc_info_list[] = {
 int r600_debugfs_mc_info_init(struct radeon_device *rdev)
 {
 #if defined(CONFIG_DEBUG_FS)
-   return radeon_debugfs_add_files(rdev, r600_mc_info_list, 
ARRAY_SIZE(r600_mc_info_list));
+   return radeon_debugfs_add_files(rdev, r600_mc_info_list, 
ARRAY_SIZE(r600_mc_info_list), NULL);
 #else
return 0;
 #endif
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 0133f5f..0518c45 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -97,7 +97,7 @@ struct gpu_formats {
unsigned blockheight;
unsigned blocksize;
unsigned valid_color;
-   enum radeon_family min_family;
+   unsigned min_family;
 };

 static const struct gpu_formats color_formats_table[] = {
@@ -185,7 +185,7 @@ bool r600_fmt_is_valid_color(u32 format)
return false;
 }

-bool r600_fmt_is_valid_texture(u32 format, enum radeon_family family)
+bool r600_fmt_is_valid_texture(u32 format, unsigned family)
 {

[Bug 50021] src/gallium/drivers/r300/r300_state.c:716:17: error: incompatible type for argument 2 of ‘r300->rws->buffer_set_tiling’