[Bug 33371] [RADEON:KMS:R600G] zsnes output all garbage when OpenGL is enabled
https://bugs.freedesktop.org/show_bug.cgi?id=33371 --- Comment #9 from Michel Dänzer 2011-08-04 02:08:57 PDT --- Please attach Xorg.0.log and dmesg output. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] pass ELD to HDMI/DP audio driver
> On Mon, 1 Aug 2011 21:51:40 +0800, Wu Fengguang
> wrote:
>
> > 1) intel_write_eld() is not called at all
> >It seems we need to call intel_write_eld() in other places besides
> >inside ->mode_set(). Is ->detect() the right place to do so? In
> >other words, are there established connector<=>encoder mapping
> >that can be queried inside intel_hdmi_detect()/intel_dp_detect()?
>
> The connector has a link to the encoder (struct intel_connector contains a
> pointer to a struct intel_encoder).
Right. I actually have this chunk. dmesg shows that in intel_hdmi_detect(),
the drm_encoder object is there, however encoder->crtc is NULL at the time.
@@ -269,6 +271,12 @@ intel_hdmi_detect(struct drm_connector *
status = connector_status_connected;
intel_hdmi->has_hdmi_sink =
drm_detect_hdmi_monitor(edid);
intel_hdmi->has_audio = drm_detect_monitor_audio(edid);
+ drm_edid_to_eld(connector, edid);
+ if (intel_hdmi->base.base.crtc)
+ intel_write_eld(&intel_hdmi->base.base,
+
&intel_hdmi->base.base.crtc->mode);
+ else
+ printk("intel_hdmi_detect: cannot write eld:
NULL crtc\n");
}
connector->display_info.raw_edid = NULL;
kfree(edid);
You may wonder why the mode parameter is needed in intel_write_eld().
This is because the ELD field aud_synch_delay (ie. A/V sync delay) may
have different values in progressive/interleaved display modes.
> > 2) intel_dp_detect() is called even though it's an HDMI monitor
> >connected to an HDMI jack.. It may be a bug specific to the
> >hardware I'm testing (attached its full dmesg).
>
> We run all of the hotplug functions when any connector change is
> detected; easier than trying to track what happened from the bits
> visible from the interrupt.
Ah yes. I figured it out later.
> I note that this patch does not include the necessary hooks for
> Ivybridge; we'll need that included (and tested) for this to be
> considered for kernel 3.1. I'd be surprised if it couldn't use
> ironlake_write_eld just fine, so it should just be a matter of setting
> the write_eld field and testing it on actual hardware.
I tested Ivybridge yesterday and ironlake_write_eld seems to not work
properly for Ivybridge. Need to double check its spec.
Thanks,
Fengguang
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33371] [RADEON:KMS:R600G] zsnes output all garbage when OpenGL is enabled
https://bugs.freedesktop.org/show_bug.cgi?id=33371 --- Comment #10 from Michel Dänzer 2011-08-04 03:15:04 PDT --- I was able to reproduce the problem, but for me it's fixed with current Mesa Git master and 7.11 branches. Make sure your 32 bit r600g is up to date, though you might also need a newer kernel / X driver. In the worst case, turning off colour tiling might work around the problem. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: 2.6.39.3 nouveau_gart_manager_new() leaks memory (FIX)
On Thu, Jul 28, 2011 at 12:07:53PM +0200, Frank van Maarseveen wrote: > /proc/slabinfo shows an anomaly on a 2.6.39.3 x86_64 system. After > running F14 + kde4 for a while it shows high kmalloc-192 numbers: > > # name ... > kmalloc-192 735694 735723264 312 : tunables000 : > slabdata 23733 23733 0 > > Digging in /sys/kernel/slab/kmalloc-192/alloc_calls one line stands out: > > 701960 nouveau_gart_manager_new+0x5d/0xf0 age=24/7405655/87972315 pid=1-4920 > cpus=0-3 > > There are 709907 allocations total and according to > /sys/kernel/slab/kmalloc-192/free_calls there are 52245 free > calls total. This seems to fix it: diff -Nurp a/drivers/gpu/drm/nouveau/nouveau_mem.c b/drivers/gpu/drm/nouveau/nouveau_mem.c --- a/drivers/gpu/drm/nouveau/nouveau_mem.c 2011-05-19 06:06:34.0 +0200 +++ b/drivers/gpu/drm/nouveau/nouveau_mem.c 2011-08-03 10:58:22.919205352 +0200 @@ -848,6 +848,7 @@ nouveau_gart_manager_del(struct ttm_mem_ nouveau_vm_unmap(&node->tmp_vma); nouveau_vm_put(&node->tmp_vma); } + kfree(node); mem->mm_node = NULL; } -- Frank ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] RFC: Common functions for GEM offset creation
On Tue, Jul 19, 2011 at 8:12 AM, Rob Clark wrote: > On Tue, Jul 19, 2011 at 4:33 AM, Chris Wilson > wrote: >> On Mon, 18 Jul 2011 19:20:56 -0500, Rob Clark wrote: >>> In the process of adding GEM support for OMAP DRM driver, I noticed that >>> I was adding code for creating/freeing mmap offsets which was virtually >>> identical to what was already duplicated in i915 and gma500 drivers. >>> >>> Rather than duplicating the code a 3rd time, it seemed like a good idea >>> to move it to the GEM core. >>> >>> Note that I don't actually have a way to test psb or i915, but the >>> changes seem straightforward enough. >> >> My only concern is that for the common functions the mmap_offset to create >> should be passed in a parameter, so that we could support more than one >> mapping for an object. > > I admit I've not got quite as far as dealing with this yet.. I'm just > starting on the dri2 part in xorg driver. (Previous pvr xorg driver > has some non-GEM way of sharing buffers.) So I'm figuring out some of > this stuff as I go. > > For me I think it isn't the end of the world to have same offset in > all processes, although I'm interested if there is a better way. > There is just one 'struct drm_local_map' in 'struct drm_gem_object', > so I admit that I'm not quite sure how this was intended to work. > Chris, any suggestions? I still haven't found a good excuse for offsets to be per-process. I'm just wondering if I should go ahead and send a non-RFC version of the patches. I guess in the end it is not userspace visible so completely possible to change later. But it seems these util fxns should also be useful to a handful of other upcoming SoC DRM drivers (such as the Samsung one that was recently posted). BR, -R ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
PROBLEM: Possible problem in i915_dma_cleanup function in i915_dma.c module
Hello!
This problem is found in 3.0 kernel.
In i915_dma_cleanup function(drivers/gpu/drm/i915/i915_dma.c module) I found
following:
135static int i915_dma_cleanup(struct drm_device * dev)
136{
...
152 /* Clear the HWS virtual address at teardown */
153 if (I915_NEED_GFX_HWS(dev))
154 i915_free_hws(dev);
...
157}
2102int i915_driver_unload(struct drm_device *dev)
2103{
2174 if (!I915_NEED_GFX_HWS(dev))
2175 i915_free_hws(dev);
2190}
I.e. in one case i915_free_hws function is called when (I915_NEED_GFX_HWS(dev))
condition is true(i915_dma_cleanup), but in other case it called when
(!I915_NEED_GFX_HWS(dev)) condition is true(in i915_driver_unload function).
This is intentional?
Corresponding init function is called only when (!I915_NEED_GFX_HWS(dev))
condition is true(in i915_driver_load function). Therefore I guess that if
condition is wrong in i915_dma_cleanup function.
Thanks,
Dmitry
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33371] [RADEON:KMS:R600G] zsnes output all garbage when OpenGL is enabled
https://bugs.freedesktop.org/show_bug.cgi?id=33371 --- Comment #11 from Lars Wendler 2011-08-04 08:42:26 PDT --- (In reply to comment #10) > I was able to reproduce the problem, but for me it's fixed with current Mesa > Git master and 7.11 branches. Make sure your 32 bit r600g is up to date, > though > you might also need a newer kernel / X driver. > > In the worst case, turning off colour tiling might work around the problem. I've just tested zsnes with gallium r600 from mesa-7.11 and the problem seems to be gone. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/3] RFC: Common functions for GEM offset creation
>> On Tue, Jul 19, 2011 at 4:33 AM, Chris Wilson >> wrote: >>> My only concern is that for the common functions the mmap_offset to create >>> should be passed in a parameter, so that we could support more than one >>> mapping for an object. [ snip ] > On Tue, Jul 19, 2011 at 8:12 AM, Rob Clark wrote: > Chris, any suggestions? I still haven't found a good excuse for > offsets to be per-process. > > I'm just wondering if I should go ahead and send a non-RFC version of > the patches. I guess in the end it is not userspace visible so > completely possible to change later. But it seems these util fxns > should also be useful to a handful of other upcoming SoC DRM drivers > (such as the Samsung one that was recently posted). Imo you're patches looks nice and should go in as is. Fixing the mmap handling of gem objects for real looks like more work: For the second cpu-coherent mapping of i915 gem objects (as opposed to the gpu coherent mapping using the mmap_offset infrastructure) we directly create a vma for the underlying shmfs node in a hand-rolled mmap ioctl (using do_mmap), the core drm mmap handling is layered with a bit of historical cruft of it's own and ttm seems to do a bit of reinventing the wheel. So imo this needs some more cleanup to be nice and beautiful than just adding an additional argument. It's somewhere on one of my todo list ... ;-) Cheers, Daniel -- Daniel Vetter daniel.vet...@ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/9] drm/gem: add functions for mmap offset creation
---
drivers/gpu/drm/drm_gem.c | 88 +
include/drm/drmP.h|3 ++
2 files changed, 91 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 2b997d2..809358a 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -273,6 +273,94 @@ again:
}
EXPORT_SYMBOL(drm_gem_handle_create);
+
+/**
+ * drm_gem_free_mmap_offset - release a fake mmap offset for an object
+ * @obj: obj in question
+ *
+ * This routine frees fake offsets allocated by drm_gem_create_mmap_offset().
+ */
+void
+drm_gem_free_mmap_offset(struct drm_gem_object *obj)
+{
+ struct drm_device *dev = obj->dev;
+ struct drm_gem_mm *mm = dev->mm_private;
+ struct drm_map_list *list = &obj->map_list;
+
+ drm_ht_remove_item(&mm->offset_hash, &list->hash);
+ drm_mm_put_block(list->file_offset_node);
+ kfree(list->map);
+ list->map = NULL;
+}
+EXPORT_SYMBOL(drm_gem_free_mmap_offset);
+
+/**
+ * drm_gem_create_mmap_offset - create a fake mmap offset for an object
+ * @obj: obj in question
+ *
+ * GEM memory mapping works by handing back to userspace a fake mmap offset
+ * it can use in a subsequent mmap(2) call. The DRM core code then looks
+ * up the object based on the offset and sets up the various memory mapping
+ * structures.
+ *
+ * This routine allocates and attaches a fake offset for @obj.
+ */
+int
+drm_gem_create_mmap_offset(struct drm_gem_object *obj)
+{
+ struct drm_device *dev = obj->dev;
+ struct drm_gem_mm *mm = dev->mm_private;
+ struct drm_map_list *list;
+ struct drm_local_map *map;
+ int ret = 0;
+
+ /* Set the object up for mmap'ing */
+ list = &obj->map_list;
+ list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
+ if (!list->map)
+ return -ENOMEM;
+
+ map = list->map;
+ map->type = _DRM_GEM;
+ map->size = obj->size;
+ map->handle = obj;
+
+ /* Get a DRM GEM mmap offset allocated... */
+ list->file_offset_node = drm_mm_search_free(&mm->offset_manager,
+ obj->size / PAGE_SIZE, 0, 0);
+
+ if (!list->file_offset_node) {
+ DRM_ERROR("failed to allocate offset for bo %d\n", obj->name);
+ ret = -ENOSPC;
+ goto out_free_list;
+ }
+
+ list->file_offset_node = drm_mm_get_block(list->file_offset_node,
+ obj->size / PAGE_SIZE, 0);
+ if (!list->file_offset_node) {
+ ret = -ENOMEM;
+ goto out_free_list;
+ }
+
+ list->hash.key = list->file_offset_node->start;
+ ret = drm_ht_insert_item(&mm->offset_hash, &list->hash);
+ if (ret) {
+ DRM_ERROR("failed to add to map hash\n");
+ goto out_free_mm;
+ }
+
+ return 0;
+
+out_free_mm:
+ drm_mm_put_block(list->file_offset_node);
+out_free_list:
+ kfree(list->map);
+ list->map = NULL;
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_gem_create_mmap_offset);
+
/** Returns a reference to the object named by the handle. */
struct drm_gem_object *
drm_gem_object_lookup(struct drm_device *dev, struct drm_file *filp,
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 111e98f..ec156c3 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1622,6 +1622,9 @@ drm_gem_object_handle_unreference_unlocked(struct
drm_gem_object *obj)
drm_gem_object_unreference_unlocked(obj);
}
+void drm_gem_free_mmap_offset(struct drm_gem_object *obj);
+int drm_gem_create_mmap_offset(struct drm_gem_object *obj);
+
struct drm_gem_object *drm_gem_object_lookup(struct drm_device *dev,
struct drm_file *filp,
u32 handle);
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/9] drm/i915: use common functions for mmap offset creation
---
drivers/gpu/drm/i915/i915_gem.c | 85 +--
1 files changed, 2 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5c0d124..5676eaa 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1265,74 +1265,6 @@ out:
}
/**
- * i915_gem_create_mmap_offset - create a fake mmap offset for an object
- * @obj: obj in question
- *
- * GEM memory mapping works by handing back to userspace a fake mmap offset
- * it can use in a subsequent mmap(2) call. The DRM core code then looks
- * up the object based on the offset and sets up the various memory mapping
- * structures.
- *
- * This routine allocates and attaches a fake offset for @obj.
- */
-static int
-i915_gem_create_mmap_offset(struct drm_i915_gem_object *obj)
-{
- struct drm_device *dev = obj->base.dev;
- struct drm_gem_mm *mm = dev->mm_private;
- struct drm_map_list *list;
- struct drm_local_map *map;
- int ret = 0;
-
- /* Set the object up for mmap'ing */
- list = &obj->base.map_list;
- list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
- if (!list->map)
- return -ENOMEM;
-
- map = list->map;
- map->type = _DRM_GEM;
- map->size = obj->base.size;
- map->handle = obj;
-
- /* Get a DRM GEM mmap offset allocated... */
- list->file_offset_node = drm_mm_search_free(&mm->offset_manager,
- obj->base.size / PAGE_SIZE,
- 0, 0);
- if (!list->file_offset_node) {
- DRM_ERROR("failed to allocate offset for bo %d\n",
- obj->base.name);
- ret = -ENOSPC;
- goto out_free_list;
- }
-
- list->file_offset_node = drm_mm_get_block(list->file_offset_node,
- obj->base.size / PAGE_SIZE,
- 0);
- if (!list->file_offset_node) {
- ret = -ENOMEM;
- goto out_free_list;
- }
-
- list->hash.key = list->file_offset_node->start;
- ret = drm_ht_insert_item(&mm->offset_hash, &list->hash);
- if (ret) {
- DRM_ERROR("failed to add to map hash\n");
- goto out_free_mm;
- }
-
- return 0;
-
-out_free_mm:
- drm_mm_put_block(list->file_offset_node);
-out_free_list:
- kfree(list->map);
- list->map = NULL;
-
- return ret;
-}
-
-/**
* i915_gem_release_mmap - remove physical page mappings
* @obj: obj in question
*
@@ -1360,19 +1292,6 @@ i915_gem_release_mmap(struct drm_i915_gem_object *obj)
obj->fault_mappable = false;
}
-static void
-i915_gem_free_mmap_offset(struct drm_i915_gem_object *obj)
-{
- struct drm_device *dev = obj->base.dev;
- struct drm_gem_mm *mm = dev->mm_private;
- struct drm_map_list *list = &obj->base.map_list;
-
- drm_ht_remove_item(&mm->offset_hash, &list->hash);
- drm_mm_put_block(list->file_offset_node);
- kfree(list->map);
- list->map = NULL;
-}
-
static uint32_t
i915_gem_get_gtt_size(struct drm_i915_gem_object *obj)
{
@@ -1493,7 +1412,7 @@ i915_gem_mmap_gtt(struct drm_file *file,
}
if (!obj->base.map_list.map) {
- ret = i915_gem_create_mmap_offset(obj);
+ ret = drm_gem_create_mmap_offset(&obj->base);
if (ret)
goto out;
}
@@ -3614,7 +3533,7 @@ static void i915_gem_free_object_tail(struct
drm_i915_gem_object *obj)
trace_i915_gem_object_destroy(obj);
if (obj->base.map_list.map)
- i915_gem_free_mmap_offset(obj);
+ drm_gem_free_mmap_offset(&obj->base);
drm_gem_object_release(&obj->base);
i915_gem_info_remove_obj(dev_priv, obj->base.size);
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/9] drm/gma500: use common functions for mmap offset creation
---
drivers/staging/gma500/psb_gem.c | 63 +
1 files changed, 2 insertions(+), 61 deletions(-)
diff --git a/drivers/staging/gma500/psb_gem.c b/drivers/staging/gma500/psb_gem.c
index 76ff7ba..3a397f5 100644
--- a/drivers/staging/gma500/psb_gem.c
+++ b/drivers/staging/gma500/psb_gem.c
@@ -42,13 +42,7 @@ void psb_gem_free_object(struct drm_gem_object *obj)
struct gtt_range *gtt = container_of(obj, struct gtt_range, gem);
psb_gtt_free_range(obj->dev, gtt);
if (obj->map_list.map) {
- /* Do things GEM should do for us */
- struct drm_gem_mm *mm = obj->dev->mm_private;
- struct drm_map_list *list = &obj->map_list;
- drm_ht_remove_item(&mm->offset_hash, &list->hash);
- drm_mm_put_block(list->file_offset_node);
- kfree(list->map);
- list->map = NULL;
+ drm_gem_free_mmap_offset(obj);
}
drm_gem_object_release(obj);
}
@@ -60,59 +54,6 @@ int psb_gem_get_aperture(struct drm_device *dev, void *data,
}
/**
- * psb_gem_create_mmap_offset - invent an mmap offset
- * @obj: our object
- *
- * This is basically doing by hand a pile of ugly crap which should
- * be done automatically by the GEM library code but isn't
- */
-static int psb_gem_create_mmap_offset(struct drm_gem_object *obj)
-{
- struct drm_device *dev = obj->dev;
- struct drm_gem_mm *mm = dev->mm_private;
- struct drm_map_list *list;
- struct drm_local_map *map;
- int ret;
-
- list = &obj->map_list;
- list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
- if (list->map == NULL)
- return -ENOMEM;
- map = list->map;
- map->type = _DRM_GEM;
- map->size = obj->size;
- map->handle =obj;
-
- list->file_offset_node = drm_mm_search_free(&mm->offset_manager,
- obj->size / PAGE_SIZE, 0, 0);
- if (!list->file_offset_node) {
- DRM_ERROR("failed to allocate offset for bo %d\n", obj->name);
- ret = -ENOSPC;
- goto free_it;
- }
- list->file_offset_node = drm_mm_get_block(list->file_offset_node,
- obj->size / PAGE_SIZE, 0);
- if (!list->file_offset_node) {
- ret = -ENOMEM;
- goto free_it;
- }
- list->hash.key = list->file_offset_node->start;
- ret = drm_ht_insert_item(&mm->offset_hash, &list->hash);
- if (ret) {
- DRM_ERROR("failed to add to map hash\n");
- goto free_mm;
- }
- return 0;
-
-free_mm:
- drm_mm_put_block(list->file_offset_node);
-free_it:
- kfree(list->map);
- list->map = NULL;
- return ret;
-}
-
-/**
* psb_gem_dumb_map_gtt- buffer mapping for dumb interface
* @file: our drm client file
* @dev: drm device
@@ -142,7 +83,7 @@ int psb_gem_dumb_map_gtt(struct drm_file *file, struct
drm_device *dev,
/* Make it mmapable */
if (!obj->map_list.map) {
- ret = psb_gem_create_mmap_offset(obj);
+ ret = drm_gem_create_mmap_offset(obj);
if (ret)
goto out;
}
--
1.7.4.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/radeon/kms: make some watermark messages debug only
From: Alex Deucher
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 401c6eb..fe73da7 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -743,7 +743,7 @@ static void evergreen_program_watermarks(struct
radeon_device *rdev,
!evergreen_average_bandwidth_vs_available_bandwidth(&wm) ||
!evergreen_check_latency_hiding(&wm) ||
(rdev->disp_priority == 2)) {
- DRM_INFO("force priority to high\n");
+ DRM_DEBUG_KMS("force priority to high\n");
priority_a_cnt |= PRIORITY_ALWAYS_ON;
priority_b_cnt |= PRIORITY_ALWAYS_ON;
}
--
1.7.1.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] pass ELD to HDMI/DP audio driver
On Thu, 4 Aug 2011 17:40:24 +0800, Wu Fengguang wrote: > Right. I actually have this chunk. dmesg shows that in intel_hdmi_detect(), > the drm_encoder object is there, however encoder->crtc is NULL at the > time. Correct. encoder->crtc is set only when the output is active. > You may wonder why the mode parameter is needed in intel_write_eld(). > This is because the ELD field aud_synch_delay (ie. A/V sync delay) may > have different values in progressive/interleaved display modes. Ok, so you can't write ELD data until the display is active, which happens at mode_set time. Do you need to provide ELD when the display is inactive? Is this only to enable audio output when the display is not on? In that case, we will need to essentially turn enough of the output on to allow for audio data, picking a mode which provide sufficient bandwidth. > I tested Ivybridge yesterday and ironlake_write_eld seems to not work > properly for Ivybridge. Need to double check its spec. That's unfortunate... -- keith.pack...@intel.com pgpS1isZ4j8oP.pgp Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #12 from Sven Arvidsson 2011-08-04 14:33:09 PDT --- Created an attachment (id=49931) --> (https://bugs.freedesktop.org/attachment.cgi?id=49931) backtrace On my HD5670 I get a floating point exception (backtrace attached). Is this a bug or have I failed to apply one of the patches? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #13 from Vadim 2011-08-04 14:47:16 PDT --- (In reply to comment #12) > Created an attachment (id=49931) --> (https://bugs.freedesktop.org/attachment.cgi?id=49931) > backtrace > > On my HD5670 I get a floating point exception (backtrace attached). Is this a > bug or have I failed to apply one of the patches? It seems kernel patch (0001-drm-radeon-kms-add-htile-support-to-the-cs-checker.patch) is missing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40562] New: Shutting down X/KDE sometimes leads to kernel crash on kernel-3.0.1-rc1 with radeon/kms
https://bugzilla.kernel.org/show_bug.cgi?id=40562 Summary: Shutting down X/KDE sometimes leads to kernel crash on kernel-3.0.1-rc1 with radeon/kms Product: Drivers Version: 2.5 Kernel Version: 3.0.1-rc1 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: bugzilla.kernel@boris64.net Regression: No Created an attachment (id=67542) --> (https://bugzilla.kernel.org/attachment.cgi?id=67542) foto of kernel panic My pc now crashed about the 2nd time (dunno how to reproduce, yet) when trying to restart. It looks like X dies and takes the whole kernel down. Please check the attached picture which is a foto of the kernel panic. I hope it is useful as it's somehow blurred. Used software: -kernel-3.0.1-rc1 -xorg-server-1.10.3 -radeon/kms -xf86-video-ati/mesa/libdrm from git Need more logs/infos? Please tell me what else would be required. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40562] Shutting down X/KDE sometimes leads to kernel crash on kernel-3.0.1-rc1 with radeon/kms
https://bugzilla.kernel.org/show_bug.cgi?id=40562 --- Comment #1 from boris64 2011-08-04 22:47:57 --- Created an attachment (id=67552) --> (https://bugzilla.kernel.org/attachment.cgi?id=67552) dmesg -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40562] Shutting down X/KDE sometimes leads to kernel crash on kernel-3.0.1-rc1 with radeon/kms
https://bugzilla.kernel.org/show_bug.cgi?id=40562 --- Comment #2 from boris64 2011-08-04 22:48:26 --- Created an attachment (id=67562) --> (https://bugzilla.kernel.org/attachment.cgi?id=67562) kernel config -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 40562] Shutting down X/KDE sometimes leads to kernel crash on kernel-3.0.1-rc1 with radeon/kms
https://bugzilla.kernel.org/show_bug.cgi?id=40562 boris64 changed: What|Removed |Added Attachment #67542|0 |1 is obsolete|| --- Comment #3 from boris64 2011-08-04 22:50:16 --- Created an attachment (id=67572) --> (https://bugzilla.kernel.org/attachment.cgi?id=67572) foto of kernel panic Oops, i posted the wrong picture. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39683] radeon "hd6770 flex" dpms fails to unblank one display sometimes
https://bugs.freedesktop.org/show_bug.cgi?id=39683 --- Comment #3 from aaron 2011-08-04 22:15:04 PDT --- Created an attachment (id=49937) --> (https://bugs.freedesktop.org/attachment.cgi?id=49937) dmesg output -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39683] radeon "hd6770 flex" dpms fails to unblank one display sometimes
https://bugs.freedesktop.org/show_bug.cgi?id=39683 --- Comment #4 from aaron 2011-08-04 22:16:20 PDT --- re-tested via ssh to to eliminate delayed events (and i now have 3 screens...) xset dpms force off: all displays turn off then almost immediately DVI-0 and HDMI-0 turn back on but DisplayPort-1 stays off xset q states "monitor is off" then i press shift( cause an event): xset q states "monitor is on" DVI-0 and HDMI-0 stay on and DisplayPort-1 stays off then "xset dpms force off" again all 3 displays turn off xset q states "monitor is off" then i press shift( cause an event): all 3 displays turn on xset q states "monitor is on" this is a repeatable loop -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39683] radeon "hd6770 flex" dpms fails to unblank one display sometimes
https://bugs.freedesktop.org/show_bug.cgi?id=39683 --- Comment #5 from aaron 2011-08-04 22:18:44 PDT --- Created an attachment (id=49938) --> (https://bugs.freedesktop.org/attachment.cgi?id=49938) xorg.0.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39848] New: sensors are inaccessible on radeon X1950 PCIe
https://bugs.freedesktop.org/show_bug.cgi?id=39848 Summary: sensors are inaccessible on radeon X1950 PCIe Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.freedesktop.org ReportedBy: thierry.vign...@gmail.com My X1950 (RV350) Radeon card has a hw monitoring chip onboard. I read that it's now possible to access it via the dri framework and the standard lm-sensors toolkit, and the lm63 is the driver I need. I ran sensors-detect: Next adapter: Radeon i2c bit bus 0x92 (i2c-2) Do you want to scan it? (YES/no/selectively): Client found at address 0x4c (...) Probing for `National Semiconductor LM63'...Success! (confidence 6, driver `lm63') (...) Now follows a summary of the probes I have just done. (...) Driver `lm63': * Bus `Radeon i2c bit bus 0x92' Busdriver `UNKNOWN', I2C address 0x4c Chip `National Semiconductor LM63' (confidence: 6) But lm63 doesn't seem to work. Modules load without any error, but if I run 'sensors', only the motherboard sensors are printed. qFrom dmesg: i2c /dev entries driver smsc47b397: found SMSC LPC47B397-NC (base address 0x0900, revision 1) With kernel 2.6.3x and 3.0 With xserver 1.7, 1.9 & 1.10 with x11 driver 6.14.1 & previous too $ lspcidrake -v|fgrep VGA lCard:ATI Radeon X1950 and earlier: ATI Technologies Inc|RV530LE [Radeon X1600/X1650 PRO] [DISPLAY_VGA] (vendor:1002 device:71c6 subv:174b subd:0880) $ lspci|fgrep VGA 01:00.0 VGA compatible controller: ATI Technologies Inc RV530LE [Radeon X1600/X1650 PRO] -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39513] sensors are inaccessible on radeon 9600xt agp
https://bugs.freedesktop.org/show_bug.cgi?id=39513 --- Comment #15 from Thierry Vignaud 2011-08-04 23:48:13 PDT --- I've a very similar issue on RV350. See https://bugs.freedesktop.org/show_bug.cgi?id=39848 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39848] sensors are inaccessible on radeon X1950 PCIe
https://bugs.freedesktop.org/show_bug.cgi?id=39848 --- Comment #1 from Thierry Vignaud 2011-08-04 23:48:49 PDT --- Created an attachment (id=49940) --> (https://bugs.freedesktop.org/attachment.cgi?id=49940) kernel-3.0 dmesg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39848] sensors are inaccessible on radeon X1950 PCIe
https://bugs.freedesktop.org/show_bug.cgi?id=39848 --- Comment #2 from Thierry Vignaud 2011-08-04 23:50:30 PDT --- Created an attachment (id=49941) --> (https://bugs.freedesktop.org/attachment.cgi?id=49941) ROM -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 39848] sensors are inaccessible on radeon X1950 PCIe
https://bugs.freedesktop.org/show_bug.cgi?id=39848 Thierry Vignaud changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #3 from Thierry Vignaud 2011-08-04 23:55:14 PDT --- argh, now it works :-( -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [RFC PATCH] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
> -Original Message- > From: Sascha Hauer [mailto:s.hauer at pengutronix.de] > Sent: Thursday, August 04, 2011 12:47 AM > To: daeinki > Cc: dri-devel at lists.freedesktop.org; kyungmin.park at samsung.com > Subject: Re: [PATCH] [RFC PATCH] DRM: add DRM Driver for Samsung SoC > EXYNOS4210. > > On Mon, Aug 01, 2011 at 12:52:37PM +0900, daeinki wrote: > > Hi, Sascha Hauer. > > thank you for your comments and below is my answer. > > > > Sascha Hauer wrote: > > >Hi, > > > > > >On Fri, Jul 29, 2011 at 04:24:35PM +0900, Inki Dae wrote: > > >>This patch is a DRM Driver(only including FIMD Driver yet) > > >>for Samsung SoC Exynos4210. and as RFC, I am sending only DRM driver > part. > > >> > > >>this patch is based on git repository below: > > >>git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git, > > >>branch: drm-next > > >>commit-id: 5a96a899bbdee86024ab9ea6d02b9e242faacbed > > >> > > >>We tried to re-use lowlevel codes of the FIMD driver(s3c-fb.c > > >>based on Linux framebuffer) but couldn't so because lowlevel codes > > >>of s3c-fb.c are included internally and so this driver shares only > > >>platform device. > > >> > > >>Sub drivers such as fimd or hdmi have indenpendent platform device and > > >>Platform driver and when driver's probe is called, the driver object > > >>including callbacks(for hardware control) would be registered to > > >>Samsung drm driver. and then when samsung drm driver is probed, > > >>each probe callback of the driver object registered is called so that > > >>additional callbacks for drm framework would be set at this time. > > >> > > >>We used GEM framework for buffer management and this driver supports > > >>only physically continuous memory yet(non-iommu). and for buffer > allocation, > > >>we used DMA APIs(dma_alloc_writecombine) but we will change it to CMA > instead > > >>of DMA APIs later. > > >> > > >>Refer to this link for CMA(Continuous Memory Allocator): > > >>http://lkml.org/lkml/2011/7/20/45 > > >> > > >>Future works: > > >>- HDMI support. > > >>- drm plane feature support. > > >> refer to this link for drm plane feature: > > >> http://www.spinics.net/lists/dri-devel/msg11778.html > > >>- change the allocator to CMA. > > >>- iommu support.(for non-continuous physical memory usage) > > >>- fimd driver update. > > >>- add exception codes and code clean. > > >> > > >>to support all features above, we need long time and hard work. > > >>so we wish that only some features(fimd and non-iommu) are applied to > > >>mainline first. > > >> > > >>We would be pleased you to give us your comments. > > > > > >So far I only had a quick look over the driver. You might know that > > >I wrote a Freescale i.MX drm driver which I posted to the list some > time > > >ago. > > > > > >My driver lacks GEM support which your driver has, so I specifically > > >looked at this part. It seems we could reuse the GEM code on i.MX and > > >probably on most other ARMs aswell. Can you split out this code > > >and remove the samsung_ namespace? > > > > > By any chance, you mean drm_gem_free_mmap_offset()? > > this patch had already been posted by Rob Clark, Omap TI as RFC. > > > > you can refer to this link for it. > > http://www.spinics.net/lists/dri-devel/msg13018.html > > > > if so, I am aware of it but his patch isn't applied to drm-next yet > > and so my drm driver doesn't include his patch. of course I will > > reuse it and remove the samsung_ namespace as you pointed out if the > > patch is applied to drm-next. > > Not only. I meant the full content of samsaung_drm_gem.c, > samsung_drm_buf.c and maybe even samsung_drm_fb.c. > > Except for the samsung namespace these functions could look the same > on i.MX and other dumb framebuffer drm drivers. > > Sascha > I agree with you but I think it remains to be seem yet if I understood what you mean. many drm drivers(i915, radeon and so on) in mainline are using their own prefix yet. Sometime, these duplicated codes should be used as common part. Thank you for your comments. > -- > 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- |
[PATCH] [RFC PATCH] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
> -Original Message- > From: Alan Cox [mailto:alan at lxorguk.ukuu.org.uk] > Sent: Thursday, August 04, 2011 3:54 AM > To: daeinki > Cc: Sascha Hauer; kyungmin.park at samsung.com; dri- > devel at lists.freedesktop.org > Subject: Re: [PATCH] [RFC PATCH] DRM: add DRM Driver for Samsung SoC > EXYNOS4210. > > > if so, I am aware of it but his patch isn't applied to drm-next yet and > > so my drm driver doesn't include his patch. of course I will reuse it > > and remove the samsung_ namespace as you pointed out if the patch is > > applied to drm-next. > > It would be nice it was as its also the same as the code being carried in > the GEM glue for the gma500 driver so we now have 3 users (plus i915 can > use it). > > I agree with Sascha Hauer that a lot more could be shared with other > (particularly future 'dumb') drivers. I think however it would be better > to see what wants moving *after* such drivers are merged rather than > guess in advance and do unneeded work and get it wrong anyway. > > It's a nice reference driver for anyone else writing a DRM driver too. > > Architecturally it's actually not quite as neat a fit for PC dumb devices > as it might first seem though - in the PC world framebuffer case for a lot > of cards I suspect you actually want to use real GEM objects. > > In the PC case you do get multiple framebuffers allocated not all of > which are in use so for cards with limited memory a true GEM object is > useful. This would then be 'pinned' and 'unpinned' by copying it > to/from video RAM and invalidating the mappings so mmap users fault with > the new address next access) > In fact, the FIMD and HDMI hardware on Samsung SoC EXYNOS4210 have no any their own video ram(maybe most of embedded systems) so that they use only system memory. Thank you for your explanation about pin/unpin. I could understand pin/unpin feature through you. If so, I think the feature(that physical memory mapping is done at page fault handler of specific gem module) doesn't need for embedded systems without their own video memory and so they would need only the mapping way that user space would be mapped to physical memory directly not at the page fault handler once user requests specific mmap ioctl(not mmap system call). you can refer to i915_gem_mmap_ioctl() of i915/i915_gem.c for that. Thank you for your comments. > With that behaviour proper use can be made of video RAM and out of use > objects can still be paged. > > For other cases it looks right as is. > > Alan
[PATCH 1/2] drm: Fix irq install error handling
The registered irq should be unregistered by free_irq() if irq_postinstall() returns the error after request_irq() is called successfully. Signed-off-by: Joonyoung Shim Signed-off-by: Kyungmin Park --- drivers/gpu/drm/drm_irq.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 2022a5c..7497c89 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -368,6 +368,7 @@ int drm_irq_install(struct drm_device *dev) mutex_lock(&dev->struct_mutex); dev->irq_enabled = 0; mutex_unlock(&dev->struct_mutex); + free_irq(drm_dev_to_irq(dev), dev); } return ret; -- 1.7.1
[PATCH 2/2] drm: Add NULL check about irq functions
The struct drm_driver has some function pointers for irq. They are
gpu specific and some functions aren't essential things. This can
prevents creation of unnecessary dummy function for irq.
Signed-off-by: Joonyoung Shim
Signed-off-by: Kyungmin Park
---
drivers/gpu/drm/drm_irq.c | 23 +++
1 files changed, 15 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 7497c89..4137af0 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -291,11 +291,14 @@ static void drm_irq_vgaarb_nokms(void *cookie, bool state)
if (!dev->irq_enabled)
return;
- if (state)
- dev->driver->irq_uninstall(dev);
- else {
- dev->driver->irq_preinstall(dev);
- dev->driver->irq_postinstall(dev);
+ if (state) {
+ if (dev->driver->irq_uninstall)
+ dev->driver->irq_uninstall(dev);
+ } else {
+ if (dev->driver->irq_preinstall)
+ dev->driver->irq_preinstall(dev);
+ if (dev->driver->irq_postinstall)
+ dev->driver->irq_postinstall(dev);
}
}
@@ -338,7 +341,8 @@ int drm_irq_install(struct drm_device *dev)
DRM_DEBUG("irq=%d\n", drm_dev_to_irq(dev));
/* Before installing handler */
- dev->driver->irq_preinstall(dev);
+ if (dev->driver->irq_preinstall)
+ dev->driver->irq_preinstall(dev);
/* Install handler */
if (drm_core_check_feature(dev, DRIVER_IRQ_SHARED))
@@ -363,7 +367,9 @@ int drm_irq_install(struct drm_device *dev)
vga_client_register(dev->pdev, (void *)dev,
drm_irq_vgaarb_nokms, NULL);
/* After installing handler */
- ret = dev->driver->irq_postinstall(dev);
+ if (dev->driver->irq_postinstall)
+ ret = dev->driver->irq_postinstall(dev);
+
if (ret < 0) {
mutex_lock(&dev->struct_mutex);
dev->irq_enabled = 0;
@@ -414,7 +420,8 @@ int drm_irq_uninstall(struct drm_device *dev)
if (!drm_core_check_feature(dev, DRIVER_MODESET))
vga_client_register(dev->pdev, NULL, NULL, NULL);
- dev->driver->irq_uninstall(dev);
+ if (dev->driver->irq_uninstall)
+ dev->driver->irq_uninstall(dev);
free_irq(drm_dev_to_irq(dev), dev);
--
1.7.1
[PATCH] [RFC PATCH] DRM: add DRM Driver for Samsung SoC EXYNOS4210.
On Wed, Aug 03, 2011 at 07:54:24PM +0100, Alan Cox wrote: > > if so, I am aware of it but his patch isn't applied to drm-next yet and > > so my drm driver doesn't include his patch. of course I will reuse it > > and remove the samsung_ namespace as you pointed out if the patch is > > applied to drm-next. > > It would be nice it was as its also the same as the code being carried in > the GEM glue for the gma500 driver so we now have 3 users (plus i915 can > use it). > > I agree with Sascha Hauer that a lot more could be shared with other > (particularly future 'dumb') drivers. I think however it would be better > to see what wants moving *after* such drivers are merged rather than > guess in advance and do unneeded work and get it wrong anyway. Forking is much easier than merging, so I really want to share as much as possible from the start. I'm not aware of any SoC having dedicated graphics memory, they all use system memory and the only difference I know is that some systems have a iommu and others don't. Also, don't forget that we do not talk about three major graphic card vendors, but about dozens of SoC vendors with different graphic cores. > > It's a nice reference driver for anyone else writing a DRM driver too. > > Architecturally it's actually not quite as neat a fit for PC dumb devices > as it might first seem though - in the PC world framebuffer case for a lot > of cards I suspect you actually want to use real GEM objects. > > In the PC case you do get multiple framebuffers allocated not all of > which are in use so for cards with limited memory a true GEM object is > useful. This would then be 'pinned' and 'unpinned' by copying it > to/from video RAM and invalidating the mappings so mmap users fault with > the new address next access) /me has just learned something about GEM ;) 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- |
[Bug 33371] [RADEON:KMS:R600G] zsnes output all garbage when OpenGL is enabled
https://bugs.freedesktop.org/show_bug.cgi?id=33371 --- Comment #9 from Michel D?nzer 2011-08-04 02:08:57 PDT --- Please attach Xorg.0.log and dmesg output. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH v3] pass ELD to HDMI/DP audio driver
> On Mon, 1 Aug 2011 21:51:40 +0800, Wu Fengguang
> wrote:
>
> > 1) intel_write_eld() is not called at all
> >It seems we need to call intel_write_eld() in other places besides
> >inside ->mode_set(). Is ->detect() the right place to do so? In
> >other words, are there established connector<=>encoder mapping
> >that can be queried inside intel_hdmi_detect()/intel_dp_detect()?
>
> The connector has a link to the encoder (struct intel_connector contains a
> pointer to a struct intel_encoder).
Right. I actually have this chunk. dmesg shows that in intel_hdmi_detect(),
the drm_encoder object is there, however encoder->crtc is NULL at the time.
@@ -269,6 +271,12 @@ intel_hdmi_detect(struct drm_connector *
status = connector_status_connected;
intel_hdmi->has_hdmi_sink =
drm_detect_hdmi_monitor(edid);
intel_hdmi->has_audio = drm_detect_monitor_audio(edid);
+ drm_edid_to_eld(connector, edid);
+ if (intel_hdmi->base.base.crtc)
+ intel_write_eld(&intel_hdmi->base.base,
+
&intel_hdmi->base.base.crtc->mode);
+ else
+ printk("intel_hdmi_detect: cannot write eld:
NULL crtc\n");
}
connector->display_info.raw_edid = NULL;
kfree(edid);
You may wonder why the mode parameter is needed in intel_write_eld().
This is because the ELD field aud_synch_delay (ie. A/V sync delay) may
have different values in progressive/interleaved display modes.
> > 2) intel_dp_detect() is called even though it's an HDMI monitor
> >connected to an HDMI jack.. It may be a bug specific to the
> >hardware I'm testing (attached its full dmesg).
>
> We run all of the hotplug functions when any connector change is
> detected; easier than trying to track what happened from the bits
> visible from the interrupt.
Ah yes. I figured it out later.
> I note that this patch does not include the necessary hooks for
> Ivybridge; we'll need that included (and tested) for this to be
> considered for kernel 3.1. I'd be surprised if it couldn't use
> ironlake_write_eld just fine, so it should just be a matter of setting
> the write_eld field and testing it on actual hardware.
I tested Ivybridge yesterday and ironlake_write_eld seems to not work
properly for Ivybridge. Need to double check its spec.
Thanks,
Fengguang
[Bug 33371] [RADEON:KMS:R600G] zsnes output all garbage when OpenGL is enabled
https://bugs.freedesktop.org/show_bug.cgi?id=33371 --- Comment #10 from Michel D?nzer 2011-08-04 03:15:04 PDT --- I was able to reproduce the problem, but for me it's fixed with current Mesa Git master and 7.11 branches. Make sure your 32 bit r600g is up to date, though you might also need a newer kernel / X driver. In the worst case, turning off colour tiling might work around the problem. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
2.6.39.3 nouveau_gart_manager_new() leaks memory (FIX)
On Thu, Jul 28, 2011 at 12:07:53PM +0200, Frank van Maarseveen wrote: > /proc/slabinfo shows an anomaly on a 2.6.39.3 x86_64 system. After > running F14 + kde4 for a while it shows high kmalloc-192 numbers: > > # name ... > kmalloc-192 735694 735723264 312 : tunables000 : > slabdata 23733 23733 0 > > Digging in /sys/kernel/slab/kmalloc-192/alloc_calls one line stands out: > > 701960 nouveau_gart_manager_new+0x5d/0xf0 age=24/7405655/87972315 pid=1-4920 > cpus=0-3 > > There are 709907 allocations total and according to > /sys/kernel/slab/kmalloc-192/free_calls there are 52245 free > calls total. This seems to fix it: diff -Nurp a/drivers/gpu/drm/nouveau/nouveau_mem.c b/drivers/gpu/drm/nouveau/nouveau_mem.c --- a/drivers/gpu/drm/nouveau/nouveau_mem.c 2011-05-19 06:06:34.0 +0200 +++ b/drivers/gpu/drm/nouveau/nouveau_mem.c 2011-08-03 10:58:22.919205352 +0200 @@ -848,6 +848,7 @@ nouveau_gart_manager_del(struct ttm_mem_ nouveau_vm_unmap(&node->tmp_vma); nouveau_vm_put(&node->tmp_vma); } + kfree(node); mem->mm_node = NULL; } -- Frank
[PATCH 0/3] RFC: Common functions for GEM offset creation
On Tue, Jul 19, 2011 at 8:12 AM, Rob Clark wrote: > On Tue, Jul 19, 2011 at 4:33 AM, Chris Wilson > wrote: >> On Mon, 18 Jul 2011 19:20:56 -0500, Rob Clark wrote: >>> In the process of adding GEM support for OMAP DRM driver, I noticed that >>> I was adding code for creating/freeing mmap offsets which was virtually >>> identical to what was already duplicated in i915 and gma500 drivers. >>> >>> Rather than duplicating the code a 3rd time, it seemed like a good idea >>> to move it to the GEM core. >>> >>> Note that I don't actually have a way to test psb or i915, but the >>> changes seem straightforward enough. >> >> My only concern is that for the common functions the mmap_offset to create >> should be passed in a parameter, so that we could support more than one >> mapping for an object. > > I admit I've not got quite as far as dealing with this yet.. ?I'm just > starting on the dri2 part in xorg driver. ?(Previous pvr xorg driver > has some non-GEM way of sharing buffers.) ?So I'm figuring out some of > this stuff as I go. > > For me I think it isn't the end of the world to have same offset in > all processes, although I'm interested if there is a better way. > There is just one 'struct drm_local_map' in 'struct drm_gem_object', > so I admit that I'm not quite sure how this was intended to work. > Chris, any suggestions? I still haven't found a good excuse for offsets to be per-process. I'm just wondering if I should go ahead and send a non-RFC version of the patches. I guess in the end it is not userspace visible so completely possible to change later. But it seems these util fxns should also be useful to a handful of other upcoming SoC DRM drivers (such as the Samsung one that was recently posted). BR, -R
PROBLEM: Possible problem in i915_dma_cleanup function in i915_dma.c module
Hello!
This problem is found in 3.0 kernel.
In i915_dma_cleanup function(drivers/gpu/drm/i915/i915_dma.c module) I found
following:
?135static int i915_dma_cleanup(struct drm_device * dev)
?136{
...
?152 ???/* Clear the HWS virtual address at teardown */
?153 ???if (I915_NEED_GFX_HWS(dev))
?154 ???i915_free_hws(dev);
...
?157}
2102int i915_driver_unload(struct drm_device *dev)
2103{
2174 ???if (!I915_NEED_GFX_HWS(dev))
2175 ???i915_free_hws(dev);
2190}
I.e. in one case i915_free_hws function is called when (I915_NEED_GFX_HWS(dev))
condition is true(i915_dma_cleanup), but in other case it called when
(!I915_NEED_GFX_HWS(dev)) condition is true(in i915_driver_unload function).
This is intentional?
Corresponding init function is called only when (!I915_NEED_GFX_HWS(dev))
condition is true(in i915_driver_load function). Therefore I guess that if
condition is wrong in i915_dma_cleanup function.
Thanks,
Dmitry
[Bug 33371] [RADEON:KMS:R600G] zsnes output all garbage when OpenGL is enabled
https://bugs.freedesktop.org/show_bug.cgi?id=33371 --- Comment #11 from Lars Wendler 2011-08-04 08:42:26 PDT --- (In reply to comment #10) > I was able to reproduce the problem, but for me it's fixed with current Mesa > Git master and 7.11 branches. Make sure your 32 bit r600g is up to date, > though > you might also need a newer kernel / X driver. > > In the worst case, turning off colour tiling might work around the problem. I've just tested zsnes with gallium r600 from mesa-7.11 and the problem seems to be gone. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH 0/3] RFC: Common functions for GEM offset creation
>> On Tue, Jul 19, 2011 at 4:33 AM, Chris Wilson >> wrote: >>> My only concern is that for the common functions the mmap_offset to create >>> should be passed in a parameter, so that we could support more than one >>> mapping for an object. [ snip ] > On Tue, Jul 19, 2011 at 8:12 AM, Rob Clark wrote: > Chris, any suggestions? ?I still haven't found a good excuse for > offsets to be per-process. > > I'm just wondering if I should go ahead and send a non-RFC version of > the patches. ?I guess in the end it is not userspace visible so > completely possible to change later. ?But it seems these util fxns > should also be useful to a handful of other upcoming SoC DRM drivers > (such as the Samsung one that was recently posted). Imo you're patches looks nice and should go in as is. Fixing the mmap handling of gem objects for real looks like more work: For the second cpu-coherent mapping of i915 gem objects (as opposed to the gpu coherent mapping using the mmap_offset infrastructure) we directly create a vma for the underlying shmfs node in a hand-rolled mmap ioctl (using do_mmap), the core drm mmap handling is layered with a bit of historical cruft of it's own and ttm seems to do a bit of reinventing the wheel. So imo this needs some more cleanup to be nice and beautiful than just adding an additional argument. It's somewhere on one of my todo list ... ;-) Cheers, Daniel -- Daniel Vetter daniel.vetter at ffwll.ch - +41 (0) 79 364 57 48 - http://blog.ffwll.ch
[PATCH 0/3] Common functions for GEM offset creation
In the process of adding GEM support for OMAP DRM driver, I noticed that I was adding code for creating/freeing mmap offsets which was virtually identical to what was already duplicated in i915 and gma500 drivers. Rather than duplicating the code a 3rd time, it seemed like a good idea to move it to the GEM core. Note that I don't actually have a way to test psb or i915, but the changes seem straightforward enough. -- For the curious, OMAP DRM driver is here: https://github.com/robclark/kernel-omap4/commits/linux-omap-3.0-drm I'll send patches when it's dependencies are merged and it is slightly more than half baked ;-) Rob Clark (3): drm/gem: add functions for mmap offset creation drm/i915: use common functions for mmap offset creation drm/gma500: use common functions for mmap offset creation drivers/gpu/drm/drm_gem.c| 88 ++ drivers/gpu/drm/i915/i915_gem.c | 85 +--- drivers/staging/gma500/psb_gem.c | 63 +-- include/drm/drmP.h |3 + 4 files changed, 95 insertions(+), 144 deletions(-) -- 1.7.4.1
[PATCH 1/9] drm/gem: add functions for mmap offset creation
---
drivers/gpu/drm/drm_gem.c | 88 +
include/drm/drmP.h|3 ++
2 files changed, 91 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 2b997d2..809358a 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -273,6 +273,94 @@ again:
}
EXPORT_SYMBOL(drm_gem_handle_create);
+
+/**
+ * drm_gem_free_mmap_offset - release a fake mmap offset for an object
+ * @obj: obj in question
+ *
+ * This routine frees fake offsets allocated by drm_gem_create_mmap_offset().
+ */
+void
+drm_gem_free_mmap_offset(struct drm_gem_object *obj)
+{
+ struct drm_device *dev = obj->dev;
+ struct drm_gem_mm *mm = dev->mm_private;
+ struct drm_map_list *list = &obj->map_list;
+
+ drm_ht_remove_item(&mm->offset_hash, &list->hash);
+ drm_mm_put_block(list->file_offset_node);
+ kfree(list->map);
+ list->map = NULL;
+}
+EXPORT_SYMBOL(drm_gem_free_mmap_offset);
+
+/**
+ * drm_gem_create_mmap_offset - create a fake mmap offset for an object
+ * @obj: obj in question
+ *
+ * GEM memory mapping works by handing back to userspace a fake mmap offset
+ * it can use in a subsequent mmap(2) call. The DRM core code then looks
+ * up the object based on the offset and sets up the various memory mapping
+ * structures.
+ *
+ * This routine allocates and attaches a fake offset for @obj.
+ */
+int
+drm_gem_create_mmap_offset(struct drm_gem_object *obj)
+{
+ struct drm_device *dev = obj->dev;
+ struct drm_gem_mm *mm = dev->mm_private;
+ struct drm_map_list *list;
+ struct drm_local_map *map;
+ int ret = 0;
+
+ /* Set the object up for mmap'ing */
+ list = &obj->map_list;
+ list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
+ if (!list->map)
+ return -ENOMEM;
+
+ map = list->map;
+ map->type = _DRM_GEM;
+ map->size = obj->size;
+ map->handle = obj;
+
+ /* Get a DRM GEM mmap offset allocated... */
+ list->file_offset_node = drm_mm_search_free(&mm->offset_manager,
+ obj->size / PAGE_SIZE, 0, 0);
+
+ if (!list->file_offset_node) {
+ DRM_ERROR("failed to allocate offset for bo %d\n", obj->name);
+ ret = -ENOSPC;
+ goto out_free_list;
+ }
+
+ list->file_offset_node = drm_mm_get_block(list->file_offset_node,
+ obj->size / PAGE_SIZE, 0);
+ if (!list->file_offset_node) {
+ ret = -ENOMEM;
+ goto out_free_list;
+ }
+
+ list->hash.key = list->file_offset_node->start;
+ ret = drm_ht_insert_item(&mm->offset_hash, &list->hash);
+ if (ret) {
+ DRM_ERROR("failed to add to map hash\n");
+ goto out_free_mm;
+ }
+
+ return 0;
+
+out_free_mm:
+ drm_mm_put_block(list->file_offset_node);
+out_free_list:
+ kfree(list->map);
+ list->map = NULL;
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_gem_create_mmap_offset);
+
/** Returns a reference to the object named by the handle. */
struct drm_gem_object *
drm_gem_object_lookup(struct drm_device *dev, struct drm_file *filp,
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 111e98f..ec156c3 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1622,6 +1622,9 @@ drm_gem_object_handle_unreference_unlocked(struct
drm_gem_object *obj)
drm_gem_object_unreference_unlocked(obj);
}
+void drm_gem_free_mmap_offset(struct drm_gem_object *obj);
+int drm_gem_create_mmap_offset(struct drm_gem_object *obj);
+
struct drm_gem_object *drm_gem_object_lookup(struct drm_device *dev,
struct drm_file *filp,
u32 handle);
--
1.7.4.1
[PATCH 2/9] drm/i915: use common functions for mmap offset creation
---
drivers/gpu/drm/i915/i915_gem.c | 85 +--
1 files changed, 2 insertions(+), 83 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 5c0d124..5676eaa 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1265,74 +1265,6 @@ out:
}
/**
- * i915_gem_create_mmap_offset - create a fake mmap offset for an object
- * @obj: obj in question
- *
- * GEM memory mapping works by handing back to userspace a fake mmap offset
- * it can use in a subsequent mmap(2) call. The DRM core code then looks
- * up the object based on the offset and sets up the various memory mapping
- * structures.
- *
- * This routine allocates and attaches a fake offset for @obj.
- */
-static int
-i915_gem_create_mmap_offset(struct drm_i915_gem_object *obj)
-{
- struct drm_device *dev = obj->base.dev;
- struct drm_gem_mm *mm = dev->mm_private;
- struct drm_map_list *list;
- struct drm_local_map *map;
- int ret = 0;
-
- /* Set the object up for mmap'ing */
- list = &obj->base.map_list;
- list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
- if (!list->map)
- return -ENOMEM;
-
- map = list->map;
- map->type = _DRM_GEM;
- map->size = obj->base.size;
- map->handle = obj;
-
- /* Get a DRM GEM mmap offset allocated... */
- list->file_offset_node = drm_mm_search_free(&mm->offset_manager,
- obj->base.size / PAGE_SIZE,
- 0, 0);
- if (!list->file_offset_node) {
- DRM_ERROR("failed to allocate offset for bo %d\n",
- obj->base.name);
- ret = -ENOSPC;
- goto out_free_list;
- }
-
- list->file_offset_node = drm_mm_get_block(list->file_offset_node,
- obj->base.size / PAGE_SIZE,
- 0);
- if (!list->file_offset_node) {
- ret = -ENOMEM;
- goto out_free_list;
- }
-
- list->hash.key = list->file_offset_node->start;
- ret = drm_ht_insert_item(&mm->offset_hash, &list->hash);
- if (ret) {
- DRM_ERROR("failed to add to map hash\n");
- goto out_free_mm;
- }
-
- return 0;
-
-out_free_mm:
- drm_mm_put_block(list->file_offset_node);
-out_free_list:
- kfree(list->map);
- list->map = NULL;
-
- return ret;
-}
-
-/**
* i915_gem_release_mmap - remove physical page mappings
* @obj: obj in question
*
@@ -1360,19 +1292,6 @@ i915_gem_release_mmap(struct drm_i915_gem_object *obj)
obj->fault_mappable = false;
}
-static void
-i915_gem_free_mmap_offset(struct drm_i915_gem_object *obj)
-{
- struct drm_device *dev = obj->base.dev;
- struct drm_gem_mm *mm = dev->mm_private;
- struct drm_map_list *list = &obj->base.map_list;
-
- drm_ht_remove_item(&mm->offset_hash, &list->hash);
- drm_mm_put_block(list->file_offset_node);
- kfree(list->map);
- list->map = NULL;
-}
-
static uint32_t
i915_gem_get_gtt_size(struct drm_i915_gem_object *obj)
{
@@ -1493,7 +1412,7 @@ i915_gem_mmap_gtt(struct drm_file *file,
}
if (!obj->base.map_list.map) {
- ret = i915_gem_create_mmap_offset(obj);
+ ret = drm_gem_create_mmap_offset(&obj->base);
if (ret)
goto out;
}
@@ -3614,7 +3533,7 @@ static void i915_gem_free_object_tail(struct
drm_i915_gem_object *obj)
trace_i915_gem_object_destroy(obj);
if (obj->base.map_list.map)
- i915_gem_free_mmap_offset(obj);
+ drm_gem_free_mmap_offset(&obj->base);
drm_gem_object_release(&obj->base);
i915_gem_info_remove_obj(dev_priv, obj->base.size);
--
1.7.4.1
[PATCH 3/9] drm/gma500: use common functions for mmap offset creation
---
drivers/staging/gma500/psb_gem.c | 63 +
1 files changed, 2 insertions(+), 61 deletions(-)
diff --git a/drivers/staging/gma500/psb_gem.c b/drivers/staging/gma500/psb_gem.c
index 76ff7ba..3a397f5 100644
--- a/drivers/staging/gma500/psb_gem.c
+++ b/drivers/staging/gma500/psb_gem.c
@@ -42,13 +42,7 @@ void psb_gem_free_object(struct drm_gem_object *obj)
struct gtt_range *gtt = container_of(obj, struct gtt_range, gem);
psb_gtt_free_range(obj->dev, gtt);
if (obj->map_list.map) {
- /* Do things GEM should do for us */
- struct drm_gem_mm *mm = obj->dev->mm_private;
- struct drm_map_list *list = &obj->map_list;
- drm_ht_remove_item(&mm->offset_hash, &list->hash);
- drm_mm_put_block(list->file_offset_node);
- kfree(list->map);
- list->map = NULL;
+ drm_gem_free_mmap_offset(obj);
}
drm_gem_object_release(obj);
}
@@ -60,59 +54,6 @@ int psb_gem_get_aperture(struct drm_device *dev, void *data,
}
/**
- * psb_gem_create_mmap_offset - invent an mmap offset
- * @obj: our object
- *
- * This is basically doing by hand a pile of ugly crap which should
- * be done automatically by the GEM library code but isn't
- */
-static int psb_gem_create_mmap_offset(struct drm_gem_object *obj)
-{
- struct drm_device *dev = obj->dev;
- struct drm_gem_mm *mm = dev->mm_private;
- struct drm_map_list *list;
- struct drm_local_map *map;
- int ret;
-
- list = &obj->map_list;
- list->map = kzalloc(sizeof(struct drm_map_list), GFP_KERNEL);
- if (list->map == NULL)
- return -ENOMEM;
- map = list->map;
- map->type = _DRM_GEM;
- map->size = obj->size;
- map->handle =obj;
-
- list->file_offset_node = drm_mm_search_free(&mm->offset_manager,
- obj->size / PAGE_SIZE, 0, 0);
- if (!list->file_offset_node) {
- DRM_ERROR("failed to allocate offset for bo %d\n", obj->name);
- ret = -ENOSPC;
- goto free_it;
- }
- list->file_offset_node = drm_mm_get_block(list->file_offset_node,
- obj->size / PAGE_SIZE, 0);
- if (!list->file_offset_node) {
- ret = -ENOMEM;
- goto free_it;
- }
- list->hash.key = list->file_offset_node->start;
- ret = drm_ht_insert_item(&mm->offset_hash, &list->hash);
- if (ret) {
- DRM_ERROR("failed to add to map hash\n");
- goto free_mm;
- }
- return 0;
-
-free_mm:
- drm_mm_put_block(list->file_offset_node);
-free_it:
- kfree(list->map);
- list->map = NULL;
- return ret;
-}
-
-/**
* psb_gem_dumb_map_gtt- buffer mapping for dumb interface
* @file: our drm client file
* @dev: drm device
@@ -142,7 +83,7 @@ int psb_gem_dumb_map_gtt(struct drm_file *file, struct
drm_device *dev,
/* Make it mmapable */
if (!obj->map_list.map) {
- ret = psb_gem_create_mmap_offset(obj);
+ ret = drm_gem_create_mmap_offset(obj);
if (ret)
goto out;
}
--
1.7.4.1
[PATCH] drm/radeon/kms: make some watermark messages debug only
From: Alex Deucher
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 401c6eb..fe73da7 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -743,7 +743,7 @@ static void evergreen_program_watermarks(struct
radeon_device *rdev,
!evergreen_average_bandwidth_vs_available_bandwidth(&wm) ||
!evergreen_check_latency_hiding(&wm) ||
(rdev->disp_priority == 2)) {
- DRM_INFO("force priority to high\n");
+ DRM_DEBUG_KMS("force priority to high\n");
priority_a_cnt |= PRIORITY_ALWAYS_ON;
priority_b_cnt |= PRIORITY_ALWAYS_ON;
}
--
1.7.1.1
[PATCH v3] pass ELD to HDMI/DP audio driver
On Thu, 4 Aug 2011 17:40:24 +0800, Wu Fengguang wrote: > Right. I actually have this chunk. dmesg shows that in intel_hdmi_detect(), > the drm_encoder object is there, however encoder->crtc is NULL at the > time. Correct. encoder->crtc is set only when the output is active. > You may wonder why the mode parameter is needed in intel_write_eld(). > This is because the ELD field aud_synch_delay (ie. A/V sync delay) may > have different values in progressive/interleaved display modes. Ok, so you can't write ELD data until the display is active, which happens at mode_set time. Do you need to provide ELD when the display is inactive? Is this only to enable audio output when the display is not on? In that case, we will need to essentially turn enough of the output on to allow for audio data, picking a mode which provide sufficient bandwidth. > I tested Ivybridge yesterday and ironlake_write_eld seems to not work > properly for Ivybridge. Need to double check its spec. That's unfortunate... -- keith.packard at intel.com -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110804/71df7b00/attachment.pgp>
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #12 from Sven Arvidsson 2011-08-04 14:33:09 PDT --- Created an attachment (id=49931) --> (https://bugs.freedesktop.org/attachment.cgi?id=49931) backtrace On my HD5670 I get a floating point exception (backtrace attached). Is this a bug or have I failed to apply one of the patches? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 36602] Hierarchical Z support for R600
https://bugs.freedesktop.org/show_bug.cgi?id=36602 --- Comment #13 from Vadim 2011-08-04 14:47:16 PDT --- (In reply to comment #12) > Created an attachment (id=49931) --> (https://bugs.freedesktop.org/attachment.cgi?id=49931) > backtrace > > On my HD5670 I get a floating point exception (backtrace attached). Is this a > bug or have I failed to apply one of the patches? It seems kernel patch (0001-drm-radeon-kms-add-htile-support-to-the-cs-checker.patch) is missing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 40562] New: Shutting down X/KDE sometimes leads to kernel crash on kernel-3.0.1-rc1 with radeon/kms
https://bugzilla.kernel.org/show_bug.cgi?id=40562 Summary: Shutting down X/KDE sometimes leads to kernel crash on kernel-3.0.1-rc1 with radeon/kms Product: Drivers Version: 2.5 Kernel Version: 3.0.1-rc1 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-dri at kernel-bugs.osdl.org ReportedBy: bugzilla.kernel.org at boris64.net Regression: No Created an attachment (id=67542) --> (https://bugzilla.kernel.org/attachment.cgi?id=67542) foto of kernel panic My pc now crashed about the 2nd time (dunno how to reproduce, yet) when trying to restart. It looks like X dies and takes the whole kernel down. Please check the attached picture which is a foto of the kernel panic. I hope it is useful as it's somehow blurred. Used software: -kernel-3.0.1-rc1 -xorg-server-1.10.3 -radeon/kms -xf86-video-ati/mesa/libdrm from git Need more logs/infos? Please tell me what else would be required. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 40562] Shutting down X/KDE sometimes leads to kernel crash on kernel-3.0.1-rc1 with radeon/kms
https://bugzilla.kernel.org/show_bug.cgi?id=40562 --- Comment #1 from boris64 2011-08-04 22:47:57 --- Created an attachment (id=67552) --> (https://bugzilla.kernel.org/attachment.cgi?id=67552) dmesg -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 40562] Shutting down X/KDE sometimes leads to kernel crash on kernel-3.0.1-rc1 with radeon/kms
https://bugzilla.kernel.org/show_bug.cgi?id=40562 --- Comment #2 from boris64 2011-08-04 22:48:26 --- Created an attachment (id=67562) --> (https://bugzilla.kernel.org/attachment.cgi?id=67562) kernel config -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 40562] Shutting down X/KDE sometimes leads to kernel crash on kernel-3.0.1-rc1 with radeon/kms
https://bugzilla.kernel.org/show_bug.cgi?id=40562 boris64 changed: What|Removed |Added Attachment #67542|0 |1 is obsolete|| --- Comment #3 from boris64 2011-08-04 22:50:16 --- Created an attachment (id=67572) --> (https://bugzilla.kernel.org/attachment.cgi?id=67572) foto of kernel panic Oops, i posted the wrong picture. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug.
[Bug 39683] radeon "hd6770 flex" dpms fails to unblank one display sometimes
https://bugs.freedesktop.org/show_bug.cgi?id=39683 --- Comment #3 from aaron 2011-08-04 22:15:04 PDT --- Created an attachment (id=49937) --> (https://bugs.freedesktop.org/attachment.cgi?id=49937) dmesg output -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39683] radeon "hd6770 flex" dpms fails to unblank one display sometimes
https://bugs.freedesktop.org/show_bug.cgi?id=39683 --- Comment #4 from aaron 2011-08-04 22:16:20 PDT --- re-tested via ssh to to eliminate delayed events (and i now have 3 screens...) xset dpms force off: all displays turn off then almost immediately DVI-0 and HDMI-0 turn back on but DisplayPort-1 stays off xset q states "monitor is off" then i press shift( cause an event): xset q states "monitor is on" DVI-0 and HDMI-0 stay on and DisplayPort-1 stays off then "xset dpms force off" again all 3 displays turn off xset q states "monitor is off" then i press shift( cause an event): all 3 displays turn on xset q states "monitor is on" this is a repeatable loop -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39683] radeon "hd6770 flex" dpms fails to unblank one display sometimes
https://bugs.freedesktop.org/show_bug.cgi?id=39683 --- Comment #5 from aaron 2011-08-04 22:18:44 PDT --- Created an attachment (id=49938) --> (https://bugs.freedesktop.org/attachment.cgi?id=49938) xorg.0.log -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39848] New: sensors are inaccessible on radeon X1950 PCIe
https://bugs.freedesktop.org/show_bug.cgi?id=39848 Summary: sensors are inaccessible on radeon X1950 PCIe Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: thierry.vignaud at gmail.com My X1950 (RV350) Radeon card has a hw monitoring chip onboard. I read that it's now possible to access it via the dri framework and the standard lm-sensors toolkit, and the lm63 is the driver I need. I ran sensors-detect: Next adapter: Radeon i2c bit bus 0x92 (i2c-2) Do you want to scan it? (YES/no/selectively): Client found at address 0x4c (...) Probing for `National Semiconductor LM63'...Success! (confidence 6, driver `lm63') (...) Now follows a summary of the probes I have just done. (...) Driver `lm63': * Bus `Radeon i2c bit bus 0x92' Busdriver `UNKNOWN', I2C address 0x4c Chip `National Semiconductor LM63' (confidence: 6) But lm63 doesn't seem to work. Modules load without any error, but if I run 'sensors', only the motherboard sensors are printed. qFrom dmesg: i2c /dev entries driver smsc47b397: found SMSC LPC47B397-NC (base address 0x0900, revision 1) With kernel 2.6.3x and 3.0 With xserver 1.7, 1.9 & 1.10 with x11 driver 6.14.1 & previous too $ lspcidrake -v|fgrep VGA lCard:ATI Radeon X1950 and earlier: ATI Technologies Inc|RV530LE [Radeon X1600/X1650 PRO] [DISPLAY_VGA] (vendor:1002 device:71c6 subv:174b subd:0880) $ lspci|fgrep VGA 01:00.0 VGA compatible controller: ATI Technologies Inc RV530LE [Radeon X1600/X1650 PRO] -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39513] sensors are inaccessible on radeon 9600xt agp
https://bugs.freedesktop.org/show_bug.cgi?id=39513 --- Comment #15 from Thierry Vignaud 2011-08-04 23:48:13 PDT --- I've a very similar issue on RV350. See https://bugs.freedesktop.org/show_bug.cgi?id=39848 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39848] sensors are inaccessible on radeon X1950 PCIe
https://bugs.freedesktop.org/show_bug.cgi?id=39848 --- Comment #1 from Thierry Vignaud 2011-08-04 23:48:49 PDT --- Created an attachment (id=49940) --> (https://bugs.freedesktop.org/attachment.cgi?id=49940) kernel-3.0 dmesg -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39848] sensors are inaccessible on radeon X1950 PCIe
https://bugs.freedesktop.org/show_bug.cgi?id=39848 --- Comment #2 from Thierry Vignaud 2011-08-04 23:50:30 PDT --- Created an attachment (id=49941) --> (https://bugs.freedesktop.org/attachment.cgi?id=49941) ROM -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 39848] sensors are inaccessible on radeon X1950 PCIe
https://bugs.freedesktop.org/show_bug.cgi?id=39848 Thierry Vignaud changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #3 from Thierry Vignaud 2011-08-04 23:55:14 PDT --- argh, now it works :-( -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
