[DRM] BUG: sleeping function called from invalid context, drm_lastclose
Hi Arnd, this commit: commit 58374713c9dfb4d231f8c56cac089f6fbdedc2ec Author: Arnd Bergmann a...@arndb.de Date: Sat Jul 10 23:51:39 2010 +0200 drm: kill BKL from common code moved the call to (inside drm_release) drm_lastclose inside dev-count_lock spinlock. drm_lastclose however takes dev-struct_mutex (now inside an atomic context): BUG: sleeping function called from invalid context at /home/kronos/src/linux-2.6.git/kernel/mutex.c:94 in_atomic(): 1, irqs_disabled(): 0, pid: 3331, name: Xorg Pid: 3331, comm: Xorg Not tainted 2.6.35-06113-gf6cec0a #272 Call Trace: [8102770e] __might_sleep+0xf8/0xfa [8127cf18] mutex_lock+0x1f/0x3e [a052d1c1] drm_lastclose+0x92/0x2ad [drm] [a052dbc7] drm_release+0x5ca/0x60d [drm] [810b118f] fput+0x130/0x1f7 [810ae77d] filp_close+0x63/0x6d [810ae82f] sys_close+0xa8/0xe2 [8100296b] system_call_fastpath+0x16/0x1b Luca -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] i915: do not read uninitialized -dev_private
-dev_private at that point is NULL and is initialied only a few lines
later.
Signed-off-by: Luca Tettamanti kronos...@gmail.com
---
I'm beginnig to dive into DRMKMS, that assignment really confused me :P
drivers/gpu/drm/i915/i915_dma.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index a9f8589..648670d 100644
--- a/drivers/gpu/drm/i915/i915_dma.c
+++ b/drivers/gpu/drm/i915/i915_dma.c
@@ -1578,7 +1578,7 @@ static void i915_get_mem_freq(struct drm_device *dev)
*/
int i915_driver_load(struct drm_device *dev, unsigned long flags)
{
- struct drm_i915_private *dev_priv = dev-dev_private;
+ struct drm_i915_private *dev_priv;
resource_size_t base, size;
int ret = 0, mmio_bar;
uint32_t agp_size, prealloc_size, prealloc_start;
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Q] How to tell we're using the KMS (during suspend/resume) outside the graphics driver
On Sat, Mar 6, 2010 at 10:36 PM, Rafael J. Wysocki r...@sisk.pl wrote: Hi, For at least two reasons it would be beneficial for some code outisde the graphics driver(s) to know if the KMS are used. First, in the non-KMS (ie. UMS) case we probably wouldn't want to call acpi_video_resume(), because that has a potential to mess up with the GPU (it actually is known to do that on at least one system). Second, in the KMS case, we'd be able to skip the kernel VT switch, because the KMS driver uses its own framebuffer anyway. So, is there any reasonable way to check that from the outside of the graphics driver? It should be general enough to cover the cases when there are two graphics adapters with different drivers in the system and so forth. Inside the kernel? If you have a struct pci_dev you can get the associated struct drm_device with pci_get_drvdata and then check the KMS feature: drm_core_check_feature(dev, DRIVER_MODESET). I'm note sure how to check that a device is graphic card though :| Luca -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
It seems to me that Linus' technical argument is indeed being mostly ignored. While breaking the ABI is unfortunate, the real problem that Linus complained about is that you can't install several userspace versions side-by-side. This means that if you install your new kernel and userspace, reboot, and find the new kernel doesn't work for some reason, you can't just go back to the old kernel and have working X, because you just replaced userspace with a version that no longer works with the kernel that worked correctly. This is even worse for distributions that want to upgrade the kernel, because each kernel package would need to have a Depends on the exact userspace package version. Thus, the package manager would remove the older kernel when the new one is installed (since they depend on different versions of the same userspace package). If the new kernel somehow doesn't work, the user is totally screwed and must reboot from a live CD. As pointed out, in this case, it is relatively easy to solve by adding a version number to libdrm-nouveau, the X driver and the DRI drivers. X will then have to load the correct driver and give Mesa the DRI driver name with the correct version appended. It may be a good idea to do this before the new nouveau ABI gets shipped in released distributions, and with a generic mechanisms that can be used by all X/drm drivers. Workarounds are possible, such as replacing /usr/bin/X with a script that loads the correct version, or using X over /dev/fb0 (which should work fine with any DRM KMS driver, and any non-DRI framebuffer), but they shouldn't be needed. BTW, the nVidia proprietary driver also ties the kernel and userspace version in this way, and is actually worse because it replaces the X libglx.so, breaking all other drivers. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
I think you need to be clearer about that. Your distribution packaging may not support that out of the box. There are a variety of ways to do almsot all of this including having entire parallel X installs for development work. Sure, but each user must manually find out how to setup that, and create and test the setup himself (or happen to use a distribution that somehow eases that, if any exist). I think that Linus has a good point in saying that this should be provided by default. And ideally not just by the distribution, but upstream, so that people wanting to test bleeding edge DRM drivers (not necessarily just nouveau) can do so more easily, and beable to go back to their working setup by rebooting should something go wrong. The fundamental problem you can't solve by versioning though is the exact one here. A new kernel that requires version X of a driver won't help if the newest version you have is X - 1. Yes, but the fact that you can't have both X - 1 and X at the same time makes it worse, since for instance bisecting won't just work. Yeah perhaps Fedora should have pushed an update that was smart enough to handle the Nouveau old/new ABI before the patch went upstream. Hindsight is an exact science. Well, yes, but it can still be implemented in time for the next distribution releases and the lesson can be learned for similar future situations. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
So overall, I'd say that we spent about a month of developer time at least between jbarnes, ickle, and myself, on extending the execbuf interface to add a flag saying dear kernel, please don't do this bit of work on this buffer, because I don't need it and it makes things slow. Perhaps then, we should break ABI compatibility _more_ often to speed up development, but also have awesome mechanisms to make it painless for the user. Such as: 1. Automatic side by side userspace installation, as Linus proposed 2. Kernel make install refusing to proceed if it finds that userspace is not updated, and giving instructions on how to update userspace 3. Distributions packaging the new ABI X/Mesa drivers and libdrm even for stable distributions 4. Kernel make install offering to automatically install said distribution packages if it detects a supported distribution 5. Ability to drop new versions of drivers/gpu/drm in an older kernel tree and have it compile (within reasonable limits) In particular, for people with (slightly) old kernels, it should be much easier to make updated DRM trees still work with older kernels, than attempting to make updated userspace work with older kernel modules. This also actually gives them the benefits of the new code. And for people with really old kernels, it's not different from any other hardware device, which requires a kernel upgrade to have better support. Then, for instance, Linus would just have seen the following upon running make install: This kernel requires the Nouveau userspace version 0.0.16, which you don't have installed. Fedora 12 has been detected. Invoke yum to install the rpmnames RPMs required for it? [y/n] _or_ Ubuntu 9.10 has been detected Invoke apt-get to install the debnames packages required for it? [y/n] If the user says no, or the distribution is unknown, instructions on how to download and compile the source would be presented. Once you setup this system, you can freely break the ABI with no significant user discomfort by just raising the version number. This also potentially applies to stuff other than DRM (e.g. perf, kvm, iptables, udev, filesystem-specific tools/APIs, various device configuration systems, and so on). The really stable APIs/ABIs should not be the (undocumented) kernel ones, but Xlib and OpenGL, which actually have formal specifications. Perhaps eventually Gallium could join them as a stable API closer to the hardware, but that's a long way off. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] drm/ttm: add pool wc/uc page allocator
While this is almost surely a good idea, note that userspace caching and suballocation substantially improves Mesa performance even on PCIe systems. This is mostly due to the unavoidable overhead of kernel calls and pagetable modifications, as well as the avoidable linear search the kernel currently does to find an empty space in virtual address space, as well as the additional pagefaults. Userspace caching and suballocation mean that you just have to compute a pointer, which you cannot beat with any kernel-space solution. This is also the way glibc allocates normal memory with malloc(), for the same reason. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [RFC] drm/ttm: add pool wc/uc page allocator
^^^ Luca, I've never seen this show up high on a profile (yet). Do you see that with Nouveau? I used to have an rb-tree implementation of drm_mm_xxx lying around, but I didn't use it because I didn't have a case where it showed up? Yes, before I did userspace allocation, in doom3 profiles, get_unmapped_area and function called by it (all coming from sys_mmap) consumed around 10% of the time. Note that this is not DRM-specific code, but rather the generic Linux code for finding free virtual address space, which walks over all the vmas in the process and, in the default x86 variant, does an rb-tree lookup for each vma! It could be fixed by either in the kernel with better data structures and algorithms or in userspace by using MAP_FIXED. However, this will still leave significant kernel overhead (e.g. just drm_mm_search_free_in_range takes 1%). -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] [rfc] drm/radeon/kms: pm debugging check for vbl.
2010/2/18 Dave Airlie airl...@gmail.com: 2010/2/18 Rafał Miłecki zaj...@gmail.com: W dniu 18 lutego 2010 09:28 użytkownik Dave Airlie airl...@gmail.com napisał: It adds some reading printing steps before every reclock, while we really want it to happen as soon as possible. Maybe you could execute this only on some btw you won't get the print if you are in vblank, and if you aren't well the print doesn't matter, I'm also thinking the engine change reads/writes a lot of regs, so two more might not matter so much. Yeah, maybe that's right. While your idea of testing being in VBLANK is sane :) it could happen we start reclocking in VBLANK (first test will pass), we reclock out of VBLANK (not wanted, possible corruption), and we hit next VBLANK in second test. In such situation (machine) I'm sure we will hit false in test anyway (sooner or later) but maybe we could improve in anyway somehow? To make sure it's sill the same VBLANK? That could be possible, though if a reclock takes a full scanout to operate we've got other issues as it would never be possible by the sounds of it. I might be seeing something like this O_o [ 257.583603] [drm] not in vbl for pm change 00020002 at entry [ 257.583609] [drm] Setting: e: 22000 m: 3 p: 16 (no warning at exit) I have wait queue fix in place... I also see some unsynched reclocks. On a somewhat unrelated note the current clock selection code does not work well with the tables defined on my card (M76): [ 156.577741] ATOM BIOS: ASUS_F3Sa [ 156.577794] [drm] Clocks initialized ! [ 156.577833] [drm] 5 Power State(s) [ 156.577871] [drm] State 0 Default (default) [ 156.577909] [drm]16 PCIE Lanes [ 156.577946] [drm]3 Clock Mode(s) [ 156.577984] [drm]0 engine/memory: 22/30 [ 156.578023] [drm]1 engine/memory: 22/30 [ 156.578063] [drm]2 engine/memory: 22/30 [ 156.578102] [drm] State 1 Performance [ 156.578139] [drm]16 PCIE Lanes [ 156.578177] [drm]3 Clock Mode(s) [ 156.578214] [drm]0 engine/memory: 22/252000 [ 156.578253] [drm]1 engine/memory: 22/30 [ 156.578292] [drm]2 engine/memory: 50/40 [ 156.578332] [drm] State 2 Battery [ 156.578369] [drm]16 PCIE Lanes [ 156.578406] [drm]3 Clock Mode(s) [ 156.578444] [drm]0 engine/memory: 22/252000 [ 156.578483] [drm]1 engine/memory: 22/252000 [ 156.578522] [drm]2 engine/memory: 22/30 [ 156.578561] [drm] State 3 Performance [ 156.578599] [drm]16 PCIE Lanes [ 156.578636] [drm]3 Clock Mode(s) [ 156.578674] [drm]0 engine/memory: 30/40 [ 156.578713] [drm]1 engine/memory: 30/40 [ 156.578752] [drm]2 engine/memory: 50/40 [ 156.578791] [drm] State 4 Battery [ 156.578828] [drm]16 PCIE Lanes [ 156.578866] [drm]3 Clock Mode(s) [ 156.578903] [drm]0 engine/memory: 22/30 [ 156.578942] [drm]1 engine/memory: 22/30 [ 156.578981] [drm]2 engine/memory: 22/30 radeon_pick_power_state with a mobility chip only uses battery and powersave states. Luca -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon hwmon driver
On Mon, Feb 8, 2010 at 7:32 AM, Alex Deucher alexdeuc...@gmail.com wrote: On Sun, Feb 7, 2010 at 6:12 PM, Domenico Andreoli ca...@dandreoli.com wrote: Hi all, I'd like to write a hwmon driver for the Radeon GPUs. I made a quick search in the M56 and M76 register references on AMD's site but didn't find anything. I then wrote to gpudriverdevsupp...@amd.com and now I'm waiting for some response. In the meanwhile, has anybody of you seen anything related to this task while working at the graphic drivers? The thermal and fan chips are generally 3rd party chips connected via i2c. Hi Alex, AMD GPU clock tool also reports an Internal TSS, do you have clue on this one? Luca -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 1/2] drm: introduce drm_gem_object_[handle_]unreference_unlocked
With the exception of adding a new unused API in the form of gem_free_object_unlocked driver hook, I like this. Nouveau and Radeon should be able to use it (by setting it to the same function used for gem_free_object) with little or no modification (they rely on TTM locking). I didn't do it for Radeon since I'm not familiar with the code. I'll hopefully send a Nouveau patch as part of a patchset removing all non-init/KMS BKL/struct_mutex usage in it once it is done. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] drm: introduce drm_gem_object_[handle_]unreference_unlocked
This patch introduces the drm_gem_object_unreference_unlocked
and drm_gem_object_handle_unreference_unlocked functions that
do not require holding struct_mutex.
drm_gem_object_unreference_unlocked calls the new
-gem_free_object_unlocked entry point if available, and
otherwise just takes struct_mutex and just calls -gem_free_object
Signed-off-by: Luca Barbieri l...@luca-barbieri.com
---
drivers/gpu/drm/drm_gem.c | 49
include/drm/drmP.h| 28 +++--
2 files changed, 69 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 8bf3770..4018b3b 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -411,8 +411,19 @@ drm_gem_release(struct drm_device *dev, struct drm_file
*file_private)
mutex_unlock(dev-struct_mutex);
}
+static void
+drm_gem_object_free_common(struct drm_gem_object *obj)
+{
+ struct drm_device *dev = obj-dev;
+ fput(obj-filp);
+ atomic_dec(dev-object_count);
+ atomic_sub(obj-size, dev-object_memory);
+ kfree(obj);
+}
+
/**
* Called after the last reference to the object has been lost.
+ * Must be called holding struct_ mutex
*
* Frees the object
*/
@@ -427,14 +438,40 @@ drm_gem_object_free(struct kref *kref)
if (dev-driver-gem_free_object != NULL)
dev-driver-gem_free_object(obj);
- fput(obj-filp);
- atomic_dec(dev-object_count);
- atomic_sub(obj-size, dev-object_memory);
- kfree(obj);
+ drm_gem_object_free_common(obj);
}
EXPORT_SYMBOL(drm_gem_object_free);
/**
+ * Called after the last reference to the object has been lost.
+ * Must be called without holding struct_mutex
+ *
+ * Frees the object
+ */
+void
+drm_gem_object_free_unlocked(struct kref *kref)
+{
+ struct drm_gem_object *obj = (struct drm_gem_object *) kref;
+ struct drm_device *dev = obj-dev;
+
+ if (dev-driver-gem_free_object_unlocked != NULL)
+ dev-driver-gem_free_object_unlocked(obj);
+ else if (dev-driver-gem_free_object != NULL) {
+ mutex_lock(dev-struct_mutex);
+ dev-driver-gem_free_object(obj);
+ mutex_unlock(dev-struct_mutex);
+ }
+
+ drm_gem_object_free_common(obj);
+}
+EXPORT_SYMBOL(drm_gem_object_free_unlocked);
+
+static void drm_gem_object_ref_bug(struct kref *list_kref)
+{
+ BUG();
+}
+
+/**
* Called after the last handle to the object has been closed
*
* Removes any name for the object. Note that this must be
@@ -458,8 +495,10 @@ drm_gem_object_handle_free(struct kref *kref)
/*
* The object name held a reference to this object, drop
* that now.
+ *
+ * This cannot be the last reference, since the handle holds one
too.
*/
- drm_gem_object_unreference(obj);
+ kref_put(obj-refcount, drm_gem_object_ref_bug);
} else
spin_unlock(dev-object_name_lock);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index ffac157..4a3c4e4 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -801,6 +801,7 @@ struct drm_driver {
*/
int (*gem_init_object) (struct drm_gem_object *obj);
void (*gem_free_object) (struct drm_gem_object *obj);
+ void (*gem_free_object_unlocked) (struct drm_gem_object *obj);
/* vga arb irq handler */
void (*vgaarb_irq)(struct drm_device *dev, bool state);
@@ -1427,6 +1428,7 @@ extern void drm_sysfs_connector_remove(struct
drm_connector *connector);
int drm_gem_init(struct drm_device *dev);
void drm_gem_destroy(struct drm_device *dev);
void drm_gem_object_free(struct kref *kref);
+void drm_gem_object_free_unlocked(struct kref *kref);
struct drm_gem_object *drm_gem_object_alloc(struct drm_device *dev,
size_t size);
void drm_gem_object_handle_free(struct kref *kref);
@@ -1443,10 +1445,15 @@ drm_gem_object_reference(struct drm_gem_object *obj)
static inline void
drm_gem_object_unreference(struct drm_gem_object *obj)
{
- if (obj == NULL)
- return;
+ if (obj != NULL)
+ kref_put(obj-refcount, drm_gem_object_free);
+}
- kref_put(obj-refcount, drm_gem_object_free);
+static inline void
+drm_gem_object_unreference_unlocked(struct drm_gem_object *obj)
+{
+ if (obj != NULL)
+ kref_put(obj-refcount, drm_gem_object_free_unlocked);
}
int drm_gem_handle_create(struct drm_file *file_priv,
@@ -1475,6 +1482,21 @@ drm_gem_object_handle_unreference(struct drm_gem_object
*obj)
drm_gem_object_unreference(obj);
}
+static inline void
+drm_gem_object_handle_unreference_unlocked(struct drm_gem_object *obj)
+{
+ if (obj == NULL)
+ return;
+
+ /*
+ * Must bump handle count first as this may be the last
+ * ref
[PATCH 2/2] Use drm_gem_object_[handle_]unreference_unlocked where possible
Mostly obvious simplifications.
The i915 pread/pwrite ioctls, intel_overlay_put_image and
nouveau_gem_new were incorrectly using the locked versions
without locking: this is also fixed in this patch.
Signed-off-by: Luca Barbieri l...@luca-barbieri.com
---
drivers/gpu/drm/drm_gem.c | 21
drivers/gpu/drm/i915/i915_gem.c| 16 ---
drivers/gpu/drm/i915/i915_gem_tiling.c |4 +--
drivers/gpu/drm/i915/intel_display.c | 13 +++---
drivers/gpu/drm/i915/intel_overlay.c |2 +-
drivers/gpu/drm/nouveau/nouveau_display.c |7 +
drivers/gpu/drm/nouveau/nouveau_fbcon.c|4 +--
drivers/gpu/drm/nouveau/nouveau_gem.c | 26 +--
drivers/gpu/drm/nouveau/nouveau_notifier.c |9 ++
drivers/gpu/drm/nouveau/nv04_crtc.c|4 +--
drivers/gpu/drm/nouveau/nv50_crtc.c|4 +--
drivers/gpu/drm/radeon/radeon_cs.c |7 +
drivers/gpu/drm/radeon/radeon_cursor.c |8 +
drivers/gpu/drm/radeon/radeon_display.c|7 +
drivers/gpu/drm/radeon/radeon_gem.c| 36 +++-
15 files changed, 47 insertions(+), 121 deletions(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 4018b3b..aa89d4b 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -192,9 +192,7 @@ drm_gem_handle_delete(struct drm_file *filp, u32 handle)
idr_remove(filp-object_idr, handle);
spin_unlock(filp-table_lock);
- mutex_lock(dev-struct_mutex);
- drm_gem_object_handle_unreference(obj);
- mutex_unlock(dev-struct_mutex);
+ drm_gem_object_handle_unreference_unlocked(obj);
return 0;
}
@@ -325,9 +323,7 @@ again:
}
err:
- mutex_lock(dev-struct_mutex);
- drm_gem_object_unreference(obj);
- mutex_unlock(dev-struct_mutex);
+ drm_gem_object_unreference_unlocked(obj);
return ret;
}
@@ -358,9 +354,7 @@ drm_gem_open_ioctl(struct drm_device *dev, void *data,
return -ENOENT;
ret = drm_gem_handle_create(file_priv, obj, handle);
- mutex_lock(dev-struct_mutex);
- drm_gem_object_unreference(obj);
- mutex_unlock(dev-struct_mutex);
+ drm_gem_object_unreference_unlocked(obj);
if (ret)
return ret;
@@ -390,7 +384,7 @@ drm_gem_object_release_handle(int id, void *ptr, void *data)
{
struct drm_gem_object *obj = ptr;
- drm_gem_object_handle_unreference(obj);
+ drm_gem_object_handle_unreference_unlocked(obj);
return 0;
}
@@ -403,12 +397,10 @@ drm_gem_object_release_handle(int id, void *ptr, void
*data)
void
drm_gem_release(struct drm_device *dev, struct drm_file *file_private)
{
- mutex_lock(dev-struct_mutex);
idr_for_each(file_private-object_idr,
drm_gem_object_release_handle, NULL);
idr_destroy(file_private-object_idr);
- mutex_unlock(dev-struct_mutex);
}
static void
@@ -516,11 +508,8 @@ EXPORT_SYMBOL(drm_gem_vm_open);
void drm_gem_vm_close(struct vm_area_struct *vma)
{
struct drm_gem_object *obj = vma-vm_private_data;
- struct drm_device *dev = obj-dev;
- mutex_lock(dev-struct_mutex);
- drm_gem_object_unreference(obj);
- mutex_unlock(dev-struct_mutex);
+ drm_gem_object_unreference_unlocked(obj);
}
EXPORT_SYMBOL(drm_gem_vm_close);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index b4c8c02..6844ca4 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -128,9 +128,7 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data,
return -ENOMEM;
ret = drm_gem_handle_create(file_priv, obj, handle);
- mutex_lock(dev-struct_mutex);
- drm_gem_object_handle_unreference(obj);
- mutex_unlock(dev-struct_mutex);
+ drm_gem_object_handle_unreference_unlocked(obj);
if (ret)
return ret;
@@ -488,7 +486,7 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
*/
if (args-offset obj-size || args-size obj-size ||
args-offset + args-size obj-size) {
- drm_gem_object_unreference(obj);
+ drm_gem_object_unreference_unlocked(obj);
return -EINVAL;
}
@@ -501,7 +499,7 @@ i915_gem_pread_ioctl(struct drm_device *dev, void *data,
file_priv);
}
- drm_gem_object_unreference(obj);
+ drm_gem_object_unreference_unlocked(obj);
return ret;
}
@@ -961,7 +959,7 @@ i915_gem_pwrite_ioctl(struct drm_device *dev, void *data,
*/
if (args-offset obj-size || args-size obj-size ||
args-offset + args-size obj-size) {
- drm_gem_object_unreference(obj);
+ drm_gem_object_unreference_unlocked(obj);
return
Re: [PATCH] drm/ttm: Only try to preserve caching in moves in the same space
If you set to uncached | cached, VRAM-SYSTEM will still be broken because it will choose uncached. Assuming VRAM is uncached and not WC of course. The reasoning still holds if you replace all instances of uncached with WC. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/ttm: Only try to preserve caching in moves in the same space
I see a problem with this. If you have uncached TT (e.g. AGP) you want to get uncached for TT-SYSTEM, but you want cached for VRAM-SYSTEM. If you set SYSTEM to uncached, then VRAM-SYSTEM will broken, and if you set SYSTEM to cached, TT-SYSTEM will be broken. If you set to uncached | cached, VRAM-SYSTEM will still be broken because it will choose uncached. You would need to make the proposed placement conditional on the current BO memory type, which is possible but somewhat defeats the purpose of having all the ttm_bo_mem_space logic in ttm. Perhaps this doesn't usually happen because you would do VRAM-TT instead of SYSTEM (is that really always the case? what if we don't have enough space in GART?), but it seems a design deficiency in TTM anyway. The current placement caching should not really be a factor *unless* we can actually do the move just by changing the caching attributes. What do you think? Of course we could also just drop ttm_bo_mem_space and let the driver do that itself (perhaps using hardcorded helpers for the AGP and PCIE case). It seems quite a radical solution though. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/ttm: Only try to preserve caching in moves in the same space
Idea is to mask all move which involve TT (AGP) with the agp_caching_mask, it's easy to do in radeon ttm layer code and i believe it's easy to do in nouveau too. On non AGP you set agp_caching_mask to UC|WC|CACHED. Sure, but isn't that uglier and much more ad-hoc that the patch I proposed? -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/ttm: Only try to preserve caching in moves in the same space
Your patch remove the consistency of caching attribute and make move btw non fixed area different than others move, while driver can already achieve so. It is already different, because TTM does it by changing the page attributes, as opposed to copying data. Thus, it is useful to preserve the existing caching since that means we aren't going to do any work for the move. If instead the move is actually performed by copying (either memcpy or unaccelerated) we don't care about the current caching. The code should actually be: cur_flags = ttm_bo_select_caching(man, ttm_is_going_to_move_by_setting_page_caching_flags ? bo-mem.placement : 0, cur_flags); I wrote ttm_is_going_to_move_by_setting_page_caching_flags as !(man-flags TTM_MEMTYPE_FLAG_FIXED) !(bdev-man[bo-mem.mem_type].flags TTM_MEMTYPE_FLAG_FIXED); If there is a better way to express that in TTM, we should use that instead. This would fix all cases without requiring odd hacks in the drivers. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
2010/1/30 Dave Airlie airl...@gmail.com: 2009/12/24 Rafał Miłecki zaj...@gmail.com: I applied patches from http://www.botchco.com/alex/xorg/pm/ and now engine reclocks between 110MHz and 680MHz. The problem is I see ~10 black horizontal lines for a one frame time on almost every reclock. I tried to fix this or at least understand it somehow but without success. 1) Putting 500ms delay after every reclock doesn't improve anything 2) Reclocking between 110MHz and 130MHz (instead 680MHz) doesn't improve 3) Calling atombios_crtc_set_pll after reclocking doesn't improve 4) Calling ClockSource AtomBIOS commane after reclocking doesn't improve I tested 4th as SetEngineClock seems to play mostly with 0x0180 and ClockSource seems to be the only reading that register. Effects were horrible, don't ever call this AtomBIOS cammand ;) Do you have any other ideas? On top of whats in drm-radeon-testing this avoids reclocking artifacts on my rv530 laptop, I timed the atom calls and they were taking 20ms which is waaay too long, I decoded the tables and it looks like they use udelays. Seems too easy... I used the same approach and even moved the reclock in hard-irq context but I still see corruption (I'm using a M76). Luca -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/ttm: Only try to preserve caching in moves in the same space
Currently TTM tries to preserve the previous caching even for moves
between unrelated memory spaces.
This results for instance in moves from VRAM to PCIE GART changing
system memory to WC state needlessly.
This patch changes TTM to only try to preserve caching if moving from
system/TT to system/TT.
In theory, we should also do that if moving between two device memory
spaces that are backend by the same physical memory area.
However, I'm not sure how to do that in the current TTM framework and
I suspect no card/driver uses memory spaces in that way.
Signed-off-by: Luca Barbieri l...@luca-barbieri.com
---
drivers/gpu/drm/ttm/ttm_bo.c | 18 ++
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2920f9a..27ee1be 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -876,6 +876,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
mem-mm_node = NULL;
for (i = 0; i placement-num_placement; ++i) {
+ int is_tt_move;
ret = ttm_mem_type_from_flags(placement-placement[i],
mem_type);
if (ret)
@@ -891,8 +892,12 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
if (!type_ok)
continue;
- cur_flags = ttm_bo_select_caching(man, bo-mem.placement,
- cur_flags);
+ is_tt_move = !(man-flags TTM_MEMTYPE_FLAG_FIXED)
+ !(bdev-man[bo-mem.mem_type].flags
TTM_MEMTYPE_FLAG_FIXED);
+
+ /* Only try to keep the current flags if we are in the same
memory space */
+ cur_flags = ttm_bo_select_caching(man, is_tt_move ?
bo-mem.placement : 0, cur_flags);
+
/*
* Use the access and other non-mapping-related flag bits from
* the memory placement flags to the current flags
@@ -927,6 +932,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
return -EINVAL;
for (i = 0; i placement-num_busy_placement; ++i) {
+ int is_tt_move;
ret = ttm_mem_type_from_flags(placement-busy_placement[i],
mem_type);
if (ret)
@@ -941,8 +947,12 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
cur_flags))
continue;
- cur_flags = ttm_bo_select_caching(man, bo-mem.placement,
- cur_flags);
+ is_tt_move = !(man-flags TTM_MEMTYPE_FLAG_FIXED)
+ !(bdev-man[bo-mem.mem_type].flags
TTM_MEMTYPE_FLAG_FIXED);
+
+ /* Only try to keep the current flags if we are in the same
memory space */
+ cur_flags = ttm_bo_select_caching(man, is_tt_move ?
bo-mem.placement : 0, cur_flags);
+
/*
* Use the access and other non-mapping-related flag bits from
* the memory placement flags to the current flags
--
1.6.6.1.476.g01ddb
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
Nvidia cards have a synchronization primitive that could be used to synchronize several FIFOs in hardware (AKA semaphores, see [1] for an example). Does this operate wholly on the GPU on all nVidia cards? It seems that at least on some GPUs this will trigger software methods that are basically a way for the GPU to trigger an interrupt and stop the FIFO until the CPU handles the interrupt and restarts it. Also, is there a way on nVidia cards to get interrupts on fences, but only where the fence sequence number is higher than a dynamically set value? (so that one could sleep for fence X without getting an interrupt for every single fence before that) If not, it could possibly be hacked around by reading from a DMA object at the address of the fence sequence number and then resizing the DMA object so that addresses from a certain point on would trigger a protection fault interrupt. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
At a first glance: 1) We probably *will* need a delayed destroyed workqueue to avoid wasting memory that otherwise should be freed to the system. At the very least, the delayed delete process should optionally be run by a system shrinker. You are right. For VRAM we don't care since we are the only user, while for system backed memory some delayed destruction will be needed. The logical extension of the scheme would be for the Linux page allocator/swapper to check for TTM buffers to destroy when it would otherwise shrink caches, try to swap and/or wait on swap to happen. Not sure whether there are existing hooks for this or where exactly to hook this code. 2) Fences in TTM are currently not necessarily strictly ordered, and sequence numbers are hidden from the bo code. This means, for a given FIFO, fence sequence 3 may expire before fence sequence 2, depending on the usage of the buffer. My definition of channel (I sometimes used FIFO incorrectly as a synonym of that) is exactly a set of fences that are strictly ordered. If the card has multiple HW engines, each is considered a different channel (so that a channel becomes a (fifo, engine) pair). We may need however to add the concept of a sync domain that would be a set of channels that support on-GPU synchronization against each other. This would model hardware where channels with the same FIFO can be synchronized together but those with different FIFOs don't, and also multi-core GPUs where synchronization might be available only inside each core and not across cores. To sum it up, a GPU consists of a set of sync domains, each consisting of a set of channels, each consisting of a sequence of fences, with the following rules: 1. Fences within the same channel expire in order 2. If channels A and B belong to the same sync domain, it's possible to emit a fence on A that is guaranteed to expire after an arbitrary fence of B Whether channels have the same FIFO or not is essentially a driver implementation detail, and what TTM cares about is if they are in the same sync domain. [I just made up sync domain here: is there a standard term?] This assumes that the synchronizability graph is a disjoint union of complete graphs. Is there any example where it is not so? Also, does this actually model correctly Poulsbo, or am I wrong? Note that we could use CPU mediation more than we currently do. For instance now Nouveau, to do inter-channel synchronization, simply waits on the fence with the CPU immediately synchronously, while it could instead queue the commands in software, and with an interrupt/delayed mechanism submit them to hardware once the fence to be waited for is expired. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
I'm not sure I understand your proposal correctly.
It seems your proposoal is similar to mine, replacing the term fence
nodes with ttm transactions, but I'm not sure if I understand it
correctly
Here is some pseudocode for a improved, simplified version of my proposal.
It is modified so that there are no longer distinct alive/destroy
lists, but buffers are destroyed if their ref count is zero.
list_head ram_lru_list; /* list of bos */
list_head vram_unfenced_lru_list; /* list of bos */
list_head gart_unfenced_lru_list; /* list of bos */
atomic uint64_t next_seq_num;
// if read_list and write_list are empty, the buffer is unfenced and
MUST be in an unfenced lru list
// otherwise, it is fenced and MUST be, if not zombie, on some
read_list/write_list, or if zombie, on some unfenced_list
struct ttm_buffer_object
{
kref_t ref;
list_head read_list; /* list of bo_fence_nodes */
list_head write_list; /* list of bo_fence_nodes */
list_head unfenced_list; /* list entry in
[ram|[gart|vram]_unfenced]_lru_list */
[...]
};
// TODO: we could embed just the first two members in the
ttm_buffer_object, and steal the lowest bit on the fence pointer to
signify that
// this would optimize for the very common single-fence case
struct ttm_bo_fence_node
{
list_head bo_list; /* list entry in bo.[read|write]_list */
struct ttm_fence_node* fence;
struct ttm_buffer_object* bo;
list_head fence_list; /* list entry in fence.[vram|gart|destroy]_list */
};
struct ttm_fence
{
void* sync_object; /* may also turned into an object containing a
ttm_fence at the start */
uint64_t seq_num; /* unique value in order of kmalloc of this ttm_fence */
list_head bo_list; /* list of bo_fence_nodes */
};
struct ttm_channel
{
list_head fence_list; /* list of ttm_fence_node */
};
ttm_flush_fences()
{
list_head vram_list[MAX_CHANNELS];
list_head gart_list[MAX_CHANNELS];
foreach channel
{
foreach fence in channel
{
if(not driver-fence_expired(fence-sync_object))
break;
foreach bo_fence_node in fence.bo_list
{
remove bo_fence_node
if bo.read_list and bo.write_list are both empty
{
if bo.refcount is zero
destroy
else
{
append to [vram|gart]_list[channel]
}
}
}
}
}
// this is the n-way merge of vram_list[]s into the lru list
while(vram_list[]s are not all empty)
{
// this can use either a simple scan, or an heap
find channel such that
first_entry(vram_list[channel]).fence.seq_num is smallest
remove first_entry(vram_list[channel]) and put the bo at the
recent end of vram_unfenced_lru_list
}
same thing for gart;
}
// assume buffer is reserved, use current mechanism or mutex for that
// channel may be null for CPU waits
ttm_bo_wait(bo, channel, wait_for_write)
{
foreach fence_node in bo.write_list
{
if(fence_node.channel != channel)
driver-wait_fence(fence_node.fence.sync_object);
}
if(!wait_for_write)
return;
foreach fence_node in bo.read_list
{
if(fence_node.channel != channel)
driver-wait_fence(fence_node.fence.sync_object);
}
}
ttm_out_of_memory() takes memory_alloc_mutex
{
retry:
ttm_flush_fences();
if(we have enough space now)
return;
foreach in [vram|gart]_unfenced_lru_list
{
evict that buffer if it's big enough, no need to check fences
this uses the current ghost mechanism for accelerated moves
emit evicted_buffer_fence for after emission
}
if we didn't find a big enough buffer, evict the biggest buffer
(also consider empty space around it in size)
if(we have enough space now)
return;
if(burn_cpu_time_but_have_lowest_latencies)
{
while(!driver-fence_expired(evicted_bo-sync_object) and we
don't have enough space)
{
driver-wait_for_any_fence_to_expire();
ttm_flush_fences();
}
}
else
ttm_bo_wait(evicted_bo 0)
goto retry;
}
// assume the buffer has already been put in the desired memory space
// also assume we already waited for the buffer fences
ttm_add_buffer_to_fence(fence, bo)
{
remove bo from unfenced lru list if it's on it
for the none or single bo_fence_node in bo.read_list or
bo.write_list with bo_fence_node.fence.channel == fence.channel
{
remove bo_fence_node from bo_fence_node.fence.[gart|vram]_list
if(bo_fence_node.fence has all lists empty)
remove from channel and free the fence bo_fence_node.fence
remove bo_fence_node from bo.[read|list]_list
}
create a new bo_fence node and use it to add the bo to the fence
}
ttm_bo_refcount_drops_to_zero(bo)
Re: [Nouveau] [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
If not, it could possibly be hacked around by reading from a DMA object at the address of the fence sequence number and then resizing the DMA object so that addresses from a certain point on would trigger a protection fault interrupt. I don't think you can safely modify a DMA object without stalling the card completely, but i think you could use e.g. PGRAPH NOTIFY interrupts and disable them by flipping a bit in PGRAPH when you stop caring about them. The problem is that one needs to disable them *before* the one he cares about. Suppose the card is at fence 0 and we are interested in fence 1000 expiring. If we just enable interrupts, then we are going to be interrupted uselessly 1000 times. Instead, we would like to tell the card send me interrupts for fences, but only for fence number 1000 (or higher). This way one could for instance render a whole scene, and then desiring to read it into the CPU, just ask for an interrupt once rendering is done (i.e. wait for the framebuffer fence) and get a single interrupt, while we cleanly sleep undisturbed in the meantime. Basically, it would just need some way of *conditionally* causing interrupts. If there is none, then maybe we could insert a call to a fence mini-pushbuffer filled with NOPs that could be overwritten with an interrupt request on demand? Or alternatively, construct such a pushbuffer with the 2D or 3D engines, starting from our 1000 input and the fence value generated by the 3D engine? (this is likely to be slow though). Or some hack like the DMA object resizing? (would it crash the GPU? or just not work due to it caching the previous size?) -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
Doing it without software methods means you need to have a semaphore that exists in the cpu domain and therefore cannot be used again until the cpu is sure it's done. So that will probably require a rotating queue of several semaphores and a fallback to cpu waiting. Why would it need a semaphore in CPU domain? Couldn't it work this way: 1. Allocate a BO in the kernel 2. Emit on one channel a notify request on that BO 3. Emit on the other channel a wait request on that BO 4. Emit a fence on the wait channel 5. Use the existing delayed-destroy mechanism to get rid of the BO once the wait channel fence expires Then the GPU would presumably switch away from the waiting context and not reexecute it until the notify happens, or something similar. The problem is, of course, whether the GPU supports the wait request. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
The card also keeps some internal FIFO caches, so it seems to me that getting that safe of races and efficient at the same time could be a bit non-trivial. Are they flushable? It seems this *might* do the job: if (!pfifo-cache_flush(dev)) return; pfifo-reassign(dev, false); pfifo-cache_flush(dev); pfifo-cache_pull(dev, false); pfifo-cache_pull(dev, true); pfifo-reassign(dev, true); -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
We had to do a similar thing in the Poulsbo driver and it turned out that we could save a significant amount of CPU by using a delayed workqueue, collecting objects and destroying them periodically. Yes, indeed, we don't really care about a fence expiring unless we want to use that buffer or we are out of memory. Processing each fence, especially if there is an interrupt per fence, seems unnecessary, since you can just do that work in the cases mentioned above. So, here is a new proposal that should have the best features of all previously considered methods. Assume first that there is a single FIFO channel. We introduce a list of fence nodes, each containing: - A list of buffers NOT to be destroyed having the fence as their sync object (or possibly one for each memory type) - A delayed-destroy list of buffers having the fence as their sync object Fence nodes are added at the end upon emission. They are removed and freed when the buffer count drops to 0 (meaning all buffers have been moved to later fences). Thus, the number of fence nodes does not grow without bounds, but is bounded by the number of buffers. . The LRU lists are changed to only contain unfenced buffers and buffers are initially put on it. When a buffer is fenced, it is removed from the LRU list or its current fence list, and added to the new fence (possibly destroying the old fence node in the process). The reference count of buffer objects is only increased when they are put in a delayed destruction list. Upon deletion, they are destroyed immediately if they are on the LRU list and moved to the corresponding delayed-delete list if they are in the fenced list. ttm_bo_delayed_delete is no longer called by any workqueue, but only on when we run out of memory, before we try eviction. It processes the list until the first unsignalled fence, destroying all buffers it finds and freeing all the fence nodes. All the buffers in the alive lists are put in the LRU list, in the correct order. We may either keep an alive list per memory type, or sort the buffers by memory type (so they are put in the memory type LRU list) at this point Thus, after ttm_bo_delayed_delete, there is the following scenario: 1. Inactive buffers with no references are destroyed 2. Inactive buffers with references are in the LRU list 3. Fenced buffers with no references are in the delayed-destroy list attached to their fence 4. Fenced buffers with references are in the alive list attached to their fence This should have about the same CPU and memory usage of the current code, but the following advantages: 1. Delayed deletion does not run periodically, but exactly when needed (at allocation time, before eviction) 2. Delayed deletion always deletes all buffers that can be deleted, since it processes them in fence order 3. The LRU list at eviction time contains exactly all evictable buffers 4. Each buffer is always on an LRU _or_ on a delayed destroy list, so only one node is necessary 5. Once buffer deletion determines a fence is signalled, it can destroyed all its to-be-destroyed buffers without any more checking 6. Some fence logic (such as signalling of all fences on channel forced closing) can be moved from drivers to TTM 7. Some channel logic can be moved from drivers to TTM 8. The code should be simpler and more elegant Note that using a buffer with the CPU doesn't change its position in the LRU list. This is good, because evicting a buffer used by the CPU is actually a good thing, since it will move to a region of memory slower for the GPU but possibly faster for the CPU. However, for buffers in system memory, if the LRU list is used for swapping, CPU access should move the buffer to the front of list (using the LRU list for this is probably a bad idea though, since system memory swapping should be at page granularity). For multiple channels, things are slightly more complex. First, we need to built the fence data structure for each channel. Also, we need the fence/buffer nodes to be separate Delayed destruction continues to work, but the reference count needs to be set to the number of channels fencing the buffer on destruction. Putting buffers in the LRU list can be done by doing n-way merging between the channel fence lists, assigning each fence a global sequence number, and using that to merge and put back buffers in the LRU. n-way merging can be done with a small heap on the stack on current hardware where channels are limited. Furthermore, we need to keep a reference count, so that buffers are put in the LRU (or destroyed) only after they are off all the channels. The LRU list semantics are relaxed. If a buffer has both its fence emitted before another buffer, and also signaled before it, then it will be considered as less recently used, and the opposite thing happens if both are after. Otherwise, the order is undetermined. This should still guarantee good eviction behavior, and allows to have the LRU list only contain evictable buffers, while not
Re: [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
Also note that the delayed delete list is not in fence order but in deletion-time order, which perhaps gives room for more optimizations. You are right. I think then that ttm_bo_delayed_delete may still need to be changed, because it stops when ttm_bo_cleanup_refs returns -EBUSY, which happens when a fence has not been reached. This means that a buffer will need to wait for all previously deleted buffers to become unused, even if it is unused itself. Is this acceptable? What if we get rid of the delayed destroy list, and instead append buffers to be deleted to their fence object, and delete them when the fence is signaled? This also allows to do it more naturally, since the fence object can just keep a normal reference to the buffers it fences, and unreference them on expiration. Then there needs to be no special delayed destruction logic, and it would work as if the GPU were keeping a reference to the buffer itself, using fences as a proxy to have the CPU do that work for the GPU. Then the delayed work is no longer periodically destroy buffers but rather periodically check if fences are expired, naturally stopping at the first unexpired one. Drivers that support IRQs on fences could also do the work in the interrupt handler/tasklet instead, avoid the delay jiffies magic number. This may need a NAPI-like interrupt mitigation middle layer for optimal results though. But isn't an atomic cmpxchg about as costly as a spinlock? I think it's cheaper on all architectures, as otherwise it would be mostly pointless to have it, since you can emulate it with a spinlock. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
When designing this, we should also keep in mind that some drivers (e.g. nouveau) have multiple FIFO channels, and thus we would like a buffer to be referenced for reading by multiple channels at once (and be destroyed only when all fences are expired, obviously). Also, hardware may support on-GPU inter-channel synchronization, and then multiple references may be for writing too. If we use an external dynamically allocated channel/buffer list node, we can support this (if the kernel allocators aren't fast enough, which they should be, we can just keep released ones linked to the bo to speed allocations). Note that in nouveau there is a small hardware limit to channels (up to 128 on nv50), but future hardware may possibly support unlimited channels. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete (v3, final)
Resending this with Thomas Hellstrom's signoff for merging into 2.6.33
ttm_bo_delayed_delete has a race condition, because after we do:
kref_put(nentry-list_kref, ttm_bo_release_list);
we are not holding the list lock and not holding any reference to
objects, and thus every bo in the list can be removed and freed at
this point.
However, we then use the next pointer we stored, which is not guaranteed
to be valid.
This was apparently the cause of some Nouveau oopses I experienced.
This patch rewrites the function so that it keeps the reference to nentry
until nentry itself is freed and we already got a reference to nentry-next.
v2 updated by me according to Thomas Hellstrom's feedback.
v3 proposed by Thomas Hellstrom. Commit comment updated by me.
Both updates fixed minor efficiency/style issues only and all three versions
should be correct.
Signed-off-by: Luca Barbieri l...@luca-barbieri.com
Signed-off-by: Thomas Hellstrom thellst...@vmware.com
---
drivers/gpu/drm/ttm/ttm_bo.c | 58 ++
1 files changed, 25 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c7733c3..1a3e909 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -524,52 +524,44 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object
*bo, bool remove_all)
static int ttm_bo_delayed_delete(struct ttm_bo_device *bdev, bool remove_all)
{
struct ttm_bo_global *glob = bdev-glob;
- struct ttm_buffer_object *entry, *nentry;
- struct list_head *list, *next;
- int ret;
+ struct ttm_buffer_object *entry = NULL;
+ int ret = 0;
spin_lock(glob-lru_lock);
- list_for_each_safe(list, next, bdev-ddestroy) {
- entry = list_entry(list, struct ttm_buffer_object, ddestroy);
- nentry = NULL;
+ if (list_empty(bdev-ddestroy))
+ goto out_unlock;
- /*
-* Protect the next list entry from destruction while we
-* unlock the lru_lock.
-*/
+ entry = list_first_entry(bdev-ddestroy,
+ struct ttm_buffer_object, ddestroy);
+ kref_get(entry-list_kref);
+
+ for (;;) {
+ struct ttm_buffer_object *nentry = NULL;
- if (next != bdev-ddestroy) {
- nentry = list_entry(next, struct ttm_buffer_object,
- ddestroy);
+ if (entry-ddestroy.next != bdev-ddestroy) {
+ nentry = list_first_entry(entry-ddestroy,
+ struct ttm_buffer_object, ddestroy);
kref_get(nentry-list_kref);
}
- kref_get(entry-list_kref);
spin_unlock(glob-lru_lock);
ret = ttm_bo_cleanup_refs(entry, remove_all);
kref_put(entry-list_kref, ttm_bo_release_list);
+ entry = nentry;
+
+ if (ret || !entry)
+ goto out;
spin_lock(glob-lru_lock);
- if (nentry) {
- bool next_onlist = !list_empty(next);
- spin_unlock(glob-lru_lock);
- kref_put(nentry-list_kref, ttm_bo_release_list);
- spin_lock(glob-lru_lock);
- /*
-* Someone might have raced us and removed the
-* next entry from the list. We don't bother restarting
-* list traversal.
-*/
-
- if (!next_onlist)
- break;
- }
- if (ret)
+ if (list_empty(entry-ddestroy))
break;
}
- ret = !list_empty(bdev-ddestroy);
- spin_unlock(glob-lru_lock);
+out_unlock:
+ spin_unlock(glob-lru_lock);
+out:
+ if (entry)
+ kref_put(entry-list_kref, ttm_bo_release_list);
return ret;
}
--
1.6.2.5
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
Would nentry=list_first_entry(entry-ddestroy, ) work?
Yes, it seems a bit less intuitive, but if that's the accepted
practice, let's do that instead.
Here nentry may have been removed from the list by another process, which
would trigger the unnecessary call, mentioned above.
You are right.
I attached a revised patch.
It's only compile tested, but the changes are small and it should
hopefully work.
Note that in principle we could remove the special-case code for the
list head but that would require pretending the list head is actually
inside a ttm_buffer_object and adding a flag to not do the
unlock/cleanup/put/lock on it, which seems bad.
The whole function seems more complicated than needed, but I can't
find a way to do it with less code. If we could keep glob-lru_lock
while calling ttm_bo_cleanup_refs things would be much simpler, but
that would require intrusive changes and may not be possible.
From 68972c220abe3ce19eb046d72fa218646168adc7 Mon Sep 17 00:00:00 2001
From: Luca Barbieri l...@luca-barbieri.com
Date: Mon, 18 Jan 2010 19:34:53 +0100
Subject: [PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete (v2)
ttm_bo_delayed_delete has a race condition, because after we do:
kref_put(nentry-list_kref, ttm_bo_release_list);
we are not holding the list lock and not holding any reference to
objects, and thus every bo in the list can be removed and freed at
this point.
However, we then use the next pointer we stored, which is not guaranteed
to be valid.
This was apparently the cause of some Nouveau oopses I experienced.
This patch rewrites the function so that it keeps the reference to nentry
until nentry itself is freed and we already got a reference to nentry-next.
It should now be correct and free of races, but please double check this.
Updated according to Thomas Hellstrom's feedback.
Signed-off-by: Luca Barbieri l...@luca-barbieri.com
---
drivers/gpu/drm/ttm/ttm_bo.c | 58 ++---
1 files changed, 26 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2920f9a..5dfa41f 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -523,52 +523,46 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object *bo, bool remove_all)
static int ttm_bo_delayed_delete(struct ttm_bo_device *bdev, bool remove_all)
{
struct ttm_bo_global *glob = bdev-glob;
- struct ttm_buffer_object *entry, *nentry;
- struct list_head *list, *next;
- int ret;
+ struct ttm_buffer_object *entry;
+ int ret = 0;
spin_lock(glob-lru_lock);
- list_for_each_safe(list, next, bdev-ddestroy) {
- entry = list_entry(list, struct ttm_buffer_object, ddestroy);
- nentry = NULL;
+ if (list_empty(bdev-ddestroy)) {
+ spin_unlock(glob-lru_lock);
+ return 0;
+ }
- /*
- * Protect the next list entry from destruction while we
- * unlock the lru_lock.
- */
+ entry = list_first_entry(bdev-ddestroy,
+ struct ttm_buffer_object, ddestroy);
+ kref_get(entry-list_kref);
+
+ for (;;) {
+ struct ttm_buffer_object *nentry = NULL;
- if (next != bdev-ddestroy) {
- nentry = list_entry(next, struct ttm_buffer_object,
- ddestroy);
+ if (entry-ddestroy.next != bdev-ddestroy) {
+ nentry = list_first_entry(entry-ddestroy,
+struct ttm_buffer_object, ddestroy);
kref_get(nentry-list_kref);
}
- kref_get(entry-list_kref);
spin_unlock(glob-lru_lock);
ret = ttm_bo_cleanup_refs(entry, remove_all);
kref_put(entry-list_kref, ttm_bo_release_list);
+ entry = nentry;
+
+ if (ret || !entry)
+ break;
spin_lock(glob-lru_lock);
- if (nentry) {
- bool next_onlist = !list_empty(next);
+
+ if (list_empty(entry-ddestroy)) {
spin_unlock(glob-lru_lock);
- kref_put(nentry-list_kref, ttm_bo_release_list);
- spin_lock(glob-lru_lock);
- /*
- * Someone might have raced us and removed the
- * next entry from the list. We don't bother restarting
- * list traversal.
- */
-
- if (!next_onlist)
-break;
- }
- if (ret)
break;
+ }
}
- ret = !list_empty(bdev-ddestroy);
- spin_unlock(glob-lru_lock);
+ if (entry)
+ kref_put(entry-list_kref, ttm_bo_release_list);
return ret;
}
--
1.6.3.3
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon: r6xx/r7xx possible security issue, system ram access
On Mon, Jan 18, 2010 at 1:01 PM, Jerome Glisse jgli...@redhat.com wrote:
This patch workaround a possible security issue which can allow
user to abuse drm on r6xx/r7xx hw to access any system ram memory.
[...]
diff --git a/drivers/gpu/drm/radeon/r600_cs.c
b/drivers/gpu/drm/radeon/r600_cs.c
index 44060b9..edafc7b 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -503,9 +531,61 @@ static int r600_packet3_check(struct radeon_cs_parser *p,
for (i = 0; i pkt-count; i++) {
reg = start_reg + (4 * i);
switch (reg) {
+ /* This register were added late, there is userspace
+ * which does provide relocation for those but set
+ * 0 offset. In order to avoid breaking old userspace
+ * we detect this and set address to point to last
+ * CB_COLOR0_BASE, note that if userspace doesn't set
+ * CB_COLOR0_BASE before this register we will report
+ * error. Old userspace always set CB_COLOR0_BASE
+ * before any of this.
+ */
+ case R_0280E0_CB_COLOR0_FRAG:
+ case R_0280E4_CB_COLOR1_FRAG:
+ case R_0280E8_CB_COLOR2_FRAG:
+ case R_0280EC_CB_COLOR3_FRAG:
+ case R_0280F0_CB_COLOR4_FRAG:
+ case R_0280F4_CB_COLOR5_FRAG:
+ case R_0280F8_CB_COLOR6_FRAG:
+ case R_0280FC_CB_COLOR7_FRAG:
+ case R_0280C0_CB_COLOR0_TILE:
+ case R_0280C4_CB_COLOR1_TILE:
+ case R_0280C8_CB_COLOR2_TILE:
+ case R_0280CC_CB_COLOR3_TILE:
+ case R_0280D0_CB_COLOR4_TILE:
+ case R_0280D4_CB_COLOR5_TILE:
+ case R_0280D8_CB_COLOR6_TILE:
+ case R_0280DC_CB_COLOR7_TILE:
+ if (!r600_cs_packet_next_is_pkt3_nop(p)) {
+ if (!track-cb_color0_base_last) {
+ dev_err(p-dev, Broken old
userspace ? no cb_color0_base supplied
+ before trying to
write 0x%08X\n, reg);
Cosmetic issue: a space is missing between supplied and before.
Luca
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/ttm: Fix race condition in ttm_bo_delayed_delete
ttm_bo_delayed_delete has a race condition, because after we do:
kref_put(nentry-list_kref, ttm_bo_release_list);
we are not holding the list lock and not holding any reference to
objects, and thus every bo in the list can be removed and freed at
this point.
However, we then use the next pointer we stored, which is not guaranteed
to be valid.
This was apparently the cause of some Nouveau oopses I experienced.
This patch rewrites the function so that it keeps the reference to nentry
until nentry itself is freed and we already got a reference to nentry-next.
It should now be correct and free of races, but please double check this.
Signed-off-by: Luca Barbieri l...@luca-barbieri.com
---
drivers/gpu/drm/ttm/ttm_bo.c | 58 +
1 files changed, 24 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 2920f9a..1daa2f1 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -523,52 +523,42 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object
*bo, bool remove_all)
static int ttm_bo_delayed_delete(struct ttm_bo_device *bdev, bool remove_all)
{
struct ttm_bo_global *glob = bdev-glob;
- struct ttm_buffer_object *entry, *nentry;
- struct list_head *list, *next;
- int ret;
+ struct ttm_buffer_object *entry;
+ int ret = 0;
spin_lock(glob-lru_lock);
- list_for_each_safe(list, next, bdev-ddestroy) {
- entry = list_entry(list, struct ttm_buffer_object, ddestroy);
- nentry = NULL;
+ if (list_empty(bdev-ddestroy)) {
+ spin_unlock(glob-lru_lock);
+ return 0;
+ }
- /*
-* Protect the next list entry from destruction while we
-* unlock the lru_lock.
-*/
+ entry = list_first_entry(bdev-ddestroy,
+ struct ttm_buffer_object, ddestroy);
+ kref_get(entry-list_kref);
- if (next != bdev-ddestroy) {
- nentry = list_entry(next, struct ttm_buffer_object,
- ddestroy);
+ for (;;) {
+ struct ttm_buffer_object *nentry = NULL;
+
+ if (!list_empty(entry-ddestroy)
+entry-ddestroy.next != bdev-ddestroy) {
+ nentry = list_entry(entry-ddestroy.next,
+ struct ttm_buffer_object, ddestroy);
kref_get(nentry-list_kref);
}
- kref_get(entry-list_kref);
spin_unlock(glob-lru_lock);
ret = ttm_bo_cleanup_refs(entry, remove_all);
kref_put(entry-list_kref, ttm_bo_release_list);
+ entry = nentry;
- spin_lock(glob-lru_lock);
- if (nentry) {
- bool next_onlist = !list_empty(next);
- spin_unlock(glob-lru_lock);
- kref_put(nentry-list_kref, ttm_bo_release_list);
- spin_lock(glob-lru_lock);
- /*
-* Someone might have raced us and removed the
-* next entry from the list. We don't bother restarting
-* list traversal.
-*/
-
- if (!next_onlist)
- break;
- }
- if (ret)
+ if (ret || !entry)
break;
+
+ spin_lock(glob-lru_lock);
}
- ret = !list_empty(bdev-ddestroy);
- spin_unlock(glob-lru_lock);
+ if (entry)
+ kref_put(entry-list_kref, ttm_bo_release_list);
return ret;
}
--
1.6.3.3
--
Throughout its 18-year history, RSA Conference consistently attracts the
world's best and brightest in the field, creating opportunities for Conference
attendees to learn about information security's most important issues through
interactions with peers, luminaries and emerging and established companies.
http://p.sf.net/sfu/rsaconf-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
On Wed, Dec 30, 2009 at 08:03:53AM +0100, Michel Dänzer wrote: On Tue, 2009-12-29 at 19:35 +0100, Luca Tettamanti wrote: Il Mon, Dec 28, 2009 at 05:27:13PM -0500, Alex Deucher ha scritto: 2009/12/28 Luca Tettamanti kronos...@gmail.com: On Mon, Dec 28, 2009 at 01:32:24PM -0500, Alex Deucher wrote: 2009/12/28 Luca Tettamanti kronos...@gmail.com: 2009/12/28 Alex Deucher alexdeuc...@gmail.com: On Mon, Dec 28, 2009 at 5:53 AM, Luca Tettamanti kronos...@gmail.com wrote: On Sun, Dec 27, 2009 at 1:55 AM, Rafał Miłecki zaj...@gmail.com wrote: W dniu 26 grudnia 2009 20:08 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: It may be that the engine doesn't like to be reclocked while it's running. Perhaps we should use the GUI idle interrupt rather than vblanks to reclock the engine. Could you say something more about GUI idle interrupt, please? It's mentioned in the documentation of the IH (see r600.c); I guess it's enabled by GUI_IDLE_INT_ENABLE. What is this, do we already have code for that? Unless there are more subtleties all is needed it to enabled the interrupt and catch it in r600_irq_process. That's pretty much it. Pre-r6xx asics have a GUI interrupt as well. I can look up the details for that if they are not already documented. I can't find a way to ack the interrupt; I see RADEON_GUI_IDLE_INT_TEST_ACK but I think it's for pre-r6xx cards, right? You don't have to ACK it as the CP generates the interrupt in software; similar to the sw interrupts used for fences. Ok, good: I've got the stub running on my M76. r100 and rs600 parts are untested. Comments? Looks pretty good. I've included the proper defines from the register database below and you'll need to ack the gui idle interrupts on pre-r600 chips. Now you just have to do something when you get the idle interrupt. I've adapted Rafał's patch to do the reclock when the idle interrupt is fired (which btw should take care of the special case for nr CRTCs 1). Unfortunately I still see the black frame when reclocking is performed. So I tried recloking directly from the IH (yeah, I'm ashamed of myself...); this got rid of the black frame, but causes corruption of a horizontal block of the screen (during the reclock, before and after the screen looks fine). If you mean the interrupt handler for the idle interrupt, Yes. have you tried doing it in the interrupt handler for the vblank interrupt instead? Not yet; I've tried a solution similar to what Xavier suggested: lock the ring, wait for idle, reclock (outside the IH), unlock and it still causes corruption (but not the black frame). The next iteration would be: lock cp wait for idle enable vblank wait for vlbank relock unlock cp With reclock that might be moved to the vblank interrupt if it still causes problems. Sounds sensible? This approach however reintroduces the issue with multiple active crtcs... Luca -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
On Wed, Dec 30, 2009 at 10:56 AM, Luca Tettamanti kronos...@gmail.com wrote:
On Wed, Dec 30, 2009 at 08:03:53AM +0100, Michel Dänzer wrote:
On Tue, 2009-12-29 at 19:35 +0100, Luca Tettamanti wrote:
Il Mon, Dec 28, 2009 at 05:27:13PM -0500, Alex Deucher ha scritto:
2009/12/28 Luca Tettamanti kronos...@gmail.com:
On Mon, Dec 28, 2009 at 01:32:24PM -0500, Alex Deucher wrote:
Looks pretty good. I've included the proper defines from the register
database below and you'll need to ack the gui idle interrupts on
pre-r600 chips. Now you just have to do something when you get the
idle interrupt.
I've adapted Rafał's patch to do the reclock when the idle interrupt is
fired (which btw should take care of the special case for nr CRTCs 1).
Unfortunately I still see the black frame when reclocking is performed.
So I tried recloking directly from the IH (yeah, I'm ashamed of
myself...); this got rid of the black frame, but causes corruption of a
horizontal block of the screen (during the reclock, before and after the
screen looks fine).
If you mean the interrupt handler for the idle interrupt,
Yes.
have you tried
doing it in the interrupt handler for the vblank interrupt instead?
Not yet; I've tried a solution similar to what Xavier suggested: lock the
ring,
wait for idle, reclock (outside the IH), unlock and it still causes corruption
(but not the black frame).
The next iteration would be:
lock cp
wait for idle
enable vblank
wait for vlbank
relock
unlock cp
With reclock that might be moved to the vblank interrupt if it still causes
problems. Sounds sensible?
I still see corruption... this is what I'm doing:
driver decides to reclock
take cp.mutex
wait_event(gui_idle)
idle interrupt {
set idle flag
wake_up()
}
drm_vblank_get
vblank interrupt {
reclock()
}
drm_vblank_put
release cp.mutex
-ENOIDEA
Luca
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
Il Mon, Dec 28, 2009 at 05:27:13PM -0500, Alex Deucher ha scritto:
2009/12/28 Luca Tettamanti kronos...@gmail.com:
On Mon, Dec 28, 2009 at 01:32:24PM -0500, Alex Deucher wrote:
2009/12/28 Luca Tettamanti kronos...@gmail.com:
2009/12/28 Alex Deucher alexdeuc...@gmail.com:
On Mon, Dec 28, 2009 at 5:53 AM, Luca Tettamanti kronos...@gmail.com
wrote:
On Sun, Dec 27, 2009 at 1:55 AM, Rafał Miłecki zaj...@gmail.com
wrote:
W dniu 26 grudnia 2009 20:08 użytkownik Alex Deucher
alexdeuc...@gmail.com napisał:
It may be that the engine doesn't like to be reclocked while it's
running. Perhaps we should use the GUI idle interrupt rather than
vblanks to reclock the engine.
Could you say something more about GUI idle interrupt, please?
It's mentioned in the documentation of the IH (see r600.c); I guess
it's enabled by GUI_IDLE_INT_ENABLE.
What is this, do we already have code for that?
Unless there are more subtleties all is needed it to enabled the
interrupt and catch it in r600_irq_process.
That's pretty much it. Pre-r6xx asics have a GUI interrupt as well.
I can look up the details for that if they are not already documented.
I can't find a way to ack the interrupt; I see
RADEON_GUI_IDLE_INT_TEST_ACK but I think it's for pre-r6xx cards,
right?
You don't have to ACK it as the CP generates the interrupt in
software; similar to the sw interrupts used for fences.
Ok, good: I've got the stub running on my M76. r100 and rs600 parts are
untested. Comments?
Looks pretty good. I've included the proper defines from the register
database below and you'll need to ack the gui idle interrupts on
pre-r600 chips. Now you just have to do something when you get the
idle interrupt.
I've adapted Rafał's patch to do the reclock when the idle interrupt is
fired (which btw should take care of the special case for nr CRTCs 1).
Unfortunately I still see the black frame when reclocking is performed.
So I tried recloking directly from the IH (yeah, I'm ashamed of
myself...); this got rid of the black frame, but causes corruption of a
horizontal block of the screen (during the reclock, before and after the
screen looks fine). In this second case I've added a spinlock to guard
the access to the CP ring, so nothing touches it while reclocking is
performed; however by the time we process the idle interrupt -
especially considering that multiple events might be queued in the IH
ring - someone else (i.e. one of the other cores) might already have
submitted more work; what do you think?
I'm attaching 3 patches; the first one contains the stub idle IH, the
second one is Rafał's patch adapted for idle interrupt (it's not very
polished), the third one moves reclocking to IH (and as is it's just an
ugly hack).
Luca
--
In linea di principio sarei indifferente al natale, se solo il natale
ricambiasse la cortesia e mi lasciasse in pace. -- Marco d'Itri
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/r600.c 2009-12-28 16:38:38.388825742 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/r600.c 2009-12-28 22:03:12.936157804 +0100
@@ -2458,6 +2458,7 @@
int r600_irq_set(struct radeon_device *rdev)
{
u32 cp_int_cntl = CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE;
+ u32 grbm_int_cntl;
u32 mode_int = 0;
u32 hpd1, hpd2, hpd3, hpd4 = 0, hpd5 = 0, hpd6 = 0;
@@ -2465,6 +2466,8 @@
if (!rdev-ih.enabled)
return 0;
+ grbm_int_cntl = RREG32(GRBM_INT_CNTL) ~GUI_IDLE_INT_ENABLE;
+
if (ASIC_IS_DCE3(rdev)) {
hpd1 = RREG32(DC_HPD1_INT_CONTROL) ~DC_HPDx_INT_EN;
hpd2 = RREG32(DC_HPD2_INT_CONTROL) ~DC_HPDx_INT_EN;
@@ -2484,6 +2487,10 @@
DRM_DEBUG(r600_irq_set: sw int\n);
cp_int_cntl |= RB_INT_ENABLE;
}
+ if (rdev-irq.idle_int) {
+ DRM_DEBUG(r600_irq_set: GUI idle int\n);
+ grbm_int_cntl |= GUI_IDLE_INT_ENABLE;
+ }
if (rdev-irq.crtc_vblank_int[0]) {
DRM_DEBUG(r600_irq_set: vblank 0\n);
mode_int |= D1MODE_VBLANK_INT_MASK;
@@ -2518,6 +2525,7 @@
}
WREG32(CP_INT_CNTL, cp_int_cntl);
+ WREG32(GRBM_INT_CNTL, grbm_int_cntl);
WREG32(DxMODE_INT_MASK, mode_int);
if (ASIC_IS_DCE3(rdev)) {
WREG32(DC_HPD1_INT_CONTROL, hpd1);
@@ -2806,6 +2814,9 @@
case 181: /* CP EOP event */
DRM_DEBUG(IH: CP EOP\n);
break;
+ case 233: /* GUI idle event */
+ DRM_DEBUG(IH: GUI idle\n);
+ break;
default:
DRM_ERROR(Unhandled interrupt: %d %d\n, src_id, src_data);
break;
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/radeon.h 2009-12-28 16:38:13.945836481 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/radeon.h 2009-12-28 22:02:48.964001788 +0100
@@ -343,6 +343,7 @@
struct radeon_irq {
bool installed;
bool sw_int;
+ bool idle_int;
/* FIXME: use a define max crtc rather than hardcode it */
bool crtc_vblank_int[2];
/* FIXME: use defines for max hpd/dacs */
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/radeon_irq_kms.c 2009-12-28 16:37:10.669823739 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/radeon_irq_kms.c
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
On Sun, Dec 27, 2009 at 1:55 AM, Rafał Miłecki zaj...@gmail.com wrote: W dniu 26 grudnia 2009 20:08 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: It may be that the engine doesn't like to be reclocked while it's running. Perhaps we should use the GUI idle interrupt rather than vblanks to reclock the engine. Could you say something more about GUI idle interrupt, please? It's mentioned in the documentation of the IH (see r600.c); I guess it's enabled by GUI_IDLE_INT_ENABLE. What is this, do we already have code for that? Unless there are more subtleties all is needed it to enabled the interrupt and catch it in r600_irq_process. L -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
2009/12/28 Alex Deucher alexdeuc...@gmail.com: On Mon, Dec 28, 2009 at 5:53 AM, Luca Tettamanti kronos...@gmail.com wrote: On Sun, Dec 27, 2009 at 1:55 AM, Rafał Miłecki zaj...@gmail.com wrote: W dniu 26 grudnia 2009 20:08 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: It may be that the engine doesn't like to be reclocked while it's running. Perhaps we should use the GUI idle interrupt rather than vblanks to reclock the engine. Could you say something more about GUI idle interrupt, please? It's mentioned in the documentation of the IH (see r600.c); I guess it's enabled by GUI_IDLE_INT_ENABLE. What is this, do we already have code for that? Unless there are more subtleties all is needed it to enabled the interrupt and catch it in r600_irq_process. That's pretty much it. Pre-r6xx asics have a GUI interrupt as well. I can look up the details for that if they are not already documented. I can't find a way to ack the interrupt; I see RADEON_GUI_IDLE_INT_TEST_ACK but I think it's for pre-r6xx cards, right? Luca -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] rs600: use correct mask for SW interrupt
The mask happens to be the same, but the IH is reading the status, not the
not the control register.
Signed-off-by: Luca Tettamanti kronos...@gmail.com
---
drivers/gpu/drm/radeon/rs600.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-2.6.git/drivers/gpu/drm/radeon/rs600.c
===
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/rs600.c 2009-12-28
22:31:17.295766620 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/rs600.c2009-12-28
22:32:30.927884090 +0100
@@ -396,7 +396,7 @@
}
while (status || r500_disp_int) {
/* SW interrupt */
- if (G_40_SW_INT_EN(status))
+ if (G_44_SW_INT(status))
radeon_fence_process(rdev);
/* Vertical blank interrupts */
if (G_007EDC_LB_D1_VBLANK_INTERRUPT(r500_disp_int))
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
On Mon, Dec 28, 2009 at 01:32:24PM -0500, Alex Deucher wrote:
2009/12/28 Luca Tettamanti kronos...@gmail.com:
2009/12/28 Alex Deucher alexdeuc...@gmail.com:
On Mon, Dec 28, 2009 at 5:53 AM, Luca Tettamanti kronos...@gmail.com
wrote:
On Sun, Dec 27, 2009 at 1:55 AM, Rafał Miłecki zaj...@gmail.com wrote:
W dniu 26 grudnia 2009 20:08 użytkownik Alex Deucher
alexdeuc...@gmail.com napisał:
It may be that the engine doesn't like to be reclocked while it's
running. Perhaps we should use the GUI idle interrupt rather than
vblanks to reclock the engine.
Could you say something more about GUI idle interrupt, please?
It's mentioned in the documentation of the IH (see r600.c); I guess
it's enabled by GUI_IDLE_INT_ENABLE.
What is this, do we already have code for that?
Unless there are more subtleties all is needed it to enabled the
interrupt and catch it in r600_irq_process.
That's pretty much it. Pre-r6xx asics have a GUI interrupt as well.
I can look up the details for that if they are not already documented.
I can't find a way to ack the interrupt; I see
RADEON_GUI_IDLE_INT_TEST_ACK but I think it's for pre-r6xx cards,
right?
You don't have to ACK it as the CP generates the interrupt in
software; similar to the sw interrupts used for fences.
Ok, good: I've got the stub running on my M76. r100 and rs600 parts are
untested. Comments?
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/r600.c2009-12-28
16:38:38.388825742 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/r600.c 2009-12-28 22:03:12.936157804
+0100
@@ -2458,6 +2458,7 @@
int r600_irq_set(struct radeon_device *rdev)
{
u32 cp_int_cntl = CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE;
+ u32 grbm_int_cntl;
u32 mode_int = 0;
u32 hpd1, hpd2, hpd3, hpd4 = 0, hpd5 = 0, hpd6 = 0;
@@ -2465,6 +2466,8 @@
if (!rdev-ih.enabled)
return 0;
+ grbm_int_cntl = RREG32(GRBM_INT_CNTL) ~GUI_IDLE_INT_ENABLE;
+
if (ASIC_IS_DCE3(rdev)) {
hpd1 = RREG32(DC_HPD1_INT_CONTROL) ~DC_HPDx_INT_EN;
hpd2 = RREG32(DC_HPD2_INT_CONTROL) ~DC_HPDx_INT_EN;
@@ -2484,6 +2487,10 @@
DRM_DEBUG(r600_irq_set: sw int\n);
cp_int_cntl |= RB_INT_ENABLE;
}
+ if (rdev-irq.idle_int) {
+ DRM_DEBUG(r600_irq_set: GUI idle int\n);
+ grbm_int_cntl |= GUI_IDLE_INT_ENABLE;
+ }
if (rdev-irq.crtc_vblank_int[0]) {
DRM_DEBUG(r600_irq_set: vblank 0\n);
mode_int |= D1MODE_VBLANK_INT_MASK;
@@ -2518,6 +2525,7 @@
}
WREG32(CP_INT_CNTL, cp_int_cntl);
+ WREG32(GRBM_INT_CNTL, grbm_int_cntl);
WREG32(DxMODE_INT_MASK, mode_int);
if (ASIC_IS_DCE3(rdev)) {
WREG32(DC_HPD1_INT_CONTROL, hpd1);
@@ -2806,6 +2814,9 @@
case 181: /* CP EOP event */
DRM_DEBUG(IH: CP EOP\n);
break;
+ case 233: /* GUI idle event */
+ DRM_DEBUG(IH: GUI idle\n);
+ break;
default:
DRM_ERROR(Unhandled interrupt: %d %d\n, src_id,
src_data);
break;
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/radeon.h 2009-12-28
16:38:13.945836481 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/radeon.h 2009-12-28
22:02:48.964001788 +0100
@@ -343,6 +343,7 @@
struct radeon_irq {
boolinstalled;
boolsw_int;
+ boolidle_int;
/* FIXME: use a define max crtc rather than hardcode it */
boolcrtc_vblank_int[2];
/* FIXME: use defines for max hpd/dacs */
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/radeon_irq_kms.c 2009-12-28
16:37:10.669823739 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/radeon_irq_kms.c 2009-12-28
22:03:01.508077338 +0100
@@ -67,6 +67,7 @@
/* Disable *all* interrupts */
rdev-irq.sw_int = false;
+ rdev-irq.idle_int = false;
for (i = 0; i 2; i++) {
rdev-irq.crtc_vblank_int[i] = false;
}
@@ -81,6 +82,7 @@
dev-max_vblank_count = 0x001f;
rdev-irq.sw_int = true;
+ rdev-irq.idle_int = true;
radeon_irq_set(rdev);
return 0;
}
@@ -95,6 +97,7 @@
}
/* Disable *all* interrupts */
rdev-irq.sw_int = false;
+ rdev-irq.idle_int = false;
for (i = 0; i 2; i++) {
rdev-irq.crtc_vblank_int[i] = false;
}
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/r100.c2009-12-28
22:30:59.079748392 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/r100.c 2009-12-28 22:41:07.803741755
+0100
@@ -246,6 +246,9 @@
if (rdev-irq.sw_int) {
tmp |= RADEON_SW_INT_ENABLE;
}
+ if (rdev-irq.idle_int) {
+ tmp |= RADEON_GUI_IDLE_INT_ENABLE;
+ }
if (rdev
Re: [PATCH] drm/radeon/kms: add dynamic engine reclocking (V9)
2009/12/25 Rafał Miłecki zaj...@gmail.com: W dniu 24 grudnia 2009 23:19 użytkownik Luca Tettamanti kronos...@gmail.com napisał: 2009/12/24 Rafał Miłecki zaj...@gmail.com: W dniu 24 grudnia 2009 17:32 użytkownik Luca Tettamanti kronos...@gmail.com napisał: I think it would be safer to execute that code in the IH (or in a tasklet, which is guaranteed to run after the handler); the only problem I see is that atom_execute_table allocates some memory (ws? workspace?), but the GFP flag can be easily adjusted; the rest of the ops seem safe. What do you think? Thank you for commenting. Indeed we have problems with engine reclocking not happening right after VBLANK. The conversion to bh is pretty simple, and it blows up in a spectacular way :-) Aside from the locking (mutex) which has to be reworked, the show stopper is atom_op_delay, which wants to schedule. In my BIOS the biggest delays in SetEngineClock are 200us, so it would be possible to use udelay; not sure if the msec path could use the same treatment. I've read LDD3 ch07.pdf again and I can see why I've chosen workqueue. AFAIU tasklets are similar to timers but without execution time as param. It seems to be something like execute it really soon. Not really, they're part of other half of the interrupt processing; pending tasklets run in softirq, and they are guaranteed to be executed after processing the hw interrupt. That's fine but the problem is we can not sleep in tasklet handler (handlers has to be atomic). As you noticed we need to sleep in reclocking (AtomBIOS command does). Well, I've converted atom_op_delay to busy loop and the tasket does work. Locking with CP is missing though. I think solution may be sleeping in radeon_pm_idle_work_handler in place where we currently set: rdev-pm.vblank_callback = true;. We would sleep and ask IRQ code to wake us on VBLANK. Maybe this would be fast enough solution? Or do you have other, better idea? Just keep in mind that we do sleep in radeon_set_engine_clock. I don't think it would change much in term of latency. I'll follow the other thread ;-) Luca -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: add dynamic engine reclocking (V9)
Il Tue, Dec 22, 2009 at 11:06:16PM +0100, Rafał Miłecki ha scritto: V2: reorganize functions, fix modesetting calls V3: rebase patch, use radeon's workqueue V4: enable on tested chipsets only, request VBLANK IRQs V5: enable PM on older hardware (IRQs, mode_fixup, dpms) V6: use separate dynpm module parameter V7: drop RADEON_ prefix, set minimum mode for dpms off V8: update legacy encoder call, fix order in rs600 IRQ V9: update compute_clocks call in legacy, not only DPMS_OFF Hello, I've yet to find time to test this patch, but I have a big architectural doubt: + if (rdev-pm.vblank_callback) + queue_work(rdev-wq, rdev-pm.reclock_work); + IIRC the reason to wait for VBLANK is to avoid reclocking the GPU while it's drawing; this is especially important when reclocking the memory (which is not done yet). Here however you defer the recloking to some indeterminate future... I think it would be safer to execute that code in the IH (or in a tasklet, which is guaranteed to run after the handler); the only problem I see is that atom_execute_table allocates some memory (ws? workspace?), but the GFP flag can be easily adjusted; the rest of the ops seem safe. What do you think? Luca -- Ci sono due cose che l'uomo non puo` nascondere: essere ubriaco ed essere innamorato. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: add dynamic engine reclocking (V9)
2009/12/24 Rafał Miłecki zaj...@gmail.com: W dniu 24 grudnia 2009 17:32 użytkownik Luca Tettamanti kronos...@gmail.com napisał: I think it would be safer to execute that code in the IH (or in a tasklet, which is guaranteed to run after the handler); the only problem I see is that atom_execute_table allocates some memory (ws? workspace?), but the GFP flag can be easily adjusted; the rest of the ops seem safe. What do you think? Thank you for commenting. Indeed we have problems with engine reclocking not happening right after VBLANK. The conversion to bh is pretty simple, and it blows up in a spectacular way :-) Aside from the locking (mutex) which has to be reworked, the show stopper is atom_op_delay, which wants to schedule. In my BIOS the biggest delays in SetEngineClock are 200us, so it would be possible to use udelay; not sure if the msec path could use the same treatment. Marry Christmas! :) Thanks, to you too! L -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] Fix warnings on drm_handle_t to pointer conversions
A drm_handle_t can be safely converted to a pointer and back even on a
64bit platform (where the size is not the same).
Signed-off-by: Luca Tettamanti kronos...@gmail.com
---
I looked at the kernel part of the ioctl and it seems that the handle is
always a 32bit quantity, but please double check this patch :)
xf86drm.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/xf86drm.c b/xf86drm.c
index 220aaa1..fcaf3f5 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -959,7 +959,7 @@ int drmAddMap(int fd, drm_handle_t offset, drmSize size,
drmMapType type,
if (drmIoctl(fd, DRM_IOCTL_ADD_MAP, map))
return -errno;
if (handle)
- *handle = (drm_handle_t)map.handle;
+ *handle = (drm_handle_t)(unsigned long)map.handle;
return 0;
}
@@ -967,7 +967,7 @@ int drmRmMap(int fd, drm_handle_t handle)
{
drm_map_t map;
-map.handle = (void *)handle;
+map.handle = (void *)(unsigned long)handle;
if(drmIoctl(fd, DRM_IOCTL_RM_MAP, map))
return -errno;
@@ -2103,7 +2103,7 @@ int drmAddContextPrivateMapping(int fd, drm_context_t
ctx_id,
drm_ctx_priv_map_t map;
map.ctx_id = ctx_id;
-map.handle = (void *)handle;
+map.handle = (void *)(unsigned long)handle;
if (drmIoctl(fd, DRM_IOCTL_SET_SAREA_CTX, map))
return -errno;
@@ -2120,7 +2120,7 @@ int drmGetContextPrivateMapping(int fd, drm_context_t
ctx_id,
if (drmIoctl(fd, DRM_IOCTL_GET_SAREA_CTX, map))
return -errno;
if (handle)
- *handle = (drm_handle_t)map.handle;
+ *handle = (drm_handle_t)(unsigned long)map.handle;
return 0;
}
Luca
--
La mia opinione puo` essere cambiata, ma non il fatto che ho ragione.
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] Fix warnings on drm_handle_t to pointer conversions
On Wed, Dec 23, 2009 at 10:05 PM, Robert Noland rnol...@2hip.net wrote: On Wed, 2009-12-23 at 21:36 +0100, Luca Tettamanti wrote: A drm_handle_t can be safely converted to a pointer and back even on a 64bit platform (where the size is not the same). Signed-off-by: Luca Tettamanti kronos...@gmail.com --- I looked at the kernel part of the ioctl and it seems that the handle is always a 32bit quantity, but please double check this patch :) It's size varies with architecture on non-linux. Ah, I see. The handle is a long under BSD. This patch shouldn't cause issues, Yes, under BSD the cast is superfluous, but harmless. however I would personally really like to see drm_handle_t used consistently and correctly. If handle were declared as drm_handle_t it would avoid a lot of casting in libdrm and would have allowed me to reliably use arbitrary handles for maps on both i386 and amd64, by defining drm_handle_t to off_t. As it happens, that requires minor touching of some of the DDX drivers though. struct drm_map is used as an ioctl argument, so changing the type there would break the ABI. Furthermore I fear that using a type whose size changes between i386 and amd64 would result in additional fun in maintaining the 32 bit compat interface ;-) Luca -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r600/KMS: hdmi audio setup
2009/12/19 Christian König deathsim...@vodafone.de: Hi, Am Samstag, den 19.12.2009, 15:37 +0100 schrieb Luca Tettamanti: - first of all, I have a M56 (RV630) which lacks the PCI audio function, I guess in this case the audio shouldn't be enabled at all That's definitely a bug, AFAIK regarding HDMI audio the M56 is R500 based and doesn't supports it at all. Typo, sorry: it's a M76 (the core is a RV630). - the r600_audio_update_hdmi callback: is it really necessary to call it 10 times/sec, even if no audio is playing? In a normal audio driver that would be done only on ALSA -open (or maybe -prepare) functions, but in this case it's not clear to me how the two pieces (drm and alsa) interacts (can someone point me to the relevant docs?). Maybe a tighter integration between them is needed? The timer was just a workaround and known regression of the usermode ddx. The hardware is capable of raising an IRQ on audio start/stop (the IRQ gets actually raised on any change of the audio settings, which the video driver must recognize to update the various hdmi settings). I see; still the driver could touch audio settings only when the audio device is actually open, no? At the time of writing this patch the IRQ code wasn't available so I just used the same workaround as the ddx, we should get rid of it as soon as stable IRQ support is available. Ok, cool :) thanks, Luca -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r600/KMS: hdmi audio setup
2009/12/20 Christian König deathsim...@vodafone.de: Am Sonntag, den 20.12.2009, 19:10 +0100 schrieb Luca Tettamanti: Typo, sorry: it's a M76 (the core is a RV630). Interesting, I always thought that every R6xx based chipset has an audio codec. Could you make sure that there is no audio codec on this chipset? Well, the corresponding PCI function is missing. The machine is an ASUS F3Sa; I known of similar machines (with the same GPU) that have the codec, I'm not sure why it's absent on this model. Take a look in the bios, its possible the codec is just disabled. No, the BIOS is pretty minimal... If there is really no audio codec could you make some register dumps? Sure. (by the way you can do this by specifying audio=0 as an module option). Yes, I'm aware of the parameter. thanks, Luca -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
r600/KMS: hdmi audio setup
Hello, I'm currently testing kernel 2.6.32-rc1 and the first thing I noticed is: [drm] Enabling audio support ..that, and 10 wakeup/s ;-) I'd like to share a couple comments: - first of all, I have a M56 (RV630) which lacks the PCI audio function, I guess in this case the audio shouldn't be enabled at all - the r600_audio_update_hdmi callback: is it really necessary to call it 10 times/sec, even if no audio is playing? In a normal audio driver that would be done only on ALSA -open (or maybe -prepare) functions, but in this case it's not clear to me how the two pieces (drm and alsa) interacts (can someone point me to the relevant docs?). Maybe a tighter integration between them is needed? thanks, Luca -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
R600/KMS: clock gating inconsistencies
Hello, while looking at the sources of r600/kms driver I noticed a possible bug in the dynclks code path. The kernel driver always executes DynamicClockGating ATOM table (via radeon_atom_set_clock_gating); the DDX drivers (both of them) instead execute EnableASIC_StaticPwrMgt while DynamicClockGating is executed only for chip families R600. Can someone shed some light? Bonus question: in atombios.h the comments indicate that DynamicClockGating is used internally by ASIC_Init, while EnableASIC_StaticPwrMgt should supposedly be used only by BIOS (at power on?)... is there some documentation about how the ATOM table should be used? Luca -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 2/3] drm modesetting core
Il Thu, May 17, 2007 at 06:04:54PM -0700, Jesse Barnes ha scritto: On Thursday, May 17, 2007, Luca Tettamanti wrote: Il Thu, May 17, 2007 at 03:37:45PM -0700, Jesse Barnes ha scritto: This patch adds the core of the new DRM based modesetting system. A couple of comments on drm_fb since I'm somewhat familiar with fb code: new file mode 100644 index 000..0d06792 --- /dev/null +++ b/linux-core/drm_edid.c @@ -0,0 +1,467 @@ +/* + * Copyright (c) 2007 Intel Corporation + * Jesse Barnes [EMAIL PROTECTED] + * + * DDC probing routines (drm_ddc_read drm_do_probe_ddc_edid) originally from + * FB layer. Hum, why are you duplicating them here? fbmon.c has the infrastructure for parsing and even fixing known-broken EDIDs. Yeah, there's more sharing that could be done... though I don't think the fb layer has the bits to actually grab EDIDs. There are the I2C functions (fb_do_probe_ddc_edid, fb_ddc_read - I wrote them for the radeon driver, but now are available for general use) which will issue the read command; fbmon.c has the stuff for parsing the EDID; you usualy build a DB of supported modes which is then used to validate the mode requested by the user. Of course each driver has to implement the I2C adapter. Also, DRM is shared with BSD... Your patch already uses 'struct i2c_adapter' in drm_edid.c, is it portable? Luca -- Vorrei morire ucciso dagli agi. Vorrei che di me si dicesse: ``Com'è morto?'' ``Gli è scoppiato il portafogli'' -- Marcello Marchesi - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 2/3] drm modesetting core
+struct drmfb_par {
+ struct drm_device *dev;
+ struct drm_framebuffer *fb;
+};
+
+static int drmfb_setcolreg(unsigned regno, unsigned red, unsigned
green,
+unsigned blue, unsigned transp,
+struct fb_info *info)
+{
+ struct drmfb_par *par = info-par;
+ struct drm_framebuffer *fb = par-fb;
+ if (regno 17)
+ return 1;
+
+ if (regno 16) {
+ switch (fb-depth) {
+ case 15:
+ fb-pseudo_palette[regno] = ((red 0xf800) 1) |
+ ((green 0xf800) 6) |
+ ((blue 0xf800) 11);
+ break;
+ case 16:
+ fb-pseudo_palette[regno] = (red 0xf800) |
+ ((green 0xfc00) 5) |
+ ((blue 0xf800) 11);
+ break;
+ case 24:
+ case 32:
+ fb-pseudo_palette[regno] = ((red 0xff00) 8) |
+ (green 0xff00) |
+ ((blue 0xff00) 8);
+ break;
+ }
+ }
+
+ return 0;
+}
+
+/* this will let fbcon do the mode init */
+static int drmfb_set_par(struct fb_info *info)
+{
+ struct drmfb_par *par = info-par;
+ struct drm_device *dev = par-dev;
+
+ drm_set_desired_modes(dev);
+ return 0;
+}
+
+static struct fb_ops drmfb_ops = {
+ .owner = THIS_MODULE,
+ // .fb_open = drmfb_open,
+ // .fb_read = drmfb_read,
+ // .fb_write = drmfb_write,
+ // .fb_release = drmfb_release,
+ // .fb_ioctl = drmfb_ioctl,
+ .fb_set_par = drmfb_set_par,
+ .fb_setcolreg = drmfb_setcolreg,
+ .fb_fillrect = cfb_fillrect,
+ .fb_copyarea = cfb_copyarea,
+ .fb_imageblit = cfb_imageblit,
+};
+
+int drmfb_probe(struct drm_device *dev, struct drm_framebuffer *fb)
+{
+ struct fb_info *info;
+ struct drmfb_par *par;
+ struct device *device = dev-pdev-dev;
+ struct fb_var_screeninfo *var_info;
+ unsigned long base, size;
+ int ret;
+
+ info = framebuffer_alloc(sizeof(struct drmfb_par), device);
+ if (!info){
+ return -EINVAL;
+ }
-ENOMEM? Plus, spurious brackets.
+ if (register_framebuffer(info) 0)
+ return -EINVAL;
You leak the fb_info structure on error path.
+
+ printk(KERN_INFO fb%d: %s frame buffer device\n, info-node,
+info-fix.id);
+ return 0;
+}
+EXPORT_SYMBOL(drmfb_probe);
Luca
--
Software is like sex; it's better when it's free.
Linus Torvalds
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
problem with Mach64 on FC5
Hi, I have alwayls post this problem on dri-users. I have Mach64 chipset and FC5; I compile the libdrm and module for 2.6.17-2187 kernel. I compiled only libdrm and drm module, not Mesa. Compilation finish succesfully, but when I restart xorg, I have this error on the kernel output: [drm:mach64_dma_init] *ERROR* mach64_dma_init called without lock held, held 0 owner c74358e0 [drm:drm_unlock] *ERROR* Process 3216 using kernel context 0 and this: (II) ATI(0): [drm] SAREA 2200+1208: 3408 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenByBusid: Searching for BusID pci::01:00.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenByBusid: drmOpenMinor returns 6 drmOpenByBusid: drmGetBusid reports pci::01:00.0 (II) ATI(0): [drm] DRM interface version 1.3 (II) ATI(0): [drm] created mach64 driver at busid pci::01:00.0 (II) ATI(0): [drm] added 8192 byte SAREA at 0xd0975000 (II) ATI(0): [drm] mapped SAREA 0xd0975000 to 0xb7655000 (II) ATI(0): [drm] framebuffer handle = 0xfd00 (II) ATI(0): [drm] added 1 reserved context for kernel (EE) ATI(0): [dri] ATIDRIScreenInit failed because of a version mismatch. [dri] mach64.o kernel module version is 2.0.0, but version 1.0 or greater is needed. [dri] Disabling DRI. (II) ATI(0): [drm] removed 1 reserved context for kernel (II) ATI(0): [drm] unmapping 8192 bytes of SAREA 0xd0975000 at 0xb7655000 in the Xorg's log. Can I modify the version from 2.0.0 to 2.0? Is possible? How I do?I try to watch the source code but I don't find any infos. My lspci -v information about Videocard is: 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64) (prog-if 00 [VGA]) Subsystem: NEC Corporation Unknown device 80b7 Flags: bus master, stepping, medium devsel, latency 66, IRQ 5 Memory at fd00 (32-bit, non-prefetchable) [size=16M] I/O ports at 2000 [size=256] Memory at fc10 (32-bit, non-prefetchable) [size=4K] [virtual] Expansion ROM at 2800 [disabled] [size=128K] Capabilities: [50] AGP version 1.0 Capabilities: [5c] Power Management version 1 Tell me, if you need some information. What i try to do? help me. thank you. bye. Luca -- Luca 'whitenoise' Foppiano PGP FP: F75D 7A82 B1A1 8E1C 0FBF 70E7 3519 62A5 2224 1766 blog: http://bayzone.wordpress.com - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon problems with current cvs code
On 5/11/06, Matthias Hopf [EMAIL PROTECTED] wrote: On May 03, 06 14:35:45 +0200, Luca Dionisi wrote: On 3/28/06, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: It will, just no yet. It's beeing developped on intel chipsets at the moment and will probably be ported over at one point. I can't tell more precisely. As far as you know, does the ATI binary driver have FBO support? It has pBuffer support, which is good enough for Xgl, if that's what you're asking. Yes, that is what I was asking. Thanks Mat. Apologies for my not so good english :) --Luca --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon problems with current cvs code
On 3/28/06, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: At the moment it works, but xgl is slow with movies. I saw this sentence in the suse site: Driver has neither pBuffer nor FBO support. When using a composite manager all windows are rendered in software and only compositing is hardware accelerated. Astonishingly, this works well enough for most use cases. What does it mean? That is, is the driver _never_ going to have that support? It will, just no yet. It's beeing developped on intel chipsets at the moment and will probably be ported over at one point. I can't tell more precisely. As far as you know, does the ATI binary driver have FBO support? I didn't try it, yet, but should I try, may I expect better performance? TIA --Luca --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid0709bid3057dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon problems with current cvs code
What does it mean? That is, is the driver _never_ going to have that support? It will, just no yet. It's beeing developped on intel chipsets at the moment and will probably be ported over at one point. I can't tell more precisely. Thanks Ben, have a nice work. --Luca --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon problems with current cvs code
On 3/25/06, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Sat, 2006-03-25 at 02:26 +0100, Luca Dionisi wrote: I'm having problems with Xorg built from cvs sources very recently. I've also built from cvs sources libdrm and the latest kernel (2.6.16) with the drm enabled for my card (radeon) I don't know for sure, but I think my problem is with the video driver (the ati open source driver) The syptom is that Xorg start, but sometimes it hangs hup very quickly, sometimes when I change VT, sometimes when I click the mouse, ... Most of the times my whole machine becomes unusable. Any help please! I attach the log and the xorg.conf Looks like the engine is going nuts. Can you try: - Disabling AGP fast write - Lowering AGP speed - Load DRM with option no_wb=1 - Try latest DRM CVS And tell me if any of these helps. Also, when you say very recently for your X.org build, when exactly did you get the ati driver from CVS ? If it was more than 4 days ago, it might be worth updating and trying again. Ben. Very recently was not enough recently. I updated again from cvs and now it all works. Just 2 questions: Load DRM with option no_wb=1 what is it for and how do I do it? Try latest DRM CVS I have kernel 2.6.16. I saw that source files such as radeon.c were identical to the ones in DRM CVS. Am I wrong? At the moment I have a kernel compiled without module support. And the radeon drm is built-in. Do I have to change that? At the moment it works, but xgl is slow with movies. I saw this sentence in the suse site: Driver has neither pBuffer nor FBO support. When using a composite manager all windows are rendered in software and only compositing is hardware accelerated. Astonishingly, this works well enough for most use cases. What does it mean? That is, is the driver _never_ going to have that support? Many thanks --Luca --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid0944bid$1720dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
radeon problems with current cvs code
I'm having problems with Xorg built from cvs sources very recently. I've also built from cvs sources libdrm and the latest kernel (2.6.16) with the drm enabled for my card (radeon) I don't know for sure, but I think my problem is with the video driver (the ati open source driver) The syptom is that Xorg start, but sometimes it hangs hup very quickly, sometimes when I change VT, sometimes when I click the mouse, ... Most of the times my whole machine becomes unusable. Any help please! I attach the log and the xorg.conf Xorg.0.log --- _XSERVTransSocketOpenCOTSServer: Unable to open socket for inet6 _XSERVTransOpen: transport open failed for inet6/guendaline:0 _XSERVTransMakeAllCOTSServerListeners: failed to open listener for inet6 X Window System Version 7.0.0 Release Date: 21 December 2005 X Protocol Version 11, Revision 0, Release 7.0 Build Operating System:Linux 2.6.13.4 i686 Current Operating System: Linux guendaline 2.6.16 #1 SMP PREEMPT Thu Mar 23 23:45:59 CET 2006 i686 Build Date: 22 March 2006 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /opt/xorg-develop/var/log/Xorg.0.log, Time: Sat Mar 25 01:25:57 2006 (++) Using config file: /opt/xorg-develop/etc/X11/xgl-tester (==) ServerLayout X.org Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device Card0 (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (WW) The directory /opt/xorg-develop/lib/X11/fonts/local/ does not exist. Entry deleted from font path. (WW) The directory /opt/xorg-develop/lib/X11/fonts/CID/ does not exist. Entry deleted from font path. (**) FontPath set to /opt/xorg-develop/lib/X11/fonts/misc/,/opt/xorg-develop/lib/X11/fonts/100dpi/:unscaled,/opt/xorg-develop/lib/X11/fonts/75dpi/:unscaled,/opt/xorg-develop/lib/X11/fonts/TTF/,/opt/xorg-develop/lib/X11/fonts/Type1/,/opt/xorg-develop/lib/X11/fonts/Speedo/,/opt/xorg-develop/lib/X11/fonts/100dpi/,/opt/xorg-develop/lib/X11/fonts/75dpi/ (**) RgbPath set to /opt/xorg-develop/share/X11/rgb (**) ModulePath set to /opt/xorg-develop/lib/X11/modules (II) Module ABI versions: X.Org ANSI C Emulation: 0.2 X.Org Video Driver: 0.8 X.Org XInput driver : 0.5 X.Org Server Extension : 0.2 X.Org Font Renderer : 0.4 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /opt/xorg-develop/lib/X11/modules/fonts/libbitmap.so (II) Module bitmap: vendor=X.Org Foundation compiled for 7.0.0, module version = 1.0.0 Module class: X.Org Font Renderer ABI class: X.Org Font Renderer, version 0.4 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /opt/xorg-develop/lib/X11/modules/libpcidata.so (II) Module pcidata: vendor=X.Org Foundation compiled for 7.0.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 0.8 (--) using VT number 7 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 1106,3189 card 1043,807f rev 00 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 1106,b168 card , rev 00 class 06,04,00 hdr 01 (II) PCI: 00:10:0: chip 1106,3038 card 1043,80a1 rev 80 class 0c,03,00 hdr 80 (II) PCI: 00:10:1: chip 1106,3038 card 1043,80a1 rev 80 class 0c,03,00 hdr 80 (II) PCI: 00:10:2: chip 1106,3038 card 1043,80a1 rev 80 class 0c,03,00 hdr 80 (II) PCI: 00:10:3: chip 1106,3104 card 1043,80a1 rev 82 class 0c,03,20 hdr 00 (II) PCI: 00:11:0: chip 1106,3177 card 1043,80a1 rev 00 class 06,01,00 hdr 80 (II) PCI: 00:11:1: chip 1106,0571 card 1043,80a1 rev 06 class 01,01,8a hdr 00 (II) PCI: 00:11:5: chip 1106,3059 card 1043,80a1 rev 50 class 04,01,00 hdr 00 (II) PCI: 00:12:0: chip 1106,3065 card 1043,80a1 rev 74 class 02,00,00 hdr 00 (II) PCI: 01:00:0: chip 1002,5157 card 174b,7161 rev 00 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) Bus 0 prefetchable memory range: [0] -1 0 0x - 0x (0x0) MX[B] (II) PCI-to-PCI bridge: (II) Bus 1: bridge is at (0:1:0), (0,1,1), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 1 I/O range: [0] -1 0 0xd000 - 0xdfff (0x1000) IX[B] (II) Bus 1 non-prefetchable memory range: [0] -1 0 0xef00 - 0xefef (0xf0) MX[B] (II) Bus 1 prefetchable memory range: [0] -1 0 0xeff0 - 0xf7ff (0x810) MX[B] (II) PCI-to-ISA bridge: (II) Bus -1: bridge is at (0:17:0), (0,-1,-1), BCTRL: 0x0008 (VGA_EN is set) (--)
Re: ATI AIW Radeon 9800 Pro - LockUp
Il Fri, Jan 06, 2006 at 05:05:03PM -0500, Alex Deucher ha scritto: On 1/6/06, Adam K Kirchhoff [EMAIL PROTECTED] wrote: Benjamin Herrenschmidt wrote: On Thu, 2006-01-05 at 11:05 +0100, Jerome Glisse wrote: On 1/5/06, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Thu, 2006-01-05 at 02:30 +0100, Jerome Glisse wrote: On 1/5/06, Jon [EMAIL PROTECTED] wrote: I have a ATI AIW Radeon 9800 Pro (r350), I'm getting plenty of freezing with r300 DRI module. I tried Quake3 (wont get past beginning of opening game video, locks computer solid) and Xmoto (lasts for a few seconds than computer locks) GLXGears runs fine and for a long time, no freezing. (10755 frames in 5.0 sec = 2151 FPS etc) I'm using FreeBSD 6.0 Stable, I just built from cvs at freedesktop.org Mesa3D ,DRM kernel module and the r300 DRI module. Is their anything I can test or do? -- Thanks I have been trying to track down the issue during last few month. No success so far, maybe i am not a good hunter ;). Anyway could you test to first run an xserver with fglrx (no need for the drm module) and then run a server with r300 and see if you still have lockup (you shouldn't) thus i know you probably face the same lockup as i do. Have you tried checking what's going on with the card memory map ? (values of MC_AGP_LOCATION, MC_FB_LOCATION, CONFIG_MEMSIZE, CONFIG_APER_SIZE, HDP control and how they are munged by X and DRI ? There is definitely a bug or two lurking around when we have CONFIG_APER_SIZE smaller than CONFIG_MEMSIZE that might be causing those lockups). So far i have quite ignored such things. I will take a closer look to that, i haven't even tested your patch on that. I will give it a try. You may have to hack the kernel DRM too so that it puts the same values in there, currently, it's broken too. Ben. Is it safe to say that this is only a problem for cards with 256 bit memory interfaces? From http://en.wikipedia.org/wiki/Radeon_9700_core: Radeon 9700 275 256-bit Radeon 9800 325 256-bit Radeon 9700 Pro 325 256-bit Radeon 9800 Pro 380 256-bit Radeon 9800 XT 412 256-bit Do all these experience the same lockups? I think 9500s have the same problem. I've a 9500 Pro: 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R300 NE [Radeon 9500 Pro] I sometimes use blender and it seems rock solid. I've now tried UT (the first one - it's the only game that I've here...) and it randomly locks up: sometimes it happens after a few minutes, sometimes it takes 20-30 minutes... so it seems a different problem. Luca -- Home: http://kronoz.cjb.net Io mi ricordo sempre il compleanno della mia ragazza: cade il giorno dopo di quando lei me lo ricorda --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ATI documentation
Il Sun, Dec 25, 2005 at 07:06:24PM +0100, Philipp Klaus Krause ha scritto: ATI stated that they will not release any information about there hardware to developers of free drivers in the foreseeable future. Well, judging from comments posteed on this list it's somewhat expected X_X They were asked by the German computer magazine c't. You can find the information on page 168 in the magazine from 27.12.2005. Can you post a brief summary? Luca -- Home: http://kronoz.cjb.net L'amore consiste nell'essere cretini insieme. -- P. Valery --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637alloc_id=16865op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[R300] Activating Fast Write mode kills the machine
= 0xaf554000, end = 0xaf754000, offset = 0xd0102000 [drm:drm_mmap]Type = 3; start = 0xaf554000, end = 0xaf754000, offset = 0xd0102000 [drm:drm_vm_open] 0xaf554000,0x0020 [drm:drm_ioctl] pid=2464, cmd=0xc0186415, nr=0x15, dev 0xe200, auth=1 [drm:drm_addmap_core] offset = 0x00302000, size = 0x004e, type = 3 [drm:drm_mmap] start = 0xaf074000, end = 0xaf554000, offset = 0xd0302000 [drm:drm_mmap]Type = 3; start = 0xaf074000, end = 0xaf554000, offset = 0xd0302000 [drm:drm_vm_open] 0xaf074000,0x004e [drm:drm_ioctl] pid=2464, cmd=0x80206433, nr=0x33, dev 0xe200, auth=1 [drm:drm_ioctl] pid=2464, cmd=0xc0186415, nr=0x15, dev 0xe200, auth=1 [drm:drm_addmap_core] offset = 0xe900, size = 0x0008, type = 1 [drm:drm_addmap_core] Matching maps of type 1 with mismatched sizes, (524288 vs 65536) Luca -- Home: http://kronoz.cjb.net L'abilita` politica e` l'abilita` di prevedere quello che accadra` domani, la prossima settimana, il prossimo mese e l'anno prossimo. E di essere cosi` abili, piu` tardi, da spiegare perche' non e` accaduto. --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] Activating Fast Write mode kills the machine
Il Fri, Nov 11, 2005 at 12:40:10PM -0500, Felix Kühling ha scritto: Am Freitag, den 11.11.2005, 16:26 +0100 schrieb Luca: Hi, I installed the latest X.Org server from Debian (6.8.99.901.dfsg.1-2) and decided to try DRI (I have a Radeon 9500 Pro). When X.Org starts with AGPFastWrite enabled it immediatly kills the machine (no network, no serial console, no sysrq). AGPFastWrite is known to be unstable with many AGP chipsets. Is it a hardware bug or lack of docs on how it's implemented? Even when it does work it's not much of a performance win anyways. I can live without it ;) I don't use and 3D intensive application anyway, I was just testing the DRI driver for the R300... Luca -- Home: http://kronoz.cjb.net Il coraggio non mi manca. E` la paura che mi frega... --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[BUG] Compile bug in Direct Rendering Manager (kernel 2.6.11-rc1)
/char/drm/gamma_drv.o] Error 1 make[2]: *** [drivers/char/drm] Error 2 make[1]: *** [drivers/char] Error 2 make: *** [drivers] Error 2 [...] CONFIG_DRM=m CONFIG_DRM_TDFX=m CONFIG_DRM_GAMMA=m CONFIG_DRM_R128=m CONFIG_DRM_RADEON=m CONFIG_DRM_I810=m CONFIG_DRM_I830=m CONFIG_DRM_I915=m CONFIG_DRM_MGA=m CONFIG_DRM_SIS=m [...] Linux gandalf 2.6.10 #2 Wed Jan 12 18:32:56 CET 2005 i686 GNU/Linux Gnu C 3.3.4 Gnu make 3.80 binutils 2.15 util-linux 2.12 mount 2.12 module-init-tools 3.1 e2fsprogs 1.35 reiserfsprogs line reiser4progs line PPP2.4.2 Linux C Library2.3.2 Dynamic linker (ldd) 2.3.2 Procps 3.2.1 Net-tools 1.60 Kbd[opzione...] Console-tools 0.2.3 Sh-utils 5.2.1 udev 042 Regards, Luca -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQEVAwUBQeZSXhZrwl7j21nOAQI4WQf/VxwPkv0nh0nXIDqxflIKHbcT3WM6z/Lu 7bV765QOnvDs+YNLrHyWNoePOP5MeDozNxSDbba9GKJUoiGoFiAhNfgqJHXYVFjq TDpEnVVF1gREsl2IzJv7EI1rqaSn86vOwZzqgEudxnwyOWSlnlVKZ8ux0TnqhWL7 KVJ2xKqN8vx1k1CGg7o//r2/YZUFUbsBo+FHfsPumbdjYyQokK4tUGBsti+etOuh DKTw39pdv9n2GfTIzQWy7AhvNWG2I8n9mT/iGsz4crBaemI4BwwhjlqMr5yQGVL0 UoMuRVVOzqjFnf0B3Mj6E7pMlYk9Rv3Q+MRekFVtfJyhu762tLKDZg== =J7gM -END PGP SIGNATURE- --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r250 and black screen
As suggested I tried to connect a vga cable, and seem to work even in dvi mode. Thanks for the info! regards, Luca --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r250 and black screen
I investigated the problem a bit before I returned that card. I was able to get the same effect by running x11perf for a while. So I suspect it's not directly related to DRI or the 3D engine but a general power supply or overheating problem that occurs when the chip is stressed for some time. I tried to use proprietary ati driver to see if they have the same problem and everythink worked well even without the vga cable connected. This seems to exclude a hardware problem. regards Luca --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r250 and black screen
I investigated the problem a bit before I returned that card. I was able to get the same effect by running x11perf for a while. So I suspect it's not directly related to DRI or the 3D engine but a general power supply or overheating problem that occurs when the chip is stressed for some time. I tried to use proprietary ati driver to see if they have the same problem and everythink worked well even without the vga cable connected. This seems to exclude a hardware problem. regards Luca -- Email.it, the professional e-mail, gratis per te: http://www.email.it/f Sponsor: Rinfresca la tua estate con i climatizzatori ed i ventilatori * che trovi disponibili Crios, Orieme, Hokkaido, Argo, Carrier, Vortice Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2650d=6-9 --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=5047alloc_id=10808op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
r250 and black screen
I have an ati 9000 on a asus a7n8x-x. the direct rendering works well, and I can use glxgears, celestia and some other application that need it, but a lot of games don't work. For example when I try to start tuxracer the screen goes black and I can only exit pressing esc. I can listen game's audio, but the video is completely black. I looked for some errors, but I didn't find anything. I have this problem whith xfree 4.3 xfree 4.4 and x.org on Fedora, mandrake, debian, slackware (9.1/10/current). I installed last version of dri following http://dri.sourceforge.net/cgi-bin/moin.cgi/Building but the problem is not resolved. I attached the output of glxinfo and xorg.conf I don't know what log can be useful for understand the problem, so I attend your requests ;) regards, Luca PS: Your antispam filter block the smtp server of one of the most used italian provider (fastweb 213.140.2.52) glxinfo Description: Binary data xorg.conf Description: Binary data
