[Bug 43871] New: shader with uniform array/record and if clauses is not translated correctly into TGSI IR

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

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

 Bug #: 43871
   Summary: shader with uniform array/record and if clauses is not
translated correctly into TGSI IR
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: vljn at ovi.com


Hi,

the following fragment shader :

__
#version 130
uniform int mode;
uniform vec3 red;
uniform struct {
  vec3 green;
  vec3 blue;
} teststruct;
uniform vec3 testarray[3];
out vec3 fragColor;

void main()
{
   if (mode == 0)
  fragColor = red;
   if (mode == 1)
  fragColor = teststruct.green + teststruct.blue;
   if (mode == 2)
   {
  fragColor = vec3(0.);
  for(int i = 0; i < 3; i++)
 fragColor += testarray[i];
   }
}
__

is lowered to :
__
FRAG
PROPERTY FS_COLOR0_WRITES_ALL_CBUFS 1
DCL IN[0], COLOR, LINEAR
DCL OUT[0], COLOR
  0: MOV OUT[0], IN[0]
  1: END
__

using mesa from git, swrast, and setting glsl supported version to 130 in
st_extensions.c ; glsl_compiler --dump-lir seems correct, so it might be an
issue with glsl-to-tgsi.

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

[Bug 43395] Game running in wine stops rendering

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

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

--- Comment #14 from Tomas Schlosser  2011-12-15 
14:08:15 PST ---
New updates came:
kernel 3.1.5-2.fc16
mesa-dri-drivers.x86_64 7.11.2-1.fc16
No changes, rendering stops after a few minutes (5 - 10).

I can't build mesa from git. Last time I tried (using tutorial from
http://www.mesa3d.org/ - ./autoconf.sh && make && sudo make install) I got
error while running the game saying "Access Violation".

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

[Bug 43655] Latest radeon dri driver on HD6950 with kernel 3.2 flickers

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

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

Alexandre Demers  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #6 from Alexandre Demers  
2011-12-15 14:03:15 PST ---
I tested today's latest kernel version after fighting with the beast for the
last couple of days. Just to be sure, I made a clean compilation and it now
works properly without any problem. I'll assume for the moment it was related
to something stuck in the compilation.

If anything goes wrong again, I'll reopen the bug.

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

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

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

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

--- Comment #11 from Alex Deucher  2011-12-15 13:40:27 PST 
---
(In reply to comment #9)
> Created attachment 54475 [details] [review]
> glxinfo
> 
> I'm attaching the full output of "glxinfo".

Unfortunately, you'll end up with the software 3D driver if you have
acceleration disabled.  You'll have to find out what debian uses on wheezy
(r300c vs. r300g).  However, if you still get hangs even without using 3D,
there seems to be a problem with acceleration in general on his system.

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

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

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

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #54475|application/octet-stream|text/plain
  mime type||
  Attachment #54475|0   |1
   is patch||

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

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

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

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

--- Comment #10 from Camale?n  2011-12-15 13:28:13 PST 
---
(In reply to comment #8)
> Does the system hang if you remove the NoAccel option but don't load
> gnome-shell?

Yes, the user has reported that by removing that option from "xorg.conf" file
and login into gnome fallback mode (now "gnome classical") the system hung.

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

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

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

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

--- Comment #9 from Camale?n  2011-12-15 13:25:23 PST ---
Created attachment 54475
  --> https://bugs.freedesktop.org/attachment.cgi?id=54475
glxinfo

I'm attaching the full output of "glxinfo".

-- 
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/3] drm/omap: add debugfs support

[Rob Clark]

From: Andy Gross 

Right now just a tiler_map file to dump a 2d map of which areas in
tiler/dmm have pinned buffers (or reservations).  In the future more
could be added.

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/Makefile |1 +
 drivers/staging/omapdrm/omap_debugfs.c   |   42 +
 drivers/staging/omapdrm/omap_dmm_tiler.c |  149 ++
 drivers/staging/omapdrm/omap_dmm_tiler.h |4 +
 drivers/staging/omapdrm/omap_drv.c   |4 +
 drivers/staging/omapdrm/omap_drv.h   |5 +
 6 files changed, 205 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/omapdrm/omap_debugfs.c

diff --git a/drivers/staging/omapdrm/Makefile b/drivers/staging/omapdrm/Makefile
index 275054a..592cf69 100644
--- a/drivers/staging/omapdrm/Makefile
+++ b/drivers/staging/omapdrm/Makefile
@@ -5,6 +5,7 @@

 ccflags-y := -Iinclude/drm -Werror
 omapdrm-y := omap_drv.o \
+   omap_debugfs.o \
omap_crtc.o \
omap_encoder.o \
omap_connector.o \
diff --git a/drivers/staging/omapdrm/omap_debugfs.c 
b/drivers/staging/omapdrm/omap_debugfs.c
new file mode 100644
index 000..da920df
--- /dev/null
+++ b/drivers/staging/omapdrm/omap_debugfs.c
@@ -0,0 +1,42 @@
+/*
+ * drivers/staging/omapdrm/omap_debugfs.c
+ *
+ * Copyright (C) 2011 Texas Instruments
+ * Author: Rob Clark 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include "omap_drv.h"
+#include "omap_dmm_tiler.h"
+
+#ifdef CONFIG_DEBUG_FS
+
+static struct drm_info_list omap_debugfs_list[] = {
+   {"tiler_map", tiler_map_show, 0},
+};
+
+int omap_debugfs_init(struct drm_minor *minor)
+{
+   return drm_debugfs_create_files(omap_debugfs_list,
+   ARRAY_SIZE(omap_debugfs_list),
+   minor->debugfs_root, minor);
+}
+
+void omap_debugfs_cleanup(struct drm_minor *minor)
+{
+   drm_debugfs_remove_files(omap_debugfs_list,
+   ARRAY_SIZE(omap_debugfs_list), minor);
+}
+
+#endif
diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c 
b/drivers/staging/omapdrm/omap_dmm_tiler.c
index b182de5..852d944 100644
--- a/drivers/staging/omapdrm/omap_dmm_tiler.c
+++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
@@ -679,3 +679,152 @@ fail:
omap_dmm_remove();
return ret;
 }
+
+/*
+ * debugfs support
+ */
+
+#ifdef CONFIG_DEBUG_FS
+
+static const char *alphabet = "abcdefghijklmnopqrstuvwxyz"
+   "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
+static const char *special = ".,:;'\"`~!^-+";
+
+static void fill_map(char **map, int xdiv, int ydiv, struct tcm_area *a,
+   char c, bool ovw)
+{
+   int x, y;
+   for (y = a->p0.y / ydiv; y <= a->p1.y / ydiv; y++)
+   for (x = a->p0.x / xdiv; x <= a->p1.x / xdiv; x++)
+   if (map[y][x] == ' ' || ovw)
+   map[y][x] = c;
+}
+
+static void fill_map_pt(char **map, int xdiv, int ydiv, struct tcm_pt *p,
+   char c)
+{
+   map[p->y / ydiv][p->x / xdiv] = c;
+}
+
+static char read_map_pt(char **map, int xdiv, int ydiv, struct tcm_pt *p)
+{
+   return map[p->y / ydiv][p->x / xdiv];
+}
+
+static int map_width(int xdiv, int x0, int x1)
+{
+   return (x1 / xdiv) - (x0 / xdiv) + 1;
+}
+
+static void text_map(char **map, int xdiv, char *nice, int yd, int x0, int x1)
+{
+   char *p = map[yd] + (x0 / xdiv);
+   int w = (map_width(xdiv, x0, x1) - strlen(nice)) / 2;
+   if (w >= 0) {
+   p += w;
+   while (*nice)
+   *p++ = *nice++;
+   }
+}
+
+static void map_1d_info(char **map, int xdiv, int ydiv, char *nice,
+   struct tcm_area *a)
+{
+   sprintf(nice, "%dK", tcm_sizeof(*a) * 4);
+   if (a->p0.y + 1 < a->p1.y) {
+   text_map(map, xdiv, nice, (a->p0.y + a->p1.y) / 2 / ydiv, 0,
+   256 - 1);
+   } else if (a->p0.y < a->p1.y) {
+   if (strlen(nice) < map_width(xdiv, a->p0.x, 256 - 1))
+   text_map(map, xdiv, nice, a->p0.y / ydiv,
+   a->p0.x + xdiv, 256 - 1);
+   else if (strlen(nice) < map_width(xdiv, 0, a->p1.x))
+   text_map(map, xdiv, nice, a->p1.y / ydiv,
+ 

[PATCH 2/3] drm/omap: avoid aquiring mutex in atomic context

[Rob Clark]

From: Rob Clark 

omap_gem_roll() could be called by fbcon in atomic context.  Avoid
aquiring mutex, or calling tiler_pin() (which itself is not safe
for atomic context) in these cases.

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_gem.c |   16 ++--
 1 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_gem.c 
b/drivers/staging/omapdrm/omap_gem.c
index 9684891..2bc570a 100644
--- a/drivers/staging/omapdrm/omap_gem.c
+++ b/drivers/staging/omapdrm/omap_gem.c
@@ -538,10 +538,22 @@ int omap_gem_roll(struct drm_gem_object *obj, uint32_t 
roll)
return -EINVAL;
}

-   mutex_lock(&obj->dev->struct_mutex);
-
omap_obj->roll = roll;

+   if (in_atomic()) {
+   /* this can get called from fbcon in atomic context.. so
+* just ignore it and wait for next time called from
+* interruptible context to update the PAT.. the result
+* may be that user sees wrap-around instead of scrolling
+* momentarily on the screen.  If we wanted to be fancier
+* we could perhaps schedule some workqueue work at this
+* point.
+*/
+   return 0;
+   }
+
+   mutex_lock(&obj->dev->struct_mutex);
+
/* if we aren't mapped yet, we don't need to do anything */
if (omap_obj->block) {
struct page **pages;
-- 
1.7.5.4

[PATCH 1/3] drm/omap: add ywrap module param

[Rob Clark]

From: Rob Clark 

Can be set at boot or module load time to prevent YWRAP scrolling from
being enabled.

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_fbdev.c |   15 ++-
 1 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_fbdev.c 
b/drivers/staging/omapdrm/omap_fbdev.c
index d8962e8..093ae2f 100644
--- a/drivers/staging/omapdrm/omap_fbdev.c
+++ b/drivers/staging/omapdrm/omap_fbdev.c
@@ -22,6 +22,10 @@
 #include "drm_crtc.h"
 #include "drm_fb_helper.h"

+MODULE_PARM_DESC(ywrap, "Enable ywrap scrolling (omap44xx and later, default 
'y')");
+static bool ywrap_enabled = true;
+module_param_named(ywrap, ywrap_enabled, bool, 0644);
+
 /*
  * fbdev funcs, to implement legacy fbdev interface on top of drm driver
  */
@@ -32,6 +36,7 @@ struct omap_fbdev {
struct drm_fb_helper base;
struct drm_framebuffer *fb;
struct drm_gem_object *bo;
+   bool ywrap_enabled;
 };

 static void omap_fbdev_flush(struct fb_info *fbi, int x, int y, int w, int h);
@@ -75,14 +80,12 @@ static int omap_fbdev_pan_display(struct fb_var_screeninfo 
*var,
 {
struct drm_fb_helper *helper = get_fb(fbi);
struct omap_fbdev *fbdev = to_omap_fbdev(helper);
-   struct omap_drm_private *priv;
int npages;

if (!helper)
goto fallback;

-   priv = helper->dev->dev_private;
-   if (!priv->has_dmm)
+   if (!fbdev->ywrap_enabled)
goto fallback;

/* DMM roll shifts in 4K pages: */
@@ -152,7 +155,8 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
mode_cmd.width * ((mode_cmd.bpp + 7) / 8),
mode_cmd.width, mode_cmd.bpp);

-   if (priv->has_dmm) {
+   fbdev->ywrap_enabled = priv->has_dmm && ywrap_enabled;
+   if (fbdev->ywrap_enabled) {
/* need to align pitch to page size if using DMM scrolling */
mode_cmd.pitch = ALIGN(mode_cmd.pitch, PAGE_SIZE);
}
@@ -218,12 +222,13 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
/* if we have DMM, then we can use it for scrolling by just
 * shuffling pages around in DMM rather than doing sw blit.
 */
-   if (priv->has_dmm) {
+   if (fbdev->ywrap_enabled) {
DRM_INFO("Enabling DMM ywrap scrolling\n");
fbi->flags |= FBINFO_HWACCEL_YWRAP | FBINFO_READS_FAST;
fbi->fix.ywrapstep = 1;
}

+
DBG("par=%p, %dx%d", fbi->par, fbi->var.xres, fbi->var.yres);
DBG("allocated %dx%d fb", fbdev->fb->width, fbdev->fb->height);

-- 
1.7.5.4

[PATCH] drm/nouveau: Use vsprintf extension %pV

[Joe Perches]

Using %pV can save text.

Replace NV_PRINTK macro with nv_printk and use
of vsprintf extension %pV.

Convert the NV_ macros to use nv_printk
and neaten them too.

Saves ~45KB or ~5% of total code space for nouveau.

$ size drivers/gpu/drm/nouveau/built-in.o*
   textdata bss dec hex filename
 781185   25499  176860  983544   f01f8 drivers/gpu/drm/nouveau/built-in.o.new
 820650   25499  184356 1030505   fb969 drivers/gpu/drm/nouveau/built-in.o.old

Signed-off-by: Joe Perches 

---

Modified resend of https://lkml.org/lkml/2011/6/28/505

 drivers/gpu/drm/nouveau/nouveau_dp.c  |9 ++--
 drivers/gpu/drm/nouveau/nouveau_drv.c |   20 ++
 drivers/gpu/drm/nouveau/nouveau_drv.h |   67 +++-
 3 files changed, 65 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c 
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index de5efe7..087ede3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -33,10 +33,11 @@
 /**
  * aux channel util functions
  */
-#define AUX_DBG(fmt, args...) do { 
\
-   if (nouveau_reg_debug & NOUVEAU_REG_DEBUG_AUXCH) { \
-   NV_PRINTK(KERN_DEBUG, dev, "AUXCH(%d): " fmt, ch, ##args); \
-   }  \
+#define AUX_DBG(fmt, ...)  \
+do {   \
+   if (nouveau_reg_debug & NOUVEAU_REG_DEBUG_AUXCH)\
+   nv_printk(dev, KERN_DEBUG, "AUXCH(%d): " fmt,   \
+ ch, ##__VA_ARGS__);   \
 } while (0)
 #define AUX_ERR(fmt, args...) NV_ERROR(dev, "AUXCH(%d): " fmt, ch, ##args)
 
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c 
b/drivers/gpu/drm/nouveau/nouveau_drv.c
index f0a60af..0eed2a9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
@@ -494,3 +494,23 @@ module_exit(nouveau_exit);
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL and additional rights");
+
+int nv_printk(const struct drm_device *drm_dev,
+ const char *level, const char *format, ...)
+{
+   struct va_format vaf;
+   va_list args;
+   int r;
+
+   va_start(args, format);
+
+   vaf.fmt = format;
+   vaf.va = &args;
+
+   r = printk("%s[" DRM_NAME "] " DRIVER_NAME " %s: %pV",
+  level, pci_name(drm_dev->pdev), &vaf);
+
+   va_end(args);
+
+   return r;
+}
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index dfddb7e..80f49d4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -1537,37 +1537,48 @@ extern void nv_wo32(struct nouveau_gpuobj *, u32 
offset, u32 val);
  * Logging
  * Argument d is (struct drm_device *).
  */
-#define NV_PRINTK(level, d, fmt, arg...) \
-   printk(level "[" DRM_NAME "] " DRIVER_NAME " %s: " fmt, \
-   pci_name(d->pdev), ##arg)
+
+extern __attribute__ ((format (printf, 3, 4)))
+int nv_printk(const struct drm_device *drm_dev,
+ const char *level, const char *format, ...);
+
 #ifndef NV_DEBUG_NOTRACE
-#define NV_DEBUG(d, fmt, arg...) do {  
\
-   if (drm_debug & DRM_UT_DRIVER) {   \
-   NV_PRINTK(KERN_DEBUG, d, "%s:%d - " fmt, __func__, \
- __LINE__, ##arg);\
-   }  \
+#define NV_DEBUG(d, fmt, ...)  \
+do {   \
+   if (drm_debug & DRM_UT_DRIVER) {\
+   nv_printk(d, KERN_DEBUG, "%s:%d - " fmt,\
+ __func__, __LINE__, ##__VA_ARGS__);   \
+   }   \
 } while (0)
-#define NV_DEBUG_KMS(d, fmt, arg...) do {  
\
-   if (drm_debug & DRM_UT_KMS) {  \
-   NV_PRINTK(KERN_DEBUG, d, "%s:%d - " fmt, __func__, \
- __LINE__, ##arg);\
-   }  \
+#define NV_DEBUG_KMS(d, fmt, ...)  \
+do {   \
+   if (drm_debug & DRM_UT_KMS) {  

[PATCH 3/3] drm/omap: add debugfs support

[Rob Clark]

From: Andy Gross 

Right now just a tiler_map file to dump a 2d map of which areas in
tiler/dmm have pinned buffers (or reservations).  In the future more
could be added.

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/Makefile |1 +
 drivers/staging/omapdrm/omap_debugfs.c   |   42 +
 drivers/staging/omapdrm/omap_dmm_tiler.c |  149 ++
 drivers/staging/omapdrm/omap_dmm_tiler.h |4 +
 drivers/staging/omapdrm/omap_drv.c   |4 +
 drivers/staging/omapdrm/omap_drv.h   |5 +
 6 files changed, 205 insertions(+), 0 deletions(-)
 create mode 100644 drivers/staging/omapdrm/omap_debugfs.c

diff --git a/drivers/staging/omapdrm/Makefile b/drivers/staging/omapdrm/Makefile
index 275054a..592cf69 100644
--- a/drivers/staging/omapdrm/Makefile
+++ b/drivers/staging/omapdrm/Makefile
@@ -5,6 +5,7 @@
 
 ccflags-y := -Iinclude/drm -Werror
 omapdrm-y := omap_drv.o \
+   omap_debugfs.o \
omap_crtc.o \
omap_encoder.o \
omap_connector.o \
diff --git a/drivers/staging/omapdrm/omap_debugfs.c 
b/drivers/staging/omapdrm/omap_debugfs.c
new file mode 100644
index 000..da920df
--- /dev/null
+++ b/drivers/staging/omapdrm/omap_debugfs.c
@@ -0,0 +1,42 @@
+/*
+ * drivers/staging/omapdrm/omap_debugfs.c
+ *
+ * Copyright (C) 2011 Texas Instruments
+ * Author: Rob Clark 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#include "omap_drv.h"
+#include "omap_dmm_tiler.h"
+
+#ifdef CONFIG_DEBUG_FS
+
+static struct drm_info_list omap_debugfs_list[] = {
+   {"tiler_map", tiler_map_show, 0},
+};
+
+int omap_debugfs_init(struct drm_minor *minor)
+{
+   return drm_debugfs_create_files(omap_debugfs_list,
+   ARRAY_SIZE(omap_debugfs_list),
+   minor->debugfs_root, minor);
+}
+
+void omap_debugfs_cleanup(struct drm_minor *minor)
+{
+   drm_debugfs_remove_files(omap_debugfs_list,
+   ARRAY_SIZE(omap_debugfs_list), minor);
+}
+
+#endif
diff --git a/drivers/staging/omapdrm/omap_dmm_tiler.c 
b/drivers/staging/omapdrm/omap_dmm_tiler.c
index b182de5..852d944 100644
--- a/drivers/staging/omapdrm/omap_dmm_tiler.c
+++ b/drivers/staging/omapdrm/omap_dmm_tiler.c
@@ -679,3 +679,152 @@ fail:
omap_dmm_remove();
return ret;
 }
+
+/*
+ * debugfs support
+ */
+
+#ifdef CONFIG_DEBUG_FS
+
+static const char *alphabet = "abcdefghijklmnopqrstuvwxyz"
+   "ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789";
+static const char *special = ".,:;'\"`~!^-+";
+
+static void fill_map(char **map, int xdiv, int ydiv, struct tcm_area *a,
+   char c, bool ovw)
+{
+   int x, y;
+   for (y = a->p0.y / ydiv; y <= a->p1.y / ydiv; y++)
+   for (x = a->p0.x / xdiv; x <= a->p1.x / xdiv; x++)
+   if (map[y][x] == ' ' || ovw)
+   map[y][x] = c;
+}
+
+static void fill_map_pt(char **map, int xdiv, int ydiv, struct tcm_pt *p,
+   char c)
+{
+   map[p->y / ydiv][p->x / xdiv] = c;
+}
+
+static char read_map_pt(char **map, int xdiv, int ydiv, struct tcm_pt *p)
+{
+   return map[p->y / ydiv][p->x / xdiv];
+}
+
+static int map_width(int xdiv, int x0, int x1)
+{
+   return (x1 / xdiv) - (x0 / xdiv) + 1;
+}
+
+static void text_map(char **map, int xdiv, char *nice, int yd, int x0, int x1)
+{
+   char *p = map[yd] + (x0 / xdiv);
+   int w = (map_width(xdiv, x0, x1) - strlen(nice)) / 2;
+   if (w >= 0) {
+   p += w;
+   while (*nice)
+   *p++ = *nice++;
+   }
+}
+
+static void map_1d_info(char **map, int xdiv, int ydiv, char *nice,
+   struct tcm_area *a)
+{
+   sprintf(nice, "%dK", tcm_sizeof(*a) * 4);
+   if (a->p0.y + 1 < a->p1.y) {
+   text_map(map, xdiv, nice, (a->p0.y + a->p1.y) / 2 / ydiv, 0,
+   256 - 1);
+   } else if (a->p0.y < a->p1.y) {
+   if (strlen(nice) < map_width(xdiv, a->p0.x, 256 - 1))
+   text_map(map, xdiv, nice, a->p0.y / ydiv,
+   a->p0.x + xdiv, 256 - 1);
+   else if (strlen(nice) < map_width(xdiv, 0, a->p1.x))
+   text_map(map, xdiv, nice, a->p1.y / ydiv,
+

[PATCH 2/3] drm/omap: avoid aquiring mutex in atomic context

[Rob Clark]

From: Rob Clark 

omap_gem_roll() could be called by fbcon in atomic context.  Avoid
aquiring mutex, or calling tiler_pin() (which itself is not safe
for atomic context) in these cases.

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_gem.c |   16 ++--
 1 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_gem.c 
b/drivers/staging/omapdrm/omap_gem.c
index 9684891..2bc570a 100644
--- a/drivers/staging/omapdrm/omap_gem.c
+++ b/drivers/staging/omapdrm/omap_gem.c
@@ -538,10 +538,22 @@ int omap_gem_roll(struct drm_gem_object *obj, uint32_t 
roll)
return -EINVAL;
}
 
-   mutex_lock(&obj->dev->struct_mutex);
-
omap_obj->roll = roll;
 
+   if (in_atomic()) {
+   /* this can get called from fbcon in atomic context.. so
+* just ignore it and wait for next time called from
+* interruptible context to update the PAT.. the result
+* may be that user sees wrap-around instead of scrolling
+* momentarily on the screen.  If we wanted to be fancier
+* we could perhaps schedule some workqueue work at this
+* point.
+*/
+   return 0;
+   }
+
+   mutex_lock(&obj->dev->struct_mutex);
+
/* if we aren't mapped yet, we don't need to do anything */
if (omap_obj->block) {
struct page **pages;
-- 
1.7.5.4

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

[PATCH 1/3] drm/omap: add ywrap module param

[Rob Clark]

From: Rob Clark 

Can be set at boot or module load time to prevent YWRAP scrolling from
being enabled.

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_fbdev.c |   15 ++-
 1 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_fbdev.c 
b/drivers/staging/omapdrm/omap_fbdev.c
index d8962e8..093ae2f 100644
--- a/drivers/staging/omapdrm/omap_fbdev.c
+++ b/drivers/staging/omapdrm/omap_fbdev.c
@@ -22,6 +22,10 @@
 #include "drm_crtc.h"
 #include "drm_fb_helper.h"
 
+MODULE_PARM_DESC(ywrap, "Enable ywrap scrolling (omap44xx and later, default 
'y')");
+static bool ywrap_enabled = true;
+module_param_named(ywrap, ywrap_enabled, bool, 0644);
+
 /*
  * fbdev funcs, to implement legacy fbdev interface on top of drm driver
  */
@@ -32,6 +36,7 @@ struct omap_fbdev {
struct drm_fb_helper base;
struct drm_framebuffer *fb;
struct drm_gem_object *bo;
+   bool ywrap_enabled;
 };
 
 static void omap_fbdev_flush(struct fb_info *fbi, int x, int y, int w, int h);
@@ -75,14 +80,12 @@ static int omap_fbdev_pan_display(struct fb_var_screeninfo 
*var,
 {
struct drm_fb_helper *helper = get_fb(fbi);
struct omap_fbdev *fbdev = to_omap_fbdev(helper);
-   struct omap_drm_private *priv;
int npages;
 
if (!helper)
goto fallback;
 
-   priv = helper->dev->dev_private;
-   if (!priv->has_dmm)
+   if (!fbdev->ywrap_enabled)
goto fallback;
 
/* DMM roll shifts in 4K pages: */
@@ -152,7 +155,8 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
mode_cmd.width * ((mode_cmd.bpp + 7) / 8),
mode_cmd.width, mode_cmd.bpp);
 
-   if (priv->has_dmm) {
+   fbdev->ywrap_enabled = priv->has_dmm && ywrap_enabled;
+   if (fbdev->ywrap_enabled) {
/* need to align pitch to page size if using DMM scrolling */
mode_cmd.pitch = ALIGN(mode_cmd.pitch, PAGE_SIZE);
}
@@ -218,12 +222,13 @@ static int omap_fbdev_create(struct drm_fb_helper *helper,
/* if we have DMM, then we can use it for scrolling by just
 * shuffling pages around in DMM rather than doing sw blit.
 */
-   if (priv->has_dmm) {
+   if (fbdev->ywrap_enabled) {
DRM_INFO("Enabling DMM ywrap scrolling\n");
fbi->flags |= FBINFO_HWACCEL_YWRAP | FBINFO_READS_FAST;
fbi->fix.ywrapstep = 1;
}
 
+
DBG("par=%p, %dx%d", fbi->par, fbi->var.xres, fbi->var.yres);
DBG("allocated %dx%d fb", fbdev->fb->width, fbdev->fb->height);
 
-- 
1.7.5.4

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

[PATCH] exynos: add module name for Samsung Exynos SoC support.

[Inki Dae]

this patch adds module name for Samsung Exynos SoC. with this patch,
we can test kmstest, modetest and vbltest of libdrm.
Exynos drm driver of kernel side have been merged to mainline.

you can refer to mainline git repository below:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary
commit id: 1c248b7d2960faec3e1b8f3f9c5d9d0df28e0a3c

P.S. the module name of kernel side is "exynos-drm" yet so
now the name would use "exynos-drm" but it will be changed to "exynos"
once kernel side is changed.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 tests/kmstest/main.c  |1 +
 tests/modetest/modetest.c |3 ++-
 tests/vbltest/vbltest.c   |3 ++-
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/tests/kmstest/main.c b/tests/kmstest/main.c
index 5df0a38..7193ff5 100644
--- a/tests/kmstest/main.c
+++ b/tests/kmstest/main.c
@@ -61,6 +61,7 @@ char *drivers[] = {
"radeon",
"nouveau",
"vmwgfx",
+   "exynos-drm",
NULL
 };

diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 229ab8a..8059414 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -721,7 +721,8 @@ int main(int argc, char **argv)
int c;
int encoders = 0, connectors = 0, crtcs = 0, framebuffers = 0;
int test_vsync = 0;
-   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx" };
+   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx",
+   "exynos-drm" };
char *modeset = NULL;
int i, count = 0;
struct connector con_args[2];
diff --git a/tests/vbltest/vbltest.c b/tests/vbltest/vbltest.c
index 903ca0f..340a5c1 100644
--- a/tests/vbltest/vbltest.c
+++ b/tests/vbltest/vbltest.c
@@ -103,7 +103,8 @@ static void usage(char *name)
 int main(int argc, char **argv)
 {
int i, c, fd, ret;
-   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx" };
+   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx",
+   "exynos-drm" };
drmVBlank vbl;
drmEventContext evctx;
struct vbl_info handler_info;
-- 
1.7.4.1

[PATCH] drm/nouveau: Use vsprintf extension %pV

[Joe Perches]

Using %pV can save text.

Replace NV_PRINTK macro with nv_printk and use
of vsprintf extension %pV.

Convert the NV_ macros to use nv_printk
and neaten them too.

Saves ~45KB or ~5% of total code space for nouveau.

$ size drivers/gpu/drm/nouveau/built-in.o*
   textdata bss dec hex filename
 781185   25499  176860  983544   f01f8 drivers/gpu/drm/nouveau/built-in.o.new
 820650   25499  184356 1030505   fb969 drivers/gpu/drm/nouveau/built-in.o.old

Signed-off-by: Joe Perches 

---

Modified resend of https://lkml.org/lkml/2011/6/28/505

 drivers/gpu/drm/nouveau/nouveau_dp.c  |9 ++--
 drivers/gpu/drm/nouveau/nouveau_drv.c |   20 ++
 drivers/gpu/drm/nouveau/nouveau_drv.h |   67 +++-
 3 files changed, 65 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c 
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index de5efe7..087ede3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_dp.c
+++ b/drivers/gpu/drm/nouveau/nouveau_dp.c
@@ -33,10 +33,11 @@
 /**
  * aux channel util functions
  */
-#define AUX_DBG(fmt, args...) do { 
\
-   if (nouveau_reg_debug & NOUVEAU_REG_DEBUG_AUXCH) { \
-   NV_PRINTK(KERN_DEBUG, dev, "AUXCH(%d): " fmt, ch, ##args); \
-   }  \
+#define AUX_DBG(fmt, ...)  \
+do {   \
+   if (nouveau_reg_debug & NOUVEAU_REG_DEBUG_AUXCH)\
+   nv_printk(dev, KERN_DEBUG, "AUXCH(%d): " fmt,   \
+ ch, ##__VA_ARGS__);   \
 } while (0)
 #define AUX_ERR(fmt, args...) NV_ERROR(dev, "AUXCH(%d): " fmt, ch, ##args)

diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.c 
b/drivers/gpu/drm/nouveau/nouveau_drv.c
index f0a60af..0eed2a9 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.c
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.c
@@ -494,3 +494,23 @@ module_exit(nouveau_exit);
 MODULE_AUTHOR(DRIVER_AUTHOR);
 MODULE_DESCRIPTION(DRIVER_DESC);
 MODULE_LICENSE("GPL and additional rights");
+
+int nv_printk(const struct drm_device *drm_dev,
+ const char *level, const char *format, ...)
+{
+   struct va_format vaf;
+   va_list args;
+   int r;
+
+   va_start(args, format);
+
+   vaf.fmt = format;
+   vaf.va = &args;
+
+   r = printk("%s[" DRM_NAME "] " DRIVER_NAME " %s: %pV",
+  level, pci_name(drm_dev->pdev), &vaf);
+
+   va_end(args);
+
+   return r;
+}
diff --git a/drivers/gpu/drm/nouveau/nouveau_drv.h 
b/drivers/gpu/drm/nouveau/nouveau_drv.h
index dfddb7e..80f49d4 100644
--- a/drivers/gpu/drm/nouveau/nouveau_drv.h
+++ b/drivers/gpu/drm/nouveau/nouveau_drv.h
@@ -1537,37 +1537,48 @@ extern void nv_wo32(struct nouveau_gpuobj *, u32 
offset, u32 val);
  * Logging
  * Argument d is (struct drm_device *).
  */
-#define NV_PRINTK(level, d, fmt, arg...) \
-   printk(level "[" DRM_NAME "] " DRIVER_NAME " %s: " fmt, \
-   pci_name(d->pdev), ##arg)
+
+extern __attribute__ ((format (printf, 3, 4)))
+int nv_printk(const struct drm_device *drm_dev,
+ const char *level, const char *format, ...);
+
 #ifndef NV_DEBUG_NOTRACE
-#define NV_DEBUG(d, fmt, arg...) do {  
\
-   if (drm_debug & DRM_UT_DRIVER) {   \
-   NV_PRINTK(KERN_DEBUG, d, "%s:%d - " fmt, __func__, \
- __LINE__, ##arg);\
-   }  \
+#define NV_DEBUG(d, fmt, ...)  \
+do {   \
+   if (drm_debug & DRM_UT_DRIVER) {\
+   nv_printk(d, KERN_DEBUG, "%s:%d - " fmt,\
+ __func__, __LINE__, ##__VA_ARGS__);   \
+   }   \
 } while (0)
-#define NV_DEBUG_KMS(d, fmt, arg...) do {  
\
-   if (drm_debug & DRM_UT_KMS) {  \
-   NV_PRINTK(KERN_DEBUG, d, "%s:%d - " fmt, __func__, \
- __LINE__, ##arg);\
-   }  \
+#define NV_DEBUG_KMS(d, fmt, ...)  \
+do {   \
+   if (drm_debug & DRM_UT_KMS) {   

[Bug 30227] [RADEON:KMS:AGP:R300:PPC] random X freeze by a GPU lockup

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

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

--- Comment #11 from Michel D?nzer  2011-12-15 10:12:05 
PST ---
(In reply to comment #10)
> However, for me it crashes about 10-20 seconds when glxgears is running, or it
> instantly crashes when I attempt to move or resize a window in WindowMaker.
> 
> Setting agpmode=-1 fixes the problem for me.

Given your slightly different symptoms, I think we have to assume it's not
exactly the same problem. Please file your own report with all the relevant
information (at least dmesg output pertaining to agp/drm/radeon).

BTW, if you can narrow down where exactly in r300_asic_reset() the machine
check happens, maybe we can fix that.

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

[Bug 43698] On PPC, OpenGL programs use incorrect texture colors.

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

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

--- Comment #8 from Michel D?nzer  2011-12-15 10:02:06 
PST ---
Created attachment 54470
  --> https://bugs.freedesktop.org/attachment.cgi?id=54470
WIP endianness fixes

Here's some Mesa/Gallium endianness fixes I've been working on. Note that I'm
serious about 'WIP'; at the very least, this will need to be split/cleaned up,
and e.g. the util changes are just a quick'n'dirty hack which mixes driver
specific requirements into driver independent code. Also, this will probably
break colours with the r600g driver on big endian, but that should be easy to
fix by disabling its use of GPU byte swapping for textures and render targets,
and I think that's necessary anyway to work correctly in all cases possible
with OpenGL.

I'm still seeing some wrong colours e.g. in gnome-shell and assaultcube, either
I'm missing some more vital formats, or there could be similar issues with
vertex colours.

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

[Bug 43332] corrupted output in mesa-demo/fp-tri using r600g on evergreen

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

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

--- Comment #3 from Stefano Teso  2011-12-15 
09:53:39 PST ---
(In reply to comment #2)
> > The bug is also present in the libGL 7.11.2 shipped by debian, so I don't 
> > think
> > it's a regression or a bug in my config.
> 
> It looks like that inst->Dst[0].Register.WriteMask == 3 in tgsi_scs (), so the
> ZW components of the dest register are never written. Perhaps this could
> explain the artifact. Not that I'm a GL expert or anything ;-)

Forcing the mask to 15 fixes the problem. Of course this is no solution. Likely
the fragment color is not cleared properly before calling SCS?

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

[Bug 43655] Latest radeon dri driver on HD6950 with kernel 3.2 flickers

[bugzilla-daemon]

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

--- Comment #8 from Alexandre Demers  2011-12-15 
17:50:38 PST ---
I think I've found a hint. Here's the thing:

Whatever kernel version is the first entry in my Grub's list, the problem will
appear. If I select a different kernel manually or if I change the default menu
entry to a different one, everything is fine. The only exception is if my first
menu entry is Windows. Then, there is never any problem.

Here is what I see when selecting the first entry. First, the Grub's background
stays for a moment and then it switches to the boot screen (using Ubuntu, it
shows the Ubuntu loading screen). However, most of the time, it will flicker,
usually showing only a couple of clear lines at the top of the screen.

If I select another entry, it switches to the kernel initialization (showing
step by step what is being done) and then it switches to the boot screen only
after having initialized correctly the screen. The only difference I can see
between the first entries and the others is the following in my grub.cfg:
set gfxpayload=$linux_gfx_mode

I suspect a bad interaction between Grub and the rest of the initialization
process. Does my suspicion make sense?

-- 
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 43332] corrupted output in mesa-demo/fp-tri using r600g on evergreen

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

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

--- Comment #2 from Stefano Teso  2011-12-15 
09:37:46 PST ---
> The bug is also present in the libGL 7.11.2 shipped by debian, so I don't 
> think
> it's a regression or a bug in my config.

It looks like that inst->Dst[0].Register.WriteMask == 3 in tgsi_scs (), so the
ZW components of the dest register are never written. Perhaps this could
explain the artifact. Not that I'm a GL expert or anything ;-)

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

[Bug 43719] drm-core-next + AGP RV670 = Oops

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

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

--- Comment #1 from Andy Furniss  2011-12-15 
09:20:05 PST ---
(In reply to comment #0)
> I don't use this box any more as such, and this is the first drm-core-next ..

I tested some more and the latest working commit is

commit 822c4d9ae0d55a4fcea9f0a462bc6406a06692e2
Author: Jerome Glisse 
Date:   Thu Nov 10 18:24:09 2011 -0500

 drm/ttm: page allocation use page array instead of list

Starting with the commit following that - 

commit 649bf3ca77343e3be1e0af8e21356fa569b1abd9
Author: Jerome Glisse 
Date:   Tue Nov 1 20:46:13 2011 -0400

  drm/ttm: merge ttm_backend and ttm_tt V5

I get an Oops - but it is not the same as the one on head, I can start kms and
fbcon is working.

When I startx I get-

Dec 15 17:28:34 nf7 kernel: [drm] Initialized drm 1.1.0 20060810
Dec 15 17:28:35 nf7 kernel: [drm] radeon kernel modesetting enabled.
Dec 15 17:28:35 nf7 kernel: ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19
Dec 15 17:28:35 nf7 kernel: radeon :02:00.0: PCI INT A -> Link[APC4] -> GSI
19 (level, high) -> IRQ 19
Dec 15 17:28:35 nf7 kernel: [drm] initializing kernel modesetting (RV670
0x1002:0x9515 0x174B:0x0028).
Dec 15 17:28:35 nf7 kernel: [drm] register mmio base: 0xE100
Dec 15 17:28:35 nf7 kernel: [drm] register mmio size: 65536
Dec 15 17:28:35 nf7 kernel: ATOM BIOS: 
Dec 15 17:28:35 nf7 kernel: [drm] AGP mode requested: 8
Dec 15 17:28:35 nf7 kernel: agpgart-nvidia :00:00.0: AGP 3.0 bridge
Dec 15 17:28:35 nf7 kernel: agpgart-nvidia :00:00.0: putting AGP V3 device
into 8x mode
Dec 15 17:28:35 nf7 kernel: radeon :02:00.0: putting AGP V3 device into 8x
mode
Dec 15 17:28:35 nf7 kernel: radeon :02:00.0: GTT: 256M 0xC000 -
0xCFFF
Dec 15 17:28:35 nf7 kernel: radeon :02:00.0: VRAM: 512M 0xA000 -
0xBFFF (512M used)
Dec 15 17:28:35 nf7 kernel: [drm] Detected VRAM RAM=512M, BAR=256M
Dec 15 17:28:35 nf7 kernel: [drm] RAM width 256bits DDR
Dec 15 17:28:35 nf7 kernel: [TTM] Zone  kernel: Available graphics memory:
451408 kiB.
Dec 15 17:28:35 nf7 kernel: [TTM] Initializing pool allocator.
Dec 15 17:28:35 nf7 kernel: [drm] radeon: 512M of VRAM memory ready
Dec 15 17:28:35 nf7 kernel: [drm] radeon: 256M of GTT memory ready.
Dec 15 17:28:35 nf7 kernel: [drm] Supports vblank timestamp caching Rev 1
(10.10.2010).
Dec 15 17:28:35 nf7 kernel: [drm] Driver supports precise vblank timestamp
query.
Dec 15 17:28:35 nf7 kernel: [drm] radeon: irq initialized.
Dec 15 17:28:35 nf7 kernel: [drm] GART: num cpu pages 65536, num gpu pages
65536
Dec 15 17:28:35 nf7 kernel: [drm] Loading RV670 Microcode
Dec 15 17:28:35 nf7 kernel: radeon :02:00.0: WB disabled
Dec 15 17:28:35 nf7 kernel: [drm] ring test succeeded in 0 usecs
Dec 15 17:28:35 nf7 kernel: [drm] radeon: ib pool ready.
Dec 15 17:28:35 nf7 kernel: [drm] ib test succeeded in 0 usecs
Dec 15 17:28:35 nf7 kernel: [drm] Radeon Display Connectors
Dec 15 17:28:35 nf7 kernel: [drm] Connector 0:
Dec 15 17:28:35 nf7 kernel: [drm]   DVI-I
Dec 15 17:28:35 nf7 kernel: [drm]   HPD1
Dec 15 17:28:35 nf7 kernel: [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58
0x7e58 0x7e5c 0x7e5c
Dec 15 17:28:35 nf7 kernel: [drm]   Encoders:
Dec 15 17:28:35 nf7 kernel: [drm] DFP1: INTERNAL_KLDSCP_TMDS1
Dec 15 17:28:35 nf7 kernel: [drm] CRT2: INTERNAL_KLDSCP_DAC2
Dec 15 17:28:35 nf7 kernel: [drm] Connector 1:
Dec 15 17:28:35 nf7 kernel: [drm]   DIN
Dec 15 17:28:35 nf7 kernel: [drm]   Encoders:
Dec 15 17:28:35 nf7 kernel: [drm] TV1: INTERNAL_KLDSCP_DAC2
Dec 15 17:28:35 nf7 kernel: [drm] Connector 2:
Dec 15 17:28:35 nf7 kernel: [drm]   DVI-I
Dec 15 17:28:35 nf7 kernel: [drm]   HPD2
Dec 15 17:28:35 nf7 kernel: [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48
0x7e48 0x7e4c 0x7e4c
Dec 15 17:28:35 nf7 kernel: [drm]   Encoders:
Dec 15 17:28:35 nf7 kernel: [drm] CRT1: INTERNAL_KLDSCP_DAC1
Dec 15 17:28:35 nf7 kernel: [drm] DFP2: INTERNAL_LVTM1
Dec 15 17:28:35 nf7 kernel: [drm] Internal thermal controller with fan control
Dec 15 17:28:35 nf7 kernel: [drm] radeon: power management initialized
Dec 15 17:28:35 nf7 kernel: [drm] fb mappable at 0xD00C2000
Dec 15 17:28:35 nf7 kernel: [drm] vram apper at 0xD000
Dec 15 17:28:35 nf7 kernel: [drm] size 8294400
Dec 15 17:28:35 nf7 kernel: [drm] fb depth is 24
Dec 15 17:28:35 nf7 kernel: [drm]pitch is 7680
Dec 15 17:28:35 nf7 kernel: fbcon: radeondrmfb (fb0) is primary device
Dec 15 17:28:36 nf7 kernel: Console: switching to colour frame buffer device
240x67
Dec 15 17:28:36 nf7 kernel: fb0: radeondrmfb frame buffer device
Dec 15 17:28:36 nf7 kernel: drm: registered panic notifier
Dec 15 17:28:36 nf7 kernel: [drm] Initialized radeon 2.11.0 20080528 for
:02:00.0 on minor 0
Dec 15 17:28:59 nf7 kernel: BUG: unable to handle kernel NULL pointer
dereference at 001b
Dec 15 17:28:59 nf7 kernel: IP: [] fput+0x10/0x1f0
Dec 15 17:28:59 nf7 kernel: *pde =  
Dec 15 17:28:59 nf7 kernel: Oops: 0002 [#1] PREEMPT 
Dec 15 17:28:59 nf7 kernel: Modules linked in: radeo

[mipsel+rs780e]Occasionally "GPU lockup" after resuming from suspend.

[Michel Dänzer]

On Don, 2011-12-08 at 19:35 +0800, chenhc at lemote.com wrote:
> 
> I found CP_RB_WPTR has changed when "ring test failed", so I think CP is
> active, but what it get from ring buffer is wrong.

CP_RB_WPTR is normally only changed by the CPU after adding commands to
the ring buffer, so I'm afraid that may not be a valid conclusion. 


> Then, I want to know whether there is a way to check the content that
> GPU get from ring buffer. 

See the r100_debugfs_cp_csq_fifo() function, which generates the output
for /sys/kernel/debug/dri/0/r100_cp_csq_fifo. 


> BTW, when I use "echo shutdown > /sys/power/disk; echo disk >
> /sys/power/state" to do a hibernation, there will be occasionally "GPU
> reset" just like suspend. However, if I use "echo reboot >
> /sys/power/disk; echo disk > /sys/power/state" to do a hibernation and
> wakeup automatically, there is no "GPU reset" after hundreds of tests.
> What does this imply? Power loss cause something break?

Yeah, it sounds like the resume code doesn't properly re-initialize
something that's preserved on a warm boot but lost on a cold boot. 


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

[Bug 43861] Build error in latest git master

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

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTOURBUG

--- Comment #1 from Alex Deucher  2011-12-15 08:49:21 PST 
---
Builds fine here.

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

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

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

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

--- Comment #8 from Alex Deucher  2011-12-15 08:44:55 PST 
---
Does the system hang if you remove the NoAccel option but don't load
gnome-shell?

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

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

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

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

--- Comment #7 from Alex Deucher  2011-12-15 08:43:49 PST 
---
(In reply to comment #6)
> (In reply to comment #5)
> > What version of the 3D driver is he using?  
> 
> How could we check this?

Please attach the output of glxinfo.

> 
> > You might try a newer 3D driver package.  Make sure he is using the r300 
> > gallium driver (r300g).
> 
> As he's on Debian Wheezy he has installed "libgl1-mesa-dri (7.11.1-1)" but not
> sure if this tells you something.

Just need to find out if they are using the classic or gallium driver.

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

[Bug 43655] Latest radeon dri driver on HD6950 with kernel 3.2 flickers

[bugzilla-daemon]

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

Alexandre Demers  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |

--- Comment #7 from Alexandre Demers  2011-12-15 
16:31:19 PST ---
This is one driving me crazy. You were right, it is no reproducible everytime.
I have to reboot a couple of time to trigger it or to fix it... Going back to
bisection.

-- 
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 43861] New: Build error in latest git master

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

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

 Bug #: 43861
   Summary: Build error in latest git master
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: All
   URL: https://build.opensuse.org/package/rawlog?arch=i586&pa
ckage=Mesa&project=home%3Ajobermayr&repository=openSUS
E_12.1
OS/Version: Linux (All)
Status: NEW
  Severity: blocker
  Priority: highest
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: johannesobermayr at gmx.de


r600_shader.c: At top level:
r600_shader.c:190:44: error: array size missing in
'r600_shader_tgsi_instruction'
r600_shader.c:190:76: error: array size missing in 'eg_shader_tgsi_instruction'
r600_shader.c:190:106: error: array size missing in
'cm_shader_tgsi_instruction'

-- 
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: call connector dpms fxn, when setting config

[Adam Jackson]

On Thu, 2011-12-15 at 14:53 -0600, Rob Clark wrote:
> From: Rob Clark 
> 
> Call connector->funcs->dpms(DPMS_ON) rather than just setting
> connector->dpms = DPMS_ON.  This ensures that if the connector
> has something to do to enable the output (rather than just using
> drm_helper_connector_dpms helper directly), that this happens
> at bootup.  This solves an issue with connectors not getting
> enabled from fbcon_init() when the driver is loaded.
> 
> Signed-off-by: Rob Clark 

Reviewed-by: Adam Jackson 

- ajax
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20111215/fe3afe33/attachment.pgp>

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

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

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

--- Comment #6 from Camale?n  2011-12-15 07:47:32 PST ---
(In reply to comment #5)
> What version of the 3D driver is he using?  

How could we check this?

> You might try a newer 3D driver package.  Make sure he is using the r300 
> gallium driver (r300g).

As he's on Debian Wheezy he has installed "libgl1-mesa-dri (7.11.1-1)" but not
sure if this tells you something.

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

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

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

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

--- Comment #5 from Alex Deucher  2011-12-15 07:29:00 PST 
---
What version of the 3D driver is he using?  You might try a newer 3D driver
package.  Make sure he is using the r300 gallium driver (r300g).

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

[Bug 41668] Screen locks up at random points when using a 3D compositing wm (gnome-shell) on an rv515 (radeon mobility x1300)

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

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

--- Comment #19 from Alex Deucher  2011-12-15 07:19:31 PST 
---
(In reply to comment #18)
> And finally: Is it a proper fix, or just a workaround?

It's a workaround.  Since those options work, it's not a radeon bug.  It's most
likely a platform bug for your board; probably a bad apic or msi setup for your
chipset.  You might need an apic or pci quirk for your motherboard chipset.

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

[Bug 43858] DVI of ATI RADEON 9200 AGP don't work

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

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

Valter  changed:

   What|Removed |Added

  Attachment #54462|0   |1
is obsolete||

--- Comment #2 from Valter  2011-12-15 07:13:09 
PST ---
Created attachment 54464
  --> https://bugs.freedesktop.org/attachment.cgi?id=54464
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.

[Bug 43858] DVI of ATI RADEON 9200 AGP don't work

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

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

--- Comment #1 from Valter  2011-12-15 07:12:26 
PST ---
Created attachment 54463
  --> https://bugs.freedesktop.org/attachment.cgi?id=54463
dmsg output

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

[Bug 43858] New: DVI of ATI RADEON 9200 AGP don't work

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

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

 Bug #: 43858
   Summary: DVI of ATI RADEON 9200 AGP don't work
Classification: Unclassified
   Product: DRI
   Version: unspecified
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel at lists.freedesktop.org
ReportedBy: valter.giovannetti at alice.it


Created attachment 54462
  --> https://bugs.freedesktop.org/attachment.cgi?id=54462
dmesg output and Xorg.0.log

Hi.
Alexdeucher advised me to file a bug on my problem.
Excuse me for for my bad English, but I'm using the Google Transaltor!
So.:
Video card ATI Radeon 9200 AGP RV280  8x 128Mb DDR SDRAM.
xserver-xorg-video-ati/radeon ver. 1:6.14.0-0ubuntu4.1
Ubuntu Natty 11.04
Motherboard ASUS A7V400-MX

The 3D effects work, even if the windows "tear" at the top when you
move.
The DVI output does not work well.
When you open, move the windows, the monitor turns off and on again.
Same thing when you move the deskptop with the cube rotating.
Even without using Gnome what actually happens is the same, but only on the
DVI.
With the VGA everything works, but with worse resolution of the monitor.
I installed (for testing) Oneiric 11.10 but the problem remains.
Can you help me?

Tanks

Valter

-- 
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: call connector dpms fxn, when setting config

[Rob Clark]

From: Rob Clark 

Call connector->funcs->dpms(DPMS_ON) rather than just setting
connector->dpms = DPMS_ON.  This ensures that if the connector
has something to do to enable the output (rather than just using
drm_helper_connector_dpms helper directly), that this happens
at bootup.  This solves an issue with connectors not getting
enabled from fbcon_init() when the driver is loaded.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_crtc_helper.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index d2619d7..2f1ec7c 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -710,7 +710,7 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
for (i = 0; i < set->num_connectors; i++) {
DRM_DEBUG_KMS("\t[CONNECTOR:%d:%s] set DPMS 
on\n", set->connectors[i]->base.id,
  
drm_get_connector_name(set->connectors[i]));
-   set->connectors[i]->dpms = DRM_MODE_DPMS_ON;
+   
set->connectors[i]->funcs->dpms(set->connectors[i], DRM_MODE_DPMS_ON);
}
}
drm_helper_disable_unused_functions(dev);
-- 
1.7.5.4

[PATCH] staging: drm/omap: fix for connectors not enabled at bootup

[Rob Clark]

On Mon, Dec 12, 2011 at 6:39 PM, Greg KH  wrote:
> On Sun, Dec 11, 2011 at 03:13:17PM -0600, Rob Clark wrote:
>> From: Rob Clark 
>>
>> The connector's dpms fxn is only triggered by userspace. ?When the
>> driver is loaded and detected displays configured, drm core only
>> calls the crtc and encoder's dpms functions.
>>
>> Signed-off-by: Rob Clark 
>> ---
>> Arguably, this could be called a work-around, and instead drm core
>> should call connector's dpms functions and rely on
>> drm_helper_connector_dpms to call encoder and crtc dpms functions.
>> If people think it is better to fix this in drm core, and don't
>> mind me making that change, then I will do that instead.
>
> Sounds like you should do that in the drm core itself, so I'll not queue
> up this patch for now.

Ok, seems to be a one line change in drm core, which I'm about to send
a patch for:

diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index d2619d7..2f1ec7c 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -710,7 +710,7 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
for (i = 0; i < set->num_connectors; i++) {
DRM_DEBUG_KMS("\t[CONNECTOR:%d:%s] set
DPMS on\n", set->connectors[i]->base.id,

drm_get_connector_name(set->connectors[i]));
-   set->connectors[i]->dpms = DRM_MODE_DPMS_ON;
+
set->connectors[i]->funcs->dpms(set->connectors[i], DRM_MODE_DPMS_ON);
}
}
drm_helper_disable_unused_functions(dev);



> thanks,
>
> greg k-h
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43871] New: shader with uniform array/record and if clauses is not translated correctly into TGSI IR

[bugzilla-daemon]

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

 Bug #: 43871
   Summary: shader with uniform array/record and if clauses is not
translated correctly into TGSI IR
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: x86-64 (AMD64)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: v...@ovi.com


Hi,

the following fragment shader :

__
#version 130
uniform int mode;
uniform vec3 red;
uniform struct {
  vec3 green;
  vec3 blue;
} teststruct;
uniform vec3 testarray[3];
out vec3 fragColor;

void main()
{
   if (mode == 0)
  fragColor = red;
   if (mode == 1)
  fragColor = teststruct.green + teststruct.blue;
   if (mode == 2)
   {
  fragColor = vec3(0.);
  for(int i = 0; i < 3; i++)
 fragColor += testarray[i];
   }
}
__

is lowered to :
__
FRAG
PROPERTY FS_COLOR0_WRITES_ALL_CBUFS 1
DCL IN[0], COLOR, LINEAR
DCL OUT[0], COLOR
  0: MOV OUT[0], IN[0]
  1: END
__

using mesa from git, swrast, and setting glsl supported version to 130 in
st_extensions.c ; glsl_compiler --dump-lir seems correct, so it might be an
issue with glsl-to-tgsi.

-- 
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 43719] drm-core-next + AGP RV670 = Oops

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

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

Michel D?nzer  changed:

   What|Removed |Added

Product|Mesa|DRI
Version|git |unspecified
  Component|Drivers/DRI/R600|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.

[Bug 41668] Screen locks up at random points when using a 3D compositing wm (gnome-shell) on an rv515 (radeon mobility x1300)

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

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

--- Comment #18 from Przemyslaw Kochanski  
2011-12-15 06:20:29 PST ---
(In reply to comment #13)
> Try the following options in the kernel command line in grub:
> pci=nomsi
> noapic
> irqpoll
> and see if any of them help.

I've tried your suggestion and it worked! I've discovered the following:

"pci=nomsi noapic irqpoll" no freeze
"pci=nomsi irqpoll" no freeze
"irqpoll" no freeze
"pci=nomsi" no freeze
"noapic" no freeze
"" freeze

So far without any of this options I can reproduce the crash in 100% cases
under 1 minute of moving image in Gimp. I did it many times when backtracing.
However, there is slight probability that I just got lucky with one of options.
I'm 100% sure I've run `update-grub` after every /etc/default/grub change.

Assuming that all of this options fix the problem, which option should I use
(witch one disables least things)? I found the following but I don't understand
much:

noapic: [SMP,APIC] Tells the kernel to not make use of any IOAPICs that may be
present in the system.

irqpoll: [HW] When an interrupt is not handled search all handlersfor it. Also
check all handlers each timerinterrupt. Intended to get systems with badly
brokenfirmware running.

pci=nomsi: [MSI] If the PCI_MSI kernel config parameter isenabled, this kernel
boot option can be used todisable the use of MSI interrupts system-wide.

And finally: Is it a proper fix, or just a workaround?

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

[Bug 43395] Game running in wine stops rendering

[bugzilla-daemon]

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

--- Comment #14 from Tomas Schlosser  2011-12-15 
14:08:15 PST ---
New updates came:
kernel 3.1.5-2.fc16
mesa-dri-drivers.x86_64 7.11.2-1.fc16
No changes, rendering stops after a few minutes (5 - 10).

I can't build mesa from git. Last time I tried (using tutorial from
http://www.mesa3d.org/ - ./autoconf.sh && make && sudo make install) I got
error while running the game saying "Access Violation".

-- 
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 43655] Latest radeon dri driver on HD6950 with kernel 3.2 flickers

[bugzilla-daemon]

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

Alexandre Demers  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||INVALID

--- Comment #6 from Alexandre Demers  2011-12-15 
14:03:15 PST ---
I tested today's latest kernel version after fighting with the beast for the
last couple of days. Just to be sure, I made a clean compilation and it now
works properly without any problem. I'll assume for the moment it was related
to something stuck in the compilation.

If anything goes wrong again, I'll reopen the bug.

-- 
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 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

[bugzilla-daemon]

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

--- Comment #11 from Alex Deucher  2011-12-15 13:40:27 PST ---
(In reply to comment #9)
> Created attachment 54475 [details] [review]
> glxinfo
> 
> I'm attaching the full output of "glxinfo".

Unfortunately, you'll end up with the software 3D driver if you have
acceleration disabled.  You'll have to find out what debian uses on wheezy
(r300c vs. r300g).  However, if you still get hangs even without using 3D,
there seems to be a problem with acceleration in general on his system.

-- 
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 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

  Attachment #54475|application/octet-stream|text/plain
  mime type||
  Attachment #54475|0   |1
   is patch||

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

[PATCH -fixes 0/3][RESEND] Documentation updates

[Thomas Hellstrom]

Dave,

Please pull this series into drm-fixes for 3.2.

Thanks,
Thomas


On 11/21/2011 01:08 PM, Thomas Hellstrom wrote:
> A couple of updates to various interface docs
>
> In-Reply-To:
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

[PATCH 1/8][RESEND] vmwgfx: Use the revised fifo hw version register when present

[Thomas Hellstrom]

Dave,

Please pull this series into drm-fixes for 3.2!

Thanks,
Thomas



On 11/28/2011 01:19 PM, Thomas Hellstrom wrote:
> The driver implements the needed resource management required
> to use that register.
>
> Signed-off-by: Thomas Hellstrom
> Reviewed-by: Jakob Bornecrantz
> ---
>   drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c  |8 +++-
>   drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c |8 +++-
>   2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
> index 03bbc2a..a0c2f12 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
> @@ -33,6 +33,7 @@ bool vmw_fifo_have_3d(struct vmw_private *dev_priv)
>   {
>   __le32 __iomem *fifo_mem = dev_priv->mmio_virt;
>   uint32_t fifo_min, hwversion;
> + const struct vmw_fifo_state *fifo =&dev_priv->fifo;
>
>   if (!(dev_priv->capabilities&  SVGA_CAP_EXTENDED_FIFO))
>   return false;
> @@ -41,7 +42,12 @@ bool vmw_fifo_have_3d(struct vmw_private *dev_priv)
>   if (fifo_min<= SVGA_FIFO_3D_HWVERSION * sizeof(unsigned int))
>   return false;
>
> - hwversion = ioread32(fifo_mem + SVGA_FIFO_3D_HWVERSION);
> + hwversion = ioread32(fifo_mem +
> +  ((fifo->capabilities&
> +SVGA_FIFO_CAP_3D_HWVERSION_REVISED) ?
> +   SVGA_FIFO_3D_HWVERSION_REVISED :
> +   SVGA_FIFO_3D_HWVERSION));
> +
>   if (hwversion == 0)
>   return false;
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c 
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
> index 3f63435..a9e2193 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
> @@ -58,8 +58,14 @@ int vmw_getparam_ioctl(struct drm_device *dev, void *data,
>   case DRM_VMW_PARAM_FIFO_HW_VERSION:
>   {
>   __le32 __iomem *fifo_mem = dev_priv->mmio_virt;
> -
> - param->value = ioread32(fifo_mem + SVGA_FIFO_3D_HWVERSION);
> + const struct vmw_fifo_state *fifo =&dev_priv->fifo;
> +
> + param->value =
> + ioread32(fifo_mem +
> +  ((fifo->capabilities&
> +SVGA_FIFO_CAP_3D_HWVERSION_REVISED) ?
> +   SVGA_FIFO_3D_HWVERSION_REVISED :
> +   SVGA_FIFO_3D_HWVERSION));
>   break;
>   }
>   default:
>

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

[bugzilla-daemon]

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

--- Comment #10 from Camaleón  2011-12-15 13:28:13 PST ---
(In reply to comment #8)
> Does the system hang if you remove the NoAccel option but don't load
> gnome-shell?

Yes, the user has reported that by removing that option from "xorg.conf" file
and login into gnome fallback mode (now "gnome classical") the system hung.

-- 
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 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

[bugzilla-daemon]

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

--- Comment #9 from Camaleón  2011-12-15 13:25:23 PST ---
Created attachment 54475
  --> https://bugs.freedesktop.org/attachment.cgi?id=54475
glxinfo

I'm attaching the full output of "glxinfo".

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

Re: [PATCH] drm: call connector dpms fxn, when setting config

[Adam Jackson]

On Thu, 2011-12-15 at 14:53 -0600, Rob Clark wrote:
> From: Rob Clark 
> 
> Call connector->funcs->dpms(DPMS_ON) rather than just setting
> connector->dpms = DPMS_ON.  This ensures that if the connector
> has something to do to enable the output (rather than just using
> drm_helper_connector_dpms helper directly), that this happens
> at bootup.  This solves an issue with connectors not getting
> enabled from fbcon_init() when the driver is loaded.
> 
> Signed-off-by: Rob Clark 

Reviewed-by: Adam Jackson 

- ajax


signature.asc
Description: This is a digitally signed message part
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: call connector dpms fxn, when setting config

[Rob Clark]

From: Rob Clark 

Call connector->funcs->dpms(DPMS_ON) rather than just setting
connector->dpms = DPMS_ON.  This ensures that if the connector
has something to do to enable the output (rather than just using
drm_helper_connector_dpms helper directly), that this happens
at bootup.  This solves an issue with connectors not getting
enabled from fbcon_init() when the driver is loaded.

Signed-off-by: Rob Clark 
---
 drivers/gpu/drm/drm_crtc_helper.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index d2619d7..2f1ec7c 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -710,7 +710,7 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
for (i = 0; i < set->num_connectors; i++) {
DRM_DEBUG_KMS("\t[CONNECTOR:%d:%s] set DPMS 
on\n", set->connectors[i]->base.id,
  
drm_get_connector_name(set->connectors[i]));
-   set->connectors[i]->dpms = DRM_MODE_DPMS_ON;
+   
set->connectors[i]->funcs->dpms(set->connectors[i], DRM_MODE_DPMS_ON);
}
}
drm_helper_disable_unused_functions(dev);
-- 
1.7.5.4

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

Re: [PATCH] staging: drm/omap: fix for connectors not enabled at bootup

[Rob Clark]

On Mon, Dec 12, 2011 at 6:39 PM, Greg KH  wrote:
> On Sun, Dec 11, 2011 at 03:13:17PM -0600, Rob Clark wrote:
>> From: Rob Clark 
>>
>> The connector's dpms fxn is only triggered by userspace.  When the
>> driver is loaded and detected displays configured, drm core only
>> calls the crtc and encoder's dpms functions.
>>
>> Signed-off-by: Rob Clark 
>> ---
>> Arguably, this could be called a work-around, and instead drm core
>> should call connector's dpms functions and rely on
>> drm_helper_connector_dpms to call encoder and crtc dpms functions.
>> If people think it is better to fix this in drm core, and don't
>> mind me making that change, then I will do that instead.
>
> Sounds like you should do that in the drm core itself, so I'll not queue
> up this patch for now.

Ok, seems to be a one line change in drm core, which I'm about to send
a patch for:

diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index d2619d7..2f1ec7c 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -710,7 +710,7 @@ int drm_crtc_helper_set_config(struct drm_mode_set *set)
for (i = 0; i < set->num_connectors; i++) {
DRM_DEBUG_KMS("\t[CONNECTOR:%d:%s] set
DPMS on\n", set->connectors[i]->base.id,

drm_get_connector_name(set->connectors[i]));
-   set->connectors[i]->dpms = DRM_MODE_DPMS_ON;
+
set->connectors[i]->funcs->dpms(set->connectors[i], DRM_MODE_DPMS_ON);
}
}
drm_helper_disable_unused_functions(dev);



> thanks,
>
> greg k-h
> ___
> 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

[Bug 41086] [r600] Screen update problems when scrolling to the right in tvbrowser (java app)

[bugzilla-daemon]

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

Harald Judt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #14 from Harald Judt  2011-12-15 12:05:10 UTC ---
Magic worked its way, and this has been fixed recently. I don't know which
component it was, but I can exclude with certainty sun-jdk, tvbrowser, the
kernel and most probably xf86-video-ati.

I think the other types of corruption reported here (chromium, gnome-terminal)
are not related to my issue.

-- 
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 41086] [r600] Screen update problems when scrolling to the right in tvbrowser (java app)

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

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

Harald Judt  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #14 from Harald Judt  2011-12-15 12:05:10 UTC ---
Magic worked its way, and this has been fixed recently. I don't know which
component it was, but I can exclude with certainty sun-jdk, tvbrowser, the
kernel and most probably xf86-video-ati.

I think the other types of corruption reported here (chromium, gnome-terminal)
are not related to my issue.

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

[PATCH v3 5/5] drm/exynos: Add plane support with fimd

[Joonyoung Shim]

The exynos fimd supports 5 window overlays. Only one window overlay of
fimd is used by the crtc, so we need plane feature to use the rest
window overlays.

This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it
is the ioctl to decide for user to assign which window overlay.

Signed-off-by: Joonyoung Shim 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
v2: consider fixed point about src_x/src_y
v3: check to be validating the zpos ioctl parameter

 drivers/gpu/drm/exynos/Makefile |3 +-
 drivers/gpu/drm/exynos/exynos_drm_crtc.c|1 +
 drivers/gpu/drm/exynos/exynos_drm_drv.c |9 ++
 drivers/gpu/drm/exynos/exynos_drm_drv.h |8 +-
 drivers/gpu/drm/exynos/exynos_drm_encoder.c |   26 -
 drivers/gpu/drm/exynos/exynos_drm_encoder.h |2 +
 drivers/gpu/drm/exynos/exynos_drm_fimd.c|   33 --
 drivers/gpu/drm/exynos/exynos_drm_plane.c   |  163 +++
 drivers/gpu/drm/exynos/exynos_drm_plane.h   |   14 +++
 include/drm/exynos_drm.h|   10 ++
 10 files changed, 254 insertions(+), 15 deletions(-)
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_plane.c
 create mode 100644 drivers/gpu/drm/exynos/exynos_drm_plane.h

diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 0496d3f..c991272 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -5,7 +5,8 @@
 ccflags-y := -Iinclude/drm -Idrivers/gpu/drm/exynos
 exynosdrm-y := exynos_drm_drv.o exynos_drm_encoder.o exynos_drm_connector.o \
exynos_drm_crtc.o exynos_drm_fbdev.o exynos_drm_fb.o \
-   exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o
+   exynos_drm_buf.o exynos_drm_gem.o exynos_drm_core.o \
+   exynos_drm_plane.o

 obj-$(CONFIG_DRM_EXYNOS) += exynosdrm.o
 obj-$(CONFIG_DRM_EXYNOS_FIMD) += exynos_drm_fimd.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_crtc.c 
b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
index a156f6c..7f22107 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_crtc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_crtc.c
@@ -380,6 +380,7 @@ int exynos_drm_crtc_create(struct drm_device *dev, unsigned 
int nr)

exynos_crtc->pipe = nr;
exynos_crtc->dpms = DRM_MODE_DPMS_OFF;
+   exynos_crtc->overlay.zpos = DEFAULT_ZPOS;
crtc = &exynos_crtc->drm_crtc;

private->crtc[nr] = crtc;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index b86a04b..050684c 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -36,6 +36,7 @@
 #include "exynos_drm_fbdev.h"
 #include "exynos_drm_fb.h"
 #include "exynos_drm_gem.h"
+#include "exynos_drm_plane.h"

 #define DRIVER_NAME"exynos-drm"
 #define DRIVER_DESC"Samsung SoC DRM"
@@ -77,6 +78,12 @@ static int exynos_drm_load(struct drm_device *dev, unsigned 
long flags)
goto err_crtc;
}

+   for (nr = 0; nr < MAX_PLANE; nr++) {
+   ret = exynos_plane_init(dev, nr);
+   if (ret)
+   goto err_crtc;
+   }
+
ret = drm_vblank_init(dev, MAX_CRTC);
if (ret)
goto err_crtc;
@@ -163,6 +170,8 @@ static struct drm_ioctl_desc exynos_ioctls[] = {
DRM_AUTH),
DRM_IOCTL_DEF_DRV(EXYNOS_GEM_MMAP,
exynos_drm_gem_mmap_ioctl, DRM_UNLOCKED | DRM_AUTH),
+   DRM_IOCTL_DEF_DRV(EXYNOS_PLANE_SET_ZPOS, exynos_plane_set_zpos_ioctl,
+   DRM_UNLOCKED | DRM_AUTH),
 };

 static const struct file_operations exynos_drm_driver_fops = {
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index 8018798..8e8d8f0 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -33,6 +33,8 @@
 #include "drm.h"

 #define MAX_CRTC   2
+#define MAX_PLANE  5
+#define DEFAULT_ZPOS   -1

 struct drm_device;
 struct exynos_drm_overlay;
@@ -57,8 +59,8 @@ enum exynos_drm_output_type {
 struct exynos_drm_overlay_ops {
void (*mode_set)(struct device *subdrv_dev,
 struct exynos_drm_overlay *overlay);
-   void (*commit)(struct device *subdrv_dev);
-   void (*disable)(struct device *subdrv_dev);
+   void (*commit)(struct device *subdrv_dev, int zpos);
+   void (*disable)(struct device *subdrv_dev, int zpos);
 };

 /*
@@ -83,6 +85,7 @@ struct exynos_drm_overlay_ops {
  * @dma_addr: bus(accessed by dma) address to the memory region allocated
  * for a overlay.
  * @vaddr: virtual memory addresss to this overlay.
+ * @zpos: order of overlay layer(z position).
  * @default_win: a window to be enabled.
  * @color_key: color key on or off.
  * @index_color: if using color key feature then this value would be used
@@ -111,6 +114,7 @@ struct exynos_drm_overlay {
unsigned int pitch;
dma_addr_t dm

[PATCH v2 5/5] drm/exynos: Add plane support with fimd

[Joonyoung Shim]

On 12/15/2011 02:26 AM, Jesse Barnes wrote:
> On Wed, 14 Dec 2011 19:00:15 +0900
> Joonyoung Shim  wrote:
>
>> The exynos fimd supports 5 window overlays. Only one window overlay of
>> fimd is used by the crtc, so we need plane feature to use the rest
>> window overlays.
>>
>> This creates one ioctl exynos specific - DRM_EXYNOS_PLANE_SET_ZPOS, it
>> is the ioctl to decide for user to assign which window overlay.
>>
>> Signed-off-by: Joonyoung Shim
>> Signed-off-by: Inki Dae
>> Signed-off-by: Kyungmin Park
>> ---
>> v2: consider fixed point about src_x/src_y
> Looks pretty good; the only thing that jumped out was that you don't
> seem to be validating the zpos ioctl parameters for sanity.  Not sure
> if there's much to do, but it may be worth checking for a max zpos or
> something...
>

OK, i added to check to be validating the zpos ioctl parameter.

Thanks.

[Bug 43655] Latest radeon dri driver on HD6950 with kernel 3.2 flickers

[bugzilla-daemon]

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

--- Comment #5 from Michel Dänzer  2011-12-15 10:18:01 UTC 
---
It sounds like the problem may happen or not with a certain probability with
any given kernel. You should probably test each kernel a certain number of
times before declaring it as good, or the bisection may not work correctly.

-- 
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 43655] Latest radeon dri driver on HD6950 with kernel 3.2 flickers

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

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

--- Comment #5 from Michel D?nzer  2011-12-15 10:18:01 
UTC ---
It sounds like the problem may happen or not with a certain probability with
any given kernel. You should probably test each kernel a certain number of
times before declaring it as good, or the bisection may not work correctly.

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

[Bug 30227] [RADEON:KMS:AGP:R300:PPC] random X freeze by a GPU lockup

[bugzilla-daemon]

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

--- Comment #11 from Michel Dänzer  2011-12-15 10:12:05 PST 
---
(In reply to comment #10)
> However, for me it crashes about 10-20 seconds when glxgears is running, or it
> instantly crashes when I attempt to move or resize a window in WindowMaker.
> 
> Setting agpmode=-1 fixes the problem for me.

Given your slightly different symptoms, I think we have to assume it's not
exactly the same problem. Please file your own report with all the relevant
information (at least dmesg output pertaining to agp/drm/radeon).

BTW, if you can narrow down where exactly in r300_asic_reset() the machine
check happens, maybe we can fix that.

-- 
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 43698] On PPC, OpenGL programs use incorrect texture colors.

[bugzilla-daemon]

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

--- Comment #8 from Michel Dänzer  2011-12-15 10:02:06 PST 
---
Created attachment 54470
  --> https://bugs.freedesktop.org/attachment.cgi?id=54470
WIP endianness fixes

Here's some Mesa/Gallium endianness fixes I've been working on. Note that I'm
serious about 'WIP'; at the very least, this will need to be split/cleaned up,
and e.g. the util changes are just a quick'n'dirty hack which mixes driver
specific requirements into driver independent code. Also, this will probably
break colours with the r600g driver on big endian, but that should be easy to
fix by disabling its use of GPU byte swapping for textures and render targets,
and I think that's necessary anyway to work correctly in all cases possible
with OpenGL.

I'm still seeing some wrong colours e.g. in gnome-shell and assaultcube, either
I'm missing some more vital formats, or there could be similar issues with
vertex colours.

-- 
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 43332] corrupted output in mesa-demo/fp-tri using r600g on evergreen

[bugzilla-daemon]

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

--- Comment #3 from Stefano Teso  2011-12-15 09:53:39 
PST ---
(In reply to comment #2)
> > The bug is also present in the libGL 7.11.2 shipped by debian, so I don't 
> > think
> > it's a regression or a bug in my config.
> 
> It looks like that inst->Dst[0].Register.WriteMask == 3 in tgsi_scs (), so the
> ZW components of the dest register are never written. Perhaps this could
> explain the artifact. Not that I'm a GL expert or anything ;-)

Forcing the mask to 15 fixes the problem. Of course this is no solution. Likely
the fragment color is not cleared properly before calling SCS?

-- 
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 43332] corrupted output in mesa-demo/fp-tri using r600g on evergreen

[bugzilla-daemon]

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

--- Comment #2 from Stefano Teso  2011-12-15 09:37:46 
PST ---
> The bug is also present in the libGL 7.11.2 shipped by debian, so I don't 
> think
> it's a regression or a bug in my config.

It looks like that inst->Dst[0].Register.WriteMask == 3 in tgsi_scs (), so the
ZW components of the dest register are never written. Perhaps this could
explain the artifact. Not that I'm a GL expert or anything ;-)

-- 
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 43719] drm-core-next + AGP RV670 = Oops

[bugzilla-daemon]

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

--- Comment #1 from Andy Furniss  2011-12-15 
09:20:05 PST ---
(In reply to comment #0)
> I don't use this box any more as such, and this is the first drm-core-next ..

I tested some more and the latest working commit is

commit 822c4d9ae0d55a4fcea9f0a462bc6406a06692e2
Author: Jerome Glisse 
Date:   Thu Nov 10 18:24:09 2011 -0500

 drm/ttm: page allocation use page array instead of list

Starting with the commit following that - 

commit 649bf3ca77343e3be1e0af8e21356fa569b1abd9
Author: Jerome Glisse 
Date:   Tue Nov 1 20:46:13 2011 -0400

  drm/ttm: merge ttm_backend and ttm_tt V5

I get an Oops - but it is not the same as the one on head, I can start kms and
fbcon is working.

When I startx I get-

Dec 15 17:28:34 nf7 kernel: [drm] Initialized drm 1.1.0 20060810
Dec 15 17:28:35 nf7 kernel: [drm] radeon kernel modesetting enabled.
Dec 15 17:28:35 nf7 kernel: ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19
Dec 15 17:28:35 nf7 kernel: radeon :02:00.0: PCI INT A -> Link[APC4] -> GSI
19 (level, high) -> IRQ 19
Dec 15 17:28:35 nf7 kernel: [drm] initializing kernel modesetting (RV670
0x1002:0x9515 0x174B:0x0028).
Dec 15 17:28:35 nf7 kernel: [drm] register mmio base: 0xE100
Dec 15 17:28:35 nf7 kernel: [drm] register mmio size: 65536
Dec 15 17:28:35 nf7 kernel: ATOM BIOS: 
Dec 15 17:28:35 nf7 kernel: [drm] AGP mode requested: 8
Dec 15 17:28:35 nf7 kernel: agpgart-nvidia :00:00.0: AGP 3.0 bridge
Dec 15 17:28:35 nf7 kernel: agpgart-nvidia :00:00.0: putting AGP V3 device
into 8x mode
Dec 15 17:28:35 nf7 kernel: radeon :02:00.0: putting AGP V3 device into 8x
mode
Dec 15 17:28:35 nf7 kernel: radeon :02:00.0: GTT: 256M 0xC000 -
0xCFFF
Dec 15 17:28:35 nf7 kernel: radeon :02:00.0: VRAM: 512M 0xA000 -
0xBFFF (512M used)
Dec 15 17:28:35 nf7 kernel: [drm] Detected VRAM RAM=512M, BAR=256M
Dec 15 17:28:35 nf7 kernel: [drm] RAM width 256bits DDR
Dec 15 17:28:35 nf7 kernel: [TTM] Zone  kernel: Available graphics memory:
451408 kiB.
Dec 15 17:28:35 nf7 kernel: [TTM] Initializing pool allocator.
Dec 15 17:28:35 nf7 kernel: [drm] radeon: 512M of VRAM memory ready
Dec 15 17:28:35 nf7 kernel: [drm] radeon: 256M of GTT memory ready.
Dec 15 17:28:35 nf7 kernel: [drm] Supports vblank timestamp caching Rev 1
(10.10.2010).
Dec 15 17:28:35 nf7 kernel: [drm] Driver supports precise vblank timestamp
query.
Dec 15 17:28:35 nf7 kernel: [drm] radeon: irq initialized.
Dec 15 17:28:35 nf7 kernel: [drm] GART: num cpu pages 65536, num gpu pages
65536
Dec 15 17:28:35 nf7 kernel: [drm] Loading RV670 Microcode
Dec 15 17:28:35 nf7 kernel: radeon :02:00.0: WB disabled
Dec 15 17:28:35 nf7 kernel: [drm] ring test succeeded in 0 usecs
Dec 15 17:28:35 nf7 kernel: [drm] radeon: ib pool ready.
Dec 15 17:28:35 nf7 kernel: [drm] ib test succeeded in 0 usecs
Dec 15 17:28:35 nf7 kernel: [drm] Radeon Display Connectors
Dec 15 17:28:35 nf7 kernel: [drm] Connector 0:
Dec 15 17:28:35 nf7 kernel: [drm]   DVI-I
Dec 15 17:28:35 nf7 kernel: [drm]   HPD1
Dec 15 17:28:35 nf7 kernel: [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58
0x7e58 0x7e5c 0x7e5c
Dec 15 17:28:35 nf7 kernel: [drm]   Encoders:
Dec 15 17:28:35 nf7 kernel: [drm] DFP1: INTERNAL_KLDSCP_TMDS1
Dec 15 17:28:35 nf7 kernel: [drm] CRT2: INTERNAL_KLDSCP_DAC2
Dec 15 17:28:35 nf7 kernel: [drm] Connector 1:
Dec 15 17:28:35 nf7 kernel: [drm]   DIN
Dec 15 17:28:35 nf7 kernel: [drm]   Encoders:
Dec 15 17:28:35 nf7 kernel: [drm] TV1: INTERNAL_KLDSCP_DAC2
Dec 15 17:28:35 nf7 kernel: [drm] Connector 2:
Dec 15 17:28:35 nf7 kernel: [drm]   DVI-I
Dec 15 17:28:35 nf7 kernel: [drm]   HPD2
Dec 15 17:28:35 nf7 kernel: [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48
0x7e48 0x7e4c 0x7e4c
Dec 15 17:28:35 nf7 kernel: [drm]   Encoders:
Dec 15 17:28:35 nf7 kernel: [drm] CRT1: INTERNAL_KLDSCP_DAC1
Dec 15 17:28:35 nf7 kernel: [drm] DFP2: INTERNAL_LVTM1
Dec 15 17:28:35 nf7 kernel: [drm] Internal thermal controller with fan control
Dec 15 17:28:35 nf7 kernel: [drm] radeon: power management initialized
Dec 15 17:28:35 nf7 kernel: [drm] fb mappable at 0xD00C2000
Dec 15 17:28:35 nf7 kernel: [drm] vram apper at 0xD000
Dec 15 17:28:35 nf7 kernel: [drm] size 8294400
Dec 15 17:28:35 nf7 kernel: [drm] fb depth is 24
Dec 15 17:28:35 nf7 kernel: [drm]pitch is 7680
Dec 15 17:28:35 nf7 kernel: fbcon: radeondrmfb (fb0) is primary device
Dec 15 17:28:36 nf7 kernel: Console: switching to colour frame buffer device
240x67
Dec 15 17:28:36 nf7 kernel: fb0: radeondrmfb frame buffer device
Dec 15 17:28:36 nf7 kernel: drm: registered panic notifier
Dec 15 17:28:36 nf7 kernel: [drm] Initialized radeon 2.11.0 20080528 for
:02:00.0 on minor 0
Dec 15 17:28:59 nf7 kernel: BUG: unable to handle kernel NULL pointer
dereference at 001b
Dec 15 17:28:59 nf7 kernel: IP: [] fput+0x10/0x1f0
Dec 15 17:28:59 nf7 kernel: *pde =  
Dec 15 17:28:59 nf7 kernel: Oops: 0002 [#1] PREEMPT 
Dec 15 17:28:59 nf7 kernel: Modules linked in: radeo

[Bug 43861] Build error in latest git master

[bugzilla-daemon]

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

Alex Deucher  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||NOTOURBUG

--- Comment #1 from Alex Deucher  2011-12-15 08:49:21 PST ---
Builds fine here.

-- 
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 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

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

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

--- Comment #4 from Camale?n  2011-12-15 00:49:15 PST ---
(In reply to comment #3)

> I have asked the user to try with this option while having the firmware 
> package
> installed, will report back as soon as I get the results.

The user reported that both kernels do work (no crashes) with
"firmware-linux-nonfree" installed and using this "/etc/X11/xorg.conf" file:

***
Section "Device"
Identifier  "ATI"
Driver  "radeon"
Option  "NoAccel" "True"
EndSection

Section "Screen"
Identifier "Default Screen"
DefaultDepth 24
EndSection
***

This effectively disables 3D acceleration (which means no "gnome-shell") but
the user hasn't experienced any further crash since yesterday.

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

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

[bugzilla-daemon]

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

--- Comment #8 from Alex Deucher  2011-12-15 08:44:55 PST ---
Does the system hang if you remove the NoAccel option but don't load
gnome-shell?

-- 
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 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

[bugzilla-daemon]

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

--- Comment #7 from Alex Deucher  2011-12-15 08:43:49 PST ---
(In reply to comment #6)
> (In reply to comment #5)
> > What version of the 3D driver is he using?  
> 
> How could we check this?

Please attach the output of glxinfo.

> 
> > You might try a newer 3D driver package.  Make sure he is using the r300 
> > gallium driver (r300g).
> 
> As he's on Debian Wheezy he has installed "libgl1-mesa-dri (7.11.1-1)" but not
> sure if this tells you something.

Just need to find out if they are using the classic or gallium driver.

-- 
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 43861] New: Build error in latest git master

[bugzilla-daemon]

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

 Bug #: 43861
   Summary: Build error in latest git master
Classification: Unclassified
   Product: Mesa
   Version: git
  Platform: All
   URL: https://build.opensuse.org/package/rawlog?arch=i586&pa
ckage=Mesa&project=home%3Ajobermayr&repository=openSUS
E_12.1
OS/Version: Linux (All)
Status: NEW
  Severity: blocker
  Priority: highest
 Component: Drivers/Gallium/r600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: johannesoberm...@gmx.de


r600_shader.c: At top level:
r600_shader.c:190:44: error: array size missing in
'r600_shader_tgsi_instruction'
r600_shader.c:190:76: error: array size missing in 'eg_shader_tgsi_instruction'
r600_shader.c:190:106: error: array size missing in
'cm_shader_tgsi_instruction'

-- 
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: [mipsel+rs780e]Occasionally "GPU lockup" after resuming from suspend.

[Michel Dänzer]

On Don, 2011-12-08 at 19:35 +0800, che...@lemote.com wrote:
> 
> I found CP_RB_WPTR has changed when "ring test failed", so I think CP is
> active, but what it get from ring buffer is wrong.

CP_RB_WPTR is normally only changed by the CPU after adding commands to
the ring buffer, so I'm afraid that may not be a valid conclusion. 


> Then, I want to know whether there is a way to check the content that
> GPU get from ring buffer. 

See the r100_debugfs_cp_csq_fifo() function, which generates the output
for /sys/kernel/debug/dri/0/r100_cp_csq_fifo. 


> BTW, when I use "echo shutdown > /sys/power/disk; echo disk >
> /sys/power/state" to do a hibernation, there will be occasionally "GPU
> reset" just like suspend. However, if I use "echo reboot >
> /sys/power/disk; echo disk > /sys/power/state" to do a hibernation and
> wakeup automatically, there is no "GPU reset" after hundreds of tests.
> What does this imply? Power loss cause something break?

Yeah, it sounds like the resume code doesn't properly re-initialize
something that's preserved on a warm boot but lost on a cold boot. 


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast |  Debian, X and DRI developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

[bugzilla-daemon]

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

--- Comment #6 from Camaleón  2011-12-15 07:47:32 PST ---
(In reply to comment #5)
> What version of the 3D driver is he using?  

How could we check this?

> You might try a newer 3D driver package.  Make sure he is using the r300 
> gallium driver (r300g).

As he's on Debian Wheezy he has installed "libgl1-mesa-dri (7.11.1-1)" but not
sure if this tells you something.

-- 
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 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

[bugzilla-daemon]

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

--- Comment #5 from Alex Deucher  2011-12-15 07:29:00 PST ---
What version of the 3D driver is he using?  You might try a newer 3D driver
package.  Make sure he is using the r300 gallium driver (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

[Bug 41668] Screen locks up at random points when using a 3D compositing wm (gnome-shell) on an rv515 (radeon mobility x1300)

[bugzilla-daemon]

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

--- Comment #20 from Alex Deucher  2011-12-15 07:21:45 UTC ---
I would suggest emailing the linux-kernel mailing list and saying that you need
noapic or pci=msi to get things working on your board.  Include the hw details
of your system (lspci, etc.).

-- 
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 41668] Screen locks up at random points when using a 3D compositing wm (gnome-shell) on an rv515 (radeon mobility x1300)

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

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

--- Comment #20 from Alex Deucher  2011-12-15 07:21:45 UTC 
---
I would suggest emailing the linux-kernel mailing list and saying that you need
noapic or pci=msi to get things working on your board.  Include the hw details
of your system (lspci, etc.).

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

[Bug 41668] Screen locks up at random points when using a 3D compositing wm (gnome-shell) on an rv515 (radeon mobility x1300)

[bugzilla-daemon]

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

--- Comment #19 from Alex Deucher  2011-12-15 07:19:31 PST ---
(In reply to comment #18)
> And finally: Is it a proper fix, or just a workaround?

It's a workaround.  Since those options work, it's not a radeon bug.  It's most
likely a platform bug for your board; probably a bad apic or msi setup for your
chipset.  You might need an apic or pci quirk for your motherboard chipset.

-- 
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 43858] DVI of ATI RADEON 9200 AGP don't work

[bugzilla-daemon]

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

Valter  changed:

   What|Removed |Added

  Attachment #54462|0   |1
is obsolete||

--- Comment #2 from Valter  2011-12-15 07:13:09 
PST ---
Created attachment 54464
  --> https://bugs.freedesktop.org/attachment.cgi?id=54464
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

[Bug 43858] DVI of ATI RADEON 9200 AGP don't work

[bugzilla-daemon]

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

--- Comment #1 from Valter  2011-12-15 07:12:26 
PST ---
Created attachment 54463
  --> https://bugs.freedesktop.org/attachment.cgi?id=54463
dmsg output

-- 
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 43858] New: DVI of ATI RADEON 9200 AGP don't work

[bugzilla-daemon]

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

 Bug #: 43858
   Summary: DVI of ATI RADEON 9200 AGP don't work
Classification: Unclassified
   Product: DRI
   Version: unspecified
  Platform: x86 (IA32)
OS/Version: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: valter.giovanne...@alice.it


Created attachment 54462
  --> https://bugs.freedesktop.org/attachment.cgi?id=54462
dmesg output and Xorg.0.log

Hi.
Alexdeucher advised me to file a bug on my problem.
Excuse me for for my bad English, but I'm using the Google Transaltor!
So.:
Video card ATI Radeon 9200 AGP RV280  8x 128Mb DDR SDRAM.
xserver-xorg-video-ati/radeon ver. 1:6.14.0-0ubuntu4.1
Ubuntu Natty 11.04
Motherboard ASUS A7V400-MX

The 3D effects work, even if the windows "tear" at the top when you
move.
The DVI output does not work well.
When you open, move the windows, the monitor turns off and on again.
Same thing when you move the deskptop with the cube rotating.
Even without using Gnome what actually happens is the same, but only on the
DVI.
With the VGA everything works, but with worse resolution of the monitor.
I installed (for testing) Oneiric 11.10 but the problem remains.
Can you help me?

Tanks

Valter

-- 
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] drm: integer overflow in drm_mode_dirtyfb_ioctl()

[Eugene Teo]

Cc'ed Dave's work email.

On Wed, Nov 23, 2011 at 2:12 PM, Xi Wang  wrote:
> There is a potential integer overflow in drm_mode_dirtyfb_ioctl()
> if userspace passes in a large num_clips.  The call to kmalloc would
> allocate a small buffer, and the call to fb->funcs->dirty may result
> in a memory corruption.
>
> Reported-by: Haogang Chen 
> Signed-off-by: Xi Wang 
> ---
>  drivers/gpu/drm/drm_crtc.c |    4 
>  include/drm/drm_mode.h     |    2 ++
>  2 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 405c63b..8323fc3 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -1873,6 +1873,10 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
>        }
>
>        if (num_clips && clips_ptr) {
> +               if (num_clips < 0 || num_clips > DRM_MODE_FB_DIRTY_MAX_CLIPS) 
> {
> +                       ret = -EINVAL;
> +                       goto out_err1;
> +               }
>                clips = kzalloc(num_clips * sizeof(*clips), GFP_KERNEL);
>                if (!clips) {
>                        ret = -ENOMEM;
> diff --git a/include/drm/drm_mode.h b/include/drm/drm_mode.h
> index d30bedf..ddd46db 100644
> --- a/include/drm/drm_mode.h
> +++ b/include/drm/drm_mode.h
> @@ -235,6 +235,8 @@ struct drm_mode_fb_cmd {
>  #define DRM_MODE_FB_DIRTY_ANNOTATE_FILL 0x02
>  #define DRM_MODE_FB_DIRTY_FLAGS         0x03
>
> +#define DRM_MODE_FB_DIRTY_MAX_CLIPS     256
> +
>  /*
>  * Mark a region of a framebuffer as dirty.
>  *
> --
> 1.7.5.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH] drm: Enable reading 3D capabilities of 3D monitor

[Kavuri, Sateesh]

Thanks for the comments. Fixed most of the issues with the earlier patch. 
Sending out a 
new one. Comments inline below.

> -Original Message-
> From: Adam Jackson [mailto:a...@redhat.com]
> Sent: Tuesday, December 13, 2011 9:51 PM
> To: Kavuri, Sateesh
> Cc: dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH] drm: Enable reading 3D capabilities of 3D monitor
> 
> On Fri, 2011-12-09 at 11:46 +, Kavuri, Sateesh wrote:
> 
> > +   if ((multi_val == STRUCTURE_PRESENT) ||
> > +   (multi_val == STRUCTURE_MASK_PRESENT) ) {
> > +   if ((edid_ext[i+15+hdmi_vic_len] & 0x01) ==
> 0x01)
> > +   caps->format |= 0x0; /*
> FRAME_PACKING */
> > +   if ((edid_ext[i+15+hdmi_vic_len] & 0x02) ==
> 0x02)
> > +   caps->format |= 0x1;
> /*FIELD_ALTERNATIVE */
> > +   if ((edid_ext[i+15+hdmi_vic_len] & 0x04) ==
> 0x04)
> > +   caps->format |= 0x2; /*
> LINE_ALTERNATIVE */
> > +   if ((edid_ext[i+15+hdmi_vic_len] & 0x08) ==
> 0x08)
> > +   caps->format |= 0x3;
> /*SIDE_BY_SIDE_FULL */
> > +   if ((edid_ext[i+15+hdmi_vic_len] & 0x10) ==
> 0x10)
> > +   caps->format |= 0x4; /* L_DEPTH */
> > +   if ((edid_ext[i+15+hdmi_vic_len] & 0x20) ==
> 0x20)
> > +   caps->format |= 0x5; /*
> L_DEPTH_GFX_GFX_DEPTH */
> > +   if ((edid_ext[i+15+hdmi_vic_len] & 0x40) ==
> 0x40)
> > +   caps->format |= 0x6; /* TOP_BOTTOM */
> > +   if ((edid_ext[i+14+hdmi_vic_len] & 0x01) ==
> 0x01)
> > +   caps->format |= 0x7; /* S_BY_S_HALF */
> > +   if ((edid_ext[i+14+hdmi_vic_len] & 0x80) ==
> 0x80)
> > +   caps->format |= 0x8; /*
> S_BY_S_HALF_QUINCUNX */
> > +   }
> 
> This reads poorly, which makes me think it's wrong.  Is format supposed to be 
> a
> bitfield or an enum?
> 
> > +EXPORT_SYMBOL(drm_detect_3D_monitor);
> 
> I suspect this is poorly named.  There exist 3D displays which are not HDMI.

I want to integrate the other interfaces (eDP, DP, MIPI) panel detection in 
this method
itself. Started off with implementing the HDMI part. 

> 
> > +#define VSIF_RESET_INDEX 0xFFF8
> > +#define VSIF_RESET_BIT_22 0xFFBF
> > +#define VSIF_SET_BIT_19 0x8
> > +#define VSIF_RESET_BIT_20 0xFFEF
> > +#define VSIF_RESET_BIT_17 0x1
> > +#define VSIF_SET_BIT_16 0xFFFD
> > +#define VSIF_SET_MASTER_BIT 0x40
> 
> i915 style is usually to write these as (1 << 22) I think.

These I have fixed. Patch with these fixes below.

> 
> More importantly, use semantic names for register contents.  "Bit 17"
> doesn't mean anything.
> 
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index
> > 8020798..5b4d09c 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -798,6 +798,8 @@ extern int drm_mode_gamma_set_ioctl(struct
> > drm_device *dev,  extern u8 *drm_find_cea_extension(struct edid
> > *edid);  extern bool drm_detect_hdmi_monitor(struct edid *edid);
> > extern bool drm_detect_monitor_audio(struct edid *edid);
> > +extern bool drm_detect_3D_monitor(struct edid *edid); //extern struct
> > +panel_3d_caps* drm_detect_3D_monitor(struct edid *edid);
> 
> Well, which is it?
> 
> > +enum s3d_formats {
> > +   FRAME_PACKING   = 0x0,
> > +   FIELD_ALTERNATIVE   = 0x1,
> > +   LINE_ALTERNATIVE= 0x2,
> > +   SIDE_BY_SIDE_FULL   = 0x3,
> > +   L_DEPTH = 0x4,
> > +   L_DEPTH_GFX_GFX_DEPTH   = 0x5,
> > +   TOP_BOTTOM  = 0x6, /* 0x7 is reserved for future */
> > +   SIDE_BY_SIDE_HALF   = 0x8  /* 0x9 onwards is reserved for future */
> > +};
> 
> If format is supposed to be an enum, why aren't you using these symbolic
> values?

I fixed the part to use a u16 integer value to represent the format.

> 
> - ajax



>From d4c989bc807be730b2693a843fe93d4d559c05eb Mon Sep 17 00:00:00 2001
From: Sateesh Kavuri 
Date: Fri, 9 Dec 2011 17:08:42 +0530
Subject: [PATCH] Patch to enable reading the EDID information of a 3D capable 
HDMI
 monitor. This EDID information would be used to enable a user
 space application to switch the mode of the monitor to a specific 3D
 format.

--
Signed-off=by: sateesh.kav...@intel.com
---
 drivers/gpu/drm/drm_edid.c |  109 
 include/drm/drm_crtc.h |   25 ++
 2 files changed, 134 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index fe39c35..4fe49e8 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1322,6 +1322,9 @@ add_detailed_modes(stru

[Bug 43719] drm-core-next + AGP RV670 = Oops

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

Product|Mesa|DRI
Version|git |unspecified
  Component|Drivers/DRI/R600|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.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 41668] Screen locks up at random points when using a 3D compositing wm (gnome-shell) on an rv515 (radeon mobility x1300)

[bugzilla-daemon]

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

--- Comment #18 from Przemyslaw Kochanski  2011-12-15 
06:20:29 PST ---
(In reply to comment #13)
> Try the following options in the kernel command line in grub:
> pci=nomsi
> noapic
> irqpoll
> and see if any of them help.

I've tried your suggestion and it worked! I've discovered the following:

"pci=nomsi noapic irqpoll" no freeze
"pci=nomsi irqpoll" no freeze
"irqpoll" no freeze
"pci=nomsi" no freeze
"noapic" no freeze
"" freeze

So far without any of this options I can reproduce the crash in 100% cases
under 1 minute of moving image in Gimp. I did it many times when backtracing.
However, there is slight probability that I just got lucky with one of options.
I'm 100% sure I've run `update-grub` after every /etc/default/grub change.

Assuming that all of this options fix the problem, which option should I use
(witch one disables least things)? I found the following but I don't understand
much:

noapic: [SMP,APIC] Tells the kernel to not make use of any IOAPICs that may be
present in the system.

irqpoll: [HW] When an interrupt is not handled search all handlersfor it. Also
check all handlers each timerinterrupt. Intended to get systems with badly
brokenfirmware running.

pci=nomsi: [MSI] If the PCI_MSI kernel config parameter isenabled, this kernel
boot option can be used todisable the use of MSI interrupts system-wide.

And finally: Is it a proper fix, or just a workaround?

-- 
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 -fixes 0/3][RESEND] Documentation updates

[Thomas Hellstrom]

Dave,

Please pull this series into drm-fixes for 3.2.

Thanks,
Thomas


On 11/21/2011 01:08 PM, Thomas Hellstrom wrote:

A couple of updates to various interface docs

In-Reply-To:

___
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 1/8][RESEND] vmwgfx: Use the revised fifo hw version register when present

[Thomas Hellstrom]

Dave,

Please pull this series into drm-fixes for 3.2!

Thanks,
Thomas



On 11/28/2011 01:19 PM, Thomas Hellstrom wrote:

The driver implements the needed resource management required
to use that register.

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

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
index 03bbc2a..a0c2f12 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c
@@ -33,6 +33,7 @@ bool vmw_fifo_have_3d(struct vmw_private *dev_priv)
  {
__le32 __iomem *fifo_mem = dev_priv->mmio_virt;
uint32_t fifo_min, hwversion;
+   const struct vmw_fifo_state *fifo =&dev_priv->fifo;

if (!(dev_priv->capabilities&  SVGA_CAP_EXTENDED_FIFO))
return false;
@@ -41,7 +42,12 @@ bool vmw_fifo_have_3d(struct vmw_private *dev_priv)
if (fifo_min<= SVGA_FIFO_3D_HWVERSION * sizeof(unsigned int))
return false;

-   hwversion = ioread32(fifo_mem + SVGA_FIFO_3D_HWVERSION);
+   hwversion = ioread32(fifo_mem +
+((fifo->capabilities&
+  SVGA_FIFO_CAP_3D_HWVERSION_REVISED) ?
+ SVGA_FIFO_3D_HWVERSION_REVISED :
+ SVGA_FIFO_3D_HWVERSION));
+
if (hwversion == 0)
return false;

diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
index 3f63435..a9e2193 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c
@@ -58,8 +58,14 @@ int vmw_getparam_ioctl(struct drm_device *dev, void *data,
case DRM_VMW_PARAM_FIFO_HW_VERSION:
{
__le32 __iomem *fifo_mem = dev_priv->mmio_virt;
-
-   param->value = ioread32(fifo_mem + SVGA_FIFO_3D_HWVERSION);
+   const struct vmw_fifo_state *fifo =&dev_priv->fifo;
+
+   param->value =
+   ioread32(fifo_mem +
+((fifo->capabilities&
+  SVGA_FIFO_CAP_3D_HWVERSION_REVISED) ?
+ SVGA_FIFO_3D_HWVERSION_REVISED :
+ SVGA_FIFO_3D_HWVERSION));
break;
}
default:
   


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

[PATCH] exynos: add module name for Samsung Exynos SoC support.

[Inki Dae]

this patch adds module name for Samsung Exynos SoC. with this patch,
we can test kmstest, modetest and vbltest of libdrm.
Exynos drm driver of kernel side have been merged to mainline.

you can refer to mainline git repository below:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=summary
commit id: 1c248b7d2960faec3e1b8f3f9c5d9d0df28e0a3c

P.S. the module name of kernel side is "exynos-drm" yet so
now the name would use "exynos-drm" but it will be changed to "exynos"
once kernel side is changed.

Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park 
---
 tests/kmstest/main.c  |1 +
 tests/modetest/modetest.c |3 ++-
 tests/vbltest/vbltest.c   |3 ++-
 3 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/tests/kmstest/main.c b/tests/kmstest/main.c
index 5df0a38..7193ff5 100644
--- a/tests/kmstest/main.c
+++ b/tests/kmstest/main.c
@@ -61,6 +61,7 @@ char *drivers[] = {
"radeon",
"nouveau",
"vmwgfx",
+   "exynos-drm",
NULL
 };
 
diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
index 229ab8a..8059414 100644
--- a/tests/modetest/modetest.c
+++ b/tests/modetest/modetest.c
@@ -721,7 +721,8 @@ int main(int argc, char **argv)
int c;
int encoders = 0, connectors = 0, crtcs = 0, framebuffers = 0;
int test_vsync = 0;
-   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx" };
+   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx",
+   "exynos-drm" };
char *modeset = NULL;
int i, count = 0;
struct connector con_args[2];
diff --git a/tests/vbltest/vbltest.c b/tests/vbltest/vbltest.c
index 903ca0f..340a5c1 100644
--- a/tests/vbltest/vbltest.c
+++ b/tests/vbltest/vbltest.c
@@ -103,7 +103,8 @@ static void usage(char *name)
 int main(int argc, char **argv)
 {
int i, c, fd, ret;
-   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx" };
+   char *modules[] = { "i915", "radeon", "nouveau", "vmwgfx",
+   "exynos-drm" };
drmVBlank vbl;
drmEventContext evctx;
struct vbl_info handler_info;
-- 
1.7.4.1

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

[Bug 41668] Screen locks up at random points when using a 3D compositing wm (gnome-shell) on an rv515 (radeon mobility x1300)

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

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

--- Comment #17 from Przemyslaw Kochanski  
2011-12-14 17:39:45 PST ---
Created attachment 54446
  --> https://bugs.freedesktop.org/attachment.cgi?id=54446
gdb gnome-shell backtrace

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

[Bug 41668] Screen locks up at random points when using a 3D compositing wm (gnome-shell) on an rv515 (radeon mobility x1300)

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

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

--- Comment #16 from Przemyslaw Kochanski  
2011-12-14 17:38:59 PST ---
Created attachment 54445
  --> https://bugs.freedesktop.org/attachment.cgi?id=54445
output of glxinfo

I'm experiencing the same issue on Ubuntu 11.10. I'm ready to provide all
necessary backtrace. I'm attaching gnome-shell backtrace and glxinfo output.
Same issue is reported on gnome-shell bugtracker:
https://bugzilla.gnome.org/show_bug.cgi?id=650857 but they claim its either X
or the drivers fault.

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

Re: [3.1.4] mm slub memory corruption in drm_vblank_cleanup

[David Rientjes]

On Tue, 13 Dec 2011, batouzo wrote:

> Hello, we where building 3.1.4 kernel when we noticed BUG()s on bootup.
> 
> After some debugging it seems to be use after freed memory corruption
> caused by radeon driver.

That's not what's indicated here, this is the poison value being 
overwritten and detected on free.

> With radeon + kms the bug happens around 1 in 3 boot ups, right after
> the radeon is enabled (with slub debugging) or later with no debug (few
> seconds later or on shutdown esp. in rmmod).
> 
> When disabling radeon and KMS the bug was not seen;
> 
> 
> Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in
> drm_vblank_cleanup+0x78/0x90 [drm]
> Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in
> drm_vblank_cleanup+0x48/0x90 [drm]
> 
> It is Amd Bulldozer computer, with Radeon card:
> 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO
> [Radeon HD 5450]
> 
> Debian stable. Builded with make-kpkg using gcc 4.4.5
> 
>messages: http://pastebin.com/NXN5EPtG
> config used: http://pastebin.com/AeVxEX7c
> 
> Interesting part of the messages linked above is:
> 
> 
> [   94.401991] fb0: radeondrmfb frame buffer device
> [   94.401992] drm: registered panic notifier
> [   94.402033] [drm] Initialized radeon 2.11.0 20080528 for :01:00.0
> on minor 0
> [   94.402921]
> =
> [   94.402961] BUG kmalloc-16: Poison overwritten
> [   94.402982]
> -
> [   94.402983]
> [   94.403025] INFO: 0x880137dbbc38-0x880137dbbc3b. First byte
> 0x0 instead of 0x6b
> [   94.403066] INFO: Allocated in drm_vblank_init+0x139/0x260 [drm]
> age=253 cpu=3 pid=535
> [   94.403103]  set_track+0x58/0x100
> [   94.403119]  alloc_debug_processing+0x160/0x170
> [   94.403140]  __slab_alloc+0x26d/0x440
> [   94.403160]  drm_vblank_init+0x139/0x260 [drm]
> [   94.403182]  drm_debugfs_create_files+0xcb/0x1a0 [drm]
> [   94.403208]  drm_vblank_init+0x139/0x260 [drm]
> [   94.403228]  __kmalloc+0x100/0x180
> [   94.403247]  drm_vblank_init+0x139/0x260 [drm]
> [   94.403276]  radeon_irq_kms_init+0x6d/0x160 [radeon]
> [   94.403303]  evergreen_init+0x11c/0x2a0 [radeon]
> [   94.403337]  radeon_device_init+0x3c9/0x470 [radeon]
> [   94.403367]  radeon_driver_load_kms+0xad/0x160 [radeon]
> [   94.403394]  drm_get_pci_dev+0x198/0x2c0 [drm]
> [   94.403416]  local_pci_probe+0x55/0xd0
> [   94.403433]  pci_device_probe+0x10a/0x130
> [   94.403453]  driver_sysfs_add+0x72/0xa0
> [   94.403474] INFO: Freed in drm_vblank_cleanup+0x78/0x90 [drm] age=235
> cpu=0 pid=535
> [   94.403508]  set_track+0x58/0x100
> [   94.403524]  free_debug_processing+0x1f3/0x240
> [   94.403545]  __slab_free+0x1a6/0x2b0
> [   94.403562]  native_read_tsc+0x2/0x20
> [   94.403580]  delay_tsc+0x42/0x80
> [   94.403598]  drm_vblank_cleanup+0x78/0x90 [drm]
> [   94.403625]  radeon_irq_kms_fini+0xd/0x60 [radeon]
> [   94.403651]  evergreen_init+0x289/0x2a0 [radeon]
> [   94.403677]  radeon_device_init+0x3c9/0x470 [radeon]
> [   94.403704]  radeon_driver_load_kms+0xad/0x160 [radeon]
> [   94.403731]  drm_get_pci_dev+0x198/0x2c0 [drm]
> [   94.403751]  local_pci_probe+0x55/0xd0
> [   94.403772]  pci_device_probe+0x10a/0x130
> [   94.403791]  driver_sysfs_add+0x72/0xa0
> [   94.404806]  driver_probe_device+0x8e/0x1b0
> [   94.405782]  __driver_attach+0x93/0xa0
> [   94.406031] INFO: Slab 0xea0004df6e80 objects=23 used=23 fp=0x
>(null) flags=0x2004080
> [   94.406031] INFO: Object 0x880137dbbc38 @offset=7224
> fp=0x880137dbb830
> [   94.406031]
> [   94.406031] Bytes b4 0x880137dbbc28:  06 0e ff ff 00 00 00 00 5a
> 5a 5a 5a 5a 5a 5a 5a ..??
> [   94.406031]   Object 0x880137dbbc38:  00 00 00 00 6b 6b 6b 6b 6b
> 6b 6b 6b 6b 6b 6b a5 kkk???
> [   94.406031]  Redzone 0x880137dbbc48:  bb bb bb bb bb bb bb bb
>  
> [   94.406031]  Padding 0x880137dbbd88:  5a 5a 5a 5a 5a 5a 5a 5a
>  
> [   94.406031] Pid: 466, comm: udevd Not tainted 3.1.4-norm007+dbg #1
> [   94.406031] Call Trace:
> [   94.406031]  [] ? check_bytes_and_report+0x110/0x150
> [   94.406031]  [] ? check_object+0x1fe/0x250
> [   94.406031]  [] ? shmem_symlink+0xd4/0x220
> [   94.406031]  [] ? shmem_symlink+0xd4/0x220
> [   94.406031]  [] ? alloc_debug_processing+0xee/0x170
> [   94.406031]  [] ? __slab_alloc+0x26d/0x440
> [   94.406031]  [] ? shmem_symlink+0xd4/0x220
> [   94.406031]  [] ? inode_init_always+0xfc/0x1b0
> [   94.406031]  [] ? alloc_inode+0x32/0x90
> [   94.406031]  [] ? shmem_symlink+0xd4/0x220
> [   94.406031]  [] ? __kmalloc_track_caller+0xf8/0x180
> [   94.406031]  [] ? kmemdup+0x27/0x60
> [   94.406031]  [] ? shmem_symlink+0xd4/0x220
> [   94.406031]  [] ? vfs_symlink+0x87/0xa0
> [   94.406031]  [] ? sys_symlinkat+0xdc/0xf0
> [   94.406031]  [] ? system_call_fastpath+0x16/0x1b

[3.1.4] mm slub memory corruption in drm_vblank_cleanup

[David Rientjes]

On Tue, 13 Dec 2011, batouzo wrote:

> Hello, we where building 3.1.4 kernel when we noticed BUG()s on bootup.
> 
> After some debugging it seems to be use after freed memory corruption
> caused by radeon driver.

That's not what's indicated here, this is the poison value being 
overwritten and detected on free.

> With radeon + kms the bug happens around 1 in 3 boot ups, right after
> the radeon is enabled (with slub debugging) or later with no debug (few
> seconds later or on shutdown esp. in rmmod).
> 
> When disabling radeon and KMS the bug was not seen;
> 
> 
> Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in
> drm_vblank_cleanup+0x78/0x90 [drm]
> Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in
> drm_vblank_cleanup+0x48/0x90 [drm]
> 
> It is Amd Bulldozer computer, with Radeon card:
> 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO
> [Radeon HD 5450]
> 
> Debian stable. Builded with make-kpkg using gcc 4.4.5
> 
>messages: http://pastebin.com/NXN5EPtG
> config used: http://pastebin.com/AeVxEX7c
> 
> Interesting part of the messages linked above is:
> 
> 
> [   94.401991] fb0: radeondrmfb frame buffer device
> [   94.401992] drm: registered panic notifier
> [   94.402033] [drm] Initialized radeon 2.11.0 20080528 for :01:00.0
> on minor 0
> [   94.402921]
> =
> [   94.402961] BUG kmalloc-16: Poison overwritten
> [   94.402982]
> -
> [   94.402983]
> [   94.403025] INFO: 0x880137dbbc38-0x880137dbbc3b. First byte
> 0x0 instead of 0x6b
> [   94.403066] INFO: Allocated in drm_vblank_init+0x139/0x260 [drm]
> age=253 cpu=3 pid=535
> [   94.403103]  set_track+0x58/0x100
> [   94.403119]  alloc_debug_processing+0x160/0x170
> [   94.403140]  __slab_alloc+0x26d/0x440
> [   94.403160]  drm_vblank_init+0x139/0x260 [drm]
> [   94.403182]  drm_debugfs_create_files+0xcb/0x1a0 [drm]
> [   94.403208]  drm_vblank_init+0x139/0x260 [drm]
> [   94.403228]  __kmalloc+0x100/0x180
> [   94.403247]  drm_vblank_init+0x139/0x260 [drm]
> [   94.403276]  radeon_irq_kms_init+0x6d/0x160 [radeon]
> [   94.403303]  evergreen_init+0x11c/0x2a0 [radeon]
> [   94.403337]  radeon_device_init+0x3c9/0x470 [radeon]
> [   94.403367]  radeon_driver_load_kms+0xad/0x160 [radeon]
> [   94.403394]  drm_get_pci_dev+0x198/0x2c0 [drm]
> [   94.403416]  local_pci_probe+0x55/0xd0
> [   94.403433]  pci_device_probe+0x10a/0x130
> [   94.403453]  driver_sysfs_add+0x72/0xa0
> [   94.403474] INFO: Freed in drm_vblank_cleanup+0x78/0x90 [drm] age=235
> cpu=0 pid=535
> [   94.403508]  set_track+0x58/0x100
> [   94.403524]  free_debug_processing+0x1f3/0x240
> [   94.403545]  __slab_free+0x1a6/0x2b0
> [   94.403562]  native_read_tsc+0x2/0x20
> [   94.403580]  delay_tsc+0x42/0x80
> [   94.403598]  drm_vblank_cleanup+0x78/0x90 [drm]
> [   94.403625]  radeon_irq_kms_fini+0xd/0x60 [radeon]
> [   94.403651]  evergreen_init+0x289/0x2a0 [radeon]
> [   94.403677]  radeon_device_init+0x3c9/0x470 [radeon]
> [   94.403704]  radeon_driver_load_kms+0xad/0x160 [radeon]
> [   94.403731]  drm_get_pci_dev+0x198/0x2c0 [drm]
> [   94.403751]  local_pci_probe+0x55/0xd0
> [   94.403772]  pci_device_probe+0x10a/0x130
> [   94.403791]  driver_sysfs_add+0x72/0xa0
> [   94.404806]  driver_probe_device+0x8e/0x1b0
> [   94.405782]  __driver_attach+0x93/0xa0
> [   94.406031] INFO: Slab 0xea0004df6e80 objects=23 used=23 fp=0x
>(null) flags=0x2004080
> [   94.406031] INFO: Object 0x880137dbbc38 @offset=7224
> fp=0x880137dbb830
> [   94.406031]
> [   94.406031] Bytes b4 0x880137dbbc28:  06 0e ff ff 00 00 00 00 5a
> 5a 5a 5a 5a 5a 5a 5a ..??
> [   94.406031]   Object 0x880137dbbc38:  00 00 00 00 6b 6b 6b 6b 6b
> 6b 6b 6b 6b 6b 6b a5 kkk???
> [   94.406031]  Redzone 0x880137dbbc48:  bb bb bb bb bb bb bb bb
>  
> [   94.406031]  Padding 0x880137dbbd88:  5a 5a 5a 5a 5a 5a 5a 5a
>  
> [   94.406031] Pid: 466, comm: udevd Not tainted 3.1.4-norm007+dbg #1
> [   94.406031] Call Trace:
> [   94.406031]  [] ? check_bytes_and_report+0x110/0x150
> [   94.406031]  [] ? check_object+0x1fe/0x250
> [   94.406031]  [] ? shmem_symlink+0xd4/0x220
> [   94.406031]  [] ? shmem_symlink+0xd4/0x220
> [   94.406031]  [] ? alloc_debug_processing+0xee/0x170
> [   94.406031]  [] ? __slab_alloc+0x26d/0x440
> [   94.406031]  [] ? shmem_symlink+0xd4/0x220
> [   94.406031]  [] ? inode_init_always+0xfc/0x1b0
> [   94.406031]  [] ? alloc_inode+0x32/0x90
> [   94.406031]  [] ? shmem_symlink+0xd4/0x220
> [   94.406031]  [] ? __kmalloc_track_caller+0xf8/0x180
> [   94.406031]  [] ? kmemdup+0x27/0x60
> [   94.406031]  [] ? shmem_symlink+0xd4/0x220
> [   94.406031]  [] ? vfs_symlink+0x87/0xa0
> [   94.406031]  [] ? sys_symlinkat+0xdc/0xf0
> [   94.406031]  [] ? system_call_fastpath+0x16/0x1b

[Bug 43835] System crashes when radeon firmware blob (R520_cp.bin) is installed

[bugzilla-daemon]

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

--- Comment #4 from Camaleón  2011-12-15 00:49:15 PST ---
(In reply to comment #3)

> I have asked the user to try with this option while having the firmware 
> package
> installed, will report back as soon as I get the results.

The user reported that both kernels do work (no crashes) with
"firmware-linux-nonfree" installed and using this "/etc/X11/xorg.conf" file:

***
Section "Device"
Identifier  "ATI"
Driver  "radeon"
Option  "NoAccel" "True"
EndSection

Section "Screen"
Identifier "Default Screen"
DefaultDepth 24
EndSection
***

This effectively disables 3D acceleration (which means no "gnome-shell") but
the user hasn't experienced any further crash since yesterday.

-- 
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 3/3] drm/omap: multiplanar and YUV support

[Rob Clark]

From: Rob Clark 

Add support in framebuffer objects for other color formats and multi-
planar YUV (NV12).  Since this requires changing the API between the
plane and fb for getting scanout information (paddr, etc), take
advantage of the opportunity and put in place a way to allow fb's to
be unpinned when they are not being scanned out.  Now, before start
of scanout the plane calls omap_framebuffer_pin() which takes care
to pin all the backing bo's, then omap_framebuffer_update_scanout()
however many times to update the scanout address(es), etc, and then
when finished omap_framebuffer_unpin().

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_crtc.c  |2 +-
 drivers/staging/omapdrm/omap_drv.h   |8 +-
 drivers/staging/omapdrm/omap_fb.c|  149 +++---
 drivers/staging/omapdrm/omap_gem.c   |5 +
 drivers/staging/omapdrm/omap_plane.c |   53 +
 5 files changed, 149 insertions(+), 68 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_crtc.c 
b/drivers/staging/omapdrm/omap_crtc.c
index a91c788..3cee04e 100644
--- a/drivers/staging/omapdrm/omap_crtc.c
+++ b/drivers/staging/omapdrm/omap_crtc.c
@@ -168,7 +168,7 @@ static int omap_crtc_page_flip_locked(struct drm_crtc *crtc,
omap_crtc->event = event;
crtc->fb = fb;

-   omap_gem_op_async(omap_framebuffer_bo(fb), OMAP_GEM_READ,
+   omap_gem_op_async(omap_framebuffer_bo(fb, 0), OMAP_GEM_READ,
page_flip_cb, crtc);

return 0;
diff --git a/drivers/staging/omapdrm/omap_drv.h 
b/drivers/staging/omapdrm/omap_drv.h
index 0394f17..d29d7cb 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -85,9 +85,11 @@ struct drm_framebuffer *omap_framebuffer_create(struct 
drm_device *dev,
struct drm_file *file, struct drm_mode_fb_cmd2 *mode_cmd);
 struct drm_framebuffer *omap_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object **bos);
-struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer *fb);
-int omap_framebuffer_get_buffer(struct drm_framebuffer *fb, int x, int y,
-   void **vaddr, dma_addr_t *paddr, unsigned int *screen_width);
+struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer *fb, int p);
+int omap_framebuffer_pin(struct drm_framebuffer *fb);
+void omap_framebuffer_unpin(struct drm_framebuffer *fb);
+void omap_framebuffer_update_scanout(struct drm_framebuffer *fb, int x, int y,
+   struct omap_overlay_info *info);
 struct drm_connector *omap_framebuffer_get_next_connector(
struct drm_framebuffer *fb, struct drm_connector *from);
 void omap_framebuffer_flush(struct drm_framebuffer *fb,
diff --git a/drivers/staging/omapdrm/omap_fb.c 
b/drivers/staging/omapdrm/omap_fb.c
index 0d3a15e..e1f97d8 100644
--- a/drivers/staging/omapdrm/omap_fb.c
+++ b/drivers/staging/omapdrm/omap_fb.c
@@ -59,14 +59,20 @@ static const struct format formats[] = {
{ OMAP_DSS_COLOR_UYVY,DRM_FORMAT_UYVY, {{2, 1}}, true },
 };

+/* per-plane info for the fb: */
+struct plane {
+   struct drm_gem_object *bo;
+   uint32_t pitch;
+   uint32_t offset;
+   dma_addr_t paddr;
+};
+
 #define to_omap_framebuffer(x) container_of(x, struct omap_framebuffer, base)

 struct omap_framebuffer {
struct drm_framebuffer base;
-   struct drm_gem_object *bo;
-   int size;
-   dma_addr_t paddr;
const struct format *format;
+   struct plane planes[4];
 };

 static int omap_framebuffer_create_handle(struct drm_framebuffer *fb,
@@ -74,22 +80,23 @@ static int omap_framebuffer_create_handle(struct 
drm_framebuffer *fb,
unsigned int *handle)
 {
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
-return drm_gem_handle_create(file_priv, omap_fb->bo, handle);
+   return drm_gem_handle_create(file_priv,
+   omap_fb->planes[0].bo, handle);
 }

 static void omap_framebuffer_destroy(struct drm_framebuffer *fb)
 {
-   struct drm_device *dev = fb->dev;
struct omap_framebuffer *omap_fb = to_omap_framebuffer(fb);
+   int i, n = num_planes(omap_fb->format->pixel_format);

DBG("destroy: FB ID: %d (%p)", fb->base.id, fb);

drm_framebuffer_cleanup(fb);

-   if (omap_fb->bo) {
-   if (omap_fb->paddr && omap_gem_put_paddr(omap_fb->bo))
-   dev_err(dev->dev, "could not unmap!\n");
-   drm_gem_object_unreference_unlocked(omap_fb->bo);
+   for (i = 0; i < n; i++) {
+   struct plane *plane = &omap_fb->planes[i];
+   if (plane->bo)
+   drm_gem_object_unreference_unlocked(plane->bo);
}

kfree(omap_fb);
@@ -116,37 +123,76 @@ static const struct drm_framebuffer_funcs 
omap_framebuffer_funcs = {
.dirty = omap_framebuffer_dirty,
 };

-/* returns the buffer size */
-int omap_framebuffer_g

[PATCH 2/3] drm/omap: add drm_plane support

[Rob Clark]

From: Rob Clark 

Because framebuffer layer and overlay scanout video pipes are basically
thing in OMAP display subsystem (the only difference being that the first
video pipe does not support scaling or YUV formats), much of the CRTC
code is pulled into the plane implementation, and a private plane object
is used by the CRTC object.  This avoids code duplication between the
plane and CRTC.

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/Makefile |1 +
 drivers/staging/omapdrm/omap_crtc.c  |  189 +
 drivers/staging/omapdrm/omap_drv.c   |   53 ---
 drivers/staging/omapdrm/omap_drv.h   |8 +-
 drivers/staging/omapdrm/omap_plane.c |  308 ++
 drivers/staging/omapdrm/omap_priv.h  |   12 +-
 6 files changed, 403 insertions(+), 168 deletions(-)
 create mode 100644 drivers/staging/omapdrm/omap_plane.c

diff --git a/drivers/staging/omapdrm/Makefile b/drivers/staging/omapdrm/Makefile
index 275054a..467aba3 100644
--- a/drivers/staging/omapdrm/Makefile
+++ b/drivers/staging/omapdrm/Makefile
@@ -6,6 +6,7 @@
 ccflags-y := -Iinclude/drm -Werror
 omapdrm-y := omap_drv.o \
omap_crtc.o \
+   omap_plane.o \
omap_encoder.o \
omap_connector.o \
omap_fb.o \
diff --git a/drivers/staging/omapdrm/omap_crtc.c 
b/drivers/staging/omapdrm/omap_crtc.c
index cffdf5e..a91c788 100644
--- a/drivers/staging/omapdrm/omap_crtc.c
+++ b/drivers/staging/omapdrm/omap_crtc.c
@@ -27,196 +27,95 @@

 struct omap_crtc {
struct drm_crtc base;
-   struct omap_overlay *ovl;
-   struct omap_overlay_info info;
+   struct drm_plane *plane;
+   const char *name;
int id;

-   /* if there is a pending flip, this will be non-null: */
+   /* if there is a pending flip, these will be non-null: */
struct drm_pending_vblank_event *event;
+   struct drm_framebuffer *old_fb;
 };

-/* push changes down to dss2 */
-static int commit(struct drm_crtc *crtc)
-{
-   struct drm_device *dev = crtc->dev;
-   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
-   struct omap_overlay *ovl = omap_crtc->ovl;
-   struct omap_overlay_info *info = &omap_crtc->info;
-   int ret;
-
-   DBG("%s", omap_crtc->ovl->name);
-   DBG("%dx%d -> %dx%d (%d)", info->width, info->height, info->out_width,
-   info->out_height, info->screen_width);
-   DBG("%d,%d %08x", info->pos_x, info->pos_y, info->paddr);
-
-   /* NOTE: do we want to do this at all here, or just wait
-* for dpms(ON) since other CRTC's may not have their mode
-* set yet, so fb dimensions may still change..
-*/
-   ret = ovl->set_overlay_info(ovl, info);
-   if (ret) {
-   dev_err(dev->dev, "could not set overlay info\n");
-   return ret;
-   }
-
-   /* our encoder doesn't necessarily get a commit() after this, in
-* particular in the dpms() and mode_set_base() cases, so force the
-* manager to update:
-*
-* could this be in the encoder somehow?
-*/
-   if (ovl->manager) {
-   ret = ovl->manager->apply(ovl->manager);
-   if (ret) {
-   dev_err(dev->dev, "could not apply settings\n");
-   return ret;
-   }
-   }
-
-   if (info->enabled) {
-   omap_framebuffer_flush(crtc->fb, crtc->x, crtc->y,
-   crtc->fb->width, crtc->fb->height);
-   }
-
-   return 0;
-}
-
-/* update parameters that are dependent on the framebuffer dimensions and
- * position within the fb that this crtc scans out from. This is called
- * when framebuffer dimensions or x,y base may have changed, either due
- * to our mode, or a change in another crtc that is scanning out of the
- * same fb.
- */
-static void update_scanout(struct drm_crtc *crtc)
-{
-   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
-   dma_addr_t paddr;
-   unsigned int screen_width;
-
-   omap_framebuffer_get_buffer(crtc->fb, crtc->x, crtc->y,
-   NULL, &paddr, &screen_width);
-
-   DBG("%s: %d,%d: %08x (%d)", omap_crtc->ovl->name,
-   crtc->x, crtc->y, (u32)paddr, screen_width);
-
-   omap_crtc->info.paddr = paddr;
-   omap_crtc->info.screen_width = screen_width;
-}
-
 static void omap_crtc_gamma_set(struct drm_crtc *crtc,
u16 *red, u16 *green, u16 *blue, uint32_t start, uint32_t size)
 {
-   struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
-   DBG("%s", omap_crtc->ovl->name);
+   /* not supported.. at least not yet */
 }

 static void omap_crtc_destroy(struct drm_crtc *crtc)
 {
struct omap_crtc *omap_crtc = to_omap_crtc(crtc);
-   DBG("%s", omap_crtc->ovl->name);
+   omap_crtc->plane->funcs->destroy(omap_crtc->plane);
drm_crtc_cleanup(crtc);
kfree(omap_crtc);
 }

 static void omap_crtc_dpms(struct drm_crtc *crtc, in

[PATCH 1/3] drm/omap: drm API update: addfb2

[Rob Clark]

From: Rob Clark 

Update to reflect changes in:
"drm: add an fb creation ioctl that takes a pixel format v5"

Signed-off-by: Rob Clark 
---
 drivers/staging/omapdrm/omap_drv.h   |   53 +-
 drivers/staging/omapdrm/omap_fb.c|   99 ++---
 drivers/staging/omapdrm/omap_fbdev.c |   53 ---
 3 files changed, 163 insertions(+), 42 deletions(-)

diff --git a/drivers/staging/omapdrm/omap_drv.h 
b/drivers/staging/omapdrm/omap_drv.h
index 8dd7d74..bc8daa7 100644
--- a/drivers/staging/omapdrm/omap_drv.h
+++ b/drivers/staging/omapdrm/omap_drv.h
@@ -76,9 +76,9 @@ void omap_connector_flush(struct drm_connector *connector,
 void omap_connector_dpms(struct drm_connector *connector, int mode);

 struct drm_framebuffer *omap_framebuffer_create(struct drm_device *dev,
-   struct drm_file *file, struct drm_mode_fb_cmd *mode_cmd);
+   struct drm_file *file, struct drm_mode_fb_cmd2 *mode_cmd);
 struct drm_framebuffer *omap_framebuffer_init(struct drm_device *dev,
-   struct drm_mode_fb_cmd *mode_cmd, struct drm_gem_object *bo);
+   struct drm_mode_fb_cmd2 *mode_cmd, struct drm_gem_object **bos);
 struct drm_gem_object *omap_framebuffer_bo(struct drm_framebuffer *fb);
 int omap_framebuffer_get_buffer(struct drm_framebuffer *fb, int x, int y,
void **vaddr, dma_addr_t *paddr, unsigned int *screen_width);
@@ -128,4 +128,53 @@ static inline int align_pitch(int pitch, int width, int 
bpp)
return ALIGN(pitch, 8 * bytespp);
 }

+/* should these be made into common util helpers?
+ */
+
+static inline int num_planes(uint32_t pixel_format)
+{
+   switch (pixel_format) {
+   default:
+   return 1;
+   case DRM_FORMAT_NV12:
+   case DRM_FORMAT_NV21:
+   case DRM_FORMAT_NV16:
+   case DRM_FORMAT_NV61:
+   return 2;
+   case DRM_FORMAT_YUV410:
+   case DRM_FORMAT_YVU410:
+   case DRM_FORMAT_YUV411:
+   case DRM_FORMAT_YVU411:
+   case DRM_FORMAT_YUV420:
+   case DRM_FORMAT_YVU420:
+   case DRM_FORMAT_YUV422:
+   case DRM_FORMAT_YVU422:
+   case DRM_FORMAT_YUV444:
+   case DRM_FORMAT_YVU444:
+   return 3;
+   }
+}
+
+static inline int objects_lookup(struct drm_device *dev,
+   struct drm_file *filp, uint32_t pixel_format,
+   struct drm_gem_object **bos, uint32_t *handles)
+{
+   int i, n = num_planes(pixel_format);
+
+   for (i = 0; i < n; i++) {
+   bos[i] = drm_gem_object_lookup(dev, filp, handles[i]);
+   if (!bos[i]) {
+   goto fail;
+   }
+   }
+
+   return 0;
+
+fail:
+   while (--i > 0) {
+   drm_gem_object_unreference_unlocked(bos[i]);
+   }
+   return -ENOENT;
+}
+
 #endif /* __OMAP_DRV_H__ */
diff --git a/drivers/staging/omapdrm/omap_fb.c 
b/drivers/staging/omapdrm/omap_fb.c
index 0b50c5b..0d3a15e 100644
--- a/drivers/staging/omapdrm/omap_fb.c
+++ b/drivers/staging/omapdrm/omap_fb.c
@@ -22,11 +22,43 @@
 #include "drm_crtc.h"
 #include "drm_crtc_helper.h"

-
 /*
  * framebuffer funcs
  */

+/* per-format info: */
+struct format {
+   enum omap_color_mode dss_format;
+   uint32_t pixel_format;
+   struct {
+   int stride_bpp;   /* this times width is stride */
+   int sub_y;/* sub-sample in y dimension */
+   } planes[4];
+   bool yuv;
+};
+
+static const struct format formats[] = {
+   /* 16bpp [A]RGB: */
+   { OMAP_DSS_COLOR_RGB16,   DRM_FORMAT_RGB565,   {{2, 1}}, false }, 
/* RGB16-565 */
+   { OMAP_DSS_COLOR_RGB12U,  DRM_FORMAT_RGBX, {{2, 1}}, false }, 
/* RGB12x- */
+   { OMAP_DSS_COLOR_RGBX16,  DRM_FORMAT_XRGB, {{2, 1}}, false }, 
/* xRGB12- */
+   { OMAP_DSS_COLOR_RGBA16,  DRM_FORMAT_RGBA, {{2, 1}}, false }, 
/* RGBA12- */
+   { OMAP_DSS_COLOR_ARGB16,  DRM_FORMAT_ABGR, {{2, 1}}, false }, 
/* ARGB16- */
+   { OMAP_DSS_COLOR_XRGB16_1555, DRM_FORMAT_XRGB1555, {{2, 1}}, false }, 
/* xRGB15-1555 */
+   { OMAP_DSS_COLOR_ARGB16_1555, DRM_FORMAT_ARGB1555, {{2, 1}}, false }, 
/* ARGB16-1555 */
+   /* 24bpp RGB: */
+   { OMAP_DSS_COLOR_RGB24P,  DRM_FORMAT_RGB888,   {{3, 1}}, false }, 
/* RGB24-888 */
+   /* 32bpp [A]RGB: */
+   { OMAP_DSS_COLOR_RGBX32,  DRM_FORMAT_RGBX, {{4, 1}}, false }, 
/* RGBx24- */
+   { OMAP_DSS_COLOR_RGB24U,  DRM_FORMAT_XRGB, {{4, 1}}, false }, 
/* xRGB24- */
+   { OMAP_DSS_COLOR_RGBA32,  DRM_FORMAT_RGBA, {{4, 1}}, false }, 
/* RGBA32- */
+   { OMAP_DSS_COLOR_ARGB32,  DRM_FORMAT_ARGB, {{4, 1}}, false }, 
/* ARGB32- */
+   /* YUV: */
+   { OMAP_DSS_COLOR_NV12,DRM_FORMAT_NV12, {{1, 1}, {1, 2}}, 
true },
+   { OMAP_DSS_COLOR_YUV2,DRM_FORMAT_YUYV, {{2, 1}}, true },
+   { OMAP_DSS_COLOR_UYVY,DR

[PATCH 0/3] drm/omap: updates for addfb2 and plane support

[Rob Clark]

From: Rob Clark 

The first patch updates omapdrm for API changes introduced when addfb2
support (for multi-planar fb's) was added (in drm-next).  The next patch
adds drm plane (overlay) support, with CRTCs using private plane objects
to avoid code duplication between the CRTC and plane.  (This depends on
the "drm: add support for private planes" patch.)  The final patch adds
support for YUV and multi-planar YUV formats.

Rob Clark (3):
  drm/omap: drm API update: addfb2
  drm/omap: add drm_plane support
  drm/omap: multiplanar and YUV support

 drivers/staging/omapdrm/Makefile |1 +
 drivers/staging/omapdrm/omap_crtc.c  |  191 +---
 drivers/staging/omapdrm/omap_drv.c   |   53 --
 drivers/staging/omapdrm/omap_drv.h   |   69 +++-
 drivers/staging/omapdrm/omap_fb.c|  224 +--
 drivers/staging/omapdrm/omap_fbdev.c |   53 --
 drivers/staging/omapdrm/omap_gem.c   |5 +
 drivers/staging/omapdrm/omap_plane.c |  329 ++
 drivers/staging/omapdrm/omap_priv.h  |   12 +-
 9 files changed, 687 insertions(+), 250 deletions(-)
 create mode 100644 drivers/staging/omapdrm/omap_plane.c

-- 
1.7.5.4