[Bug 13683] Internal Laptopdisplay blurrys to white screen after enabling modesetting on Radeon X700 Mobility
http://bugzilla.kernel.org/show_bug.cgi?id=13683 --- Comment #23 from Jan Kreuzer kontrolla...@gmx.de 2009-11-20 08:37:49 --- Still the same with latest git. Is it possible that the bios lies about the connectors ? When i used the real old non-kms, non-xrandr radeon driver i had to specify MonitorLayout LVDS,none to get an screen, else i got the white-screen. I experimented with the video kernel-command-line, when i used video=1280x800 for all outputs i dont get the whitescreen instead the screen flickers and displays nothing. How could i force the kernel to use LVDS as first connector ? Greetings Jan -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25193] Git 3f2c77659ca552c43f544228f3a5a5fe6365513a breaks here
http://bugs.freedesktop.org/show_bug.cgi?id=25193 --- Comment #2 from Fabio fabio@libero.it 2009-11-20 00:59:13 PST --- (In reply to comment #1) Sounds like you are building against an old version of libdrm_radeon. To update build libdrm configured with --enable-radeon-experimental-api To avoid this problem current libdrm should be tagged as 2.4.16 and mesa should require libdrm_radeon = 2.4.16. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25179] File radeon_dma.c function radeonReleaseDmaRegions line 348 - Leaking dma buffer object!
http://bugs.freedesktop.org/show_bug.cgi?id=25179 --- Comment #2 from Fabio fabio@libero.it 2009-11-20 01:09:36 PST --- Does it work without that fix for the 7.6 branch? No, with a clean clone of 7.7 branch it asserts in a similar way to bug #24131 (see below). Apparently the Leaking dma buffer object! and the Assertion `bo_legacy-is_pending = bo-cref' failed. issues are related, and the commit: http://cgit.freedesktop.org/mesa/mesa/commit/?h=mesa_7_6_branchid=13b5a624b1899c457279907d58046dfb3c95addc only hide the real problem, and make new issues appear: https://bugs.launchpad.net/bugs/459961 *WARN_ONCE* File radeon_dma.c function radeonReleaseDmaRegions line 348 Leaking dma buffer object! *** doom.x86: radeon_bo_legacy.c:207: legacy_is_pending: Assertion `bo_legacy-is_pending = bo-cref' failed. signal caught: Aborted si_code -6 Trying to exit gracefully.. - Game Map Shutdown -- -- Shutting down sound hardware --- Alsa Shutdown close pcm dlclose -- idRenderSystem::Shutdown() doom.x86: radeon_bo_legacy.c:207: legacy_is_pending: Assertion `bo_legacy-is_pending = bo-cref' failed. double fault Aborted, bailing out shutdown terminal support -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25197] New: [REGRESSION] openarena: vbo/vbo_exec_api.c:881: vbo_exec_FlushVertices: Assertion `callDepth == 1' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=25197 Summary: [REGRESSION] openarena: vbo/vbo_exec_api.c:881: vbo_exec_FlushVertices: Assertion `callDepth == 1' failed. Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: zaj...@gmail.com openarena: radeon_mipmap_tree.c:422: migrate_image_to_miptree: Assertion `dstlvl-width == image-base.Width' failed. (...) openarena: vbo/vbo_exec_api.c:881: vbo_exec_FlushVertices: Assertion `callDepth == 1' failed. Using mesa master, first bad commit: commit 3f2c77659ca552c43f544228f3a5a5fe6365513a Merge: b09e749 f8ea531 Author: Dave Airlie airl...@itt42.(none) Date: Fri Nov 20 11:48:10 2009 +1000 Merge remote branch 'origin/mesa_7_7_branch' I guess this commit was supposed to fix some bugs like bug #22372 but introduced regression for me. Would you like me to bisect this? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25197] [REGRESSION] openarena: vbo/vbo_exec_api.c:881: vbo_exec_FlushVertices: Assertion `callDepth == 1' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=25197 --- Comment #1 from Rafał Miłecki zaj...@gmail.com 2009-11-20 03:15:26 PST --- Created an attachment (id=31335) -- (http://bugs.freedesktop.org/attachment.cgi?id=31335) openarena.log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25198] New: [R6XX] : System hard hangs on launching OpenGL application
http://bugs.freedesktop.org/show_bug.cgi?id=25198 Summary: [R6XX] : System hard hangs on launching OpenGL application Product: Mesa Version: git Platform: x86 (IA32) OS/Version: other Status: NEW Severity: critical Priority: high Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: hysv...@gmail.com Created an attachment (id=31336) -- (http://bugs.freedesktop.org/attachment.cgi?id=31336) glxinfo Details of the X-stack: -- mesa/drm : 5th November-2009 mesa/mesa : 7.7 xorg/xserver : 1.6.0 xorg/xf86-video-ati: 5th November-2009 O.S.- Ubuntu-9.04-32/64 ASIC-R6XX Steps to Reproduce: == 1) Install Phoronix-test-suite version 1.8.1 from http://www.phoronix- test-suite.com/download.php?file=phoronix-test-suite-1.8.1 a) untar the phoronix-test-suie b) #cd phoronix-test-suite c) #sh install.sh 2) Install test #phoronix-test-suite install video-extensions 3) #phoronix-test-suite run video-extensions Observation: System hard hangs on application launch. Additional Info : 1) The problem is specific to R6xx. The OpenGL application runs fine with R5xx series cards. 2) For some OpenGL applications (example: norsetto-shadow), the application just fails to launch 3) glxgears crashes with the following message : drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25198] [R6XX] : System hard hangs on launching OpenGL application
http://bugs.freedesktop.org/show_bug.cgi?id=25198 --- Comment #1 from samit vats hysv...@gmail.com 2009-11-20 03:41:48 PST --- Created an attachment (id=31337) -- (http://bugs.freedesktop.org/attachment.cgi?id=31337) Xorg.log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25198] [R6XX] : System hard hangs on launching OpenGL application
http://bugs.freedesktop.org/show_bug.cgi?id=25198 --- Comment #2 from samit vats hysv...@gmail.com 2009-11-20 03:42:14 PST --- Created an attachment (id=31338) -- (http://bugs.freedesktop.org/attachment.cgi?id=31338) xorg.conf -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25198] [R6XX] : System hard hangs on launching OpenGL application
http://bugs.freedesktop.org/show_bug.cgi?id=25198 --- Comment #3 from samit vats hysv...@gmail.com 2009-11-20 03:42:55 PST --- Created an attachment (id=31339) -- (http://bugs.freedesktop.org/attachment.cgi?id=31339) lspci -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25198] [R6XX] : System hard hangs on launching OpenGL application
http://bugs.freedesktop.org/show_bug.cgi?id=25198 --- Comment #4 from samit vats hysv...@gmail.com 2009-11-20 03:43:29 PST --- Created an attachment (id=31340) -- (http://bugs.freedesktop.org/attachment.cgi?id=31340) glxgears-log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25197] [REGRESSION] openarena: vbo/vbo_exec_api.c:881: vbo_exec_FlushVertices: Assertion `callDepth == 1' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=25197 Maciej Cencora m.cenc...@gmail.com changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #2 from Maciej Cencora m.cenc...@gmail.com 2009-11-20 03:54:52 PST --- This is probably a duplicate of 25177. No need to bisect. I'll try reproducing it on my machine. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25193] Git 3f2c77659ca552c43f544228f3a5a5fe6365513a breaks here
http://bugs.freedesktop.org/show_bug.cgi?id=25193 --- Comment #3 from Ed Tomlinson e...@aei.ca 2009-11-20 04:04:24 PST --- This turns out not to be the case. As stated in the initial report libdrm is from git. My log shows the correct api enabled: Emerging (1 of 1) x11-libs/libdrm- from x11 * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] Unpacking source... * GIT update -- *repository: git://anongit.freedesktop.org/git/mesa/drm Already up-to-date. *at the commit:b4312b639d56a6cad78953af0fd4f863182007e3 *branch: master *storage directory:/usr/portage/distfiles/git-src/libdrm Switched to a new branch 'branch-master' Unpacked to /var/tmp/portage/x11-libs/libdrm-/work/libdrm- * Running eautoreconf in '/var/tmp/portage/x11-libs/libdrm-/work/libdrm-' ... * Running aclocal ... [ ok ] * Running libtoolize --copy --force --install --automake ... [ ok ] * Running aclocal ... [ ok ] * Running autoconf ... [ ok ] * Running autoheader ... [ ok ] * Running automake --add-missing --copy --foreign ... [ ok ] * Running elibtoolize in: libdrm- * Applying portage-2.2.patch ... * Applying sed-1.5.6.patch ... * Applying as-needed-2.2.6.patch ... Source unpacked in /var/tmp/portage/x11-libs/libdrm-/work Compiling source in /var/tmp/portage/x11-libs/libdrm-/work/libdrm- ... * econf: updating libdrm-/config.sub with /usr/share/gnuconfig/config.sub * econf: updating libdrm-/config.guess with /usr/share/gnuconfig/config.guess ./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --prefix=/usr --datadir=/usr/share --enable-udev --enable-nouveau-experimental-api --enable-radeon-experimental-api -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25142] touhou 11/12 run very slow in wine
http://bugs.freedesktop.org/show_bug.cgi?id=25142 --- Comment #1 from Allen Walker walkerallen...@googlemail.com 2009-11-20 04:51:46 PST --- Created an attachment (id=31341) -- (http://bugs.freedesktop.org/attachment.cgi?id=31341) short xorg session with touhou 11 running I compiled xorg-server-1.7.1.901 with -pg and ran a short session with touhou 11. Note: I didn't recompile any other libraries which link against the Xorg executable. If anybody could enlighten me if I need to do so and what (or say to just drop it) it would be helpful. Some more information about the bug: - the program shows an animated loading screen at startup - the program runs for 1-2 seconds at full speed, then suddenly the framerate drops - during that time nothing visible changes (still at the loading screen, same animations, same sprites) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
drm_fb_helper: Impossible to change video mode
Hi,
On drivers using drm_fb_helper's in fb_ops it is not possible to change
video mode, because of different var-pixclock evaluation:
int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
{
[...]
if (var-pixclock == -1 || !var-pixclock)
return -EINVAL;
[...]
int drm_fb_helper_set_par(struct fb_info *info)
{
[...]
if (var-pixclock != -1) {
DRM_ERROR(PIXEL CLCOK SET\n);
return -EINVAL;
}
[...]
One of these evaluations will fail regardless of pixclock value.
P.S. check CLCOK spelling :)
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/3] drm/ttm: Add range validation function
Add a function to validate buffer in a given range of
memory. This is needed by some hw for some of their
buffer (scanout buffer, cursor ...).
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/ttm/ttm_bo.c| 305 ++-
include/drm/ttm/ttm_bo_api.h|5 +
include/drm/ttm/ttm_bo_driver.h |1 +
3 files changed, 310 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 87c0625..6b0e7e8 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -247,7 +247,6 @@ EXPORT_SYMBOL(ttm_bo_unreserve);
/*
* Call bo-mutex locked.
*/
-
static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, bool zero_alloc)
{
struct ttm_bo_device *bdev = bo-bdev;
@@ -418,6 +417,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object
*bo, bool remove_all)
kref_put(bo-list_kref, ttm_bo_ref_bug);
}
if (bo-mem.mm_node) {
+ bo-mem.mm_node-private = NULL;
drm_mm_put_block(bo-mem.mm_node);
bo-mem.mm_node = NULL;
}
@@ -610,6 +610,7 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
unsigned mem_type,
spin_lock(glob-lru_lock);
if (evict_mem.mm_node) {
+ evict_mem.mm_node-private = NULL;
drm_mm_put_block(evict_mem.mm_node);
evict_mem.mm_node = NULL;
}
@@ -826,6 +827,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
mem-mm_node = node;
mem-mem_type = mem_type;
mem-placement = cur_flags;
+ node-private = bo;
return 0;
}
@@ -856,6 +858,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
if (ret == 0 mem-mm_node) {
mem-placement = cur_flags;
+ mem-mm_node-private = bo;
return 0;
}
@@ -868,6 +871,173 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
}
EXPORT_SYMBOL(ttm_bo_mem_space);
+static unsigned long ttm_bo_free_size_if_evicted(struct ttm_buffer_object *bo)
+{
+ struct ttm_mem_type_manager *man = bo-bdev-man[bo-mem.mem_type];
+ struct drm_mm_node *node;
+ unsigned long size;
+
+ size = bo-mem.mm_node-size;
+ if (bo-mem.mm_node-ml_entry.prev != man-manager.ml_entry) {
+ node = list_entry(bo-mem.mm_node-ml_entry.prev,
+ struct drm_mm_node, ml_entry);
+ if (node-free)
+ size += node-size;
+ }
+ if (bo-mem.mm_node-ml_entry.next != man-manager.ml_entry) {
+ node = list_entry(bo-mem.mm_node-ml_entry.next,
+ struct drm_mm_node, ml_entry);
+ if (node-free)
+ size += node-size;
+ }
+ return size;
+}
+
+static void ttm_manager_evict_first(struct ttm_buffer_object *bo)
+{
+ struct ttm_mem_type_manager *man = bo-bdev-man[bo-mem.mem_type];
+ unsigned long free_size_bo, free_size_bo_first;
+ struct ttm_buffer_object *bo_first;
+
+ /* BO is not on lru list, don't add it */
+ if (!list_empty(bo-lru))
+ return;
+ bo_first = list_first_entry(man-lru, struct ttm_buffer_object, lru);
+ free_size_bo = ttm_bo_free_size_if_evicted(bo);
+ free_size_bo_first = ttm_bo_free_size_if_evicted(bo_first);
+ if (free_size_bo free_size_bo_first) {
+ list_del_init(bo-lru);
+ list_add(bo-lru, man-lru);
+ }
+}
+
+static int ttm_manager_space_range(struct ttm_buffer_object *bo,
+ uint32_t mem_type,
+ struct ttm_mem_reg *mem,
+ unsigned long start, unsigned long end,
+ bool interruptible, bool no_wait)
+{
+ struct ttm_bo_global *glob = bo-glob;
+ struct drm_mm_node *entry;
+ struct ttm_mem_type_manager *man = bo-bdev-man[mem_type];
+ struct drm_mm *mm = man-manager;
+ unsigned size = end - start;
+ struct ttm_buffer_object *tbo;
+ unsigned wasted;
+ int ret;
+
+ mem-mm_node = NULL;
+ ret = drm_mm_pre_get(man-manager);
+ if (unlikely(ret))
+ return ret;
+ spin_lock(glob-lru_lock);
+ list_for_each_entry(entry, mm-ml_entry, ml_entry) {
+ wasted = 0;
+ if (mem-page_alignment) {
+ unsigned tmp = entry-start % mem-page_alignment;
+ if (tmp)
+ wasted += mem-page_alignment - tmp;
+ }
+ if (entry-start end (entry-start+entry-size) start) {
+ if (!entry-free) {
+
[no subject]
This patch series add ttm range validation function. Aim is to include this in 2.6.33 so i have time to iron out issue, comments. ttm: I duplicated a bunch of ttm functions but now i think, best would be to add range to all function and use free list if range cover all the manager space. Doing so we might also be able to simplify mem_space alocation into a simpler function like ttm_bo_mem_space_range radeon: The second patch is a rework/cleanup of radeon object, it solves few issues along the way (i can't remember them now after fews days testing the patches). Biggest change is that we now rely on BO being validated before doing any change to radeon bo structure. As with any big patch i might introduce regressions, so far after testing on AGP:R1XX,R2XX,R3XX,R6XX PCIE:R3XX,R4XX,R5XX,R6XX,R7XX and RS480,RS690 i didn't found anythings obvious (test being X + glxgears + compiz(on hw which support it) + suspend/resume). Last patch is smaller, it just use the interface introduced by the first patch. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/3] drm/radeon/kms: Add range pinning to crtc/cursor bo
We force the crtc cursor bo to be in the first 64M, this
will help on legacy modesetting hw where the offset of
scanout buffer and cursor are relative to a base address.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/radeon.h |3 ++
drivers/gpu/drm/radeon/radeon_cursor.c |3 +-
drivers/gpu/drm/radeon/radeon_gem.c | 15 +++
drivers/gpu/drm/radeon/radeon_legacy_crtc.c |6 -
drivers/gpu/drm/radeon/radeon_object.c | 35 +++
drivers/gpu/drm/radeon/radeon_object.h |2 +
6 files changed, 62 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 4b5d86b..5cb1b79 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -245,6 +245,9 @@ int radeon_gem_object_create(struct radeon_device *rdev,
int size,
struct drm_gem_object **obj);
int radeon_gem_object_pin(struct drm_gem_object *obj, uint32_t pin_domain,
uint64_t *gpu_addr);
+extern int radeon_gem_object_pin_range(struct drm_gem_object *obj,
+ uint32_t pin_domain, uint64_t *gpu_addr,
+ unsigned long start, unsigned long end);
void radeon_gem_object_unpin(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c
b/drivers/gpu/drm/radeon/radeon_cursor.c
index 28772a3..205fca1 100644
--- a/drivers/gpu/drm/radeon/radeon_cursor.c
+++ b/drivers/gpu/drm/radeon/radeon_cursor.c
@@ -156,7 +156,8 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
return -EINVAL;
}
- ret = radeon_gem_object_pin(obj, RADEON_GEM_DOMAIN_VRAM, gpu_addr);
+ ret = radeon_gem_object_pin_range(obj, RADEON_GEM_DOMAIN_VRAM,
+ gpu_addr, 0, 64 * 1024 * 1024);
if (ret)
goto fail;
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index f3fb2bf..7db8fcb 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -92,6 +92,21 @@ int radeon_gem_object_pin(struct drm_gem_object *obj,
uint32_t pin_domain,
return r;
}
+int radeon_gem_object_pin_range(struct drm_gem_object *obj,
+ uint32_t pin_domain, uint64_t *gpu_addr,
+ unsigned long start, unsigned long end)
+{
+ struct radeon_bo *robj = obj-driver_private;
+ int r;
+
+ r = radeon_bo_reserve(robj, false);
+ if (unlikely(r != 0))
+ return r;
+ r = radeon_bo_pin_range(robj, pin_domain, gpu_addr, start, end);
+ radeon_bo_unreserve(robj);
+ return r;
+}
+
void radeon_gem_object_unpin(struct drm_gem_object *obj)
{
struct radeon_bo *robj = obj-driver_private;
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index e8a984d..3a2fb68 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -439,7 +439,11 @@ int radeon_crtc_set_base(struct drm_crtc *crtc, int x, int
y,
r = radeon_bo_reserve(rbo, false);
if (unlikely(r != 0))
return r;
- r = radeon_bo_pin(rbo, RADEON_GEM_DOMAIN_VRAM, base);
+ /* Pin buffer in the first 64M and always set crtc_base to start of
+* vram
+*/
+ r = radeon_bo_pin_range(rbo, RADEON_GEM_DOMAIN_VRAM, base,
+ 0, 64 * 1024 * 1024);
if (unlikely(r != 0)) {
radeon_bo_unreserve(rbo);
return -EINVAL;
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index bec4943..15399e6 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -200,6 +200,41 @@ retry:
return r;
}
+int radeon_bo_pin_range(struct radeon_bo *bo, u32 domain, u64 *gpu_addr,
+ unsigned long start, unsigned long end)
+{
+ u32 flags;
+ u32 tmp;
+ int r;
+
+ flags = radeon_ttm_flags_from_domain(domain);
+ if (bo-pin_count) {
+ bo-pin_count++;
+ if (gpu_addr)
+ *gpu_addr = radeon_bo_gpu_offset(bo);
+ return 0;
+ }
+ tmp = bo-tbo.mem.placement;
+ ttm_flag_masked(tmp, flags, TTM_PL_MASK_MEM);
+ bo-tbo.proposed_placement = tmp | TTM_PL_FLAG_NO_EVICT |
+ TTM_PL_MASK_CACHING;
+retry:
+ r = ttm_buffer_object_validate_range(bo-tbo,
+ bo-tbo.proposed_placement,
+ start, end, true, false);
+ if (likely(r == 0)) {
+ bo-pin_count = 1;
+ if (gpu_addr != NULL)
+ *gpu_addr =
[Bug 25142] touhou 11/12 run very slow in wine
http://bugs.freedesktop.org/show_bug.cgi?id=25142 --- Comment #2 from Allen Walker walkerallen...@googlemail.com 2009-11-20 05:59:50 PST --- ok, got oprofile running and it shows me: $ oprofile | head Overflow stats not available CPU: AMD64 processors, speed 1607.55 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 10 CPU_CLK_UNHALT...| samples| %| -- 1196504 73.1266 r300_dri.so 113025 6.9077 vmlinux 52682 3.2198 libSAD.so.2.0.0 48921 2.9899 libdricore.so 28411 1.7364 libc-2.11.so -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25142] touhou 11/12 run very slow in wine
http://bugs.freedesktop.org/show_bug.cgi?id=25142 --- Comment #3 from Allen Walker walkerallen...@googlemail.com 2009-11-20 06:06:50 PST --- better results: $ opreport -l /usr/lib/xorg/modules/dri/r300_dri.so | head Overflow stats not available CPU: AMD64 processors, speed 1607.55 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 10 samples %symbol name 633992 98.0560 radeon_ptr_4byte 11532 1.7836 radeonReadRGBASpan_ARGB 850.0131 radeon_get_cliprects 750.0116 radeonEmitState 630.0097 radeonWriteRGBASpan_ARGB 520.0080 r300DrawPrims 270.0042 r500SetupRSUnit $ opreport | head Overflow stats not available CPU: AMD64 processors, speed 1607.55 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 10 CPU_CLK_UNHALT...| samples| %| -- 646564 71.7840 r300_dri.so 68319 7.5850 vmlinux 36815 4.0873 libSAD.so.2.0.0 27617 3.0661 libdricore.so 14973 1.6624 libc-2.11.so hope that helps -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22851] [bisected] radeon_lock.c:65: radeonGetLock: Assertion `drawable != ((void *)0)' failed
http://bugs.freedesktop.org/show_bug.cgi?id=22851 Fabio fabio@libero.it changed: What|Removed |Added Summary|radeon_lock.c:65: |[bisected] radeon_lock.c:65: |radeonGetLock: Assertion|radeonGetLock: Assertion |`drawable != ((void *)0)' |`drawable != ((void *)0)' |failed |failed --- Comment #6 from Fabio fabio@libero.it 2009-11-20 06:10:58 PST --- Dave Airlie please read this. I noticed that things went worse after the merge of the radeon-texrewrite-clean branch: also the wine game Panzers II starts to assert this way. I bisected to this commit: http://cgit.freedesktop.org/~osiris/mesa/commit/?h=radeon-texrewrite-cleanid=aa195611586cdfb21bb1707b12b16e461a92d42e but probably it only triggered this same bug. So I tried bisecting master for searching where the assertion first appeared. Surprisingly I got this commit: http://cgit.freedesktop.org/mesa/mesa/commit/?id=77506dac8e81e9548a7e9680ce367175fe5747af Indeed, after reverting this commit from the 7.7 branch both Panzers II and boswars (see my previous comment for a way to reproduce this) started to work fine again. Dave, could you take a look at it? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25193] Git 3f2c77659ca552c43f544228f3a5a5fe6365513a breaks here
http://bugs.freedesktop.org/show_bug.cgi?id=25193 --- Comment #4 from Fabio fabio@libero.it 2009-11-20 06:15:57 PST --- Could you try running: LIBGL_DEBUG=verbose glxgears -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/ttm: Add range validation function V2
Add a function to validate buffer in a given range of
memory. This is needed by some hw for some of their
buffer (scanout buffer, cursor ...).
V2: A fix were missing in the first version, only update
node-private if we are actualy dealing with a node.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/ttm/ttm_bo.c| 306 ++-
include/drm/ttm/ttm_bo_api.h|5 +
include/drm/ttm/ttm_bo_driver.h |1 +
3 files changed, 311 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 87c0625..4d88397 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -247,7 +247,6 @@ EXPORT_SYMBOL(ttm_bo_unreserve);
/*
* Call bo-mutex locked.
*/
-
static int ttm_bo_add_ttm(struct ttm_buffer_object *bo, bool zero_alloc)
{
struct ttm_bo_device *bdev = bo-bdev;
@@ -418,6 +417,7 @@ static int ttm_bo_cleanup_refs(struct ttm_buffer_object
*bo, bool remove_all)
kref_put(bo-list_kref, ttm_bo_ref_bug);
}
if (bo-mem.mm_node) {
+ bo-mem.mm_node-private = NULL;
drm_mm_put_block(bo-mem.mm_node);
bo-mem.mm_node = NULL;
}
@@ -610,6 +610,7 @@ static int ttm_bo_evict(struct ttm_buffer_object *bo,
unsigned mem_type,
spin_lock(glob-lru_lock);
if (evict_mem.mm_node) {
+ evict_mem.mm_node-private = NULL;
drm_mm_put_block(evict_mem.mm_node);
evict_mem.mm_node = NULL;
}
@@ -826,6 +827,8 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
mem-mm_node = node;
mem-mem_type = mem_type;
mem-placement = cur_flags;
+ if (node)
+ node-private = bo;
return 0;
}
@@ -856,6 +859,7 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
if (ret == 0 mem-mm_node) {
mem-placement = cur_flags;
+ mem-mm_node-private = bo;
return 0;
}
@@ -868,6 +872,173 @@ int ttm_bo_mem_space(struct ttm_buffer_object *bo,
}
EXPORT_SYMBOL(ttm_bo_mem_space);
+static unsigned long ttm_bo_free_size_if_evicted(struct ttm_buffer_object *bo)
+{
+ struct ttm_mem_type_manager *man = bo-bdev-man[bo-mem.mem_type];
+ struct drm_mm_node *node;
+ unsigned long size;
+
+ size = bo-mem.mm_node-size;
+ if (bo-mem.mm_node-ml_entry.prev != man-manager.ml_entry) {
+ node = list_entry(bo-mem.mm_node-ml_entry.prev,
+ struct drm_mm_node, ml_entry);
+ if (node-free)
+ size += node-size;
+ }
+ if (bo-mem.mm_node-ml_entry.next != man-manager.ml_entry) {
+ node = list_entry(bo-mem.mm_node-ml_entry.next,
+ struct drm_mm_node, ml_entry);
+ if (node-free)
+ size += node-size;
+ }
+ return size;
+}
+
+static void ttm_manager_evict_first(struct ttm_buffer_object *bo)
+{
+ struct ttm_mem_type_manager *man = bo-bdev-man[bo-mem.mem_type];
+ unsigned long free_size_bo, free_size_bo_first;
+ struct ttm_buffer_object *bo_first;
+
+ /* BO is not on lru list, don't add it */
+ if (!list_empty(bo-lru))
+ return;
+ bo_first = list_first_entry(man-lru, struct ttm_buffer_object, lru);
+ free_size_bo = ttm_bo_free_size_if_evicted(bo);
+ free_size_bo_first = ttm_bo_free_size_if_evicted(bo_first);
+ if (free_size_bo free_size_bo_first) {
+ list_del_init(bo-lru);
+ list_add(bo-lru, man-lru);
+ }
+}
+
+static int ttm_manager_space_range(struct ttm_buffer_object *bo,
+ uint32_t mem_type,
+ struct ttm_mem_reg *mem,
+ unsigned long start, unsigned long end,
+ bool interruptible, bool no_wait)
+{
+ struct ttm_bo_global *glob = bo-glob;
+ struct drm_mm_node *entry;
+ struct ttm_mem_type_manager *man = bo-bdev-man[mem_type];
+ struct drm_mm *mm = man-manager;
+ unsigned size = end - start;
+ struct ttm_buffer_object *tbo;
+ unsigned wasted;
+ int ret;
+
+ mem-mm_node = NULL;
+ ret = drm_mm_pre_get(man-manager);
+ if (unlikely(ret))
+ return ret;
+ spin_lock(glob-lru_lock);
+ list_for_each_entry(entry, mm-ml_entry, ml_entry) {
+ wasted = 0;
+ if (mem-page_alignment) {
+ unsigned tmp = entry-start % mem-page_alignment;
+ if (tmp)
+ wasted += mem-page_alignment - tmp;
+ }
[Bug 25193] Git 3f2c77659ca552c43f544228f3a5a5fe6365513a breaks here
http://bugs.freedesktop.org/show_bug.cgi?id=25193 --- Comment #5 from Florian Scandella f...@chilicode.com 2009-11-20 06:42:33 PST --- same thing here ... ~ $ LIBGL_DEBUG=verbose glxgears libGL: OpenDriver: trying /usr/lib64/dri/tls/r600_dri.so libGL: OpenDriver: trying /usr/lib64/dri/r600_dri.so libGL error: dlopen /usr/lib64/dri/r600_dri.so failed (/usr/lib64/dri/r600_dri.so: undefined symbol: radeon_ptr_2byte_8x2) libGL error: unable to load driver: r600_dri.so libGL error: driver pointer missing libGL: OpenDriver: trying /usr/lib64/dri/tls/swrast_dri.so libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so 1273 frames in 5.0 seconds = 254.489 FPS 1235 frames in 5.0 seconds = 246.831 FPS -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25142] touhou 11/12 run very slow in wine
http://bugs.freedesktop.org/show_bug.cgi?id=25142 --- Comment #4 from Roland Scheidegger srol...@tungstengraphics.com 2009-11-20 06:51:38 PST --- (In reply to comment #3) samples %symbol name 633992 98.0560 radeon_ptr_4byte 11532 1.7836 radeonReadRGBASpan_ARGB This is a software fallback - my bet would be for CopyTex[Sub]Image2d, which the driver currently doesn't accelerate. I thought there was some branch somewhere implementing that already, but can't remember where this was... -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25142] touhou 11/12 run very slow in wine
http://bugs.freedesktop.org/show_bug.cgi?id=25142 --- Comment #5 from Allen Walker walkerallen...@googlemail.com 2009-11-20 07:10:40 PST --- (In reply to comment #4) (In reply to comment #3) samples %symbol name 633992 98.0560 radeon_ptr_4byte 11532 1.7836 radeonReadRGBASpan_ARGB This is a software fallback - my bet would be for CopyTex[Sub]Image2d, which the driver currently doesn't accelerate. I thought there was some branch somewhere implementing that already, but can't remember where this was... did you mean https://bugs.freedesktop.org/show_bug.cgi?id=19366 ? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25193] Git 3f2c77659ca552c43f544228f3a5a5fe6365513a breaks here
http://bugs.freedesktop.org/show_bug.cgi?id=25193 --- Comment #6 from Alex Deucher ag...@yahoo.com 2009-11-20 07:40:29 PST --- (In reply to comment #2) To avoid this problem current libdrm should be tagged as 2.4.16 and mesa should require libdrm_radeon = 2.4.16. That will be done once KMS is officially released upstream (makes it out of staging in the kernel). As it is now, the API may still change as evidenced by this commit. If you build a non-kms enabled mesa, you won't hit this issue. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25193] Git 3f2c77659ca552c43f544228f3a5a5fe6365513a breaks here
http://bugs.freedesktop.org/show_bug.cgi?id=25193 --- Comment #7 from Alex Deucher ag...@yahoo.com 2009-11-20 07:41:22 PST --- (In reply to comment #5) same thing here ... ~ $ LIBGL_DEBUG=verbose glxgears libGL: OpenDriver: trying /usr/lib64/dri/tls/r600_dri.so libGL: OpenDriver: trying /usr/lib64/dri/r600_dri.so libGL error: dlopen /usr/lib64/dri/r600_dri.so failed (/usr/lib64/dri/r600_dri.so: undefined symbol: radeon_ptr_2byte_8x2) libGL error: unable to load driver: r600_dri.so libGL error: driver pointer missing libGL: OpenDriver: trying /usr/lib64/dri/tls/swrast_dri.so libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so 1273 frames in 5.0 seconds = 254.489 FPS 1235 frames in 5.0 seconds = 246.831 FPS Looks like a merge error. This was fixed in master a few days ago. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25193] Git 3f2c77659ca552c43f544228f3a5a5fe6365513a breaks here
http://bugs.freedesktop.org/show_bug.cgi?id=25193 --- Comment #8 from Florian Scandella f...@chilicode.com 2009-11-20 07:54:18 PST --- hmm.. thats strange, a new clone fixed the problems ... didn't get any changes with pull. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25142] touhou 11/12 run very slow in wine
http://bugs.freedesktop.org/show_bug.cgi?id=25142 --- Comment #6 from Maciej Cencora m.cenc...@gmail.com 2009-11-20 08:06:21 PST --- Please try my r300-blit branch. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: PROBLEM: radeon, kernel = 2.6.32-rc6-git5, any mode switch on MacBookPro2, 2 is delayed by 130 seconds of black screen
On Fri, Nov 20, 2009 at 5:45 AM, Viktor Malyarchuk mal...@gmail.com wrote: Dear David, thank you and all the developers involved for your outstanding DRM/KMS work. There is a problem that was introduced in 2.6.32-rc6-git5. SUMMARY any mode switch on MacBookPro2,2 is delayed by 130 seconds of black screen. REPORT Every time I try to change mode (change resolution, add/remove second monitor) screen go black for 130 seconds before change will take effect. System is not locked as I can ssh into it. The same happen during boot time: 130 seconds of black screen before switching to native mode. Radeon module is compiled into the kernel. There is no messages in dmesg during that delay. System look locked but dutifully going back to boot process after 130 s. KEYWORDS Radeon, DRM, KMS KERNEL VERSION /proc/version Linux version 2.6.32-rc8 (r...@malyarchuk-mactel) (gcc version 4.3.4 (Debian 4.3.4-6) ) #1 SMP Thu Nov 19 20:46:58 CST 2009 KERNEL .config file Please, see attachment config-2.6.32-rc8 LAST KERNEL that work fine 2.6.32-rc6-git4 Any chance you could use git bisect and track down the problematic commit? Alex -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25198] [R6XX] : System hard hangs on launching OpenGL application
http://bugs.freedesktop.org/show_bug.cgi?id=25198 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #5 from Alex Deucher ag...@yahoo.com 2009-11-20 08:21:05 PST --- You need kernel 2.6.32 for 3D support on r6xx/r7xx chips. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25193] Git 3f2c77659ca552c43f544228f3a5a5fe6365513a breaks here
http://bugs.freedesktop.org/show_bug.cgi?id=25193 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 3/3] drm/radeon/kms: Add range pinning to crtc/cursor bo
On Fri, Nov 20, 2009 at 8:29 AM, Jerome Glisse jgli...@redhat.com wrote:
We force the crtc cursor bo to be in the first 64M, this
will help on legacy modesetting hw where the offset of
scanout buffer and cursor are relative to a base address.
This limitation only applies to pre-avivo (r1xx-r4xx) chips, there's
no need on newer hardware. Also the cursor and crtc have to be within
128 MB of each other, so you could bump the limits to 128 MB. Another
thing to consider down the road might be to treat memory over 128 MB
as invisible on these pre-avivo chips (once we support that in
general) then we no longer need this limit.
Alex
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/radeon.h | 3 ++
drivers/gpu/drm/radeon/radeon_cursor.c | 3 +-
drivers/gpu/drm/radeon/radeon_gem.c | 15 +++
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 6 -
drivers/gpu/drm/radeon/radeon_object.c | 35
+++
drivers/gpu/drm/radeon/radeon_object.h | 2 +
6 files changed, 62 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 4b5d86b..5cb1b79 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -245,6 +245,9 @@ int radeon_gem_object_create(struct radeon_device *rdev,
int size,
struct drm_gem_object **obj);
int radeon_gem_object_pin(struct drm_gem_object *obj, uint32_t pin_domain,
uint64_t *gpu_addr);
+extern int radeon_gem_object_pin_range(struct drm_gem_object *obj,
+ uint32_t pin_domain, uint64_t *gpu_addr,
+ unsigned long start, unsigned long end);
void radeon_gem_object_unpin(struct drm_gem_object *obj);
diff --git a/drivers/gpu/drm/radeon/radeon_cursor.c
b/drivers/gpu/drm/radeon/radeon_cursor.c
index 28772a3..205fca1 100644
--- a/drivers/gpu/drm/radeon/radeon_cursor.c
+++ b/drivers/gpu/drm/radeon/radeon_cursor.c
@@ -156,7 +156,8 @@ int radeon_crtc_cursor_set(struct drm_crtc *crtc,
return -EINVAL;
}
- ret = radeon_gem_object_pin(obj, RADEON_GEM_DOMAIN_VRAM, gpu_addr);
+ ret = radeon_gem_object_pin_range(obj, RADEON_GEM_DOMAIN_VRAM,
+ gpu_addr, 0, 64 * 1024 * 1024);
if (ret)
goto fail;
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index f3fb2bf..7db8fcb 100644
--- a/drivers/gpu/drm/radeon/radeon_gem.c
+++ b/drivers/gpu/drm/radeon/radeon_gem.c
@@ -92,6 +92,21 @@ int radeon_gem_object_pin(struct drm_gem_object *obj,
uint32_t pin_domain,
return r;
}
+int radeon_gem_object_pin_range(struct drm_gem_object *obj,
+ uint32_t pin_domain, uint64_t *gpu_addr,
+ unsigned long start, unsigned long end)
+{
+ struct radeon_bo *robj = obj-driver_private;
+ int r;
+
+ r = radeon_bo_reserve(robj, false);
+ if (unlikely(r != 0))
+ return r;
+ r = radeon_bo_pin_range(robj, pin_domain, gpu_addr, start, end);
+ radeon_bo_unreserve(robj);
+ return r;
+}
+
void radeon_gem_object_unpin(struct drm_gem_object *obj)
{
struct radeon_bo *robj = obj-driver_private;
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index e8a984d..3a2fb68 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -439,7 +439,11 @@ int radeon_crtc_set_base(struct drm_crtc *crtc, int x,
int y,
r = radeon_bo_reserve(rbo, false);
if (unlikely(r != 0))
return r;
- r = radeon_bo_pin(rbo, RADEON_GEM_DOMAIN_VRAM, base);
+ /* Pin buffer in the first 64M and always set crtc_base to start of
+ * vram
+ */
+ r = radeon_bo_pin_range(rbo, RADEON_GEM_DOMAIN_VRAM, base,
+ 0, 64 * 1024 * 1024);
if (unlikely(r != 0)) {
radeon_bo_unreserve(rbo);
return -EINVAL;
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_object.c
index bec4943..15399e6 100644
--- a/drivers/gpu/drm/radeon/radeon_object.c
+++ b/drivers/gpu/drm/radeon/radeon_object.c
@@ -200,6 +200,41 @@ retry:
return r;
}
+int radeon_bo_pin_range(struct radeon_bo *bo, u32 domain, u64 *gpu_addr,
+ unsigned long start, unsigned long end)
+{
+ u32 flags;
+ u32 tmp;
+ int r;
+
+ flags = radeon_ttm_flags_from_domain(domain);
+ if (bo-pin_count) {
+ bo-pin_count++;
+ if (gpu_addr)
+ *gpu_addr = radeon_bo_gpu_offset(bo);
+ return 0;
+ }
+ tmp =
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
Paulius Zaleckas wrote: On drivers using drm_fb_helper's in fb_ops it is not possible to change video mode, because of different var-pixclock evaluation: ... patch: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html P.S. check CLCOK spelling :) This patch got lost during fb helper reorganization: http://git.kernel.org/linus/1bcbf3948876e31a8ece28597dec447611ad9c8b Regards, Clemens -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 3/3] drm/radeon/kms: Add range pinning to crtc/cursor bo
On Fri, Nov 20, 2009 at 11:47:22AM -0500, Alex Deucher wrote: On Fri, Nov 20, 2009 at 8:29 AM, Jerome Glisse jgli...@redhat.com wrote: We force the crtc cursor bo to be in the first 64M, this will help on legacy modesetting hw where the offset of scanout buffer and cursor are relative to a base address. This limitation only applies to pre-avivo (r1xx-r4xx) chips, there's no need on newer hardware. Also the cursor and crtc have to be within 128 MB of each other, so you could bump the limits to 128 MB. Another thing to consider down the road might be to treat memory over 128 MB as invisible on these pre-avivo chips (once we support that in general) then we no longer need this limit. Alex I choosed 64M in hope to disminish VRAM fragmentation a little, this is also why i did not bother to make this conditional for legacy modesetting hw. For supporting non visible vram see my other ttm thread. I am working on adding this knowledge to ttm. Cheers, Jerome -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
Paulius Zaleckas wrote: On drivers using drm_fb_helper's in fb_ops it is not possible to change video mode, because of different var-pixclock evaluation: ... patch: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html Those patches will enable fbdev apps to run properly. More patches are needed if you want to support mode switching using the fbdev emulation layer. I noticed my patches and yours where lost. Who do you send patches too that can merge them ? -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Fri, 20 Nov 2009 18:53:37 + (GMT) James Simmons jsimm...@infradead.org wrote: Paulius Zaleckas wrote: On drivers using drm_fb_helper's in fb_ops it is not possible to change video mode, because of different var-pixclock evaluation: ... patch: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html Those patches will enable fbdev apps to run properly. More patches are needed if you want to support mode switching using the fbdev emulation layer. I noticed my patches and yours where lost. Who do you send patches too that can merge them ? y:/usr/src/git26 perl scripts/get_maintainer.pl -f drivers/gpu/drm/drm_fb_helper.c David Airlie airl...@linux.ie Dave Airlie airl...@redhat.com Jesse Barnes jbar...@virtuousgeek.org Mikael Pettersson mi...@it.uu.se dri-devel@lists.sourceforge.net linux-ker...@vger.kernel.org That's accurate enough. Generally, if nothing has happened in a week, the chances that it's lost are very high. Resend. If you like, cc me and I'll maintain the patches and resend them for you. cheers, lkml resendbot. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
Paulius Zaleckas wrote: On drivers using drm_fb_helper's in fb_ops it is not possible to change video mode, because of different var-pixclock evaluation: ... patch: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html Those patches will enable fbdev apps to run properly. More patches are needed if you want to support mode switching using the fbdev emulation layer. I noticed my patches and yours where lost. Who do you send patches too that can merge them ? y:/usr/src/git26 perl scripts/get_maintainer.pl -f drivers/gpu/drm/drm_fb_helper.c David Airlieairl...@linux.ie Dave Airlieairl...@redhat.com Jesse Barnesjbar...@virtuousgeek.org Mikael Petterssonmi...@it.uu.se dri-devel@lists.sourceforge.net linux-ker...@vger.kernel.org That's accurate enough. Generally, if nothing has happened in a week, the chances that it's lost are very high. Resend. If you like, cc me and I'll maintain the patches and resend them for you. You can add Tested-by: Paulius Zaleckas paulius.zalec...@gmail.com for http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html as this was preventing DirectFB from running on my Asus Eee PC 701. I tested it as well with the both my 3Dfx driver that I wrote with KMS and the nouveau driver. We just need to make sure that the patches end up in the drm-next tree or these patches will be lost when drm-next gets merged to linus tree. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25142] touhou 11/12 run very slow in wine
http://bugs.freedesktop.org/show_bug.cgi?id=25142 --- Comment #7 from Allen Walker walkerallen...@googlemail.com 2009-11-20 12:09:22 PST --- (In reply to comment #6) Please try my r300-blit branch. Was half success, failed half. My problem is that I can only get indirect rendering working and cannot compile 32bit libdrm/mesa, so wine uses older 32bit versions of mesa and drm (no r300_dri.so exists for 32bit so it is consistent with older tests before the upgrade which used indirect rendering, too). This is a problem specific to my distribution. Good side: the game runs much faster now (40-50fps). Downside: All menus and the loading screen look good, but ingame I get garbled output (like you see with old crts when the resolution is set too high). Funny is that the ingame menus are drawn properly over the garbled ingame rendering. I can't tell if this is because of the version difference between the 32bit and 64bit libraries or a real bug. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Fri, 20 Nov 2009, Paulius Zaleckas wrote: On 11/20/2009 10:01 PM, James Simmons wrote: Paulius Zaleckas wrote: On drivers using drm_fb_helper's in fb_ops it is not possible to change video mode, because of different var-pixclock evaluation: ... patch: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html Those patches will enable fbdev apps to run properly. More patches are needed if you want to support mode switching using the fbdev emulation layer. I noticed my patches and yours where lost. Who do you send patches too that can merge them ? y:/usr/src/git26 perl scripts/get_maintainer.pl -f drivers/gpu/drm/drm_fb_helper.c David Airlieairl...@linux.ie Dave Airlieairl...@redhat.com Jesse Barnesjbar...@virtuousgeek.org Mikael Petterssonmi...@it.uu.se dri-devel@lists.sourceforge.net linux-ker...@vger.kernel.org That's accurate enough. Generally, if nothing has happened in a week, the chances that it's lost are very high. Resend. If you like, cc me and I'll maintain the patches and resend them for you. You can add Tested-by: Paulius Zaleckaspaulius.zalec...@gmail.com for http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html as this was preventing DirectFB from running on my Asus Eee PC 701. I tested it as well with the both my 3Dfx driver that I wrote with KMS and the nouveau driver. We just need to make sure that the patches end up in the drm-next tree or these patches will be lost when drm-next gets merged to linus tree. IMHO this patch should end up in current (2.6.32) kernel and we should send it to stable ML. Honestly I like to see it there as well. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 21501] Assertion `lvl-size 0' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=21501 --- Comment #5 from rem11_1...@yahoo.fr 2009-11-20 13:02:23 PST --- Tested with mesa branch master from now (after branch 7.7 was merged in) and same error message : scourge: radeon_texture.c:875: migrate_image_to_miptree: Assertion `srclvl-size == dstlvl-size' failed. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25142] touhou 11/12 run very slow in wine
http://bugs.freedesktop.org/show_bug.cgi?id=25142 --- Comment #8 from Allen Walker walkerallen...@googlemail.com 2009-11-20 13:15:56 PST --- Created an attachment (id=31351) -- (http://bugs.freedesktop.org/attachment.cgi?id=31351) ingame garbled -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
2009/11/19 Eric Anholt e...@anholt.net: On Tue, 2009-11-17 at 11:33 -0500, Kristian Høgsberg wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. Ok, here's an update to the proposal. I've rebased the libdrm branch in people.freedesktop.org/~krh/libdrm.git to include a copy of $kernel_source/usr/include/drm as a toplevel include/drm directory in git. I also added a makefile rule to copy a new version of the headers from a kernel git repo and commit it with a message describing the version it was copied from. The location of the kernel repo is given at ./configure time with the --with-kernel-source argument. By adding the makefile rule, I'd like to encourage people to not hand edit the headers and to commit updates of the header files independently from other changes. And of course, updates to the headers should still follow the rules we have now; only copy over new changes once they're in drm-next (I think, or is that in Linus' tree?). Anyway, I think this should address the concerns raised in the thread and if there's no other problems, I can put this into place today. I'll merge the couple of changes on master since I branched for this work and I'll put a mesa/drm.git symlink in place to point to libdrm.git. Awesome. Just a touchup to the README to reflect the current state seems to be needed. Done and pushed. I left the repo as mesa/drm, but I think it makes sense to move it to be a toplevel repo and rename it libdrm. I don't have the admin-fu to that myself so I'll need somebody with those skills to do that for me. cheers, Kristian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [patch 1/5] drm/via: add VIA Chrome9 chipset support
Hello Thomas: I know this kernel module is made for VIAs own X.org driver and not openchrome but: 1. I don't think userspace should be able to easily trigger a kernel oops, and 2. Can't this new VIA Chrome9 DRM interface be made more compatible to the existing one? Ideally it would simply work with the existing/slightly modified (with the support from VIA?!) opensource openchrome driver... Yes, we had discussion for this early this year with openchrome. And the conclusion we got at that time is that openchrome and VIA will go in different DRM module. Thanks and Best Regards = Bruce C. Chang(張祖明) VIA Technologies, Inc. Address: 1F, 531, Chung-Cheng Road, Hsin-Tien, 231 Taipei Tel: +886-2-22185452 Ext 7323 Fax: +886-2-22186282 Skype: Bruce.C.Chang Email: brucech...@via.com.tw From: Thomas Schlichter [mailto:thomas.schlich...@web.de] Sent: 2009/11/19 [星期四] 07:24 To: Bruce Chang Cc: Benjamin Pan (Fremont); airl...@linux.ie; Joseph Chan; a...@linux-foundation.org; dri-devel@lists.sourceforge.net Subject: Re: [patch 1/5] drm/via: add VIA Chrome9 chipset support brucech...@via.com.tw wrote: Hello Sirs: Thank you very much for your help on adding VX800 PCIIDS. I would also like to share the DRM patch I have for VIA Chrome9 graph as below. The 32bit/64bit issue is solved with comp_ioctl which is used by most of the GFX chipset. This patch has been verified under Ubuntu 9.04+Upgraded kernel 2.6.32-rc5 with (1) 2D source code which is released on http://linux.via.com.tw/support/beginDownload.action?eleid=310fid=605 with EXA (2) 3D driver which is release on http://linux.via.com.tw/support/beginDownload.action?eleid=341fid=642. It supports CN896/VX800/VX855 chipsets. I tested this VIA Chrome9 DRM driver under Ubuntu 9.10 and its patched 2.6.31.4 kernel. It loads fine, bus as soon as I start my openchrome Xserver (compiled for 1.6.4, module version = 0.2.904) I get following Oops: ~~ Here the via_chome9 DRM driver is loaded ~~ Nov 18 23:50:41 netbook kernel: [ 729.223543] [drm] Initialized drm 1.1.0 20060810 Nov 18 23:50:41 netbook kernel: [ 729.231046] [drm] via_chrome9 verify function enabled. Nov 18 23:50:41 netbook kernel: [ 729.231100] pci :00:01.0: PCI INT A - GSI 16 (level, low) - IRQ 16 Nov 18 23:50:41 netbook kernel: [ 729.231291] [drm] Initialized via_chrome9 2.11.1 20080415 for :00:01.0 on minor 0 ~~ Here I start the X.org server ~~ Nov 18 23:51:01 netbook kernel: [ 749.340827] *pde = 6ef77067 Nov 18 23:51:01 netbook kernel: [ 749.340844] Modules linked in: via_chrome9 drm ppdev agpgart iptable_filter ip_tables acpi_cpufreq bridge stp x_tables bnep snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep arc4 snd_pcm_oss ecb snd_mixer_oss snd_pcm snd_seq_dummy uvcvideo ath5k snd_seq_oss videodev mac80211 led_class snd_seq_midi joydev i2c_viapro lp v4l1_compat via_sdmmc btusb ath snd_rawmidi snd_seq_midi_event snd_seq snd_timer snd_seq_device snd soundcore psmouse snd_page_alloc cfg80211 serio_raw parport video output sky2 [last unloaded: drm] Nov 18 23:51:01 netbook kernel: [ 749.340906] Nov 18 23:51:01 netbook kernel: [ 749.340913] Pid: 2407, comm: Xorg Not tainted (2.6.31.4-via-pdc-short #5) NC20/NB20 Nov 18 23:51:01 netbook kernel: [ 749.340919] EIP: 0060:[f822acf2] EFLAGS: 00013246 CPU: 0 Nov 18 23:51:01 netbook kernel: [ 749.340928] EIP is at via_chrome9_ioctl_allocate_event_tag+0x22/0x60 [via_chrome9] Nov 18 23:51:01 netbook kernel: [ 749.340934] EAX: EBX: f6a86180 ECX: EDX: f6adfe70 Nov 18 23:51:01 netbook kernel: [ 749.340939] ESI: f64bd400 EDI: f8233ac4 EBP: f6adfe30 ESP: f6adfe30 Nov 18 23:51:01 netbook kernel: [ 749.340944] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Nov 18 23:51:01 netbook kernel: [ 749.340957] f6adff00 f8493600 0001 f84a3834 f84a2e16 f84a4784 0967 40086443 Nov 18 23:51:01 netbook kernel: [ 749.340967] 0 0043 e200 0001 0043 f822acd0 f6adfe70 f6adfe70 40086443 Nov 18 23:51:01 netbook kernel: [ 749.340978] 0 00fa1400 0f01d7e0 c1d6c584 0085 f6f75730 f6f7567c f64a2bb0 f6f7572c Nov 18 23:51:01 netbook kernel: [ 749.341056] [f8493600] ? drm_ioctl+0x180/0x360 [drm] Nov 18 23:51:01 netbook kernel: [ 749.341067] [f822acd0] ? via_chrome9_ioctl_allocate_event_tag+0x0/0x60 [via_chrome9] Nov 18 23:51:01 netbook kernel: [ 749.341078] [c01b0363] ? filemap_fault+0xb3/0x400 Nov 18 23:51:01 netbook kernel: [ 749.341089] [c023985d] ? ext3_file_write+0x2d/0xc0 Nov 18 23:51:01 netbook kernel: [ 749.341100] [c01de34e] ? mem_cgroup_update_mapped_file_stat+0x1e/0x70 Nov 18 23:51:01 netbook kernel: [ 749.341106] [c01ae821] ? unlock_page+0x41/0x50 Nov 18 23:51:01 netbook kernel: [ 749.341118] [c01c62c8] ? __do_fault+0x388/0x470 Nov 18 23:51:01 netbook kernel: [ 749.341125] [c01efa03] ? vfs_ioctl+0x73/0x90 Nov 18 23:51:01 netbook kernel:
[Bug 13683] Internal Laptopdisplay blurrys to white screen after enabling modesetting on Radeon X700 Mobility
http://bugzilla.kernel.org/show_bug.cgi?id=13683 --- Comment #24 from Alex Deucher alexdeuc...@gmail.com 2009-11-20 23:41:49 --- (In reply to comment #23) Still the same with latest git. Is it possible that the bios lies about the connectors ? It's possible, but not likely. The bios claims you have local flat panel (LVDS) and a DVI-I port. Is that what your laptop has? When i used the real old non-kms, non-xrandr radeon driver i had to specify MonitorLayout LVDS,none to get an screen, else i got the white-screen. I experimented with the video kernel-command-line, when i used In those days there was a bug in the connector table parsing where LVDS was not detected on properly on ATOM systems, so you had to force it with the monitorlayout option otherwise it would ignore the panel altogether. video=1280x800 for all outputs i dont get the whitescreen instead the screen flickers and displays nothing. How could i force the kernel to use LVDS as first connector ? What do you mean first connector? LVDS always uses the first display controller right now even though either could drive it. Also, from your logs it appears you don't have any other monitors attached, so it's the only thing being used. Some LVDS panels are very picky about the timing they get and the power up sequence. This seems to be the case with yours. You might try Dave's drm-radeon-testing branch, specifically this commit: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=fba0a16eb5c55ae3bb9cf1306a84b83451389612 and see if it helps. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25193] Git 3f2c77659ca552c43f544228f3a5a5fe6365513a breaks here
http://bugs.freedesktop.org/show_bug.cgi?id=25193 Ed Tomlinson e...@aei.ca changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|NOTABUG | --- Comment #9 from Ed Tomlinson e...@aei.ca 2009-11-20 16:40:23 PST --- As discussed on irc while todays git fixed the dri problem, the corruptions persisted. As requested here is the commit the bisect found along with the log: grover mesa # git bisect good 286bf89e5a1fc931dbf523ded861b809859485e2 is the first bad commit commit 286bf89e5a1fc931dbf523ded861b809859485e2 Author: Maciej Cencora m.cenc...@gmail.com Date: Wed Nov 11 13:06:19 2009 +0100 radeon/r300: no need to flush the cmdbuf when changing scissors state in KMM mode :04 04 432ee58dfddc9afa74201382f887f8557359f75d 43d9b8f07d6a9225614ac2882aff4a266056cf46 M src grover mesa # git bisect log # bad: [015e7e7724a64d3d9e02e57f6a8eb88a6441f596] r300g: emit R300_TEX_ENABLE to indicate there are no textures bound # good: [827ba44f6ee83ab21c6a2b09323f6f1df4a7d4c8] intel: Remove non-GEM support. git bisect start '015e7e7724a64d3d9e02e57f6a8eb88a6441f596' '827ba44f6ee83ab21c6a2b09323f6f1df4a7d4c8' # bad: [012d0193cc9ad6fdc9829db0a6884a5a590dd4c5] st/xorg: Don't complain about convolution filter being 'unknown'. git bisect bad 012d0193cc9ad6fdc9829db0a6884a5a590dd4c5 # skip: [afe84fa698eae3e035e967589f0a8d55f6a83698] r200: align for mipmap tree changes git bisect skip afe84fa698eae3e035e967589f0a8d55f6a83698 # bad: [ea114345a6f19331628910745650cb64750b2bda] st/xorg: Don't initialize non-existing fields. git bisect bad ea114345a6f19331628910745650cb64750b2bda # skip: [93eb2ab8c395f81e40fa298d78805bb2c777f891] radeon: align for mipmap tree changes git bisect skip 93eb2ab8c395f81e40fa298d78805bb2c777f891 # bad: [6e5d473cc16ca2d001df213fc1d907f2943a95bb] r300: fix regression introduced in 1d5a06a1f7812c055db1d724e40d21a0e3686dd1 git bisect bad 6e5d473cc16ca2d001df213fc1d907f2943a95bb # good: [084f43c1502db1988ca53494ea590cf1351180ec] radeon: add radeon_bo_is_referenced_by_cs function git bisect good 084f43c1502db1988ca53494ea590cf1351180ec # bad: [286bf89e5a1fc931dbf523ded861b809859485e2] radeon/r300: no need to flush the cmdbuf when changing scissors state in KMM mode git bisect bad 286bf89e5a1fc931dbf523ded861b809859485e2 # good: [f6d0993212fac0eb67827716be1ab4a292c8b4e5] radeon: fix glBufferSubData git bisect good f6d0993212fac0eb67827716be1ab4a292c8b4e5 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25193] Git 3f2c77659ca552c43f544228f3a5a5fe6365513a breaks here
http://bugs.freedesktop.org/show_bug.cgi?id=25193 --- Comment #10 from Ed Tomlinson e...@aei.ca 2009-11-20 16:48:13 PST --- Just to confirm, reverting 286bf89e5a1fc931dbf523ded861b809859485e2 fixes the corruption here. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Sat, Nov 21, 2009 at 6:48 AM, James Simmons jsimm...@infradead.org wrote: On Fri, 20 Nov 2009, Paulius Zaleckas wrote: On 11/20/2009 10:01 PM, James Simmons wrote: Paulius Zaleckas wrote: On drivers using drm_fb_helper's in fb_ops it is not possible to change video mode, because of different var-pixclock evaluation: ... patch: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html Those patches will enable fbdev apps to run properly. More patches are needed if you want to support mode switching using the fbdev emulation layer. I noticed my patches and yours where lost. Who do you send patches too that can merge them ? y:/usr/src/git26 perl scripts/get_maintainer.pl -f drivers/gpu/drm/drm_fb_helper.c David Airlieairl...@linux.ie Dave Airlieairl...@redhat.com Jesse Barnesjbar...@virtuousgeek.org Mikael Petterssonmi...@it.uu.se dri-devel@lists.sourceforge.net linux-ker...@vger.kernel.org That's accurate enough. Generally, if nothing has happened in a week, the chances that it's lost are very high. Resend. If you like, cc me and I'll maintain the patches and resend them for you. You can add Tested-by: Paulius Zaleckaspaulius.zalec...@gmail.com for http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg44369.html as this was preventing DirectFB from running on my Asus Eee PC 701. I tested it as well with the both my 3Dfx driver that I wrote with KMS and the nouveau driver. We just need to make sure that the patches end up in the drm-next tree or these patches will be lost when drm-next gets merged to linus tree. IMHO this patch should end up in current (2.6.32) kernel and we should send it to stable ML. Honestly I like to see it there as well. I have them queued for drm-next already at least locally, I wasn't aware they were suitable for final, I didn't get a chance to really test them until last week and make sure they didn't hide any side effects. I can ask for them to go to stable when the merge window opens, I think its too late for final. Dave. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] drm_fb_helper: Impossible to change video mode
On Fri, Nov 20, 2009 at 11:16 PM, Paulius Zaleckas
paulius.zalec...@gmail.com wrote:
Hi,
On drivers using drm_fb_helper's in fb_ops it is not possible to change
video mode, because of different var-pixclock evaluation:
int drm_fb_helper_check_var(struct fb_var_screeninfo *var,
struct fb_info *info)
{
[...]
if (var-pixclock == -1 || !var-pixclock)
return -EINVAL;
[...]
int drm_fb_helper_set_par(struct fb_info *info)
{
[...]
if (var-pixclock != -1) {
DRM_ERROR(PIXEL CLCOK SET\n);
return -EINVAL;
}
[...]
One of these evaluations will fail regardless of pixclock value.
At the moment the problem with fbset is what to do with it in the
dual head case. Currently we create an fb console that is lowest
common size of the two heads and set native modes on both,
Now if a user runs fbset, I'm not sure what the right answer is,
a) pick a head in advance via sysfs maybe and set it on that.
b) try and set the mode on both heads cloned (what to do if
there is no common mode is another issue).
Dave.
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
