No subject

0x0314e050:  0x61010006: STATE_BASE_ADDRESS
0x0314e054:  0x0001:general state base address 0x
0x0314e058:  0x0001:surface state base address 0x
0x0314e05c:  0x0001:indirect state base address 0x
0x0314e060:  0x0001:instruction state base address 0x
0x0314e064:  0x1001:general state upper bound 0x1000
0x0314e068:  0x1001:indirect state upper bound 0x1000
0x0314e06c:  0x1001:instruction state upper bound 0x1000

And if we look at some of the other auxiliary instructions buffers sent
along with the batch:

  0314e00016384 0048  000ab700 dirty purgeable render uncached
...
  11e3 4096 0011  000ab700 purgeable render uncached
  11e2b000 4096 0011  000ab700 purgeable render uncached
  10e43000 4096 0011  000ab700 render uncached
  10e44000 4096 0011  000ab700 purgeable render uncached

0x10 being the instruction domain for a total of about 20 instruction
buffers referenced from that batch above the upper bound (and in
particular appears to have been the first batch to use addresses above
256M).

This batch fits the modus operandi of the bug that was fixed in
2.14.901, it would seem sensible to address the known issue first.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

[no subject]

[Sascha Hauer]

On Tue, May 22, 2012 at 04:06:41PM +0200, Lars-Peter Clausen wrote:
> On 05/18/2012 02:27 PM, Sascha Hauer wrote:
> > Hi All,
> > 
> > The following adds a drm/kms driver for the Freescale i.MX LCDC
> > controller. Most notable change to the last SDRM based version is that
> > the SDRM layer has been removed and the driver now is purely i.MX
> > specific. I hope that this is more acceptable now.
> > 
> > Another change is that the probe is now devicetree based. For now I
> > took the easy way out and only put an edid blob into the devicetree.
> > I haven't documented the binding yet, I would add that when the rest
> > is considered ok.
> > 
> > Comments very welcome.
> > 
> 
> Hi,
> 
> I really liked the sdrm layer. At least some bits of it. I've been working
> on a "simple" DRM driver as well. The hardware has no fancy acceleration
> features, just a simple buffer and some scanout logic. I'm basically using
> the same gem buffer structure and the buffer is also allocated using
> dma_alloc_writecombine, which means we can probably share all of the GEM
> handling code and probably also most of the fbdev code. I also started with
> the Exynos GEM code as a template, but reworked it later to be more like the
> UDL code, which made it a bit more compact. I think it would be a good idea
> to put at least the GEM handling in some common code as I expect that we'll
> see more similar "simple" DRM drivers pop up.

Ok, I'll try to put the GEM stuff into helper functions. Would you care
to review/test it? I have something else to do right now but I hope I'll
be there next week.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

No subject

i don't think kernel is the right place for it, for instance you need
to set the primary surface thing, i don't want to parse cmd stream in
kernel to figure that out. I would rather have userspace tool that
postprocess thing and convert it to proper AMD dump format.

Cheers,
Jerome

[no subject]

[Sascha Hauer]

On Tue, May 22, 2012 at 04:06:41PM +0200, Lars-Peter Clausen wrote:
> On 05/18/2012 02:27 PM, Sascha Hauer wrote:
> > Hi All,
> > 
> > The following adds a drm/kms driver for the Freescale i.MX LCDC
> > controller. Most notable change to the last SDRM based version is that
> > the SDRM layer has been removed and the driver now is purely i.MX
> > specific. I hope that this is more acceptable now.
> > 
> > Another change is that the probe is now devicetree based. For now I
> > took the easy way out and only put an edid blob into the devicetree.
> > I haven't documented the binding yet, I would add that when the rest
> > is considered ok.
> > 
> > Comments very welcome.
> > 
> 
> Hi,
> 
> I really liked the sdrm layer. At least some bits of it. I've been working
> on a "simple" DRM driver as well. The hardware has no fancy acceleration
> features, just a simple buffer and some scanout logic. I'm basically using
> the same gem buffer structure and the buffer is also allocated using
> dma_alloc_writecombine, which means we can probably share all of the GEM
> handling code and probably also most of the fbdev code. I also started with
> the Exynos GEM code as a template, but reworked it later to be more like the
> UDL code, which made it a bit more compact. I think it would be a good idea
> to put at least the GEM handling in some common code as I expect that we'll
> see more similar "simple" DRM drivers pop up.

I totally agree. Having to track other drivers for bug fixes to apply
them on the own driver is not very convenient. As answered to Rob I do
not really have a clue how to accomplish this.

> 
> The code in question can be found at
> https://github.com/lclausen-adi/linux-2.6/commit/87a8fd6b98317c7a486846cc8405d0bd68d8
> 
> Btw. the imx-drm.h is missing in your patch.

Oops, here it is for reference, will include it in the next round.


#ifndef _IMX_DRM_H_
#define _IMX_DRM_H_

/**
 * User-desired buffer creation information structure.
 *
 * @size: requested size for the object.
 *  - this size value would be page-aligned internally.
 * @flags: user request for setting memory type or cache attributes.
 * @handle: returned handle for the object.
 */
struct imx_drm_gem_create {
unsigned int size;
unsigned int flags;
unsigned int handle;
};

struct imx_drm_device;
struct imx_drm_crtc;

struct imx_drm_crtc_helper_funcs {
int (*enable_vblank)(struct drm_crtc *crtc);
void (*disable_vblank)(struct drm_crtc *crtc);
};

int imx_drm_add_crtc(struct drm_crtc *crtc,
struct imx_drm_crtc **new_crtc,
const struct drm_crtc_funcs *crtc_funcs,
const struct drm_crtc_helper_funcs *crtc_helper_funcs,
const struct imx_drm_crtc_helper_funcs *ec_helper_funcs,
struct module *owner);
int imx_drm_remove_crtc(struct imx_drm_crtc *);
int imx_drm_init_drm(struct platform_device *pdev,
int preferred_bpp);
int imx_drm_exit_drm(void);

int imx_drm_crtc_vblank_get(struct imx_drm_crtc *imx_drm_crtc);
void imx_drm_crtc_vblank_put(struct imx_drm_crtc *imx_drm_crtc);
void imx_drm_handle_vblank(struct imx_drm_crtc *imx_drm_crtc);

/*
 * imx drm buffer entry structure.
 *
 * @paddr: physical address of allocated memory.
 * @vaddr: kernel virtual address of allocated memory.
 * @size: size of allocated memory.
 */
struct imx_drm_buf_entry {
dma_addr_t paddr;
void __iomem *vaddr;
unsigned int size;
};

/* get physical memory information of a drm framebuffer. */
struct imx_drm_buf_entry *imx_drm_fb_get_buf(struct drm_framebuffer *fb);

struct imx_drm_encoder;
int imx_drm_add_encoder(struct drm_encoder *encoder,
struct imx_drm_encoder **new_enc,
struct module *owner);
int imx_drm_remove_encoder(struct imx_drm_encoder *);

struct imx_drm_connector;
int imx_drm_add_connector(struct drm_connector *connector,
struct imx_drm_connector **new_con,
struct module *owner);
int imx_drm_remove_connector(struct imx_drm_connector *);

void imx_drm_mode_config_init(struct drm_device *drm);

#define to_imx_drm_gem_obj(x)   container_of(x,\
struct imx_drm_gem_obj, base)

struct imx_drm_gem_obj {
struct drm_gem_object base;
struct imx_drm_buf_entry *entry;
};

/* unmap a buffer from user space. */
int imx_drm_gem_munmap_ioctl(struct drm_device *drm, void *data,
struct drm_file *file_priv);

/* initialize gem object. */
int imx_drm_gem_init_object(struct drm_gem_object *obj);

/* free gem object. */
void imx_drm_gem_free_object(struct drm_gem_object *gem_obj);

/* create memory region for drm framebuffer. */
int imx_drm_gem_dumb_create(struct drm_file *file_priv,
struct drm_device *drm, struct drm_mode_create_dumb *args);

/* map memory region for drm framebuffer to user space. */
int imx_drm_gem_dumb_map_offset(struct drm_file *file_priv,
struct 

[no subject]

[Lars-Peter Clausen]

On 05/18/2012 02:27 PM, Sascha Hauer wrote:
> Hi All,
> 
> The following adds a drm/kms driver for the Freescale i.MX LCDC
> controller. Most notable change to the last SDRM based version is that
> the SDRM layer has been removed and the driver now is purely i.MX
> specific. I hope that this is more acceptable now.
> 
> Another change is that the probe is now devicetree based. For now I
> took the easy way out and only put an edid blob into the devicetree.
> I haven't documented the binding yet, I would add that when the rest
> is considered ok.
> 
> Comments very welcome.
> 

Hi,

I really liked the sdrm layer. At least some bits of it. I've been working
on a "simple" DRM driver as well. The hardware has no fancy acceleration
features, just a simple buffer and some scanout logic. I'm basically using
the same gem buffer structure and the buffer is also allocated using
dma_alloc_writecombine, which means we can probably share all of the GEM
handling code and probably also most of the fbdev code. I also started with
the Exynos GEM code as a template, but reworked it later to be more like the
UDL code, which made it a bit more compact. I think it would be a good idea
to put at least the GEM handling in some common code as I expect that we'll
see more similar "simple" DRM drivers pop up.

The code in question can be found at
https://github.com/lclausen-adi/linux-2.6/commit/87a8fd6b98317c7a486846cc8405d0bd68d8

Btw. the imx-drm.h is missing in your patch.

- Lars

> Thanks
>  Sascha
> 
> 
> Sascha Hauer (2):
>   DRM: add Freescale i.MX LCDC driver
>   pcm038 lcdc support
> 
>  arch/arm/boot/dts/imx27-phytec-phycore.dts |   39 ++
>  arch/arm/boot/dts/imx27.dtsi   |7 +
>  arch/arm/mach-imx/clock-imx27.c|1 +
>  drivers/gpu/drm/Kconfig|2 +
>  drivers/gpu/drm/Makefile   |1 +
>  drivers/gpu/drm/imx/Kconfig|   18 +
>  drivers/gpu/drm/imx/Makefile   |8 +
>  drivers/gpu/drm/imx/imx-drm-core.c |  745 
> 
>  drivers/gpu/drm/imx/imx-fb.c   |  179 +++
>  drivers/gpu/drm/imx/imx-fbdev.c|  275 ++
>  drivers/gpu/drm/imx/imx-gem.c  |  343 +
>  drivers/gpu/drm/imx/imx-lcdc-crtc.c|  517 +++
>  drivers/gpu/drm/imx/imx-parallel-display.c |  228 +
>  13 files changed, 2363 insertions(+)
>  create mode 100644 drivers/gpu/drm/imx/Kconfig
>  create mode 100644 drivers/gpu/drm/imx/Makefile
>  create mode 100644 drivers/gpu/drm/imx/imx-drm-core.c
>  create mode 100644 drivers/gpu/drm/imx/imx-fb.c
>  create mode 100644 drivers/gpu/drm/imx/imx-fbdev.c
>  create mode 100644 drivers/gpu/drm/imx/imx-gem.c
>  create mode 100644 drivers/gpu/drm/imx/imx-lcdc-crtc.c
>  create mode 100644 drivers/gpu/drm/imx/imx-parallel-display.c
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel

[no subject]

[Sascha Hauer]

Hi All,

The following adds a drm/kms driver for the Freescale i.MX LCDC
controller. Most notable change to the last SDRM based version is that
the SDRM layer has been removed and the driver now is purely i.MX
specific. I hope that this is more acceptable now.

Another change is that the probe is now devicetree based. For now I
took the easy way out and only put an edid blob into the devicetree.
I haven't documented the binding yet, I would add that when the rest
is considered ok.

Comments very welcome.

Thanks
 Sascha


Sascha Hauer (2):
  DRM: add Freescale i.MX LCDC driver
  pcm038 lcdc support

 arch/arm/boot/dts/imx27-phytec-phycore.dts |   39 ++
 arch/arm/boot/dts/imx27.dtsi   |7 +
 arch/arm/mach-imx/clock-imx27.c|1 +
 drivers/gpu/drm/Kconfig|2 +
 drivers/gpu/drm/Makefile   |1 +
 drivers/gpu/drm/imx/Kconfig|   18 +
 drivers/gpu/drm/imx/Makefile   |8 +
 drivers/gpu/drm/imx/imx-drm-core.c |  745 
 drivers/gpu/drm/imx/imx-fb.c   |  179 +++
 drivers/gpu/drm/imx/imx-fbdev.c|  275 ++
 drivers/gpu/drm/imx/imx-gem.c  |  343 +
 drivers/gpu/drm/imx/imx-lcdc-crtc.c|  517 +++
 drivers/gpu/drm/imx/imx-parallel-display.c |  228 +
 13 files changed, 2363 insertions(+)
 create mode 100644 drivers/gpu/drm/imx/Kconfig
 create mode 100644 drivers/gpu/drm/imx/Makefile
 create mode 100644 drivers/gpu/drm/imx/imx-drm-core.c
 create mode 100644 drivers/gpu/drm/imx/imx-fb.c
 create mode 100644 drivers/gpu/drm/imx/imx-fbdev.c
 create mode 100644 drivers/gpu/drm/imx/imx-gem.c
 create mode 100644 drivers/gpu/drm/imx/imx-lcdc-crtc.c
 create mode 100644 drivers/gpu/drm/imx/imx-parallel-display.c
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

No subject

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

BR,
-R

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

No subject

> Those two checks could probably be combined into one (< values || > values)
> for further simplification.

Answer:
Fixed. The new function was just copy-paste, but your suggestion is good.

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index d3aaeb6..6014413 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -3033,6 +3033,24 @@ int drm_mode_connector_update_edid_property(struct 
drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_mode_connector_update_edid_property);

+static bool drm_property_change_is_valid(struct drm_property *property,
+__u64 value)
+{
+   if (property->flags & DRM_MODE_PROP_IMMUTABLE)
+   return false;
+   if (property->flags & DRM_MODE_PROP_RANGE) {
+   if (value < property->values[0] || value > property->values[1])
+   return false;
+   return true;
+   } else {
+   int i;
+   for (i = 0; i < property->num_values; i++)
+   if (property->values[i] == value)
+   return true;
+   return false;
+   }
+}
+
 int drm_mode_connector_property_set_ioctl(struct drm_device *dev,
   void *data, struct drm_file *file_priv)
 {
@@ -3069,28 +3087,9 @@ int drm_mode_connector_property_set_ioctl(struct 
drm_device *dev,
}
property = obj_to_property(obj);

-   if (property->flags & DRM_MODE_PROP_IMMUTABLE)
+   if (!drm_property_change_is_valid(property, out_resp->value))
goto out;

-   if (property->flags & DRM_MODE_PROP_RANGE) {
-   if (out_resp->value < property->values[0])
-   goto out;
-
-   if (out_resp->value > property->values[1])
-   goto out;
-   } else {
-   int found = 0;
-   for (i = 0; i < property->num_values; i++) {
-   if (property->values[i] == out_resp->value) {
-   found = 1;
-   break;
-   }
-   }
-   if (!found) {
-   goto out;
-   }
-   }
-
/* Do DPMS ourselves */
if (property == connector->dev->mode_config.dpms_property) {
if (connector->funcs->dpms)
-- 
1.7.10

No subject

> Please add that to the error message and use printk_once() since we only
> really want to annoy the user the first time.

For each time we see the message, we need to increase the value by 1, so instead
of using printk_once, I just added this information to the message. Anyway, we
shouldn't be seeing this message too many times, since we don't add new
properties that often.

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 0a22ef8..37bb7ab 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2819,7 +2819,7 @@ void drm_property_destroy(struct drm_device *dev, struct 
drm_property *property)
 }
 EXPORT_SYMBOL(drm_property_destroy);

-int drm_connector_attach_property(struct drm_connector *connector,
+void drm_connector_attach_property(struct drm_connector *connector,
   struct drm_property *property, uint64_t init_val)
 {
int i;
@@ -2828,13 +2828,13 @@ int drm_connector_attach_property(struct drm_connector 
*connector,
if (connector->property_ids[i] == 0) {
connector->property_ids[i] = property->base.id;
connector->property_values[i] = init_val;
-   break;
+   return;
}
}

-   if (i == DRM_CONNECTOR_MAX_PROPERTY)
-   return -EINVAL;
-   return 0;
+   WARN(1, "Failed to attach connector property. Please increase "
+   "DRM_CONNECTOR_MAX_PROPERTY by 1 for each time you see this "
+   "message\n");
 }
 EXPORT_SYMBOL(drm_connector_attach_property);

diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f35e7ed..036faec 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -910,8 +910,8 @@ extern int drmfb_remove(struct drm_device *dev, struct 
drm_framebuffer *fb);
 extern void drm_crtc_probe_connector_modes(struct drm_device *dev, int maxX, 
int maxY);
 extern bool drm_crtc_in_use(struct drm_crtc *crtc);

-extern int drm_connector_attach_property(struct drm_connector *connector,
- struct drm_property *property, uint64_t 
init_val);
+extern void drm_connector_attach_property(struct drm_connector *connector,
+ struct drm_property *property, 
uint64_t init_val);
 extern struct drm_property *drm_property_create(struct drm_device *dev, int 
flags,
const char *name, int 
num_values);
 extern struct drm_property *drm_property_create_enum(struct drm_device *dev, 
int flags,
-- 
1.7.10

No subject

> 
> Perhaps we could add a debug message here for catch the unhandled types..
> 
This shouldn't happen. The previous checks should eliminate all objects that
don't have properties. The only possibility I can think of is if we add
properties to a new kind of object and forget to include it in the switch...
In this case, we'll still return -EINVAL, which is good.

No subject

> How about adding obj->properties.count to avoid having to count every
> time?
I just blindly followed the connector properties example. But your idea is good,
so I implemented it. Fixed, but in a new patch near the end of the series.
Putting the in the end of the series should make it easier to review IMHO.

> Just add the trailing comma to the last line as well. Otherwise we keep
> on having ugly diffs when new ioctls are added.
Fixed.

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 19a289f..b6783f9 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -2875,6 +2875,58 @@ int drm_connector_property_get_value(struct 
drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_connector_property_get_value);

+void drm_object_attach_property(struct drm_mode_object *obj,
+   struct drm_property *property,
+   uint64_t init_val)
+{
+   int i;
+
+   for (i = 0; i < DRM_OBJECT_MAX_PROPERTY; i++) {
+   if (obj->properties->ids[i] == 0) {
+   obj->properties->ids[i] = property->base.id;
+   obj->properties->values[i] = init_val;
+   return;
+   }
+   }
+
+   WARN(1, "Failed to attach object property (type: 0x%x). Please "
+   "increase DRM_OBJECT_MAX_PROPERTY by 1 for each time you see "
+   "this message on the same object type.\n", obj->type);
+}
+EXPORT_SYMBOL(drm_object_attach_property);
+
+int drm_object_property_set_value(struct drm_mode_object *obj,
+ struct drm_property *property, uint64_t val)
+{
+   int i;
+
+   for (i = 0; i < DRM_OBJECT_MAX_PROPERTY; i++) {
+   if (obj->properties->ids[i] == property->base.id) {
+   obj->properties->values[i] = val;
+   return 0;
+   }
+   }
+
+   return -EINVAL;
+}
+EXPORT_SYMBOL(drm_object_property_set_value);
+
+int drm_object_property_get_value(struct drm_mode_object *obj,
+ struct drm_property *property, uint64_t *val)
+{
+   int i;
+
+   for (i = 0; i < DRM_OBJECT_MAX_PROPERTY; i++) {
+   if (obj->properties->ids[i] == property->base.id) {
+   *val = obj->properties->values[i];
+   return 0;
+   }
+   }
+
+   return -EINVAL;
+}
+EXPORT_SYMBOL(drm_object_property_get_value);
+
 int drm_mode_getproperty_ioctl(struct drm_device *dev,
   void *data, struct drm_file *file_priv)
 {
@@ -3148,6 +3200,136 @@ out:
return ret;
 }

+static int drm_mode_connector_set_obj_prop(struct drm_mode_object *obj,
+  struct drm_property *property,
+  uint64_t value)
+{
+   int ret = -EINVAL;
+   struct drm_connector *connector = obj_to_connector(obj);
+
+   /* Do DPMS ourselves */
+   if (property == connector->dev->mode_config.dpms_property) {
+   if (connector->funcs->dpms)
+   (*connector->funcs->dpms)(connector, (int)value);
+   ret = 0;
+   } else if (connector->funcs->set_property)
+   ret = connector->funcs->set_property(connector, property, 
value);
+
+   /* store the property value if successful */
+   if (!ret)
+   drm_connector_property_set_value(connector, property, value);
+   return ret;
+}
+
+int drm_mode_obj_get_properties_ioctl(struct drm_device *dev, void *data,
+ struct drm_file *file_priv)
+{
+   struct drm_mode_obj_get_properties *arg = data;
+   struct drm_mode_object *obj;
+   int ret = 0;
+   int i;
+   int copied = 0;
+   int props_count = 0;
+   uint32_t __user *props_ptr;
+   uint64_t __user *prop_values_ptr;
+
+   if (!drm_core_check_feature(dev, DRIVER_MODESET))
+   return -EINVAL;
+
+   mutex_lock(>mode_config.mutex);
+
+   obj = drm_mode_object_find(dev, arg->obj_id, arg->obj_type);
+   if (!obj) {
+   ret = -EINVAL;
+   goto out;
+   }
+   if (!obj->properties) {
+   ret = -EINVAL;
+   goto out;
+   }
+
+   /* Assume [ prop, 0, prop ] won't happen (if we ever delete properties,
+* we need to remove the gap inside the array). */
+   for (props_count = 0; props_count < DRM_OBJECT_MAX_PROPERTY &&
+   obj->properties->ids[props_count] != 0; props_count++)
+   ;
+
+   /* This ioctl is called twice, once to determine how much space is
+* needed, and the 2nd time to fill it. */
+   if ((arg->count_props >= props_count) && props_count) {
+   copied = 0;
+   props_ptr = (uint32_t __user *)(unsigned long)(arg->props_ptr);
+   prop_values_ptr = (uint64_t __user *)(unsigned 

No subject

>
Subject: [PATCH 1/1] =A0=A0=A0 drivers/gpu/drm/i915: Fixed uninitialized

No subject

than escalating the bug into a random failure.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

No subject

No subject

No subject

No subject

[Rodrigo Vivi]

There are many bugs open on fd.o regarding missing modes that are supported on 
Windows and other closed source drivers.

No subject

[Rodrigo Vivi]

There are many bugs open on fd.o regarding missing modes that are supported on 
Windows and other closed source drivers.

[no subject]

[Rodrigo Vivi]

There are many bugs open on fd.o regarding missing modes that are supported on 
Windows and other closed source drivers.
From EDID spec we can (might?) infer modes using GTF and CVT when monitor 
allows it trough range limited flag... obviously limiting by the range.
From our code:
 * EDID spec says modes should be preferred in this order:
 * - preferred detailed mode
 * - other detailed modes from base block
 * - detailed modes from extension blocks
 * - CVT 3-byte code modes
 * - standard timing codes
 * - established timing codes
 * - modes inferred from GTF or CVT range information
 *
 * We get this pretty much right.

Not actually so right... We were inferring just using GTF... not CVT or even 
GTF2.
This patch not just add some common cvt modes but also allows some modes been 
inferred when using gtf2 as well.

Cheers,
Rodrigo.

From 4b7a88d0d812583d850ca691d1ac491355230d11 Mon Sep 17 00:00:00 2001
From: Rodrigo Vivi rodrigo.v...@intel.com
Date: Wed, 11 Apr 2012 15:36:31 -0300
Subject: [PATCH] drm/edid: Adding common CVT inferred modes when monitor
 allows range limited ones trough EDID.

Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/drm_edid.c   |   37 +-
 drivers/gpu/drm/drm_edid_modes.h |  101 ++
 2 files changed, 136 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7ee7be1..3179572 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1020,17 +1020,50 @@ drm_gtf_modes_for_range(struct drm_connector 
*connector, struct edid *edid,
return modes;
 }
 
+static int
+drm_cvt_modes_for_range(struct drm_connector *connector, struct edid *edid,
+   struct detailed_timing *timing)
+{
+   int i, modes = 0;
+   struct drm_display_mode *newmode;
+   struct drm_device *dev = connector-dev;
+
+   for (i = 0; i  drm_num_cvt_inferred_modes; i++) {
+   if (mode_in_range(drm_cvt_inferred_modes + i, edid, timing)) {
+   newmode = drm_mode_duplicate(dev, 
drm_cvt_inferred_modes[i]);
+   if (newmode) {
+   drm_mode_probed_add(connector, newmode);
+   modes++;
+   }
+   }
+   }
+
+   return modes;
+}
+
 static void
 do_inferred_modes(struct detailed_timing *timing, void *c)
 {
struct detailed_mode_closure *closure = c;
struct detailed_non_pixel *data = timing-data.other_data;
-   int gtf = (closure-edid-features  DRM_EDID_FEATURE_DEFAULT_GTF);
+   int timing_level = standard_timing_level(closure-edid);
 
-   if (gtf  data-type == EDID_DETAIL_MONITOR_RANGE)
+   if (data-type == EDID_DETAIL_MONITOR_RANGE)
+   switch (timing_level) {
+   case LEVEL_DMT:
+   break;
+   case LEVEL_GTF:
+   case LEVEL_GTF2:
closure-modes += drm_gtf_modes_for_range(closure-connector,
  closure-edid,
  timing);
+   break;
+   case LEVEL_CVT:
+   closure-modes += drm_cvt_modes_for_range(closure-connector,
+ closure-edid,
+ timing);
+   break;
+   }
 }
 
 static int
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index a91ffb1..7e14a32 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers/gpu/drm/drm_edid_modes.h
@@ -266,6 +266,107 @@ static const struct drm_display_mode drm_dmt_modes[] = {
 static const int drm_num_dmt_modes =
sizeof(drm_dmt_modes) / sizeof(struct drm_display_mode);
 
+static const struct drm_display_mode drm_cvt_inferred_modes[] = {
+   /* 640x480@60Hz */
+   { DRM_MODE(640x480, DRM_MODE_TYPE_DRIVER, 23750  640, 664,
+  720, 800, 0, 480, 483, 487, 500, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+   /* 800x600@60Hz */
+   { DRM_MODE(800x600, DRM_MODE_TYPE_DRIVER, 38250, 800, 832,
+  912, 1024, 0, 600, 603, 607, 624, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+   /* 900x600@60Hz */
+   { DRM_MODE(900x600, DRM_MODE_TYPE_DRIVER, 45250, 960, 992,
+  1088, 1216, 0, 600, 603, 609, 624, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+   /* 1024x576@60Hz */
+   { DRM_MODE(1024x576, DRM_MODE_TYPE_DRIVER, 46500, 1024, 1064,
+  1160, 1296, 0, 576, 579, 584, 599, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+   /* 1024x768@60Hz */
+   { DRM_MODE(1024x768, DRM_MODE_TYPE_DRIVER, 63500, 1024, 1072,
+  1176, 1328, 0, 768, 771, 775, 798, 0

[no subject]

[Rodrigo Vivi]

There are many bugs open on fd.o regarding missing modes that are supported on 
Windows and other closed source drivers.
From EDID spec we can (might?) infer modes using GTF and CVT when monitor 
allows it trough range limited flag... obviously limiting by the range.
From our code:
 * EDID spec says modes should be preferred in this order:
 * - preferred detailed mode
 * - other detailed modes from base block
 * - detailed modes from extension blocks
 * - CVT 3-byte code modes
 * - standard timing codes
 * - established timing codes
 * - modes inferred from GTF or CVT range information
 *
 * We get this pretty much right.

Not actually so right... We were inferring just using GTF... not CVT or even 
GTF2.
This patch not just add some common cvt modes but also allows some modes been 
inferred when using gtf2 as well.

Cheers,
Rodrigo.

From 4b7a88d0d812583d850ca691d1ac491355230d11 Mon Sep 17 00:00:00 2001
From: Rodrigo Vivi rodrigo.v...@intel.com
Date: Wed, 11 Apr 2012 15:36:31 -0300
Subject: [PATCH] drm/edid: Adding common CVT inferred modes when monitor
 allows range limited ones trough EDID.

Signed-off-by: Rodrigo Vivi rodrigo.v...@intel.com
---
 drivers/gpu/drm/drm_edid.c   |   37 +-
 drivers/gpu/drm/drm_edid_modes.h |  101 ++
 2 files changed, 136 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7ee7be1..3179572 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1020,17 +1020,50 @@ drm_gtf_modes_for_range(struct drm_connector 
*connector, struct edid *edid,
return modes;
 }
 
+static int
+drm_cvt_modes_for_range(struct drm_connector *connector, struct edid *edid,
+   struct detailed_timing *timing)
+{
+   int i, modes = 0;
+   struct drm_display_mode *newmode;
+   struct drm_device *dev = connector-dev;
+
+   for (i = 0; i  drm_num_cvt_inferred_modes; i++) {
+   if (mode_in_range(drm_cvt_inferred_modes + i, edid, timing)) {
+   newmode = drm_mode_duplicate(dev, 
drm_cvt_inferred_modes[i]);
+   if (newmode) {
+   drm_mode_probed_add(connector, newmode);
+   modes++;
+   }
+   }
+   }
+
+   return modes;
+}
+
 static void
 do_inferred_modes(struct detailed_timing *timing, void *c)
 {
struct detailed_mode_closure *closure = c;
struct detailed_non_pixel *data = timing-data.other_data;
-   int gtf = (closure-edid-features  DRM_EDID_FEATURE_DEFAULT_GTF);
+   int timing_level = standard_timing_level(closure-edid);
 
-   if (gtf  data-type == EDID_DETAIL_MONITOR_RANGE)
+   if (data-type == EDID_DETAIL_MONITOR_RANGE)
+   switch (timing_level) {
+   case LEVEL_DMT:
+   break;
+   case LEVEL_GTF:
+   case LEVEL_GTF2:
closure-modes += drm_gtf_modes_for_range(closure-connector,
  closure-edid,
  timing);
+   break;
+   case LEVEL_CVT:
+   closure-modes += drm_cvt_modes_for_range(closure-connector,
+ closure-edid,
+ timing);
+   break;
+   }
 }
 
 static int
diff --git a/drivers/gpu/drm/drm_edid_modes.h b/drivers/gpu/drm/drm_edid_modes.h
index a91ffb1..7e14a32 100644
--- a/drivers/gpu/drm/drm_edid_modes.h
+++ b/drivers/gpu/drm/drm_edid_modes.h
@@ -266,6 +266,107 @@ static const struct drm_display_mode drm_dmt_modes[] = {
 static const int drm_num_dmt_modes =
sizeof(drm_dmt_modes) / sizeof(struct drm_display_mode);
 
+static const struct drm_display_mode drm_cvt_inferred_modes[] = {
+   /* 640x480@60Hz */
+   { DRM_MODE(640x480, DRM_MODE_TYPE_DRIVER, 23750  640, 664,
+  720, 800, 0, 480, 483, 487, 500, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+   /* 800x600@60Hz */
+   { DRM_MODE(800x600, DRM_MODE_TYPE_DRIVER, 38250, 800, 832,
+  912, 1024, 0, 600, 603, 607, 624, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+   /* 900x600@60Hz */
+   { DRM_MODE(900x600, DRM_MODE_TYPE_DRIVER, 45250, 960, 992,
+  1088, 1216, 0, 600, 603, 609, 624, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+   /* 1024x576@60Hz */
+   { DRM_MODE(1024x576, DRM_MODE_TYPE_DRIVER, 46500, 1024, 1064,
+  1160, 1296, 0, 576, 579, 584, 599, 0,
+  DRM_MODE_FLAG_PHSYNC | DRM_MODE_FLAG_NVSYNC) },
+   /* 1024x768@60Hz */
+   { DRM_MODE(1024x768, DRM_MODE_TYPE_DRIVER, 63500, 1024, 1072,
+  1176, 1328, 0, 768, 771, 775, 798, 0

No subject

[Benjamin Herrenschmidt]

Under some circumstances, pci_map_rom() can return a valid mapping
but a size of 0 (if it cannot find an image in the header).

This causes nouveau to try to kmalloc() a 0 sized pointer and
dereference it, which crashes.

Signed-off-by: Benjamin Herrenschmidt 
---

Please send to Linus asap, without this, it crashes on the G5

 drivers/gpu/drm/nouveau/nouveau_bios.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c 
b/drivers/gpu/drm/nouveau/nouveau_bios.c
index 637afe7..80963d0 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bios.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
@@ -177,14 +177,15 @@ bios_shadow_pci(struct nvbios *bios)

if (!pci_enable_rom(pdev)) {
void __iomem *rom = pci_map_rom(pdev, );
-   if (rom) {
+   if (rom && length) {
bios->data = kmalloc(length, GFP_KERNEL);
if (bios->data) {
memcpy_fromio(bios->data, rom, length);
bios->length = length;
}
-   pci_unmap_rom(pdev, rom);
}
+   if (rom)
+   pci_unmap_rom(pdev, rom);

pci_disable_rom(pdev);
}
-- 
1.7.9.5

No subject

when the corresponding pins are not actually hooked up to anything.  In
these cases, there is no NAK, nor timeout, nor any other indication from
the GMBUS controller that a transaction fails.  The first gmbus
transaction timeout is caught by the "wait_for" timeout, causing the
transition to bit-banging mode for subsequent (failed) attempts.

This might be what was meant by the following note in the GPIO_CTL
description:
  "The registers that control digital display (HDMI/DVI, DisplayPort)
pins should only be utilized if the Port Detected bit in the related
control register is set to 1."
(http://intellinuxgraphics.org/documentation/SNB/IHD_OS_Vol3_Part3.pdf,
section 2.2.2)

Signed-off-by: Daniel Kurtz 
---
 drivers/gpu/drm/i915/intel_i2c.c |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index 73431ed..154fedd 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -380,8 +380,8 @@ gmbus_xfer(struct i2c_adapter *adapter,
 */
if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0,
 10)) {
-   DRM_INFO("GMBUS [%s] timed out waiting for idle\n",
-adapter->name);
+   DRM_ERROR("GMBUS [%s] timed out waiting for idle\n",
+ adapter->name);
ret = -ETIMEDOUT;
}
I915_WRITE(GMBUS0 + reg_offset, 0);
@@ -396,7 +396,7 @@ clear_err:
 */
if (wait_for((I915_READ(GMBUS2 + reg_offset) & GMBUS_ACTIVE) == 0,
 10))
-   DRM_INFO("GMBUS [%s] timed out after NAK\n", adapter->name);
+   DRM_ERROR("GMBUS [%s] timed out after NAK\n", adapter->name);

/* Toggle the Software Clear Interrupt bit. This has the effect
 * of resetting the GMBUS controller and so clearing the
@@ -421,8 +421,8 @@ clear_err:
goto out;

 timeout:
-   DRM_INFO("GMBUS [%s] timed out, falling back to bit banging on pin 
%d\n",
-bus->adapter.name, bus->reg0 & 0xff);
+   DRM_ERROR("GMBUS [%s] timed out, falling back to bit banging on pin 
%d\n",
+ bus->adapter.name, bus->reg0 & 0xff);
I915_WRITE(GMBUS0 + reg_offset, 0);

/* Hardware may not support GMBUS over these pins? Try GPIO bitbanging 
instead. */
-- 
1.7.7.3

No subject

makes me afraid of some weird GTT flushing issue, given the adventures
we had with VT-d on that hardware where we idle the gpu before any GTT
updates. I wonder what would happen if we idled the GPU before any GTT
updates even when VT-d wasn't running...

> The latest thinking on the hibernate issues is kernel one sets up an
> fbcon, hibernate restores the old memory and the GTT still points at
> the pages,
> then something writes to the console and overwrites real memory., just
> a working theory, nobody has proven it yet.

Presumably the resumed kernel will not be able to write to the console
until the i915 driver is running again, at which point it will have
updated all of the GTT entries. And, presumably the booted kernel won't
be writing to the console after it has loaded the resumed kernel memory?

-- 
keith.packard at intel.com

No subject

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

No subject

by the DMM so that we can do the PAT programming and that can only be
gotten from the hwmod entry.  And if you use the hwmod device entry,
you have to match the name used for that entry.

Regards,

Andy

No subject

k in return path of radeon_fence_count_emitted" fixes=0Athe problem. Tested=
 on top of 47492a23a and 3.3.0-rc3+00188-g3ec1e88.=0A=0A=0AThanks,=0A=0AMik=
ko

No subject

sl-to-tgsi.

BTW in which commit was the new ioctl disabled? I mean, I can understand th=
at if I don't have kernel with support for the new ioctl it breaks the test=
s,
however if the ioctl was disabled later shouldn't be current git working un=
less another regression happened?

> Anyway, sorry, I won't probably help you with this bug anytime soon.

Well, I don't care much for piglit, I just want to make sure r300g don't ge=
t too rusty now when the development has moved to new drivers.

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

No subject

disable the output polling during suspend. The following patch seems to
get rid of the problems I'm seeing. Does this look okay to you?

No subject

dangerball: intel_tris.c:128: intel_extend_inline: Assertion 'intel->prim.flush
== intel_flush_inline_primitive' failed.

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

No subject

GPU lockup CP stall for more than 1msec
Jan 23 23:53:54 thoregon kernel: [17121.080137] GPU lockup (waiting
for 0x002080B7 last fence id 0x002080B6)
Jan 23 23:53:54 thoregon kernel: [17121.096334] radeon :07:00.0:
GPU softreset
Jan 23 23:53:54 thoregon kernel: [17121.096341] radeon :07:00.0:
R_008010_GRBM_STATUS=0xA0003028
Jan 23 23:53:54 thoregon kernel: [17121.096346] radeon :07:00.0:
R_008014_GRBM_STATUS2=0x0002
Jan 23 23:53:54 thoregon kernel: [17121.096351] radeon :07:00.0:
R_000E50_SRBM_STATUS=0x20C0
Jan 23 23:53:54 thoregon kernel: [17121.096362] radeon :07:00.0:
R_008020_GRBM_SOFT_RESET=0x7FEE
Jan 23 23:53:54 thoregon kernel: [17121.111386] radeon :07:00.0:
R_008020_GRBM_SOFT_RESET=0x0001
Jan 23 23:53:54 thoregon kernel: [17121.127378] radeon :07:00.0:
R_008010_GRBM_STATUS=0x3028
Jan 23 23:53:54 thoregon kernel: [17121.127384] radeon :07:00.0:
R_008014_GRBM_STATUS2=0x0002
Jan 23 23:53:54 thoregon kernel: [17121.127390] radeon :07:00.0:
R_000E50_SRBM_STATUS=0x20C0
Jan 23 23:53:54 thoregon kernel: [17121.128393] radeon :07:00.0:
GPU reset succeed
Jan 23 23:53:54 thoregon kernel: [17121.10] [drm] PCIE GART of
512M enabled (table at 0x0004).
Jan 23 23:53:54 thoregon kernel: [17121.133364] radeon :07:00.0: WB enabled
Jan 23 23:53:54 thoregon kernel: [17121.133370] [drm] fence driver on
ring 0 use gpu addr 0x2c00 and cpu addr 0x8803286e5c00
Jan 23 23:53:54 thoregon kernel: [17121.179627] [drm] ring test on 0
succeeded in 1 usecs
Jan 23 23:53:54 thoregon kernel: [17121.179653] [drm] ib test on ring
0 succeeded in 1 usecs

There where no messages about X getting stuck ("blocked for more than
120 seconds"), but after trying to access the system and failing
SysRq+W reported this:
Jan 24 08:08:20 thoregon kernel: [46786.741180] SysRq : Show Blocked State
Jan 24 08:08:20 thoregon kernel: [46786.741190]   task
   PC stack   pid father
Jan 24 08:08:20 thoregon kernel: [46786.741270] X   D
880337d50a00 0  3047   3026 0x0044
Jan 24 08:08:20 thoregon kernel: [46786.741281]  880327eacac0
0086 880327d52e00 00010a00
Jan 24 08:08:20 thoregon kernel: [46786.741292]  88031be9bfd8
00010a00 88031be9a000 88031be9bfd8
Jan 24 08:08:20 thoregon kernel: [46786.741301]  00010a00
880327eacac0 00010a00 00010a00
Jan 24 08:08:20 thoregon kernel: [46786.741310] Call Trace:
Jan 24 08:08:20 thoregon kernel: [46786.741326]  []
? schedule_timeout+0x157/0x220
Jan 24 08:08:20 thoregon kernel: [46786.741336]  []
? run_timer_softirq+0x240/0x240
Jan 24 08:08:20 thoregon kernel: [46786.741346]  []
? radeon_fence_wait+0x239/0x3b0
Jan 24 08:08:20 thoregon kernel: [46786.741356]  []
? wake_up_bit+0x40/0x40
Jan 24 08:08:20 thoregon kernel: [46786.741364]  []
? radeon_ib_get+0x257/0x2e0
Jan 24 08:08:20 thoregon kernel: [46786.741372]  []
? radeon_cs_ioctl+0x27a/0x4d0
Jan 24 08:08:20 thoregon kernel: [46786.741381]  []
? drm_ioctl+0x3e4/0x490
Jan 24 08:08:20 thoregon kernel: [46786.741389]  []
? radeon_cs_finish_pages+0xa0/0xa0
Jan 24 08:08:20 thoregon kernel: [46786.741398]  []
? do_page_fault+0x199/0x420
Jan 24 08:08:20 thoregon kernel: [46786.741406]  []
? mmap_region+0x1dc/0x570
Jan 24 08:08:20 thoregon kernel: [46786.741414]  []
? do_vfs_ioctl+0x96/0x4e0
Jan 24 08:08:20 thoregon kernel: [46786.741422]  []
? sys_ioctl+0x49/0x90
Jan 24 08:08:20 thoregon kernel: [46786.741430]  []
? system_call_fastpath+0x16/0x1b

I did search my logs for more GPU lockups after noting that this also
happened with 3.2.
The first lockup in my logs occurred on Nov 4 under 3.1. But until
3.3-rc1 X always was able to resume normal operations.

My best guess for the cause of the GPU lockups seems to be the upgrade
from xf86-video-ati-6.14.2 to 6.14.3, but 3.3-rc1 seems to have an
independent bug that prevents X to recover from a GPU lockup/reset.

>> Of course it would be best if we did not lockup in the first place.
>
> Not sure if this is important: I also upgraded to mesa 8.0-rc1 before
> the first hang, but after switching back to 3.2 but still using mesa
> 8.0 I did not have any problems.
> Except the KDE desktop effects there should not have been any OpenGL
> programs running.
> The screen saver itself is just turning the screens off via the KDE
> power profile.
>
> I will report again, when I succeeded in triggering the GPU lockup again...
>
> Torsten

No subject

/usr/sbin/run-crons && /usr/sbin/run-crons)
Jan 21 19:39:41 thoregon kernel: [ 6364.620131] radeon :07:00.0:
GPU lockup CP stall for more than 1msec
Jan 21 19:39:41 thoregon kernel: [ 6364.620139] GPU lockup (waiting
for 0x0003F1F2 last fence id 0x0003F1F1)
Jan 21 19:39:41 thoregon kernel: [ 6364.636341] radeon :07:00.0:
GPU softreset
Jan 21 19:39:41 thoregon kernel: [ 6364.636348] radeon :07:00.0:
R_008010_GRBM_STATUS=0xA0003028
Jan 21 19:39:41 thoregon kernel: [ 6364.636354] radeon :07:00.0:
R_008014_GRBM_STATUS2=0x0002
Jan 21 19:39:41 thoregon kernel: [ 6364.620131] radeon :07:00.0:
GPU lockup CP stall for more than 1msec
Jan 21 19:39:41 thoregon kernel: [ 6364.620139] GPU lockup (waiting
for 0x0003F1F2 last fence id 0x0003F1F1)
Jan 21 19:39:41 thoregon kernel: [ 6364.636341] radeon :07:00.0:
GPU softreset
Jan 21 19:39:41 thoregon kernel: [ 6364.636348] radeon :07:00.0:
R_008010_GRBM_STATUS=0xA0003028
Jan 21 19:39:41 thoregon kernel: [ 6364.636354] radeon :07:00.0:
R_008014_GRBM_STATUS2=0x0002
Jan 21 19:39:41 thoregon kernel: [ 6364.636359] radeon :07:00.0:
R_000E50_SRBM_STATUS=0x20C0
Jan 21 19:39:41 thoregon kernel: [ 6364.636370] radeon :07:00.0:
R_008020_GRBM_SOFT_RESET=0x7FEE
Jan 21 19:39:41 thoregon kernel: [ 6364.651219] radeon :07:00.0:
R_008020_GRBM_SOFT_RESET=0x0001
Jan 21 19:39:41 thoregon kernel: [ 6364.667212] radeon :07:00.0:
R_008010_GRBM_STATUS=0x3028
Jan 21 19:39:41 thoregon kernel: [ 6364.667217] radeon :07:00.0:
R_008014_GRBM_STATUS2=0x0002
Jan 21 19:39:41 thoregon kernel: [ 6364.667223] radeon :07:00.0:
R_000E50_SRBM_STATUS=0x20C0
Jan 21 19:39:41 thoregon kernel: [ 6364.668226] radeon :07:00.0:
GPU reset succeed
Jan 21 19:39:41 thoregon kernel: [ 6364.673142] [drm] PCIE GART of
512M enabled (table at 0x0004).
Jan 21 19:39:41 thoregon kernel: [ 6364.673177] radeon :07:00.0: WB enabled
Jan 21 19:39:41 thoregon kernel: [ 6364.673184] [drm] fence driver on
ring 0 use gpu addr 0x2c00 and cpu addr 0x880328636c00
Jan 21 19:39:41 thoregon kernel: [ 6364.719445] [drm] ring test on 0
succeeded in 1 usecs
Jan 21 19:40:01 thoregon cron[3975]: (root) CMD (test -x
/usr/sbin/run-crons && /usr/sbin/run-crons)
Jan 21 19:43:37 thoregon kernel: [ 6600.390150] INFO: task X:3098
blocked for more than 120 seconds.
Jan 21 19:43:37 thoregon kernel: [ 6600.390157] "echo 0 >
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
Jan 21 19:43:37 thoregon kernel: [ 6600.390163] X   D
880337d50a00 0  3098   3077 0x0040
Jan 21 19:43:37 thoregon kernel: [ 6600.390174]  88031df15080
0086 8802f5087300 00010a00
Jan 21 19:43:37 thoregon kernel: [ 6600.390185]  88031bf79fd8
00010a00 88031bf78000 88031bf79fd8
Jan 21 19:43:37 thoregon kernel: [ 6600.390194]  00010a00
88031df15080 00010a00 00010a00
Jan 21 19:43:37 thoregon kernel: [ 6600.390203] Call Trace:
Jan 21 19:43:37 thoregon kernel: [ 6600.390219]  []
? __mutex_lock_slowpath+0xc8/0x140
Jan 21 19:43:37 thoregon kernel: [ 6600.390230]  []
? mutex_lock+0x1a/0x40
Jan 21 19:43:37 thoregon kernel: [ 6600.390239]  []
? radeon_ib_get+0x52/0x230
Jan 21 19:43:37 thoregon kernel: [ 6600.390249]  []
? r600_ib_test+0x5a/0x300
Jan 21 19:43:37 thoregon kernel: [ 6600.390258]  []
? rv770_startup+0xf7e/0x1590
Jan 21 19:43:37 thoregon kernel: [ 6600.390267]  []
? rv770_resume+0x2c/0x90
Jan 21 19:43:37 thoregon kernel: [ 6600.390275]  []
? radeon_gpu_reset+0x11e/0x160
Jan 21 19:43:37 thoregon kernel: [ 6600.390284]  []
? radeon_fence_wait+0x363/0x3b0
Jan 21 19:43:37 thoregon kernel: [ 6600.390293]  []
? wake_up_bit+0x40/0x40
Jan 21 19:43:37 thoregon kernel: [ 6600.390301]  []
? radeon_ib_get+0x1e7/0x230
Jan 21 19:43:37 thoregon kernel: [ 6600.390310]  []
? radeon_cs_ioctl+0x27a/0x4d0
Jan 21 19:43:37 thoregon kernel: [ 6600.390319]  []
? drm_ioctl+0x3e4/0x490
Jan 21 19:43:37 thoregon kernel: [ 6600.390327]  []
? radeon_cs_finish_pages+0xa0/0xa0
Jan 21 19:43:37 thoregon kernel: [ 6600.390336]  []
? do_page_fault+0x199/0x420
Jan 21 19:43:37 thoregon kernel: [ 6600.390344]  []
? mmap_region+0x1dc/0x570
Jan 21 19:43:37 thoregon kernel: [ 6600.390352]  []
? do_vfs_ioctl+0x96/0x4e0
Jan 21 19:43:37 thoregon kernel: [ 6600.390359]  []
? __schedule+0x28c/0x630
Jan 21 19:43:37 thoregon kernel: [ 6600.390366]  []
? sys_ioctl+0x49/0x90
Jan 21 19:43:37 thoregon kernel: [ 6600.390375]  []
? system_call_fastpath+0x16/0x1b
Jan 21 19:45:08 thoregon kernel: [ 6691.864440] SysRq : Emergency Sync
Jan 21 19:45:08 thoregon kernel: [ 6691.864838] Emergency Sync complete
Jan 21 19:45:14 thoregon kernel: [ 6697.476112] SysRq : Emergency Remount R/O
Jan 21 19:46:33 thoregon kernel: [0.00] Linux version
3.3.0-rc1 (root at thoregon) (gcc version 4.5.3 (Gentoo 4.5.3-r2 p1.0,
pie-0.4.6) ) #1 SMP Fri Jan 20 09:54:26 CET 2012

I did not have any trouble with 3.2 or earlier 

No subject

symbol is exported without explicit consent of the original author 
(regardless of what we think about GPL/proprietary modules covtroversy). 
So if NVidia needs to link DMA buffer sharing against their proprietary 
driver, they should have explicit permission from the original author to 
turn its symbols into EXPORT_SYMBOL.

-- Ilija

No subject

this sort of thing, nouveau is a good solution its just not going to
beat the binary driver in a lot of ways, just not sure whether I care
enough yet.

Dave.

No subject

However softpipe does not have polygons disappearing at all, so it would appear
to be a r300g problem. PrBoom uses GL_TRIANGLE_STRIPs to draw the walls, so
this is probably unrelated to this bug.

And another thing I noticed fixed. The OGLSB4th Edition chapter 16 vertexblend
draws the shiny light correctly (before it was slightly garbled, it would be a
bright white but with distorted red/white/pink in the middle).

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

No subject

Dec 11 17:16:36 nf7 kernel: [drm] Initialized drm 1.1.0 20060810
Dec 11 17:16:37 nf7 kernel: [drm] radeon kernel modesetting enabled.
Dec 11 17:16:37 nf7 kernel: ACPI: PCI Interrupt Link [APC4] enabled at IRQ 19
Dec 11 17:16:37 nf7 kernel: radeon :02:00.0: PCI INT A -> Link[APC4] -> GSI
19 (level, high) -> IRQ 19
Dec 11 17:16:37 nf7 kernel: [drm] initializing kernel modesetting (RV670
0x1002:0x9515 0x174B:0x0028).
Dec 11 17:16:37 nf7 kernel: [drm] register mmio base: 0xE100
Dec 11 17:16:37 nf7 kernel: [drm] register mmio size: 65536
Dec 11 17:16:37 nf7 kernel: ATOM BIOS: 
Dec 11 17:16:37 nf7 kernel: [drm] AGP mode requested: 8
Dec 11 17:16:37 nf7 kernel: agpgart-nvidia :00:00.0: AGP 3.0 bridge
Dec 11 17:16:37 nf7 kernel: agpgart-nvidia :00:00.0: putting AGP V3 device
into 8x mode
Dec 11 17:16:37 nf7 kernel: radeon :02:00.0: putting AGP V3 device into 8x
mode
Dec 11 17:16:37 nf7 kernel: radeon :02:00.0: GTT: 256M 0xC000 -
0xCFFF
Dec 11 17:16:37 nf7 kernel: radeon :02:00.0: VRAM: 512M 0xA000 -
0xBFFF (512M used)
Dec 11 17:16:37 nf7 kernel: [drm] Detected VRAM RAM=512M, BAR=256M
Dec 11 17:16:37 nf7 kernel: [drm] RAM width 256bits DDR
Dec 11 17:16:37 nf7 kernel: [TTM] Zone  kernel: Available graphics memory:
451408 kiB.
Dec 11 17:16:37 nf7 kernel: [TTM] Initializing pool allocator.
Dec 11 17:16:37 nf7 kernel: [drm] radeon: 512M of VRAM memory ready
Dec 11 17:16:37 nf7 kernel: [drm] radeon: 256M of GTT memory ready.
Dec 11 17:16:37 nf7 kernel: [drm] Supports vblank timestamp caching Rev 1
(10.10.2010).
Dec 11 17:16:37 nf7 kernel: [drm] Driver supports precise vblank timestamp
query.
Dec 11 17:16:37 nf7 kernel: [drm] radeon: irq initialized.
Dec 11 17:16:37 nf7 kernel: [drm] GART: num cpu pages 65536, num gpu pages
65536
Dec 11 17:16:37 nf7 kernel: [drm] Loading RV670 Microcode
Dec 11 17:16:37 nf7 kernel: BUG: unable to handle kernel NULL pointer
dereference at   (null)
Dec 11 17:16:37 nf7 kernel: IP: [] radeon_ttm_tt_populate+0xb0/0x160
[radeon]
Dec 11 17:16:37 nf7 kernel: *pde =  
Dec 11 17:16:37 nf7 kernel: Oops: 0002 [#1] PREEMPT 
Dec 11 17:16:37 nf7 kernel: Modules linked in: radeon(+) ttm drm_kms_helper drm
i2c_algo_bit i2c_core cfbcopyarea cfbimgblt cfbfillrect fbcon font bitblit
softcursor fb fbdev ehci_hcd nvidia_agp agpgart ohci_hcd usbhid usbcore
usb_common snd_intel8x0 snd_ac97_codec ac97_bus forcedeth
Dec 11 17:16:37 nf7 kernel: 
Dec 11 17:16:37 nf7 kernel: Pid: 2313, comm: modprobe Not tainted
3.2.0-rc1-10801-g32faa34 #1/NF7-S/NF7 (nVidia-nForce2)
Dec 11 17:16:37 nf7 kernel: EIP: 0060:[] EFLAGS: 00010202 CPU: 0
Dec 11 17:16:37 nf7 kernel: EIP is at radeon_ttm_tt_populate+0xb0/0x160
[radeon]
Dec 11 17:16:37 nf7 kernel: EAX: 3311c000 EBX: c14ec4c0 ECX:  EDX:

Dec 11 17:16:37 nf7 kernel: ESI:  EDI: f306cd20 EBP: f60e7bb0 ESP:
f60e7b7c
Dec 11 17:16:37 nf7 kernel:  DS: 007b ES: 007b FS:  GS: 0033 SS: 0068
Dec 11 17:16:37 nf7 kernel: Process modprobe (pid: 2313, ti=f60e6000
task=f7310290 task.ti=f60e6000)
Dec 11 17:16:37 nf7 kernel: Stack:
Dec 11 17:16:37 nf7 kernel:  1000    
f696e000 f60e7bf8 
Dec 11 17:16:37 nf7 kernel:  f694882c f8b6ff0e f306cd20 f60e7c1c f696e44c
f60e7bc0 f8b6fcab f694882c
Dec 11 17:16:37 nf7 kernel:   f60e7bf8 f8b70fb7 f696e43c f696e494
f8010114 f6948860 
Dec 11 17:16:37 nf7 kernel: Call Trace:
Dec 11 17:16:37 nf7 kernel:  [] ?
ttm_tt_set_placement_caching+0xe/0x1c0 [ttm]
Dec 11 17:16:37 nf7 kernel:  [] ttm_tt_bind+0x3b/0x60 [ttm]
Dec 11 17:16:37 nf7 kernel:  [] ttm_bo_handle_move_mem+0x2e7/0x320
[ttm]
Dec 11 17:16:37 nf7 kernel:  [] ttm_bo_move_buffer+0x105/0x120 [ttm]
Dec 11 17:16:37 nf7 kernel:  [] ?
ttm_mem_global_alloc_zone+0xc4/0x150 [ttm]
Dec 11 17:16:37 nf7 kernel:  [] ttm_bo_validate+0xa5/0x150 [ttm]
Dec 11 17:16:37 nf7 kernel:  [] ttm_bo_init+0x2c2/0x3b0 [ttm]
Dec 11 17:16:37 nf7 kernel:  [] radeon_bo_create+0x1ac/0x2b0 [radeon]
Dec 11 17:16:37 nf7 kernel:  [] ? radeon_bo_create+0x2b0/0x2b0
[radeon]
Dec 11 17:16:37 nf7 kernel:  [] radeon_wb_init+0x17d/0x1b0 [radeon]
Dec 11 17:16:37 nf7 kernel:  [] r600_startup+0x27a/0x7b0 [radeon]
Dec 11 17:16:37 nf7 kernel:  [] ?
radeon_gart_table_vram_alloc+0x4b/0x60 [radeon]
Dec 11 17:16:37 nf7 kernel:  [] r600_init+0x12f/0x280 [radeon]
Dec 11 17:16:37 nf7 kernel:  [] radeon_device_init+0x308/0x4f0
[radeon]
Dec 11 17:16:37 nf7 kernel:  [] ? radeon_combios_fini+0x10/0x10
[radeon]
Dec 11 17:16:37 nf7 kernel:  [] radeon_driver_load_kms+0x84/0x110
[radeon]
Dec 11 17:16:37 nf7 kernel:  [] drm_get_pci_dev+0x141/0x250 [drm]
Dec 11 17:16:37 nf7 kernel:  [] ? kmem_cache_alloc_trace+0x3f/0x120
Dec 11 17:16:37 nf7 kernel:  [] ? sysfs_do_create_link+0x14e/0x1c0
Dec 11 17:16:37 nf7 kernel:  [] radeon_pci_probe+0x85/0xb8 [radeon]
Dec 11 17:16:37 nf7 kernel:  [] local_pci_probe+0x13/0x20
Dec 11 17:16:37 nf7 kernel:  [] pci_device_probe+0x5f/0x90
Dec 11 17:16:37 nf7 kernel:  [] 

No subject

Windows.

There are only two physical keys:
 - power-on button
 - "keyboard"-labeled button, which seems to do nothing
   hardware-related; it triggers an event caught up by acer_wmi.
   I think all it does is telling the OS: "hey, pull up the software
   virtual keyboard on the second display".

> >  - there are a some unhandled WMI events logged from the acer-wmi
> >module [3] when closing the lid, opening it, and most importantly,
> >when the (main) screen is turned on or off by DPMS.
> > 
> 
> I will look at your dsdt and log from acer-wmi then try to improve
> acer-wmi.

Thanks a lot!

> > What do you think? I haven't really succeeded in nailing the source of
> > the issue down, but here are a few possibilities I'm thinking of:
> > 
> >  - the driver is not aware it can drive two LVDS displays (not very
> >likely, and it has worked once, see above)
> > 
> >  - there is some kind of switch that is able to turn the second screen
> >on or off (I'm thinking of something like rfkill). If so, it looks
> >like something non-standard and undocumented. This would explain
> >the WMI events (see the last note above)
> > 
> 
> What's the behavior of Windows?

I meant an internal switch that would be controlled by GPIO or
such. It doesn't seem very likely though...

> >  - buggy ACPI implementation. I tried to extract then recompile the
> >DSDT [4], and iasl spews out 17 errors and 12 warnings. Also worth
> >noticing is that line in dmesg:
> > "pci:00: ACPI _OSC request failed (AE_ERROR), returned control mask: 
> > 0x1d"
> > 
> > 
> > The Archlinux userland is:
> >  - libdrm 2.4.27
> >  - xorg-server 1.11.2
> >  - intel-dri 7.11.1
> >  - xf86-video-intel 2.17.0
> > 
> > 
> > Please let me know if there are any other details I should provide.
> > Regards,
> > Baptiste
> > 
> > Attachments:
> > [1] dmesg-DSM-functions.log - drm errors when booting normally
> > [2] dmesg-video-lvds2.log - drm errors when forcing LVDS2 on the cmdline
> > [3] acer_wmi.log - WMI events that land in dmesg
> > [4] dsdt - /sys/firmware/acpi/tables/DSDT
> 
> Please also attached on dmidecode log.

See [3] for dmidecode, I've also provided the dsdt [4] again.
Here is also everything related to ACPI in dmesg [5].

> Thank's a lot!
> Joey Lee

Let me know if there's anything else I can provide,
Baptiste

[1] http://lists.freedesktop.org/archives/intel-gfx/2010-October/008339.html
[2] https://bugs.freedesktop.org/show_bug.cgi?id=29821
[3] http://zorun.tonbnc.fr/lkml/dmidecode
[4] http://zorun.tonbnc.fr/lkml/dsdt
[5] http://zorn.tonbnc.fr/lkml/dmesg-acpi.log

No subject

start_kernel
|-> setup_arch
|-> x86_init.oem.arch_setup = xen_arch_setup

|-> check_bugs
|-> identify_boot_cpu
|-> identify_cpu
|-> select_idle_routine


so xen_arch_setup will set pm_idle and select_idle_routine will honour
it. I'm being told this is run either in the dom0 or the paravirt guest
and if so, I don't see any issue with this for baremetal. So you can
have my ACK provided this is tested on baremetal too.

Thanks.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551

No subject

allocating request. Though, it's unlikely cause if request is NULL
then BUG_ON will be hit in i915_add_request(). So, to unify the callee
uses of i915_add_request(), I'm proposing the following patch. Please
let me know what do you guys think. If you guys agree, I can sent a
formal patch.

Index: work/modi.linux-3.1.1/drivers/gpu/drm/i915/i915_gem.c
===
--- work.orig/modi.linux-3.1.1/drivers/gpu/drm/i915/i915_gem.c
+++ work/modi.linux-3.1.1/drivers/gpu/drm/i915/i915_gem.c
@@ -1736,8 +1736,6 @@ i915_add_request(struct intel_ring_buffe
int was_empty;
int ret;

-   BUG_ON(request == NULL);
-
ret = ring->add_request(ring, );
if (ret)
return ret;
@@ -2002,9 +2000,11 @@ i915_gem_retire_work_handler(struct work
ret = i915_gem_flush_ring(ring,
  0, I915_GEM_GPU_DOMAINS);
request = kzalloc(sizeof(*request), GFP_KERNEL);
-   if (ret || request == NULL ||
-   i915_add_request(ring, NULL, request))
-   kfree(request);
+   if (request) {
+   ret = i915_add_request(ring, NULL, request);
+   if (ret)
+   kfree(request);
+   }
}

idle &= list_empty(>request_list);


Thanks,
Rakib

No subject

are looking for. I recognize that it disrupts your current views/plans on 
how this should be done, but I do want to work with you to find a suitable 
middle ground that covers most of the possiblities.

In case you are looking at my code to follow the above-described 
scenarios, please make sure you pull the latest stuff from my github 
repository. I have been pushing new stuff since my original annoucement.


> I still foresee problems with tiling, we generally don't encourage
> accel code to live in the kernel, and you'll really want a
> tiled->untiled blit for this thing,

Accel code should not go into the kernel (that I fully agree) and there is 
nothing here that would behove us to do so. Restricting my comments to 
Radeon GPU (which is the only one that I know well enough), shaders for 
blit copy live in the kernel and irrespective of VCRTCM work. I rely on 
them to move the frame buffer out of VRAM to CTD device but I don't add 
any additional features.

Now for detiling, I think that it should be the responsibility of the 
receiving CTD device, not the GPU pushing the data (Alan mentioned that 
during the initial set of comments, and although I didn't say anything to 
it that has been my view as well).

Even if you wanted to use GPU for detiling (which I'll explain shortly why 
you should not), it would not require any new accel code in the kernel. It 
would merely require one bit flip in the setup of blit copy that already 
lives in the kernel.

However, de-tiling in GPU is a bad idea for two reasons. I tried to do 
that just as an experiment on Radeon GPUs and watched with the PCI Express 
analyzer what happens on the bus (yeah, I have some "heavy weapons" in my 
lab). Normally a tile is a continuous array of memory locations in VRAM. 
If blit-copy function is told to assume tiled source and linear 
destination (de-tiling) it will read a continuous set of addresses in 
VRAM, but then scatter 8 rows of 8 pixels each on non-contignuous set of 
addresses of the destination. If the destination is the PCI-Express bus, 
it will result in 8 32-byte write transactions instead of 2 128-byte 
transactions per each tile. That will choke the throughput of the bus 
right there.

BTW, this is the crux of the blit-copy performance improvement that you 
got from me back in October. Since blit-copy deals with copying a linear 
array, playing with tiled/non-tiled bits only affects the order in which 
addresses are accessed, so the trick was to get rid of short PCIe 
transactions and also shape up linear to rectangle mapping to make address 
pattern more friendly for the host.


> also for Intel GPUs where you have
> UMA, would you read from the UMA.
>

Yes the read would be from UMA. I have not yet looked at Intel GPUs in 
detail, so I don't have an answer for you on what problems would pop up 
and how to solve them, but I'll be glad to revisit the Intel discussion 
once I do some homework.

Some initial thoughts is that frame buffer in Intel are at the end of the 
day pages in the system memory, so anyone/anything can get to them if they 
are correctly mapped.


> It also doesn't solve the optimus GPU problem in any useful fashion,
> since it can't deal with all the use cases, so we still have to write
> an alternate solution that can deal with them, so we just end up with
> two answers.
>

Can you elaborate on some specific use cases that are of your concern? I 
have had this case in mind and I think I can make it work. First I would 
have to add CTD functionality to Intel driver. That should be 
straightforward. Once I get there, I'll be ready to experiment and we'll 
probably be in better position to discuss the specifics then (i.e. when we 
have something working to compare with what you did in PRIME experiemnt), 
but it would be good to know your specific concerns early.


thanks,

Ilija

No subject

When the root cause will be discovered, we should allow both of course. But
so far, all the attempts on this weren't successful.

-- 
Eugeni Dodonov


--bcaec54306ded2a5b704b258e725
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Nov 22, 2011 at 18:15, Matthew Garrett <=
span dir=3D"ltr">mailto:mjg at redhat.com">mjg at 
redhat.com=
t; wrote:

On Fri, Nov 18, 2011 at 10:41:29PM -0800, Keith Packard w=
rote:

 + =A0 =A0 /*
 + =A0 =A0 =A0* Only enable RC6 if all dma remapping is disabled, or if=

 + =A0 =A0 =A0* theres no iommu present in the machine.
 + =A0 =A0 =A0*/
 + =A0 =A0 if (INTEL_INFO(dev)-gen =3D=3D 6)
 + =A0 =A0 =A0 =A0 =A0 =A0 return no_iommu || dmar_disabled;

So the user has to choose between 5W of power saving or having dmar? =
And
we default to giving them dmar?From the latest invest=
igations, it is either this, or random gpu hangs and crashes when both are =
enabled :(.When the root cause will be discovered, we should allow =
both of course. But so far, all the attempts on this werent successful=
.

-- Eugeni Dodonovhttp://eugeni.dodonov.net/"=
 target=3D"_blank">

--bcaec54306ded2a5b704b258e725--

No subject

some other method before passing the frame off to the overlay.

Rather disappointing, and seemingly not of too much use.  But, I'd like
to expose what functionality there is in any case.

Ben.

> 
> v2: fix ABI of get_plane - move format_type_ptr to the end
> 
> Acked-by: Alan Cox 
> Reviewed-by: Rob Clark 
> Reviewed-by: Daniel Vetter 
> Signed-off-by: Jesse Barnes 
> ---
>  drivers/gpu/drm/drm_crtc.c |  257 
> +++-
>  drivers/gpu/drm/drm_drv.c  |3 +
>  include/drm/drm.h  |3 +
>  include/drm/drm_crtc.h |   75 +-
>  include/drm/drm_mode.h |   33 ++
>  5 files changed, 368 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index fe738f0..804ef12 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -321,6 +321,7 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
>  {
>   struct drm_device *dev = fb->dev;
>   struct drm_crtc *crtc;
> + struct drm_plane *plane;
>   struct drm_mode_set set;
>   int ret;
>  
> @@ -337,6 +338,15 @@ void drm_framebuffer_cleanup(struct drm_framebuffer *fb)
>   }
>   }
>  
> + list_for_each_entry(plane, >mode_config.plane_list, head) {
> + if (plane->fb == fb) {
> + /* should turn off the crtc */
> + ret = plane->funcs->disable_plane(plane);
> + if (ret)
> + DRM_ERROR("failed to disable plane with busy 
> fb\n");
> + }
> + }
> +
>   drm_mode_object_put(dev, >base);
>   list_del(>head);
>   dev->mode_config.num_fb--;
> @@ -535,6 +545,50 @@ void drm_encoder_cleanup(struct drm_encoder *encoder)
>  }
>  EXPORT_SYMBOL(drm_encoder_cleanup);
>  
> +int drm_plane_init(struct drm_device *dev, struct drm_plane *plane,
> +unsigned long possible_crtcs,
> +const struct drm_plane_funcs *funcs,
> +uint32_t *formats, uint32_t format_count)
> +{
> + mutex_lock(>mode_config.mutex);
> +
> + plane->dev = dev;
> + drm_mode_object_get(dev, >base, DRM_MODE_OBJECT_PLANE);
> + plane->funcs = funcs;
> + plane->format_types = kmalloc(sizeof(uint32_t) * format_count,
> +   GFP_KERNEL);
> + if (!plane->format_types) {
> + DRM_DEBUG_KMS("out of memory when allocating plane\n");
> + drm_mode_object_put(dev, >base);
> + return -ENOMEM;
> + }
> +
> + memcpy(plane->format_types, formats, format_count);
> + plane->format_count = format_count;
> + plane->possible_crtcs = possible_crtcs;
> +
> + list_add_tail(>head, >mode_config.plane_list);
> + dev->mode_config.num_plane++;
> +
> + mutex_unlock(>mode_config.mutex);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_plane_init);
> +
> +void drm_plane_cleanup(struct drm_plane *plane)
> +{
> + struct drm_device *dev = plane->dev;
> +
> + mutex_lock(>mode_config.mutex);
> + kfree(plane->format_types);
> + drm_mode_object_put(dev, >base);
> + list_del(>head);
> + dev->mode_config.num_plane--;
> + mutex_unlock(>mode_config.mutex);
> +}
> +EXPORT_SYMBOL(drm_plane_cleanup);
> +
>  /**
>   * drm_mode_create - create a new display mode
>   * @dev: DRM device
> @@ -866,6 +920,7 @@ void drm_mode_config_init(struct drm_device *dev)
>   INIT_LIST_HEAD(>mode_config.encoder_list);
>   INIT_LIST_HEAD(>mode_config.property_list);
>   INIT_LIST_HEAD(>mode_config.property_blob_list);
> + INIT_LIST_HEAD(>mode_config.plane_list);
>   idr_init(>mode_config.crtc_idr);
>  
>   mutex_lock(>mode_config.mutex);
> @@ -942,6 +997,7 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>   struct drm_encoder *encoder, *enct;
>   struct drm_framebuffer *fb, *fbt;
>   struct drm_property *property, *pt;
> + struct drm_plane *plane, *plt;
>  
>   list_for_each_entry_safe(encoder, enct, >mode_config.encoder_list,
>head) {
> @@ -966,6 +1022,10 @@ void drm_mode_config_cleanup(struct drm_device *dev)
>   crtc->funcs->destroy(crtc);
>   }
>  
> + list_for_each_entry_safe(plane, plt, >mode_config.plane_list,
> +  head) {
> + plane->funcs->destroy(plane);
> + }
>  }
>  EXPORT_SYMBOL(drm_mode_config_cleanup);
>  
> @@ -1466,6 +1526,197 @@ out:
>  }
>  
>  /**
> + * drm_mode_getplane_res - get plane info
> + * @dev: DRM device
> + * @data: ioctl data
> + * @file_priv: DRM file info
> + *
> + * Return an plane count and set of IDs.
> + */
> +int drm_mode_getplane_res(struct drm_device *dev, void *data,
> + struct drm_file *file_priv)
> +{
> + struct drm_mode_get_plane_res *plane_resp = data;
> + struct drm_mode_config *config;
> + struct drm_plane *plane;
> + uint32_t __user *plane_ptr;
> + int copied = 

No subject

be -EREMOTEIO, which could be caused by transmission error so it should be
retried.

-- 
Eugeni Dodonov


--bcaec51f8fc3b70e6504af85018a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 17, 2011 at 18:41, Keith Packard 

No subject

install libtxc_dxtn

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

No subject

TTM_PL_FLAG_NO_EVICT so you vq buffer is not allocated with the no
evict flags, then i guess it got evicted on first bo allocation which
is strange, maybe first bo has some lpfn constraint.

>> > =A0 =A0 =A0 =A0Second question I have is how are monochrome cursor ima=
ges
>> > handled with KMS. Yes we need to support CLE266 which is used in a lot
>> > of POS devices. That chipset only supports monochrome cursors.
>>
>> You can hide the cursor limitation from userspace and pretend supporting
>> rgb cursor.
>
> So just return -ENXIO in that case.

No, so far there is no format specification for cursor, so userspace
can send monochrome or you can accept rgb from userspace and convert
to monochrome inside the kernel, but i think it's better to just
assume userspace sends you monochrome.

Cheers,
Jerome

No subject

[Inki Dae]

Hi, Dave.



I am sending a mail I wonder where are we on this. I had sent DRM Driver
patch v5 for Samsung SoC Exynos4210 a week ago but I didn't received any
comments from you.



You can refer to these patches I sent from links below.

v1: < https://lwn.net/Articles/454380/ >

v2: < http://www.spinics.net/lists/kernel/msg1224275.html >

v3: < http://www.spinics.net/lists/dri-devel/msg13755.html >

v4: < http://permalink.gmane.org/gmane.comp.video.dri.devel/60439 >

v5: < http://comments.gmane.org/gmane.comp.video.dri.devel/60802 >



and also you can refer to our working repository below.

< http://git.infradead.org/users/kmpark/linux-2.6-samsung >

Branch name : dev/samsung-drm



If there are any problems regarding our driver then please give me your
comments or advices so that we are going to prepare next patch; otherwise we
wish our driver be applied to mainline.



Thanks,

Inki Dae.

-- next part --
An HTML attachment was scrubbed...
URL: 

No subject

Power_Down_delay value, which is actually documented to be the 'T3
time sequence' value used 'during power up'. There aren't separate T1
and T2 values, but there is a combined T1+T2 value in the PP_ON_DELAYS
register, so I use that instead.

VBT doesn't provide any values for T1 or T2, so we'll always just use
the hardware value for that.

The panel power up delay is thus T1 + T2 + T3, which should be
sufficient in all cases.

The panel power down delay is T1 + T2 + T12, using T1+T2 as a proxy
for T11, which isn't available anywhere.

On the macbook air I'm testing with, this yields a power-up delay of
over 200ms and a power-down delay of over 600ms. It all works now, but
we're frobbing these power controls several times during mode setting,
making the whole process take an awfully long time.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/i915_drv.h |1 -
 drivers/gpu/drm/i915/intel_dp.c |   59 --
 2 files changed, 43 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7916bd9..bcdf58b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -672,7 +672,6 @@ typedef struct drm_i915_private {
unsigned int lvds_border_bits;
/* Panel fitter placement and size for Ironlake+ */
u32 pch_pf_pos, pch_pf_size;
-   int panel_t3, panel_t12;

struct drm_crtc *plane_to_crtc_mapping[2];
struct drm_crtc *pipe_to_crtc_mapping[2];
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index fbc19e4..7ebbdff 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -59,6 +59,8 @@ struct intel_dp {
bool is_pch_edp;
uint8_t train_set[4];
uint8_t link_status[DP_LINK_STATUS_SIZE];
+   int panel_power_up_delay;
+   int panel_power_down_delay;
 };

 /**
@@ -838,7 +840,7 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp 
*intel_dp)
 {
struct drm_device *dev = intel_dp->base.base.dev;
struct drm_i915_private *dev_priv = dev->dev_private;
-   u32 pp;
+   u32 pp, pp_status;

if (!is_edp(intel_dp))
return;
@@ -847,10 +849,7 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp 
*intel_dp)
 * If the panel wasn't on, make sure there's not a currently
 * active PP sequence before enabling AUX VDD.
 */
-   if (!(I915_READ(PCH_PP_STATUS) & PP_ON)) {
-   DRM_DEBUG_KMS("eDP VDD was not on\n");
-   msleep(dev_priv->panel_t3);
-   }
+   pp_status = I915_READ(PCH_PP_STATUS);

pp = I915_READ(PCH_PP_CONTROL);
pp &= ~PANEL_UNLOCK_MASK;
@@ -860,7 +859,10 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp 
*intel_dp)
POSTING_READ(PCH_PP_CONTROL);
DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
  I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
-   msleep(1000);
+   if (!(pp_status & PP_ON)) {
+   msleep(intel_dp->panel_power_up_delay);
+   DRM_DEBUG_KMS("eDP VDD was not on\n");
+   }
 }

 static void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp)
@@ -880,10 +882,9 @@ static void ironlake_edp_panel_vdd_off(struct intel_dp 
*intel_dp)
POSTING_READ(PCH_PP_CONTROL);

/* Make sure sequencer is idle before allowing subsequent activity */
-   msleep(dev_priv->panel_t12);
DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
  I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
-   msleep(1000);
+   msleep(intel_dp->panel_power_down_delay);
 }

 /* Returns true if the panel was already on when called */
@@ -921,8 +922,10 @@ static bool ironlake_edp_panel_on (struct intel_dp 
*intel_dp)
return false;
 }

-static void ironlake_edp_panel_off (struct drm_device *dev)
+static void ironlake_edp_panel_off(struct drm_encoder *encoder)
 {
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
u32 pp, idle_off_mask = PP_ON | PP_SEQUENCE_MASK |
PP_CYCLE_DELAY_ACTIVE | PP_SEQUENCE_STATE_MASK;
@@ -939,6 +942,7 @@ static void ironlake_edp_panel_off (struct drm_device *dev)
pp &= ~POWER_TARGET_ON;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
+   msleep(intel_dp->panel_power_down_delay);

if (wait_for((I915_READ(PCH_PP_STATUS) & idle_off_mask) == 0, 5000))
DRM_ERROR("panel off wait timed out: 0x%08x\n",
@@ -1044,7 +1048,7 @@ static void intel_dp_prepare(struct drm_encoder *encoder)

if (is_edp(intel_dp)) {
ironlake_edp_backlight_off(dev);
-   ironlake_edp_panel_off(dev);
+   ironlake_edp_panel_off(encoder);
if 

[no subject]

[Inki Dae]

Hi, Dave.

 

I am sending a mail I wonder where are we on this. I had sent DRM Driver
patch v5 for Samsung SoC Exynos4210 a week ago but I didn't received any
comments from you.

 

You can refer to these patches I sent from links below.

v1:  https://lwn.net/Articles/454380/ 

v2:  http://www.spinics.net/lists/kernel/msg1224275.html 

v3:  http://www.spinics.net/lists/dri-devel/msg13755.html 

v4:  http://permalink.gmane.org/gmane.comp.video.dri.devel/60439 

v5:  http://comments.gmane.org/gmane.comp.video.dri.devel/60802 

 

and also you can refer to our working repository below.

 http://git.infradead.org/users/kmpark/linux-2.6-samsung 

Branch name : dev/samsung-drm

 

If there are any problems regarding our driver then please give me your
comments or advices so that we are going to prepare next patch; otherwise we
wish our driver be applied to mainline.

 

Thanks,

Inki Dae.

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

No subject

> Please report at bugs.freedesktop.org
This also happens with the wine tests. I wanted to add this on the Mesa bug,
but I don't have my password at the moment(different keychain). For the Mesa
devs debugging the tests may be easier than debugging NFS:MW.

(see: http://bugs.winehq.org/show_bug.cgi?id=22459#c6)

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

No subject

Power_Down_delay value, which is actually documented to be the 'T3
time sequence' value used 'during power up'. There aren't separate T1
and T2 values, but there is a combined T1+T2 value in the PP_ON_DELAYS
register, so I use that instead.

VBT doesn't provide any values for T1 or T2, so we'll always just use
the hardware value for that.

The panel power up delay is thus T1 + T2 + T3, which should be
sufficient in all cases.

The panel power down delay is T1 + T2 + T12, using T1+T2 as a proxy
for T11, which isn't available anywhere.

On the macbook air I'm testing with, this yields a power-up delay of
over 200ms and a power-down delay of over 600ms. It all works now, but
we're frobbing these power controls several times during mode setting,
making the whole process take an awfully long time.

Signed-off-by: Keith Packard 
---
 drivers/gpu/drm/i915/i915_drv.h |1 -
 drivers/gpu/drm/i915/intel_dp.c |   56 --
 2 files changed, 41 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7916bd9..bcdf58b 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -672,7 +672,6 @@ typedef struct drm_i915_private {
unsigned int lvds_border_bits;
/* Panel fitter placement and size for Ironlake+ */
u32 pch_pf_pos, pch_pf_size;
-   int panel_t3, panel_t12;

struct drm_crtc *plane_to_crtc_mapping[2];
struct drm_crtc *pipe_to_crtc_mapping[2];
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 41b1e05..f1d6105 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -59,6 +59,8 @@ struct intel_dp {
bool is_pch_edp;
uint8_t train_set[4];
uint8_t link_status[DP_LINK_STATUS_SIZE];
+   int panel_power_up_delay;
+   int panel_power_down_delay;
 };

 /**
@@ -848,10 +850,6 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp 
*intel_dp)
 * active PP sequence before enabling AUX VDD.
 */
pp_status = I915_READ(PCH_PP_STATUS);
-   if (!(pp_status & PP_ON)) {
-   DRM_DEBUG_KMS("eDP VDD was not on\n");
-   msleep(dev_priv->panel_t3);
-   }

pp = I915_READ(PCH_PP_CONTROL);
pp &= ~PANEL_UNLOCK_MASK;
@@ -861,7 +859,10 @@ static void ironlake_edp_panel_vdd_on(struct intel_dp 
*intel_dp)
POSTING_READ(PCH_PP_CONTROL);
DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
  I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
-   msleep(1000);
+   if (!(pp_status & PP_ON)) {
+   msleep(intel_dp->panel_power_up_delay);
+   DRM_DEBUG_KMS("eDP VDD was not on\n");
+   }
 }

 static void ironlake_edp_panel_vdd_off(struct intel_dp *intel_dp)
@@ -881,10 +882,9 @@ static void ironlake_edp_panel_vdd_off(struct intel_dp 
*intel_dp)
POSTING_READ(PCH_PP_CONTROL);

/* Make sure sequencer is idle before allowing subsequent activity */
-   msleep(dev_priv->panel_t12);
DRM_DEBUG_KMS("PCH_PP_STATUS: 0x%08x PCH_PP_CONTROL: 0x%08x\n",
  I915_READ(PCH_PP_STATUS), I915_READ(PCH_PP_CONTROL));
-   msleep(1000);
+   msleep(intel_dp->panel_power_down_delay);
 }

 /* Returns true if the panel was already on when called */
@@ -922,8 +922,10 @@ static bool ironlake_edp_panel_on (struct intel_dp 
*intel_dp)
return false;
 }

-static void ironlake_edp_panel_off (struct drm_device *dev)
+static void ironlake_edp_panel_off(struct drm_encoder *encoder)
 {
+   struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+   struct drm_device *dev = encoder->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
u32 pp, idle_off_mask = PP_ON | PP_SEQUENCE_MASK |
PP_CYCLE_DELAY_ACTIVE | PP_SEQUENCE_STATE_MASK;
@@ -940,6 +942,7 @@ static void ironlake_edp_panel_off (struct drm_device *dev)
pp &= ~POWER_TARGET_ON;
I915_WRITE(PCH_PP_CONTROL, pp);
POSTING_READ(PCH_PP_CONTROL);
+   msleep(intel_dp->panel_power_down_delay);

if (wait_for((I915_READ(PCH_PP_STATUS) & idle_off_mask) == 0, 5000))
DRM_ERROR("panel off wait timed out: 0x%08x\n",
@@ -1045,7 +1048,7 @@ static void intel_dp_prepare(struct drm_encoder *encoder)

if (is_edp(intel_dp)) {
ironlake_edp_backlight_off(dev);
-   ironlake_edp_panel_off(dev);
+   ironlake_edp_panel_off(encoder);
if (!is_pch_edp(intel_dp))
ironlake_edp_pll_on(encoder);
else
@@ -1088,7 +1091,7 @@ intel_dp_dpms(struct drm_encoder *encoder, int mode)
intel_dp_sink_dpms(intel_dp, mode);
intel_dp_link_down(intel_dp);
if (is_edp(intel_dp))
-   ironlake_edp_panel_off(dev);
+   

No subject

legacy interface provided on top of DRM/KMS driver mostly via helper
functions.  With this approach, you get the richer KMS API (and all
the related plumbing for hotplug, EDID parsing, multi-head support,
flipping, etc) for userspace stuff that needs that, but can keep the
fbdev userspace interface for legacy apps.  It is the best of both
worlds.  There isn't really any good reason to propagate standalone
fbdev driver anymore.

BR,
-R

> --
> Felipe Contreras
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>

No subject

bisecting brought me to commit
288d5abec8314ae50fe6692f324b0444acae8486. Reverting seems to work as
microcode is loaded with compiled in firmware and radeon kms driver.


That's

commit 288d5abec8314ae50fe6692f324b0444acae8486
Author: Linus Torvalds 
Date:   Wed Aug 3 22:03:29 2011 -1000

Boot up with usermodehelper disabled

--=20
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=3Demail
--- You are receiving this mail because: ---
You are watching the assignee of the bug.=

No subject

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

No subject

related to X. And drm should be able to live without X. So why would
libdrm-intel rely on libpciaccess/X to be build? I'm sure we could do
without it, since all other drivers do.

As things are right now, would that imply using a X lib to build
libdrm-intel and then use it with Wayland for instance? Isn't Wayland
supposed to be able to run completly without X?

Cheers,

-- 
Alexandre Demers

No subject

fix in a hurry (lots of copy-paste), and maybe it would be better to
re-do it properly...


Thanks again,
Kirill

No subject

1.   Start up with a 2048x768 surface and set each of the two CRTCs (at=
 1024x768 timings) to display left/right half of the screen,

2.   Allow for "seamless" mode set, i.e. let the vendor's DRM to report=
 that the current mode (set by the VBIOS for example) is the same as the sw=
itch-to mode, and therefore don't turn off the connectors and CRTCs.  This =
avoids unnecessary flashes on the screen at boot time.

3.   Start up in clone without specifying "video=3D", and not going int=
o 1024x768.  We would like to start up in a user-specified mode in clone co=
nfiguration.

We have a highly configurable driver, and we need to be able to control exa=
ctly how the display(s) come up.  I'm trying to figure out if there is a wa=
y to do this and still play nice with KMS's initialization sequence.

Are any of those possible under KMS at this time?

Thanks,

Sinclair

--_000_519094DF2EA3494E93EBDAE6DE87A2C601146A9C85rrsmsx504amrc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

http://www.w3.org/TR/REC-html40; =
xmlns:q=3D"http://schemas.xmlsoap.org/soap/envelope/; xmlns:rtc=3D"http://m=
icrosoft.com/officenet/conferencing" xmlns:D=3D"DAV:" xmlns:Repl=3D"http://=
schemas.microsoft.com/repl/" xmlns:mt=3D"http://schemas.microsoft.com/share=
point/soap/meetings/" xmlns:x2=3D"http://schemas.microsoft.com/office/excel=
/2003/xml" xmlns:ppda=3D"http://www.passport.com/NameSpace.xsd; xmlns:ois=
=3D"http://schemas.microsoft.com/sharepoint/soap/ois/; xmlns:dir=3D"http://=
schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds=3D"http://www.w3=
.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.microsoft.com/sharepoint=
/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc; xmlns:xsd=3D"http=
://www.w3.org/2001/XMLSchema" xmlns:sub=3D"http://schemas.microsoft.com/sha=
repoint/soap/2002/1/alerts/" xmlns:ec=3D"http://www.w3.org/2001/04/xmlenc#"=
 xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/; xmlns:sps=3D"http://=
schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http://www.w3.org/2001=
/XMLSchema-instance" xmlns:udcs=3D"http://schemas.microsoft.com/data/udc/so=
ap" xmlns:udcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile; xmlns:udc=
p2p=3D"http://schemas.microsoft.com/data/udc/parttopart; xmlns:wf=3D"http:/=
/schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:dsss=3D"http://sche=
mas.microsoft.com/office/2006/digsig-setup" xmlns:dssi=3D"http://schemas.mi=
crosoft.com/office/2006/digsig" xmlns:mdssi=3D"http://schemas.openxmlformat=
s.org/package/2006/digital-signature" xmlns:mver=3D"http://schemas.openxmlf=
ormats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.microsoft.c=
om/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlformats.org/pa=
ckage/2006/relationships" xmlns:spwp=3D"http://microsoft.com/sharepoint/web=
partpages" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/20=
06/types" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/200=
6/messages" xmlns:pptsl=3D"http://schemas.microsoft.com/sharepoint/soap/Sli=
deLibrary/" xmlns:spsl=3D"http://microsoft.com/webservices/SharePointPortal=
Server/PublishedLinksService" xmlns:Z=3D"urn:schemas-microsoft-com:" xmlns:=
st=3D"" xmlns=3D"http://www.w3.org/TR/REC-html40;>From reading the=
 code it is not 

No subject

and actual brightness is maximum (255*2890=736950). I see no other
change after it until manual brightness change. This is a totally
reversed to your problem.

Could you help to get the LPBC value in the initial dark condition? If
it's not corresponds to 255, maybe something sneaks and changes it but
not logged.

[3.125522] [drm:is_backlight_combination_mode],
BLM_COMBINATION_MODE = 1073741824
[3.125525] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[3.125527] [drm:intel_panel_set_backlight], set backlight PWM = 736950
[3.125529] [drm:is_backlight_combination_mode],
BLM_COMBINATION_MODE = 1073741824
[3.125531] [drm:is_backlight_combination_mode],
BLM_COMBINATION_MODE = 1073741824
[3.125533] [drm:intel_panel_get_max_backlight], max backlight PWM = 736950
[3.125535] [drm:intel_panel_set_backlight], set backlight max = 736950
[3.125537] [drm:intel_panel_set_backlight], set backlight lbpc = 255
[3.125544] [drm:intel_panel_set_backlight], set backlight level = 2890

> Yes, that's the case. (Except that after closing the lid it's off again.)

Maybe this is another clue for root cause. Would it be convenient for
you to gather the log?

 1. $ dmesg -c
 2. Close the lid
 3. Open the lid
 4. $ dmesg > dmesg.lid

Thanks a lot,
Michael Chang

No subject

passing a framebuffer between two V4L2 devices and between a V4L2 device
and GPU. The V4L2 device can either be an input or an output one.
The original idea were to add yet-another-mmap-mode at the VIDIOC streaming
ioctls, and keep using QBUF/DQBUF to handle it. However, as I've pointed
there, this would leed into sync issues on a shared buffer, causing flip
effects. Also, as the API is generic, it can be used also on generic computers,
like desktops, notebooks and tablets (even on arm-based designs), and it
may end to be actually implemented as a PCI2PCI transfer.

So, based at all I've seen, I'm pretty much convinced that the normal MMAP
way of streaming (VIDIOC_[REQBUF|STREAMON|STREAMOFF|QBUF|DQBUF ioctl's)
are not the best way to share data with framebuffers. We probably need
something that it will be an enhanced version of the VIDIOC_FBUF/VIDIOC_OVERLAY
ioctls. Unfortunately, we can't just add more stuff there, as there's no
reserved space. So, we'll probably add some VIDIOC_FBUF2 series of ioctl's.

It seems to me that the proper way to develop such API is to start working
with Xorg V4L driver, changing it to work with KMS and with the new API
(probably porting some parts of the Xorg driver to kernelspace).

One of the problems with a shared framebuffer is that an overlayed V4L stream
may, at the worse case, be sent to up to 4 different GPU's and/or displays.

Imagine a scenario like:

===+===
|  |  |
|  D1 +|---+ D2   |
| | V4L|   |  |
+-|+---|--|
| ||   |  |
|  D3 ++---+ D4   |
|  |  |
===


Where D1, D2, D3 and D4 are 4 different displays, and the same V4L framebuffer 
is
partially shared between them (the above is an example of a V4L input, although
the reverse scenario of having one frame buffer divided into 4 V4L outputs
also seems to be possible).

As the same image may be divided into 4 monitors, the buffer filling should be
synced with all of them, in order to avoid flipping effects. Also, the shared
buffer can't be re-used until all displays finish reading. From what I 
understood 
from the discussions with DRI people, the display API's currently has similar 
issues
of needing to wait for a buffer to be completely used before allowing it to be
re-used. According to them, this were solved there by dynamically allocating 
buffers. 
We may need to do something similar to that also at V4L.

Btw, the need of managing buffers is currently being covered by the proposal
for new ioctl()s to support multi-sized video-buffers [1].

[1] http://www.spinics.net/lists/linux-media/msg30869.html

It makes sense to me to discuss such proposal together with the above 
discussions, 
in order to keep the API consistent.

On my understanding, the SoC people that are driving those changes will
be working on providing the API proposals for it. They should also be
providing the needed patches, open source drivers and userspace application(s) 
that allows testing and validating the GPU <==> V4L transfers using the newly 
API.

Thanks,
Mauro

No subject

which contradicts with the topic we are discussed. Regardless of the
combination_mode, the log seems to work ..  weird.

2011/5/9 Melchior FRANZ 

> * Joey Lee -- Monday 09 May 2011:
> > The following is debug patch, and please add kernel parameter
> > drm.debug=0x02 :
>
> The result is with acpi_osi=Linux:
>
>
> boot phase:
> [3.310274] [drm:intel_panel_get_backlight], get backlight val = 2890
> [3.310280] [drm:intel_panel_get_backlight], get backlight PWM = 2890
> [3.310615] [drm:intel_panel_get_backlight], get backlight val = 2890
> [3.310617] [drm:intel_panel_get_backlight], get backlight PWM = 2890
> [3.310619] [drm:intel_panel_set_backlight], set backlight PWM = 0
> [3.310622] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189401930
> [3.310624] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [3.310626] [drm:intel_panel_set_backlight], set backlight level = 0
>
> [3.641522] [drm:intel_panel_set_backlight], set backlight PWM = 2890
> [3.641525] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189399040
> [3.641527] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [3.641529] [drm:intel_panel_set_backlight], set backlight level = 2890
>
> [   11.410563] video LNXVIDEO:01: Restoring backlight state
>
>
>
> brightness up:
>   [no output]
>
>
>
> brightness down:
> [  152.697127] [drm:intel_panel_get_max_backlight], max backlight PWM =
> 2890
> [  152.697136] [drm:intel_panel_set_backlight], set backlight PWM = 283
> [  152.697141] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189401930
> [  152.697146] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [  152.697150] [drm:intel_panel_set_backlight], set backlight level = 283
>
> [  166.720631] [drm:intel_panel_get_max_backlight], max backlight PWM =
> 2890
> [  166.720640] [drm:intel_panel_set_backlight], set backlight PWM = 578
> [  166.720645] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189399323
> [  166.720649] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [  166.720654] [drm:intel_panel_set_backlight], set backlight level = 578
>
> [  178.091776] [drm:intel_panel_get_max_backlight], max backlight PWM =
> 2890
> [  178.091784] [drm:intel_panel_set_backlight], set backlight PWM = 861
> [  178.091789] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189399618
> [  178.091793] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [  178.091797] [drm:intel_panel_set_backlight], set backlight level = 861
>
> [  188.888370] [drm:intel_panel_get_max_backlight], max backlight PWM =
> 2890
> [  188.888379] [drm:intel_panel_set_backlight], set backlight PWM = 1156
> [  188.888383] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189399901
> [  188.888388] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [  188.888392] [drm:intel_panel_set_backlight], set backlight level = 1156
>
> [  196.411657] [drm:intel_panel_get_max_backlight], max backlight PWM =
> 2890
> [  196.411665] [drm:intel_panel_set_backlight], set backlight PWM = 1439
> [  196.411670] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189400196
> [  196.411674] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [  196.411678] [drm:intel_panel_set_backlight], set backlight level = 1439
>
> [  201.256229] [drm:intel_panel_get_max_backlight], max backlight PWM =
> 2890
> [  201.256238] [drm:intel_panel_set_backlight], set backlight PWM = 1734
> [  201.256243] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189400479
> [  201.256247] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [  201.256252] [drm:intel_panel_set_backlight], set backlight level = 1734
>
> [  206.939838] [drm:intel_panel_get_max_backlight], max backlight PWM =
> 2890
> [  206.939846] [drm:intel_panel_set_backlight], set backlight PWM = 2017
> [  206.939851] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189400774
> [  206.939856] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [  206.939860] [drm:intel_panel_set_backlight], set backlight level = 2017
>
> [  213.779732] [drm:intel_panel_get_max_backlight], max backlight PWM =
> 2890
> [  213.779740] [drm:intel_panel_set_backlight], set backlight PWM = 2312
> [  213.779744] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189401057
> [  213.779749] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [  213.779753] [drm:intel_panel_set_backlight], set backlight level = 2312
>
> [  222.583806] [drm:intel_panel_get_max_backlight], max backlight PWM =
> 2890
> [  222.583814] [drm:intel_panel_set_backlight], set backlight PWM = 2595
> [  222.583819] [drm:intel_panel_set_backlight], set backlight tmp(1) =
> 189401352
> [  222.583824] [drm:intel_panel_set_backlight], set backlight tmp(2) =
> 189399040
> [  222.583828] 

No subject

Linux Cg bug or Trine Linux version bug.

Windows Trine version (from humble bundle) with WINE works perfectly.

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

No subject

logout is being done with libICE. I know it is not being done with Hal,
Consolekit or the XKillClient Xlib function. I will update this bug report as
soon as I know which function causes this and have a testcase ready. If you
think it will lead to a fix I would be willing to use a pencil and paper to
write out the exact call trace in the kernel panic (which I have no way of
copying or pasting).

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

No subject

The Xorg.0.log from the previous boot is attached.

Gabriel

--BOKacYhQ+x31HxR3
Content-Type: application/x-trash
Content-Disposition: attachment; filename="Xorg.0.log.old"
Content-Transfer-Encoding: quoted-printable

=0AX.Org X Server 1.7.7=0ARelease Date: 2010-05-04=0AX Protocol Version 11,=
 Revision 0=0ABuild Operating System: Linux 2.6.26-2-powerpc64 ppc Debian=
=0ACurrent Operating System: Linux gra-vd1 2.6.38 #27 SMP Tue Apr 12 10:22:=
50 CEST 2011 ppc64=0AKernel command line: ro root=3D/dev/md0 =0ABuild Date:=
 19 February 2011  02:44:42PM=0Axorg-server 2:1.7.7-13 (Cyril Brulebois 

No subject

[KMS] Kernel modesetting enabled.

No subject

[...]
direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on AMD RV770

No subject

00 [VGA controller])
(PCI-E)

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

No subject

While screen is loading application will crash with following backtrace

~/Savage2/savage2.bin 
warning: The VAD has been replaced by a hack pending a complete rewrite
EE r600_pipe.c:343 r600_get_param - r600: unknown param 45
EE r600_pipe.c:343 r600_get_param - r600: unknown param 45
*** glibc detected *** /home/kdekorte/Savage2/savage2.bin: free(): invalid
pointer: 0x099254d0 ***
=== Backtrace: =
/lib64/libc.so.6[0x3a34476d63]
/usr/lib64/dri/r600_dri.so(+0x123ebd)[0x7f80e94c5ebd]


Using git bisect, isolated crash to the following commit

89d81ab16c05818b290ed735c1343d3abde449bf is the first bad commit
commit 89d81ab16c05818b290ed735c1343d3abde449bf
Author: Ian Romanick 
Date:   Tue Jan 25 10:41:20 2011 -0800

glsl: Calcluate Mesa state slots in front-end instead of back-end

This should be the last bit of infrastructure changes before
generating GLSL IR for assembly shaders.

This commit leaves some odd code formatting in ir_to_mesa and brw_fs.
This was done to minimize whitespace changes / reindentation in some
loops.  The following commit will restore formatting sanity.

Reviewed-by: Eric Anholt 
Reviewed-by: Chad Versace 

:04 04 cad3ca6fb2a7b45cd21397a87f940da85102fcba
34a321443a5f0d58a5c15ea9330801c59a28c1f2 Msrc

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

No subject

one seemed fine and the interface looked okay to me.

Dave.

No subject

backlight handling, and it would be sad if it wasn't fixed in 2.6.38.
But I think this is only because I have a gen 2 and the check for
combination mode for gen 2 was added in 2.6.37, everyone else already
had the buggy backlight behaviour for ages. Without the check gen 2
works correctly because the PWM value never changes, only LBPC, and
the driver didn't touch LBPC.

>> -/* i915_suspend.c */
>> -extern int i915_save_state(struct drm_device *dev);
>> -extern int i915_restore_state(struct drm_device *dev);
>> -
>
> Looks like a spurious cleanup hunk, should be a separate hunk (possibly
> along with other save/restore state cleanups, like removing all the
> ILK+ code that probably won't work well :).

Wild guess: ILK+ means Ironlake+?

But indeed, though as the duplicate declaration is in the diff context
it seemed safe enough at the time. ;-)

>> -void intel_panel_setup_backlight(struct drm_device *dev)
>> -{
>> -struct drm_i915_private *dev_priv = dev->dev_private;
>> -
>> -dev_priv->backlight_level = intel_panel_get_backlight(dev);
>> -dev_priv->backlight_enabled = dev_priv->backlight_level != 0;
>>  }
>
> This is getting pretty messy.

That functions was added in the 2.6.38 cycle I think, in an attempt
to fix the backlight problems.

>  Your patch is a step in the right
> direction, but I think we may as well go further:
>   - suspend/resume of backlight state belongs in the backlight class
> driver

There is no backlight suspend/resume handling, the panel just gets
enabled at resume. The registers save/restore is done i915_suspend.c,
where it belongs. The current bugginess is not only for suspend, but
for any two DPMS on calls without a disable in between. Try

xset dpms force off
xset dpms force on
..change brightness..
xset dpms force on

I think you'll get the old brightness.

>   - that driver should call into the registered i915 backlight handler
> if i915 is controlling it natively (PWM native, combo, legacy)

Brightness setting is only needed for ASLE, otherwise it's never set
by the driver. So in the end most complexity is only there because of
one combination: ASLE + legacy combination mode.

>   - we need a backlight driver struct with function pointers for the
> various calls, so we can split out the PCH functions from the rest;
> might be good to separate native, combo, and legacy that way as
> well; even if results in some code duplication it might make each
> easier to read and less likely to break others when we make changes

Problem is, are we sure that systems don't change from legacy combination
mode to BLC_PWM_CTL only? Otherwise you have to check every time.

I must admit I'm not sure what the backlight hierarchy is, but I don't
think the intel_panel.c code has much to do with it: It has nothing to
do with backlight key events and doesn't handle them. All it does is
enabling or disabling the panel for DPMS. The only thing that needs to
set the backlight is intel_opregion.c when ASLE is used, and that bit
should indeed go somewhere else.

So if I'd clean up the code, I think this is what I would try first:

Rip out all brightness control out of intel_panel.c and replace it
with a generic, minimal register saving for disabling the panel, with
all system specific info (which registers to use, masks, etc.) stored
in struct intel_device_info.

All the extra complexity comes from ASLE. As you wrote the Intel ASLE
documentation, I hope you can give some more information about it:

1) First, are there any gen 2 or gen 3 systems with ASLE? If not, there
is no need to handle legacy combination mode for those gens. I think
ASLE came with gen 4, but can you confirm that? Either the gen 2 check
for legacy mode is not needed, or a gen 3 check needs to be added.

2) What happens if the driver doesn't support ASLE? If the BIOS changes
the brightness directly, then we can rip out the whole ASLE thing, as
it's useless. This is probably not possible, so we have to keep the
ASLE madness.

If ASLE needs to set the brightness then we need a way to do that.
But I'd change the interface to a percentage or 0-255 scale, that
fits better with the ASLE thing and the max brightness is hidden.

(I dislike ASLE because it's clear the BIOS knows how to do what it
wants, but bothers the driver with it, which has to do it the same
way as the BIOS, or things stop working.)

And instead of all those almost duplicate functions I'd have one
generic one that works for all, with system specific stuff put in
struct intel_device_info.

i915_read_blc_pwm_ctl() can be greatly simplified by calling
i915_save_state() early and often enough. I don't think you want crash
recovery scattered around the code like that, but done centrally so it's
easier to recover from a hardware crash. I guess saving state just after
driver initialisation and after every modeset is close to enough, but I
have no idea about 3D. My hope is that after a GPU hang, the system can
be restored by resetting the GPU and 

No subject

Iwai 
Date: Mon, 21 Feb 2011 14:19:27 +0100
Subject: [PATCH] drm/i915: Fix calculation of backlight value in combined mode

The commit a95735569312f2ab0c80425e2cd1e5cb0b4e1870
drm/i915: Refactor panel backlight controls
causes a regression for GM45 that is using the combined mode for
controlling the backlight brightness.  The commit introduced a wrong bit shift 
for
computing the current backlight level.

Bugzilla: https://bugzilla.novell.com/show_bug.cgi?id=672946
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=34524

Signed-off-by: Takashi Iwai 
Cc: 
---
 drivers/gpu/drm/i915/intel_panel.c |1 -
 1 file changed, 1 deletion(-)

--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -176,7 +176,6 @@
val &= ~1;
pci_read_config_byte(dev->pdev, PCI_LBPC, );
val *= lbpc;
-   val >>= 1;
}
}

No subject

When I load the fglrx ati proprietary driver (11.1) for the 5450 card, then=
 I
get throughputs of about 2GB/s in both directions.=20

Running the same test in same environment on the HD5970=20
with the gallium drivers and kernel mode setting and pcie_gen2 activation, i
get about the same figures as above.
With fglrx for 5970, then 5970 only performs well in CPU->GPU with about 2G=
B/s
and only 0.5GB/s in GPU->CPU direction=20

I have included the test and configuration output for both cases (fglrx and
radeon) and also code for the testprogram might you want to reproduce this
case.

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

No subject

is the 8GB->24GB, but it still has 4GB->8GB free - so it can launch one more
guest (but without PCI passthrough devices).

> On a 4GB machine or less, that would be the same as kernel memory.
> Now, if 4 guests think they can allocate 2GB of coherent memory
> each, you might run out of kernel memory on the host?

So host in this case refers to the Hypervisor and it does not care
about the DMA or what - it does not have any device drivers(*) or such.
The first guest (dom0) is the one that deals with the device drivers.

*: It has one: the serial port, but that is not really that important
for this discussion.
> 
> 
> Another thing that I was thinking of is what happens if you have a
> huge gart and allocate a lot of coherent memory. Could that
> potentially exhaust IOMMU resources?



So the GART is in the PCI space in one of the BARs of the device right?
(We are talking about the discrete card GART, not the poor man AMD IOMMU?)
The PCI space is under the 4GB, so it would be considered coherent by
definition.

However the PCI space with its BARs eats in the 4GB space, so if you
have a 1GB region from 0xC->0x10, then you only have 3GB
left of DMA32 zone.

If I think of this as an accounting, and if the PCI space goes further
down (say 0x4, so from 2GB->4GB it is a E820 gap, and 0GB->2GB is System RAM
with 4GB->6GB being the other System RAM, for a cumulative number of 4GB
of memory in the machine), we would only have 2GB of DMA32 zone (The GFP_KERNEL
zone is 4GB, while GFP_DMA32 zone is 2GB).

Then the answer is yes. However, wouldn't such device be 64-bit? And
if they are 64-bit, then the TTM API wouldn't bother to allocate pages
from the 32-bit region, right?

> 
> >>/Thomas
> >>
> >>*) I think gem's flink still is vulnerable to this, though, so it
> >Is there a good test-case for this?
> 
> 
> Not put in code. What you can do (for example in an openGL app) is
> to write some code that tries to flink with a guessed bo name until
> it succeeds. Then repeatedly from within the app, try to flink the
> same name until something crashes. I don't think the linux OOM
> killer can handle that situation. Should be fairly easy to put
> together.

Uhhh, OK, you just flew over what I know about graphics. Let me
research this a bit more.

> 
> /Thomas

No subject

for this, it can also go to /dev/nirvana.

The version related informations for drm-core seems also not to be
lovely maintained.
How long do we see 1.1.0 as version? For ages?

Did you know about interface-version?
You found the places for DRM_IF_*?
No, this is not a riddle or quiz-show, just have a look into
.
The IF-version (currently: v1.4) is in 
and you will find there comments which "document" it, see
drm_setversion():
...
/*
 * Version 1.1 includes tying of DRM to specific de=
vice
 * Version 1.4 has proper PCI domain support
 */
...

Why the hell aren't those version mumbo-jumbos "well" documented?
By "well" I mean not deeply hided in the source-code.
I remember this version mumbo-jumbo should be in the first lines of
the driver's c-file, maintained as a history of changes.

And for the god's sake if you use hardcoded date-strings - Europeans
like me still get confused by 01/11/2010 (is it 01-Nov-2010 or
11-Jan-2010?) - why don't you use a clear 10-Oct-2010 (here:
drm-vblank-timestamping):

$ dmesg | grep vblank
[   10.359312] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[   10.359349] [drm] Driver supports precise vblank timestamp query.

Also for drm-vblank-timestamping:
Is your Rev and date still valid, where is it documented? Source-code?

In general, do you see drm-related docs in Documentation directory of
the linux-kernel (see [3] for linux-next)?
Why?

Did you had a look at the author's names in the diverse header and
c-files in the kernel-drm tree?
Maintained or not maintained, this is here the question :-)?

It is a logical and correct consequence to remove such version crap if
it is not 1. properly documented or 2. well maintained.
As an example see linux-wireless mailing-list and the removal of
module-version of ath5k-driver (see [5],[6]).

When you want to throw off the date-related stuff completely from the
whole(!) kernel-drm tree, you have to do appropriate removals in
libdrm.

The only argument I can understand is a breakage of the drm ABI.
Anyway, the world won't stop turning by these changes.
Now, there is a reason to bump the core-version with driver-date and
core-date removal :-)?

diff --git a/include/drm/drm_core.h b/include/drm/drm_core.h
index 1485f3f..d54449e 100644
--- a/include/drm/drm_core.h
+++ b/include/drm/drm_core.h
@@ -29,5 +29,5 @@
 #define DRM_IF_MINOR   4

 #define CORE_MAJOR 1
-#define CORE_MINOR 1
+#define CORE_MINOR 2
 #define CORE_PATCHLEVEL 0

Aaargh, where shall I document this core-version bump?
In the git commit? As usual: Documentation is seen as a punishment for code=
rs?

Dear developers, if you don't maintain your drivers with version *and
date*, then please kill the latter.

Last but not least:
Is there an official recommendation (written down docs) about how to
maintain driver documentation?
An excellent example of a driver or even for a sub-tree of the kernel.
Thanks in advance.

With this email I want to call the attention of the drm developers to
my removal request.
As you know the kernel got rid also of the firmware stuff (it took some tim=
e).

Speaking as an end-user, I did all efforts to change the circumstance
by pointing to the problem in IRC and MLs.
"Laziness" is not an argument to me.
RIP driver-date and core-date (I won't drop a tear for you).

Regards,
- Sedat -

[1] http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg00117.ht=
ml
[2] http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg00121.ht=
ml
[3] http://www.mail-archive.com/dri-devel at lists.freedesktop.org/msg00125.ht=
ml
[4] http://git.kernel.org/?p=3Dlinux/kernel/git/next/linux-next.git;a=3Dtre=
e;f=3DDocumentation
[5] http://marc.info/?t=3D12913495091=3D1=3D4
[6] http://git.kernel.org/?p=3Dlinux/kernel/git/next/linux-next.git;a=3Dcom=
mit;h=3Db7555ec7c604f2f00e432579dac29df5ce525433

--000e0ce0da0ac962cb0498f70fd5
Content-Type: text/x-diff; charset=US-ASCII; 
name="0001-drm-Remove-DRIVER_DATE-from-drm-drivers.patch"
Content-Disposition: attachment; 
filename="0001-drm-Remove-DRIVER_DATE-from-drm-drivers.patch"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_gihrfcfe0

RnJvbSAxOGI3ZjQ5ZjdjNjZjYzRiZTQ3NTU0ZDNhOGJkNjRiY2E4NmE1ZTRjIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBTZWRhdCBEaWxlayA8c2VkYXQuZGlsZWtAZ21haWwuY29tPgpE
YXRlOiBTdW4sIDIgSmFuIDIwMTEgMDA6MTg6NTcgKzAxMDAKU3ViamVjdDogW1BBVENIIDEvNF0g
ZHJtOiBSZW1vdmUgRFJJVkVSX0RBVEUgZnJvbSBkcm0gZHJpdmVycwoKU2lnbmVkLW9mZi1ieTog
U2VkYXQgRGlsZWsgPHNlZGF0LmRpbGVrQGdtYWlsLmNvbT4KLS0tCiBkcml2ZXJzL2dwdS9kcm0v
ZHJtX2Rydi5jICAgICAgICAgICAgIHwgICAgMSAtCiBkcml2ZXJzL2dwdS9kcm0vaTgxMC9pODEw
X2Rydi5jICAgICAgIHwgICAgMSAtCiBkcml2ZXJzL2dwdS9kcm0vaTgxMC9pODEwX2Rydi5oICAg
ICAgIHwgICAgMSAtCiBkcml2ZXJzL2dwdS9kcm0vaTgzMC9pODMwX2Rydi5jICAgICAgIHwgICAg
MSAtCiBkcml2ZXJzL2dwdS9kcm0vaTgzMC9pODMwX2Rydi5oICAgICAgIHwgICAgMSAtCiBkcml2

No subject

attached setup.log), which I partly cherry-picked [1] or refreshed
against linux-next (next-20101217).
They worked also with yesterdays next-20101221.
I have attached a follow-up/fix-up patch for one of Daniel's patchsets.
(See below 
"danvet-drm-for-sedat-dilek-v2/0006-drm-nouveau-don-t-munge-in-drm_mm-internals-follow-u.patch")
All 3 patchsets tested with radeon RV250.

Also, I am highly interested in the backlight-type patches [4] (see
below P.S. and attached setup.log).
I have also refreshed them against linux-next (apply against
next-20101221), but tested with radeon-only.
These patches has still not entered platform-driver-x86/for-next.

I would like to see all 4 patchsets in linux-next (namely 2.6.38).
(I am using these patchsets for several weeks, I regularly check with
openarena and in a rough daily-work. YES, I am using the kernels I
built.).

What shall I do to help?
Where to send the refreshed patches?
Some patches from Daniel are complained by scripts/checkpatch.pl (IIRC
80 lines wrapping, etc.).
Approx before 14 days Dave OKed Daniels patchsets on an IRC conversation.

Kind Regards,
- Sedat -

[1] http://cgit.freedesktop.org/~danvet/drm/log/?h=for-sedat-dilek
[2] http://lists.freedesktop.org/archives/dri-devel/2010-November/005847.html
[3] http://lists.freedesktop.org/archives/dri-devel/2010-November/005859.html
[4] http://lists.freedesktop.org/archives/dri-devel/2010-November/005605.html

P.S.:

$ cd $HOME/src/linux-2.6/linux-2.6.37-rc6/debian/patches

$ cat series/2~next20101217.dileks.2
### FROM-DANVET #1
# Patches from 
# v2: 0001..0005 cherry-picked and 0006 is a follow-up patch to 0001
+ 
danvet-drm-for-sedat-dilek-v2/0001-drm-nouveau-don-t-munge-in-drm_mm-internals.patch
+ danvet-drm-for-sedat-dilek-v2/0002-drm-mm-track-free-areas-implicitly.patch
+ 
danvet-drm-for-sedat-dilek-v2/0003-drm-mm-extract-node-insert-helper-functions.patch
+ 
danvet-drm-for-sedat-dilek-v2/0004-drm-mm-add-api-for-embedding-struct-drm_mm_node.patch
+ 
danvet-drm-for-sedat-dilek-v2/0005-drm-mm-add-helper-to-unwind-scan-state.patch
+ 
danvet-drm-for-sedat-dilek-v2/0006-drm-nouveau-don-t-munge-in-drm_mm-internals-follow-u.patch

### FROM-DANVET #2
# Patches from 
# For more Details see

+ 
danvet-embed-drm_gem_object-into-radeon_bo/1-3-drm-radeon-embed-struct-drm_gem_object-v2.patch
+ 
danvet-embed-drm_gem_object-into-radeon_bo/2-3-drm-radeon-introduce-gem_to_radeon_bo-helper.patch
+ 
danvet-embed-drm_gem_object-into-radeon_bo/3-3-drm-radeon-kill-radeon_bo--gobj-pointer.patch

### FROM-DANVET #3
# Patches from 
# For more Details see

+ 
danvet-radeon-asic-header-cleanup-2/1-7-radeon-consolidate-asic-specific-function-decls-for-pre-r600.patch
+ 
danvet-radeon-asic-header-cleanup-2/2-7-radeon-consolidate-asic-specific-function-decls-for-r600-later.patch
+ 
danvet-radeon-asic-header-cleanup-2/3-7-radeon-drop-extern-from-function-decls.patch
+ 
danvet-radeon-asic-header-cleanup-2/4-7-radeon-kill-decls-for-inline-functions.patch
+ 
danvet-radeon-asic-header-cleanup-2/5-7-radeon-move-blit-functions-to-radeon_asic.h.patch
+ danvet-radeon-asic-header-cleanup-2/6-7-radeon-kill-r100_io_-r-w-reg.patch
+ danvet-radeon-asic-header-cleanup-2/7-7-radeon-kill-rdev--pciep_-r-w-reg.patch

### DRM-RADEON-KMS-WRITEBACK
+ 
drm-radeon-kms-writeback/drm-radeon-kms-enable-writeback-on-radeon-AGP-boards.patch

### BACKLIGHT-TYPE
# Patches from 
# For more Details see

+ backlight-type/1-5-Backlight-Add-backlight-type-v2.patch
+ backlight-type/2-5-i915-Add-native-backlight-control-v2.patch
+ 
backlight-type/3-5-radeon-Expose-backlight-class-device-for-legacy-LVDS-encoder.patch
+ 
backlight-type/4-5-nouveau-Change-the-backlight-parent-device-to-the-connector-not-the-PCI-dev-v2.patch
+ 
backlight-type/5-5-ACPI-Tie-ACPI-backlight-devices-to-PCI-devices-if-possible.patch

- EOT -

--0016364ef320c4c2860497f8bab4
Content-Type: text/x-log; charset=US-ASCII; 
name="setup_linux-next_next20101221.dileks.2.log"
Content-Disposition: attachment; 
filename="setup_linux-next_next20101221.dileks.2.log"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_ghzr3s2v0

bWFrZSAtZiBkZWJpYW4vcnVsZXMucmVhbCBzZXR1cC1mbGF2b3VyIEFCSU5BTUU9JycgQVJDSD0n
aTM4NicgQ09NUElMRVI9J2djYy00LjUnIEZFQVRVUkVTRVQ9J25vbmUnIEZMQVZPVVI9JzY4Nicg
SU5JVFJEX0NNRD0ndXBkYXRlLWluaXRyYW1mcycgS0NPTkZJRz0nZGViaWFuL2NvbmZpZy9jb25m
aWcgZGViaWFuL2NvbmZpZy9rZXJuZWxhcmNoLXg4Ni9jb25maWcgZGViaWFuL2NvbmZpZy9rZXJu
ZWxhcmNoLXg4Ni9jb25maWctYXJjaC0zMiBkZWJpYW4vY29uZmlnL2kzODYvbm9uZS9jb25maWcu

No subject

would allow easy abuse of the GPU to access any system ram. There is a
reason we do expensive command checking in the other amd gpu driver
(drivers/gpu/drm/radeon/*cs.c files)

Cheers,
Jerome

No subject

mapping object in drm file and iirc we will report error if we can't
find a mapping for userspace object). I guess at one point we should
start thinking about what we want to do on that front.

Doing a v3.

Cheers,
Jerome

No subject

[Dave Airlie]

Hi Linus,

sorry this is a bit later than I expected got sidetracked into a real-life 
gastro bug for a couple of days just after merge window opened,

Main features amongst it all:
new stub driver for poulsbo backlight support
drm core: kdb lut support, lots of cleanups, edid enhancement for audio 
capability
ttm: optimised eviction process (saves a lot of unnecessary object 
movement) + allow an alternate underlying memory manager to be plugged in
vmware: bring in line with upstream changes + use alternate memory manager
nouveau: iniital power management support, hardware inter-channel sync,
better handling of gpu errors and non-mappable VRAM, tiling corruption 
fixes, nvaf support
radeon: new fences on r6xx+, spread spectrum improvements on r5xx+ (DP 
support and LVDS fixes), evergreen blit support, ppl fixes, lots of tiling 
fixes
intel: rework of AGP/DRM driver interfaces to be a lot cleaner, support 
for using the whole GTT range instead of just the CPU mappable region
lots of eDP fixes, unload fixes, DP audio support, also a lot of output 
from the Chris Wilson bugfixing machine.

Dave.

The following changes since commit 2b666ca4a68cbc22483b0f2e1ba3c0e59b01ae9e:

  Merge branch 'fix/misc' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6 (2010-10-17 
09:38:08 -0700)

are available in the git repository at:

  ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git 
drm-core-next

Alex Deucher (18):
  drm/radeon/kms: clean up r6xx/r7xx blit init (v2)
  drm/radeon/kms: enable writeback (v2)
  drm/radeon/kms/r6xx+: use new style fencing (v3)
  drm/radeon/kms: properly handle 40 bit MC addresses in the cursor code
  drm/radeon/kms: prefer high post dividers in legacy pll algo
  drm/radeon/kms: remove some pll algo flags
  drm/radeon/kms: remove new pll algo
  drm/radeon/kms: rework spread spectrum handling
  drm/radeon/kms: add drm blit support for evergreen
  drm/radeon/kms: make sure blit addr masks are 64 bit
  drm/radeon/kms: avivo cursor workaround applies to evergreen as well
  drm/radeon/kms/evergreen: add some additional safe regs v2
  drm/radeon/kms: implement display watermark support for evergreen
  drm/radeon/kms: MC vram map needs to be >= pci aperture size
  drm/radeon/kms/evergreen: set the clear state to the blit state
  drm/radeon/kms: fix 2D tile height alignment in the r600 CS checker
  drm/radeon/kms: properly compute group_size on 6xx/7xx
  drm/radeon/kms: fix r6xx/7xx 1D tiling CS checker v2

Andrea Gelmini (1):
  drivers: gpu: drm: i915: Fix a typo.

Ben Skeggs (56):
  drm/nv50: add new accelerated bo move funtion
  drm/nouveau: move check for no-op bo move before memcpy fallback
  drm/nouveau: remove second map of notifier bo
  drm/nouveau: require explicit unmap of kmapped bos
  drm/nouveau: have nv_mask return original register value
  drm/nouveau: move ramht code out of nouveau_object.c, nothing to see here
  drm/nouveau: modify object accessors, offset in bytes rather than dwords
  drm/nouveau: rebase per-channel pramin heap offsets to 0
  drm/nouveau: remove nouveau_gpuobj_ref completely, replace with sanity
  drm/nouveau: simplify fake gpu objects
  drm/nv50: allow gpuobjs that aren't mapped into aperture
  drm/nv50: calculate vram reordering block size
  drm/nouveau: rework init ordering so nv50_instmem.c can be less bad
  drm/nouveau: tidy ram{ht,fc,ro} a bit
  drm/nouveau: add spinlock around ramht modifications
  drm/nouveau: fix gpuobj refcount to use atomics
  drm/nouveau: protect gpuobj list + global instmem heap with spinlock
  drm/nouveau: remove nouveau_gpuobj_late_takedown
  drm/nouveau: protect ramht_find() from oopsing if on channel without ramht
  drm/nv50: move vm trap to nv50_fb.c
  drm/nv50: report BAR access faults
  drm/nv50: fix SOR count for early chipsets
  drm/nouveau: better handling of unmappable vram
  drm/nouveau: handle fifo pusher errors better
  drm/nouveau: we can't free ACPI EDID, so make a copy that we can
  drm/nv50: mark PCIEGART pages non-present rather than using dummy page
  drm/nouveau: zero dummy page
  drm/nv50: fix 100c90 write on nva3
  drm/nouveau: make the behaviour of get_pll_limits() consistent
  drm/nouveau: make bios code easier to use externally
  drm/nouveau: import initial work on vbios performance table parsing
  drm/nv50: import initial clock get/set routines + hook up pm engine
  drm/nv04-nv40: import initial pm backend
  drm/nouveau: allow static performance level setting
  drm/nouveau: restore perflvl on resume, and restore boot perflvl on unload
  drm/nouveau: fix potential accuracy loss when parsing perf 0x1c tables
  drm/nouveau: implement parsing of DCB 2.2 GPIO table
  drm/nouveau: fix thinko in volt 0x1x parsing
  drm/nv50: flush bar1 vm / dma object 

No subject

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

No subject

DIN: S-video?

Clearly your working monitor (DVI) is on output DVI-0.

What is the actual card you have? (manufacturer, model)
List all of the connectors that it actually (physically) has.

I can think of a few possibilities:
1) That the DVI and HDMI plugs are wired into the same place,
2) That the HDMI plug is on the DP (or you are actually using a DP-HDMI cable)
and you suffer from a similar defect as my mainboard:
http://www.phoronix.com/forums/showthread.php?t=24480

If you have BOTH an HDMI plug as well as a DP plug on your card, then I would
guess option 1 and you will need to pick up a passive DP-HDMI adapter cable to
use the second monitor. If there IS NO DP plug, then I would guess option (2),
in which case you'll have to hack the kernel to make it work or beg someone to
add a workaround for this defect.

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

No subject

test different graphical settings yet.

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

No subject

bugs  13/15


fdo20701  fail

Returncode: 1

Errors:
Mesa: Mesa 7.9-devel DEBUG build Sep 11 2010 06:16:40


Output:
init:104: framebuffer status = 0x8cdd
--

then

fdo25614-genmipmap  fail

---
Returncode: 1

Errors:
Mesa: Mesa 7.9-devel DEBUG build Sep 11 2010 06:16:40


Output:
Probe at (0,0)
  Expected: 0.00 1.00 0.00 1.00
  Observed: 0.501961 0.501961 0.501961 0.501961
Probe at (0,0)
  Expected: 0.00 1.00 0.00 1.00
  Observed: 0.00 0.00 0.00 0.00
Probe at (0,0)
  Expected: 0.00 1.00 0.00 1.00
  Observed: 0.00 0.00 0.00 0.00
Probe at (0,0)
  Expected: 0.00 1.00 0.00 1.00
  Observed: 0.00 0.00 0.00 0.00
Probe at (0,0)
  Expected: 0.00 1.00 0.00 1.00
  Observed: 0.00 0.00 0.00 0.00

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

No subject

(E17 init)
  E17 INIT: XINERAMA CHOSEN: [1], 1080x1920+1280+0
  E17 INIT: XINERAMA CHOSEN: [0], 1280x1024+0+896
(output blinking starts)
  E17 INIT: XINERAMA SCREEN: [0], 1280x1024+0+0
  E17 INIT: XINERAMA CHOSEN: [153045780], 0x153045764+0+153046580
(e17 crash, try to recover)
  E17 INIT: XINERAMA CHOSEN: [1], 1920x1080+1280+0
  E17 INIT: XINERAMA CHOSEN: [0], 1280x1024+0+0
(rotation lost on [1], position lost on [0])
  E17 INIT: XINERAMA CHOSEN: [1], 1080x1920+1280+0
  E17 INIT: XINERAMA CHOSEN: [141138596], 0x141138580+0+141139396
  E17 INIT: XINERAMA CHOSEN: [0], 1280x1024+0+896
(restoring rotation confuses E17)
  ###!!! ABORT: X_CreatePixmap: BadAlloc (insufficient resources for
operation);
 6 requests ago: file nsX11ErrorHandler.cpp, line 182
  UNKNOWN [/usr/lib/xulrunner-1.9.2/libxul.so +0x001CA781]
(firefox crashing)

Now, the reason for the E17 crash looks like a use-after-free bug. Question is:
who is freeing the Xinerama structures, and why are they freed at all? I never
had these problems before, and when using stock 2.6.32 (from Debian) I don't
have these problems either, so I'm ruling out hardware failure.


I can see the following lines logged by the kernel (KMS enabled on radeon
9550):
  [12045.280155] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID
  [13500.386132] [drm:radeon_vga_detect] *ERROR* VGA-1: probed a monitor but
no|invalid EDID
  [13797.568760] [drm:radeon_dvi_detect] *ERROR* DVI-I-1: probed a monitor but
no|invalid EDID
And I believe these are harmless (and reported in #27708). I can see these
messages being reported for as long my kernel logs go back. But when the
crashes occur, they are followed by these lines:
  [35753.097508] i2c i2c-1: sendbytes: NAK bailout.
  [35762.752866] i2c i2c-1: sendbytes: NAK bailout.
  [35772.912023] i2c i2c-1: readbytes: ack/nak timeout
Which I believe are not so harmless. Or they could be a red herring, I'm not
qualified to tell.

Since the same time, I've been seeing a lot of lines logged by g-s-d, like
  gdk_pixbuf_format_get_name: assertion `format != NULL' failed
But I do not believe these are relevant.

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

No subject

shouldn't be firing at all under normal circumstances. (Looking at it we
don't handle the introduction of the BSD ring correctly, but that is
irrelevant on the EeePC 900.)

Do the stalls and tearing go away with:

diff --git a/drivers/gpu/drm/i915/i915_irq.c
b/drivers/gpu/drm/i915/i915_irq.c
index e4d42a7..dc5fb4f 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1305,8 +1305,7 @@ void i915_hangcheck_elapsed(unsigned long data)
dev_priv->hangcheck_count = 0;

/* Issue a wake-up to catch stuck h/w. */
-   if (dev_priv->render_ring.waiting_gem_seqno |
-   dev_priv->bsd_ring.waiting_gem_seqno) {
+   if (0) {
DRM_ERROR("Hangcheck timer elapsed... GPU idle, missed 
IRQ.\n");
if (dev_priv->render_ring.waiting_gem_seqno)
DRM_WAKEUP(_priv->render_ring.irq_queue);

-- 
Chris Wilson, Intel Open Source Technology Centre

No subject

[Tejun Heo]

Commit 991ea75c (drm: use workqueue instead of slow-work), which made
drm to use wq instead of slow-work, didn't account for the return
value difference between delayed_slow_work_enqueue() and
queue_delayed_work().  The former returns 0 on success and -errno on
failures while the latter never fails and only uses the return value
to indicate whether the work was already pending or not.

This misconversion triggered spurious error messages.  Remove the now
unnecessary return value check and error message.

Markus: caught another incorrect conversion in drm_kms_helper_poll_enable()

Signed-off-by: Tejun Heo 
Reported-by: Markus Trippelsdorf 
Tested-by: Markus Trippelsdorf 
Cc: David Airlie 
Cc: dri-devel at lists.freedesktop.org
---
Oops, you're right.  So, this should do it.

Thank you.

 drivers/gpu/drm/drm_crtc_helper.c |   16 
 1 files changed, 4 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/drm_crtc_helper.c 
b/drivers/gpu/drm/drm_crtc_helper.c
index 4598130..b9e4dbf 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -839,7 +839,6 @@ static void output_poll_execute(struct work_struct *work)
struct drm_connector *connector;
enum drm_connector_status old_status, status;
bool repoll = false, changed = false;
-   int ret;

mutex_lock(>mode_config.mutex);
list_for_each_entry(connector, >mode_config.connector_list, head) {
@@ -874,11 +873,8 @@ static void output_poll_execute(struct work_struct *work)
dev->mode_config.funcs->output_poll_changed(dev);
}

-   if (repoll) {
-   ret = queue_delayed_work(system_nrt_wq, delayed_work, 
DRM_OUTPUT_POLL_PERIOD);
-   if (ret)
-   DRM_ERROR("delayed enqueue failed %d\n", ret);
-   }
+   if (repoll)
+   queue_delayed_work(system_nrt_wq, delayed_work, 
DRM_OUTPUT_POLL_PERIOD);
 }

 void drm_kms_helper_poll_disable(struct drm_device *dev)
@@ -893,18 +889,14 @@ void drm_kms_helper_poll_enable(struct drm_device *dev)
 {
bool poll = false;
struct drm_connector *connector;
-   int ret;

list_for_each_entry(connector, >mode_config.connector_list, head) {
if (connector->polled)
poll = true;
}

-   if (poll) {
-   ret = queue_delayed_work(system_nrt_wq, 
>mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
-   if (ret)
-   DRM_ERROR("delayed enqueue failed %d\n", ret);
-   }
+   if (poll)
+   queue_delayed_work(system_nrt_wq, 
>mode_config.output_poll_work, DRM_OUTPUT_POLL_PERIOD);
 }
 EXPORT_SYMBOL(drm_kms_helper_poll_enable);

-- 
1.7.1

No subject

start of the GPU reset, which is the last callsite to unlock cp.mutex,
ie radeon_gpu_reset->radeon_resume->rv770_resume->rv770=
_startup->r600_cp_resume->radeon_ring_test->r600_ring_test->radeon_ring_unl=
ock_commit>
before the hang at
radeon_gpu_reset->->drm_helper_resume_force_mode->drm_c=
rtc_helper_set_mode->mode_fixup->atombios_crtc_mode_fixup->radeon_pm_comput=
e_clocks->radeon_pm_set_clocks>.

Looking through all the calls between these two spots, I just can't
see anything that _could_ have locked cp.mutex, unless I'm misreading
the disassembly of mutex_lock.

Any thoughts?

Dan
--=20
Daniel J Blueman

No subject

radeontool patched with attachement 34810

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

No subject

df16dd53c575d0cb9dbee20a3149927c862a9ff6  hwmon: (ltc4245) Read only one GPIO
pin

and *sometime* before this commit:

09bdf591f4724c7d0328d4d7b8808492addb5a28  drm/radeon/kms: fix dpms state on
resume

Alex, I am pretty much a 'newb' when it comes to git and the kernel in general
and currently git is making my brain hurt severely. When I have the time I will
read up more on git and try and work out an easy way to exclude unrelated
commits that break my kernel and include bug fix commits that allow me to
bisect this issue successfully. Any pointers to articles/howtos on dealing with
this specific kind of issue with git?

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

No subject

/* A typical clean-up sequence for objects stored in an idr tree, will
 * use idr_for_each() to free all objects, if necessary, then
 * idr_remove_all() to remove all ids, and idr_destroy() to free
 * up the cached idr_layers.
 */

We were missing the vital idr_rmove_all() step and so were leaking
the used layers for every dri client:

unreferenced object 0xf32133c0 (size 148):
  comm "plymouthd", pid 131, jiffies 4294678490 (age 2308.030s)
  hex dump (first 32 bytes):
04 00 00 00 00 00 00 00 00 00 00 00 00 40 19 f3  . at ..
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  
  backtrace:
[] create_object+0x124/0x1f1
[] kmemleak_alloc+0x4c/0x90
[] kmem_cache_alloc+0xee/0x13c
[] idr_pre_get+0x24/0x61
[] drm_gem_handle_create+0x27/0x7f [drm]
[] i915_gem_create_ioctl+0x4f/0x71 [i915]
[] drm_ioctl+0x272/0x356 [drm]
[] vfs_ioctl+0x33/0x91
[] do_vfs_ioctl+0x46b/0x496
[] sys_ioctl+0x46/0x66
[] sysenter_do_call+0x12/0x38
[] 0x

Fixes https://bugzilla.kernel.org/show_bug.cgi?id=15803

Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/drm_drv.c |1 +
 drivers/gpu/drm/drm_gem.c |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 4a66201..79b73cb 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -362,6 +362,7 @@ static void __exit drm_core_exit(void)

unregister_chrdev(DRM_MAJOR, "drm");

+   idr_remove_all(_minors_idr);
idr_destroy(_minors_idr);
 }

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 830cb97..58bd0f7 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -419,6 +419,7 @@ drm_gem_release(struct drm_device *dev, struct drm_file 
*file_private)
idr_for_each(_private->object_idr,
 _gem_object_release_handle, NULL);

+   idr_remove_all(_private->object_idr);
idr_destroy(_private->object_idr);
 }

-- 
1.7.1

No subject

crappy monitors are still crappy.  The hw i2c engines are mostly there
to reduce CPU usage and allow i2c transactions to be interrupt driven.

Alex

No subject

than hw can handle, but it seems to use only a small portion of the buffer.
I've changed the code so that it does not abort"
Since the game was working fine with this hardware in Windows (and my RV530 is
well above minimum requirements) I suspected this to be a Wine issue and I
asked at their forums, sadly with little response. Finally soreau at #radeon
said this in theory can be fixed in driver and advised to open a bug here.

This issue is not only affecting SoaSE, I also saw this message in wine d3d9
test run and when I was experimenting with other games like for example
Starcraft 2.

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

No subject

itdiff;h=3Df892034a8ce80ed7098f667aae2eb6300e570603
is part of vanilla 2.6.35-rc4 and -rc5, but neither kernel works for
me.

> Does this patch help?
(0001-drm-radeon-kms-fix-possible-mis-detection-of-sidepor.patch)

After adding this to 2.6.35-rc5 the system boots and works so far.

But the CP is still broken:
[0.426931] Linux agpgart interface v0.103
[0.427092] [drm] Initialized drm 1.1.0 20060810
[0.427196] [drm] radeon defaulting to kernel modesetting.
[0.427255] [drm] radeon kernel modesetting enabled.
[0.427372] radeon :01:05.0: PCI INT A -> GSI 18 (level, low) -> IRQ=
 18
[0.429659] [drm] initializing kernel modesetting (RS690 0x1002:0x791E).
[0.429817] [drm] register mmio base: 0xFE9F
[0.429876] [drm] register mmio size: 65536
[0.430457] ATOM BIOS: ATI
[0.430532] radeon :01:05.0: VRAM: 32M 0xDE00 - 0xDFFF (32M =
used)
[0.430592] radeon :01:05.0: GTT: 512M 0xBE00 - 0xDDFF
[0.430675] [drm] radeon: irq initialized.
[0.430737] mtrr: type mismatch for fc00,200 old:
write-back new: write-comb
ining
[0.430811] [drm] Detected VRAM RAM=3D32M, BAR=3D32M
[0.430868] [drm] RAM width 128bits DDR
[0.431011] [TTM] Zone  kernel: Available graphics memory: 2010234 kiB.
[0.431070] [TTM] Initializing pool allocator.
[0.431147] [drm] radeon: 32M of VRAM memory ready
[0.431205] [drm] radeon: 512M of GTT memory ready.
[0.431266] [drm] GART: num cpu pages 131072, num gpu pages 131072
[0.434654] [drm] radeon: 1 quad pipes, 1 z pipes initialized.
[0.441719] [drm] Loading RS690/RS740 Microcode
[0.441926] [drm] radeon: ring at 0xBE00
[0.577118] [drm:r100_ring_test] *ERROR* radeon: ring test failed
(sracth(0x15E4)=3D0x
CAFEDEAD)
[0.577192] [drm:r100_cp_init] *ERROR* radeon: cp isn't working (-22).
[0.577252] radeon :01:05.0: failled initializing CP (-22).
[0.577310] radeon :01:05.0: Disabling GPU acceleration
[0.577440] [drm] radeon: cp finalized
[0.578078] [drm] Default TV standard: NTSC
[0.578314] [drm] Default TV standard: NTSC
[0.578590] [drm] Radeon Display Connectors
[0.578648] [drm] Connector 0:
[0.578706] [drm]   VGA
[0.578764] [drm]   DDC: 0x7e50 0x7e40 0x7e54 0x7e44 0x7e58 0x7e48
0x7e5c 0x7e4c
[0.578837] [drm]   Encoders:
[0.578894] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[0.578952] [drm] Connector 1:
[0.579010] [drm]   S-video
[0.579067] [drm]   Encoders:
[0.579124] [drm] TV1: INTERNAL_KLDSCP_DAC1
[0.579182] [drm] Connector 2:
[0.579239] [drm]   HDMI-A
[0.579297] [drm]   DDC: 0x7e40 0x7e50 0x7e44 0x7e54 0x7e48 0x7e58
0x7e4c 0x7e5c
[0.579369] [drm]   Encoders:
[0.579427] [drm] DFP3: INTERNAL_LVTM1
[0.773375] [drm] fb mappable at 0xFC04
[0.773434] [drm] vram apper at 0xFC00
[0.773491] [drm] size 786432
[0.773549] [drm] fb depth is 8
[0.773606] [drm]pitch is 1024
[0.773737] fbcon: radeondrmfb (fb0) is primary device
[0.793240] Console: switching to colour frame buffer device 128x48
[0.794833] fb0: radeondrmfb frame buffer device
[0.794852] drm: registered panic notifier
[0.794871] Slow work thread pool: Starting up
[0.794932] Slow work thread pool: Ready
[0.794953] [drm] Initialized radeon 2.5.0 20080528 for
:01:05.0 on minor 0


Torsten

No subject

If I go one commit back, cubestorm works. It's quite a large commit and it's
not clear to me what the commit does in terms of functionality.

BTW, cubestorm is a single-buffered application.

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

No subject

a) Both r300c and r300g have difficulty with compressed textures, and
b) r300g also has a more serious problem with b8g8r8a8_unorm, b4g4r4a4_unorm,
b5g6r5_unorm textures (and possibly others), because these are what WoW uses
when compressed texture support isn't available.

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

No subject

--=20
controlled by gamma light

No subject

No subject

radeon_test_moves
 (radeon_ttm_backend_bind called through callback function)
 - radeon_ttm.c:radeon_ttm_backend_bind calls radeon_gart_bind
  - radeon_gart.c:radeon_gart_bind calls pci_map_page
   - pci_map_page is alpha_pci_map_page, which calls...
- alpha_pci_map_page calls pci_iommu.c:pci_map_single_1
 - pci_map_single_1 calls iommu_arena_alloc
  - iommu_arena_alloc calls iommu_arena_find_pages
   - iommu_arena_find_pages returns non-0
  - iommu_arena_alloc returns non-0
 - pci_map_single_1 returns 0 after printing
   "could not allocate dma page tables" error
- alpha_pci_map_page returns 0 from pci_map_single_1
  - radeon_gart_bind returns non-0, error path prints
"*ERROR* failed to bind 128 pages at 0x0FF02000"

Is this the cause of the bug we're seeing in the report [1]?

Anyone know what's going wrong here?

Thanks!
Matt Turner

[1] https://bugs.freedesktop.org/show_bug.cgi?id=26403

No subject

mesa upgrade to f4bcd0ca some hours later. At the time I installed lugaru (and
did not see any crash) I had just installed 2.6.34-996.201005261005 (drm-next
from mainline kernel PPA). Hours before I had installed 2.6.34-999.201005231006
(linus tree). So I must have been running one of those kernels.

Both these kernels hang when I try them now with mesa 20100523 fa552261
(installed), and also with 20100429 f7cf8b46 (git checkout, using
LD_LIBRARY_PATH and LIBGL_DRIVERS_PATH).

So maybe I was just lucky when I tried lugaro out the first times. I think I
played with it more than 10 minutes. The way I reproduce the hang now is simply
by choosing Tutorial and then do nothing. Just let the rabbit stand there and
jump by itself. After 10-30 seconds the machine locks up. The sound goes into a
stuttering (sub-second) loop and I have to power off with the power button.

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

No subject

0x46c266f0  0x46c42578  Yes (*) /usr/lib/libpng12.so.0
0x47c162d0  0x47c306b8  Yes (*) /usr/lib/libjpeg.so.62
0x46da7740  0x46db14b8  Yes (*) /usr/lib/libXi.so.6
0x46aea720  0x46af4ff8  Yes (*) /usr/lib/libXext.so.6
0x4686a620  0x468758e8  Yes (*) /lib/libz.so.1
0x4a84fe00  0x4a89ce68  Yes (*) /usr/lib/libgnomeui-2.so.0
0x4a76d160  0x4a7a7f58  Yes (*) /usr/lib/libbonoboui-2.so.0
0x4a6d4270  0x4a710bb8  Yes (*) /usr/lib/libgnomevfs-2.so.0
0x48268fa0  0x482884e8  Yes (*) /usr/lib/libgnomecanvas-2.so.0
0x4a733ea0  0x4a73eba8  Yes (*) /usr/lib/libgnome-2.so.0
0x47c62350  0x47c67b18  Yes (*) /lib/libpopt.so.0
0x47df82b0  0x47e28a58  Yes (*) /usr/lib/libbonobo-2.so.0
0x47e96050  0x47e9f208  Yes (*) /usr/lib/libbonobo-activation.so.4
0x47992d90  0x479ba7b8  Yes (*) /usr/lib/libORBit-2.so.0
0x48297350  0x482a93c8  Yes (*) /usr/lib/libart_lgpl_2.so.2
0x47a9ef00  0x47abc5c8  Yes (*) /usr/lib/libgconf-2.so.4
0x46c15f40  0x46c176b8  Yes (*) /lib/libgthread-2.0.so.0
0x4685f880  0x46863688  Yes (*) /lib/librt.so.1
0x47a1aea0  0x47a1bad8  Yes (*) /usr/lib/libgtkglext-x11-1.0.so.0
0x47f674c0  0x47f8d7a8  Yes (*) /usr/lib/libgdkglext-x11-1.0.so.0
0xb775a7a0  0xb77b0e68  Yes
/home/chris/Programs/local-mesa/lib/libGLU.so.1
0xb7714b50  0xb7748398  Yes
/home/chris/Programs/local-mesa/lib/libGL.so.1
0x476678f0  0x47676698  Yes (*) /usr/lib/libXmu.so.6
0x47525b40  0x475629e8  Yes (*) /usr/lib/libXt.so.6
0x46d55380  0x46d59d28  Yes (*) /usr/lib/libSM.so.6
0x46d61530  0x46d711e8  Yes (*) /usr/lib/libICE.so.6
0x46f8add0  0x47260ab8  Yes (*) /usr/lib/libgtk-x11-2.0.so.0
0x47a0f3f0  0x47a15208  Yes (*) /usr/lib/libpangox-1.0.so.0
0x468b7370  0x46948798  Yes (*) /usr/lib/libX11.so.6
0x46e9a250  0x46effc78  Yes (*) /usr/lib/libgdk-x11-2.0.so.0
0x473d31b0  0x473e02e8  Yes (*) /usr/lib/libatk-1.0.so.0
0x46b74ad0  0x46be0088  Yes (*) /lib/libgio-2.0.so.0
0x474d3420  0x474ee088  Yes (*) /usr/lib/libpangoft2-1.0.so.0
0x46d7e0f0  0x46d90908  Yes (*) /usr/lib/libgdk_pixbuf-2.0.so.0
0x4743c3d0  0x474414b8  Yes (*) /usr/lib/libpangocairo-1.0.so.0
0x473f80e0  0x4741a088  Yes (*) /usr/lib/libpango-1.0.so.0
0x46c8a3c0  0x46cf3528  Yes (*) /usr/lib/libfreetype.so.6
0x46d20f60  0x46d3ccc8  Yes (*) /usr/lib/libfontconfig.so.1
0x46b1c460  0x46b47898  Yes (*) /lib/libgobject-2.0.so.0
0x46b5cc30  0x46b5dd98  Yes (*) /lib/libgmodule-2.0.so.0
0x46a0ca20  0x46a8a328  Yes (*) /lib/libglib-2.0.so.0
0x47453210  0x474ad328  Yes (*) /usr/lib/libcairo.so.2
0x4858bf90  0x485aa008  Yes (*) /usr/lib/liblua-5.1.so
0x4683ba60  0x4683ca88  Yes (*) /lib/libdl.so.2
0x475bd620  0x4762c688  Yes (*) /usr/lib/libstdc++.so.6
0x46812420  0x4682c718  Yes (*) /lib/libm.so.6
0x474faf40  0x475131f8  Yes (*) /lib/libgcc_s.so.1
0x46846300  0x46851c28  Yes (*) /lib/libpthread.so.0
0x466af990  0x467bb4a0  Yes (*) /lib/libc.so.6
0x47eb5680  0x47ec1568  Yes (*) /usr/lib/libgnome-keyring.so.0
0x47845b00  0x4792b0d8  Yes (*) /usr/lib/libxml2.so.2
0x47683530  0x47694af8  Yes (*) /usr/lib/libdbus-glib-1.so.2
0x46e36230  0x46e623c8  Yes (*) /lib/libdbus-1.so.3
0x4a677e60  0x4a6af598  Yes (*) /usr/lib/libssl.so.10
0x4a517e80  0x4a5fb0a8  Yes (*) /usr/lib/libcrypto.so.10
0x47e89940  0x47e8aac8  Yes (*) /usr/lib/libavahi-glib.so.1
0x47d8b550  0x47d91818  Yes (*) /usr/lib/libavahi-common.so.3
0x47dc78e0  0x47dd0f48  Yes (*) /usr/lib/libavahi-client.so.3
0x46afd650  0x46b0bb48  Yes (*) /lib/libresolv.so.2
0x469e1190  0x469f23c8  Yes (*) /lib/libselinux.so.1
0x47c39a20  0x47c3a2c8  Yes (*) /lib/libutil.so.1
0x47ea9f70  0x47eadac8  Yes (*) /usr/lib/libgailutil.so.18
0x47dd9c50  0x47dda968  Yes (*) /usr/lib/libORBitCosNaming-2.so.0
0x46677830  0x4668ed0f  Yes (*) /lib/ld-linux.so.2
0x47c3fad0  0x47c427a8  Yes (*) /usr/lib/libXxf86vm.so.1
0x46c777c0  0x46c78248  Yes (*) /usr/lib/libXdamage.so.1
0x46c7ce70  0x46c7f3a8  Yes (*) /usr/lib/libXfixes.so.3
0x47d014f0  0x47d06ba8  Yes (*) /usr/lib/libdrm.so.2
0x46c1ce60  0x46c1e998  Yes (*) /lib/libuuid.so.1
0x46889e80  0x46898608  Yes (*) /usr/lib/libxcb.so.1
0x46d9c2c0  0x46da2178  Yes (*) /usr/lib/libXrender.so.1
0x46dc0780  0x46dc1258  Yes (*) /usr/lib/libXinerama.so.1
0x46db7150  0x46dbbc38  Yes (*) /usr/lib/libXrandr.so.2
0x46e7be40  0x46e81458  Yes (*) /usr/lib/libXcursor.so.1
0x47447890  0x47448488  Yes (*) /usr/lib/libXcomposite.so.1
0x46c4f040  0x46c67f28  Yes (*) /lib/libexpat.so.1
0x46dd07a0  0x46e22e68  Yes (*) /usr/lib/libpixman-1.so.0
0x46dc5da0  0x46dc78d8  Yes (*) /lib/libcap-ng.so.0
0x44e54750  0x44e764d8  Yes (*) /lib/libgssapi_krb5.so.2
0x44e99e50  0x44efcf88  Yes (*) /lib/libkrb5.so.3
0x47976d10  0x47977928  Yes (*) /lib/libcom_err.so.2
0x44f497f0  0x44f64288  Yes (*) /lib/libk5crypto.so.3
0x4687ea00  

No subject

Client side is other machine: indirect glx -> via network.

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

No subject

versions of libdrm from 2.4.18 on.  I suppose this means that the Arch Linux
people must have patched their version of Linux kernel 2.6.33.3, otherwise it
should not have worked with that version of libdrm?  Finally, there is the
xf86-video-nouveau package, which now is version 0.0.15_git20100314-1.

This time, I cloned the git repository of the Nouveau sources with this
command:
"git clone --depth 1 git://anongit.freedesktop.org/nouveau/linux-2.6", which
turned out to be version 2.6.34-rc5 of the Linux kernel.  The patch utility
refused to apply the mwk patch, as they were already there.  So I tried that
kernel as is, and this time X segfaulted, dropping the computer back to the
80x50 text screen.  Should I build different versions of libdrm, or
xf86-video-nouveau?

Attached is the Xorg.0.log resulting from this combination of Nouveau kernel
2.6.34-rc5, libdrm 2.4.19-2, and xf86-video-nouveau 0.0.15_git20100314-1.

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

No subject

started with the kernel configuration for Arch Linux, but ended up removing
many modules as otherwise that 350 MHz Pentium II needed 6 hours to compile.  I
updated the system before I tried the patch.  These are the current versions
for Arch Linux:

nouveau-drm 0.0.16_20100313-2
xf86-video-nouveau 0.0.15_git20100314-1
kernel26 2.6.33.3-2


Here is the tail of Xorg.0.log:

(II) Module nouveau: vendor="X.Org Foundation"
compiled for 1.7.5.902, module version = 0.0.15
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 6.0
(II) NOUVEAU driver 
(II) NOUVEAU driver for NVIDIA chipset families :
RIVA TNT(NV04)
RIVA TNT2   (NV05)
GeForce 256 (NV10)
GeForce 2   (NV11, NV15)
GeForce 4MX (NV17, NV18)
GeForce 3   (NV20)
GeForce 4Ti (NV25, NV28)
GeForce FX  (NV3x)
GeForce 6   (NV4x)
GeForce 7   (G7x)
GeForce 8   (G8x)
(II) Primary Device is: PCI 01 at 00:00:0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 7, (OK)
drmOpenByBusid: Searching for BusID pci::01:00.0
drmOpenDevice: node name is /dev/dri/card0
drmOpenDevice: open result is 7, (OK)
drmOpenByBusid: drmOpenMinor returns 7
drmOpenByBusid: drmGetBusid reports pci::01:00.0
(EE) [drm] failed to open device
(EE) No devices detected.

Fatal server error:
no screens found

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

No subject

invaluable for delving into and fixing some obnoxious driver bugs. I
suspect its honeymoon period is now over - those bugs that it could
detect easily have been fixed (I hope). In order to capture the relevant
information for later chipset generations, we will need to parse the
command stream and include auxiliary buffers. So whilst I would prefer to
see this in a release so that I can easily diagnose bug reports, I accept
that there is more work to be done and will HTFU.

-- 
Chris Wilson, Intel Open Source Technology Centre