Re: [PATCH] drm: convert drm_ioctl to unlocked_ioctl
On Friday 18 December 2009, Dave Airlie wrote: This looks good, I've taken this and I've squashed the generic pieces of your RFC into this (i.e. I haven't modified the drivers, but just added the flag to allow the ioctls to be unlocked if the driver selects them). Do you think we should try and get this in soon, its seems like it shouldn't have any regressions unless we start switching drivers over. Well, since the patch should not change the behaviour of the drivers, it probably doesn't matter to users either way. However, it touches a number of places, which can break patches that others are working on, so maybe you should get it upstream at a point that has the least impact to developer (possibly now). Doing it now at least makes it easier to test moving drivers to unlocked operation. Arnd -- 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
[Bug 24593] S3TC compression doesn't work on KMS enabled kernels with R300 (RV530 71C1)
http://bugs.freedesktop.org/show_bug.cgi?id=24593 Fabio fabio@libero.it changed: What|Removed |Added CC||fabio@libero.it --- Comment #5 from Fabio fabio@libero.it 2009-12-18 00:49:44 PST --- This should be fixed in 2.6.33-rc1 and later, which include this commit: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=d785d78bbdb53580b12c40e820af5a3281ce2fc8 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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] drivers/radeon/kms: Workaround RV410/R420 CP errata.
From 7c1de3201bd4e965da7c1d542c46d8b2725bf42d Mon Sep 17 00:00:00 2001
From: Corbin Simpson mostawesomed...@gmail.com
Date: Fri, 18 Dec 2009 01:00:57 -0800
Subject: [PATCH] drivers/radeon/kms: Workaround RV410/R420 CP errata.
Long story short, this fixes sporadic hardlocks with my rv410 during
times of intense 2D acceleration (Flash on Fx3).
Signed-off-by: Corbin Simpson mostawesomed...@gmail.com
---
drivers/gpu/drm/radeon/r420.c | 35 +++
drivers/gpu/drm/radeon/radeon.h |1 +
2 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index 5c7fe52..6f096a6 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -30,6 +30,7 @@
#include radeon_reg.h
#include radeon.h
#include atom.h
+#include r100d.h
#include r420d.h
int r420_mc_init(struct radeon_device *rdev)
@@ -165,6 +166,36 @@ static void r420_clock_resume(struct radeon_device *rdev)
WREG32_PLL(R_0D_SCLK_CNTL, sclk_cntl);
}
+static void r420_cp_errata_init(struct radeon_device *rdev)
+{
+/* RV410 and R420 can lock up if CP DMA to host memory happens while the
+ * 2D engine is busy.
+ *
+ * The proper workaround is to queue a RESYNC at the beginning of the CP
+ * init, apparently.
+ */
+radeon_scratch_get(rdev, rdev-resync_scratch);
+
+radeon_ring_lock(rdev, 8);
+radeon_ring_write(rdev, PACKET0(R300_CP_RESYNC_ADDR, 1));
+radeon_ring_write(rdev, rdev-resync_scratch);
+radeon_ring_write(rdev, 0xDEADBEEF);
+radeon_ring_unlock_commit(rdev);
+}
+
+static void r420_cp_errata_fini(struct radeon_device *rdev)
+{
+/* Catch the RESYNC we dispatched all the way back, at the very beginning
+ * of the CP init.
+ */
+radeon_ring_lock(rdev, 8);
+radeon_ring_write(rdev, PACKET0(R300_RB3D_DSTCACHE_CTLSTAT, 0));
+radeon_ring_write(rdev, R300_RB3D_DC_FINISH);
+radeon_ring_unlock_commit(rdev);
+
+radeon_scratch_free(rdev, rdev-resync_scratch);
+}
+
static int r420_startup(struct radeon_device *rdev)
{
int r;
@@ -194,6 +225,9 @@ static int r420_startup(struct radeon_device *rdev)
dev_err(rdev-dev, failled initializing CP (%d).\n, r);
return r;
}
+/* Handle CP errata. */
+r420_cp_errata_init(rdev);
+
r = r100_wb_init(rdev);
if (r) {
dev_err(rdev-dev, failled initializing WB (%d).\n, r);
@@ -247,6 +281,7 @@ int r420_suspend(struct radeon_device *rdev)
void r420_fini(struct radeon_device *rdev)
{
+r420_cp_errata_fini(rdev);
r100_cp_fini(rdev);
r100_wb_fini(rdev);
r100_ib_fini(rdev);
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 5ab35b8..0da50a2 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -771,6 +771,7 @@ struct radeon_device {
struct radeon_gem gem;
struct radeon_pmpm;
uint32_tbios_scratch[RADEON_BIOS_NUM_SCRATCH];
+uint32_t resync_scratch;
struct mutexcs_mutex;
struct radeon_wbwb;
struct radeon_dummy_pagedummy_page;
--
1.6.5.2
--
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] drivers/radeon/kms: Workaround RV410/R420 CP errata.
On Fri, Dec 18, 2009 at 01:11:45AM -0800, Corbin Simpson wrote: From 7c1de3201bd4e965da7c1d542c46d8b2725bf42d Mon Sep 17 00:00:00 2001 From: Corbin Simpson mostawesomed...@gmail.com Date: Fri, 18 Dec 2009 01:00:57 -0800 Subject: [PATCH] drivers/radeon/kms: Workaround RV410/R420 CP errata. Long story short, this fixes sporadic hardlocks with my rv410 during times of intense 2D acceleration (Flash on Fx3). Signed-off-by: Corbin Simpson mostawesomed...@gmail.com It seems you are using space and not tab. Cheers, Jerome -- 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
[Bug 25701] New: Gallium Radeon driver: undefined symbol: pf_is_depth_or_stencil
http://bugs.freedesktop.org/show_bug.cgi?id=25701 Summary: Gallium Radeon driver: undefined symbol: pf_is_depth_or_stencil Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/DRI/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: tstel...@gmail.com Created an attachment (id=32169) -- (http://bugs.freedesktop.org/attachment.cgi?id=32169) Patch to rename pf_is_depth_or_stencil function. I am using the latest version of mesa from git, commmit: 7855fcb63ba0594cdaee15f8579b66af651828e0 the Gallium Radeon driver fails to load with this error message: undefined symbol: pf_is_depth_or_stencil I think this is due to a function rename in the most recent merge. I have attached a patch that fixes the problem. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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 (V6)
W dniu 18 grudnia 2009 01:08 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2009/12/17 Rafał Miłecki zaj...@gmail.com: W dniu 17 grudnia 2009 06:43 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2009/12/16 Rafał Miłecki zaj...@gmail.com: 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 Tested on my M82==RV620 and my new M96==RV730. Also tested on RV515 by Sedat where already posted patch for AtomBIOS's mutex was needed. How does re-clocking happen if no crtcs are active? We will want to be much more aggressive when the displays are off. Currently we treat such situation as 1 crtc active. That is something I want to improve in next patch when this one will be commitet. I hope it is not stopping issue. The issue you won't get vblank interrupts if the crtcs are off, so no reclocking will occur. Whoops, nice catch! -- Rafał -- 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
[Bug 25662] R300: System locks up when running any graphical program using KMS
http://bugs.freedesktop.org/show_bug.cgi?id=25662 --- Comment #3 from Tom Stellard tstel...@gmail.com 2009-12-18 02:35:59 PST --- I noticed that if I use software rendering, I can get glxgears to run for about three seconds before X freezes. Afterwards, I can still switch virtual terminals, but X is no longer functional. If I use the gallium driver with RADEON_SOFTPIPE enabled, glxgears does not cause X to freeze, but it does not display correctly. The gears are shifted up off the top of the screen, and only the bottom half of the large red gear is visible. If I try to run Firefox with the gallium driver(RADEON_SOFTPIPE enabled), it works for a few seconds and then X freezes, and I experience the same problem as when I run glxgears with software rendering. In both cases the dmesg log is filled with entries like this: [drm:radeon_fence_wait] *ERROR* fence(e9f2c0e0:0x064A) 521ms timeout [drm:radeon_fence_wait] *ERROR* last signaled fence(0x064A) [drm:radeon_fence_wait] *ERROR* fence(e9f2c240:0x064B) 510ms timeout going to reset GPU [drm] CP reset succeed (RBBM_STATUS=0x0140) [drm] radeon: cp idle (0x1000) [drm] radeon: ring at 0x3000 [drm] ring test succeeded in 0 usecs [drm] GPU reset succeed (RBBM_STATUS=0x0140) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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] drivers/radeon/kms: Workaround RV410/R420 CP errata.
2009/12/18 Corbin Simpson mostawesomed...@gmail.com: From 7c1de3201bd4e965da7c1d542c46d8b2725bf42d Mon Sep 17 00:00:00 2001 From: Corbin Simpson mostawesomed...@gmail.com Date: Fri, 18 Dec 2009 01:00:57 -0800 Subject: [PATCH] drivers/radeon/kms: Workaround RV410/R420 CP errata. Long story short, this fixes sporadic hardlocks with my rv410 during times of intense 2D acceleration (Flash on Fx3). Can this be issue on newer chipsets as well? I get hard lockup on RV620 from time to time, very easy reproducible with just starting JDownloader (java application). It seems to do some heavy 2D and locks up my machine in something between 1 second and few minutes. This does not happen when I use UMS (non-KMS) or when I start JDownloader on KDE's virtual desktop #2 and switch to desktop #1. -- Rafał -- 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] drivers/radeon/kms: Workaround RV410/R420 CP errata.
On Fri, 2009-12-18 at 11:54 +0100, Rafał Miłecki wrote: 2009/12/18 Corbin Simpson mostawesomed...@gmail.com: From 7c1de3201bd4e965da7c1d542c46d8b2725bf42d Mon Sep 17 00:00:00 2001 From: Corbin Simpson mostawesomed...@gmail.com Date: Fri, 18 Dec 2009 01:00:57 -0800 Subject: [PATCH] drivers/radeon/kms: Workaround RV410/R420 CP errata. Long story short, this fixes sporadic hardlocks with my rv410 during times of intense 2D acceleration (Flash on Fx3). Can this be issue on newer chipsets as well? I get hard lockup on RV620 from time to time, very easy reproducible with just starting JDownloader (java application). It seems to do some heavy 2D and locks up my machine in something between 1 second and few minutes. This does not happen when I use UMS (non-KMS) or when I start JDownloader on KDE's virtual desktop #2 and switch to desktop #1. It can't be the same problem: it's specific to the 2D engine, which doesn't exist anymore as of R6xx, and it would also happen with UMS. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- 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: enable memory clock reading on legacy
W dniu 17 grudnia 2009 13:52 użytkownik Rafał Miłecki zaj...@gmail.com napisał: W dniu 17 grudnia 2009 05:56 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2009/12/16 Rafał Miłecki zaj...@gmail.com: Tested by bjaglin on IRC on RV250. Probably shouldn't enable the mem clock stuff on IGP chips since they use system memory. Ups. I think it's general bug, not only introduced by proposed patch. For newer (not legacy) GPU we don't check for being IGP as well. Could you comment on attached solution, please? Dave, could you get patch from here (second version), please? -- Rafał -- 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 (V6)
W dniu 18 grudnia 2009 01:08 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2009/12/17 Rafał Miłecki zaj...@gmail.com: W dniu 17 grudnia 2009 06:43 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2009/12/16 Rafał Miłecki zaj...@gmail.com: 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 Tested on my M82==RV620 and my new M96==RV730. Also tested on RV515 by Sedat where already posted patch for AtomBIOS's mutex was needed. How does re-clocking happen if no crtcs are active? We will want to be much more aggressive when the displays are off. Currently we treat such situation as 1 crtc active. That is something I want to improve in next patch when this one will be commitet. I hope it is not stopping issue. The issue you won't get vblank interrupts if the crtcs are off, so no reclocking will occur. Actually you discovered another bug in my patch. We can not do following: if (mode == DRM_MODE_DPMS_OFF) radeon_pm_compute_clocks(rdev); in radeon_encoders.c because we won't react on DPMS on. My bad I had screensaver disabled. -- Rafał -- 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: prevent parallel AtomBIOS calls
On Thu, Dec 17, 2009 at 12:04:02AM +0100, Rafał Miłecki wrote: In future we will execute AtomBIOS commands from contexts (like power management) so we need to make sure we won't execute two commands at same time to prevent locking up GPU. With this patch applied Sedat Dilek (RV515) was able to finally test my PM patch. Also tested on my RV620. -- Rafał I am in favor of a different approach, using a r/w lock and taking the lock in read in all path, and write in powermanager init path. Doc state that we need exclusive access to GPU while doing PM stuff. Thus r/w lock sounds like what we want to do. Should be hard to add that to ioctl modesetting callback. Never the less this patch might be usefull, as for instance we might be doing modesetting at the same time on 2 different head of an avivo gpu and this might lead to // execution of atombios and it's my understanding that atombios code is not safe in this regards. Cheers, Jerome -- 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 (V6)
On Thu, Dec 17, 2009 at 03:02:51AM +0100, Rafał Miłecki wrote: 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 Tested on my M82==RV620 and my new M96==RV730. Also tested on RV515 by Sedat where already posted patch for AtomBIOS's mutex was needed. -- Rafał Few comments. I think it would be better to change : RADEON_PM_ACTION_NONE - PM_NONE ... We already know we are in the radeon module so this is redundant to put it in the name again. And i don't think PM_NONE will conflict with other kernel symbol. Same apply to all other name. I wish to convert radeon module to use dev_err, dev_info, ... instead of DRM_DEBUG, DRM_INFO. Motivation behind that is multi GPU computer. It's not common yet but i think we will want to support that in the future. Convertion to match this can be done as a latter patch. There is few things that might be improved but that shouldn't matter that much. Good works, Cheers, Jerome -- 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: convert drm_ioctl to unlocked_ioctl
Arnd Bergmann wrote: On Friday 18 December 2009, Dave Airlie wrote: This looks good, I've taken this and I've squashed the generic pieces of your RFC into this (i.e. I haven't modified the drivers, but just added the flag to allow the ioctls to be unlocked if the driver selects them). Do you think we should try and get this in soon, its seems like it shouldn't have any regressions unless we start switching drivers over. Well, since the patch should not change the behaviour of the drivers, it probably doesn't matter to users either way. However, it touches a number of places, which can break patches that others are working on, so maybe you should get it upstream at a point that has the least impact to developer (possibly now). Doing it now at least makes it easier to test moving drivers to unlocked operation. Arnd I'm very much for this as well. Note that the vmwgfx driver has another (workaround-like) approach to achieve unlocked driver ioctls, but it shouldn't be too hard to convert it. /Thomas -- 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 -- 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
[Bug 25701] Gallium Radeon driver: undefined symbol: pf_is_depth_or_stencil
http://bugs.freedesktop.org/show_bug.cgi?id=25701 --- Comment #1 from Michel Dänzer mic...@daenzer.net 2009-12-18 05:10:58 PST --- Fixed in Git, thanks for the report. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 25701] Gallium Radeon driver: undefined symbol: pf_is_depth_or_stencil
http://bugs.freedesktop.org/show_bug.cgi?id=25701 Michel Dänzer mic...@daenzer.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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: prevent parallel AtomBIOS calls
W dniu 18 grudnia 2009 13:19 użytkownik Jerome Glisse gli...@freedesktop.org napisał: On Thu, Dec 17, 2009 at 12:04:02AM +0100, Rafał Miłecki wrote: In future we will execute AtomBIOS commands from contexts (like power management) so we need to make sure we won't execute two commands at same time to prevent locking up GPU. With this patch applied Sedat Dilek (RV515) was able to finally test my PM patch. Also tested on my RV620. -- Rafał I am in favor of a different approach, using a r/w lock and taking the lock in read in all path, and write in powermanager init path. Doc state that we need exclusive access to GPU while doing PM stuff. Thus r/w lock sounds like what we want to do. Should be hard to add that to ioctl modesetting callback. Never the less this patch might be usefull, as for instance we might be doing modesetting at the same time on 2 different head of an avivo gpu and this might lead to // execution of atombios and it's my understanding that atombios code is not safe in this regards. Sorry, I'm confused. So finally: do you think we should use read/write locking? I guess we could make atom_execute_table using read-lock and add new function like atom_execute_table_write_lock using write-lock. Then convert sensitive places (like power management) to use _write_lock instead standard atom_execute_table. Not sure about that modesetting at same time. If we don't want to do 2 modesetting operations at same time, is there really sense to introduce read/write locking? When will we use read lock then? Just for connectors and powerplay_info reading? Sounds like wasting time for that. Also could you explain: Should be hard to add that to ioctl modesetting callback. please? -- Rafał -- 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 (V6)
W dniu 18 grudnia 2009 13:24 użytkownik Jerome Glisse gli...@freedesktop.org napisał: I think it would be better to change : RADEON_PM_ACTION_NONE - PM_NONE ... We already know we are in the radeon module so this is redundant to put it in the name again. And i don't think PM_NONE will conflict with other kernel symbol. Same apply to all other name. Thanks. I guess you meant PM_ACTION_NONE? I think it'll easier to understand code when we include ACTION string. I wish to convert radeon module to use dev_err, dev_info, ... instead of DRM_DEBUG, DRM_INFO. Motivation behind that is multi GPU computer. It's not common yet but i think we will want to support that in the future. Convertion to match this can be done as a latter patch. There is few things that might be improved but that shouldn't matter that much. As that's general issue (we use DRM_*... everywhere) I would prefer to make this patch follow general design for now. Thanks for comments. -- Rafał -- 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
[Bug 25707] Problems with DRI on ATI Radeon HD3850
http://bugs.freedesktop.org/show_bug.cgi?id=25707 --- Comment #1 from Maxim kolma...@gmail.com 2009-12-18 05:35:30 PST --- Created an attachment (id=32174) -- (http://bugs.freedesktop.org/attachment.cgi?id=32174) Xorg.0.log -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 25707] Problems with DRI on ATI Radeon HD3850
http://bugs.freedesktop.org/show_bug.cgi?id=25707 --- Comment #3 from Maxim kolma...@gmail.com 2009-12-18 05:37:49 PST --- Created an attachment (id=32176) -- (http://bugs.freedesktop.org/attachment.cgi?id=32176) lspci -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 25707] New: Problems with DRI on ATI Radeon HD3850
http://bugs.freedesktop.org/show_bug.cgi?id=25707 Summary: Problems with DRI on ATI Radeon HD3850 Product: DRI Version: unspecified Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: high Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: kolma...@gmail.com Created an attachment (id=32173) -- (http://bugs.freedesktop.org/attachment.cgi?id=32173) xorg.conf I`m using Gentoo and i have problems starting hardware acceleration on my video card. I use - version of xorg-server, mesa, libdrm, xf86-video-ati and some more libraries and protocols. And I have kernel 2.6.32-gentoo. glxinfo says that it is Software Rasterizer, but i want to get hardware acceleration. More info in attachments (xorg.conf, Xorg.0.log, lspci, glxinfo) P.S I used advices in this article: http://en.gentoo-wiki.com/wiki/Radeon, but it didn`t helped. Some discussion of this is here: http://www.gentoo.ru/node/17754, but it`s in Russian and it`ll probably be useless for you. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 25707] Problems with DRI on ATI Radeon HD3850
http://bugs.freedesktop.org/show_bug.cgi?id=25707 --- Comment #2 from Maxim kolma...@gmail.com 2009-12-18 05:37:19 PST --- Created an attachment (id=32175) -- (http://bugs.freedesktop.org/attachment.cgi?id=32175) glxinfo -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 25708] New: Suppress FBO debug output
http://bugs.freedesktop.org/show_bug.cgi?id=25708 Summary: Suppress FBO debug output Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: minor Priority: medium Component: Drivers/DRI/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: fabio@libero.it While using applications that use FBO I get many messages like: Allocating 16 x 16 radeon RBO (pitch 16) These could be disabled when using non debug builds. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 25709] New: [DRI1 DRI2] sauerbraten: broken water rendering
http://bugs.freedesktop.org/show_bug.cgi?id=25709 Summary: [DRI1 DRI2] sauerbraten: broken water rendering Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: fabio@libero.it When enabling water refraction with sauerbraten water rendering is broken. Tested on both current git master, 7.7 and 7.6 branches with: GL_RENDERER = Mesa DRI R300 (RV530 71C5) 20090101 x86/MMX/SSE2 TCL DRI2 Step to reproduce: 1) run sauerbraten 2) load maps - 3 - thor 3) jump into the water and look at the water surface 4) enable shaders and water-refraction - water becomes green -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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] drm/radeon/kms: add dynamic engine reclocking (V7)
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 You may need to apply patch for AtomBIOS's mutex locking: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg45666.html (I suggest doing that). Please test this patch for dpms off: sleep 1s; xset dpms force off; sleep 1s; cat /debugfs/dri/0/radeon_pm_info Also make sure PM is still working when you come back from dpms off. -- Rafał 0001-drm-radeon-kms-add-dynamic-engine-reclocking-V7.patch Description: Binary data -- 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
[Bug 25710] New: [DRI1 DRI2] sauerbraten: lines around textures
http://bugs.freedesktop.org/show_bug.cgi?id=25710 Summary: [DRI1 DRI2] sauerbraten: lines around textures Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: fabio@libero.it Created an attachment (id=32177) -- (http://bugs.freedesktop.org/attachment.cgi?id=32177) screenshot with lines around textures When enabling shaders inside the game sauerbraten there are some lines around texture edges. Just an example on how to reproduce it: load maps - 3 - thor - locate the bridge as in the screenshot. Tested on both current git master, 7.7 and 7.6 branches with: GL_RENDERER = Mesa DRI R300 (RV530 71C5) 20090101 x86/MMX/SSE2 TCL DRI2 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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: prevent parallel AtomBIOS calls
On Fri, Dec 18, 2009 at 02:27:57PM +0100, Rafał Miłecki wrote: W dniu 18 grudnia 2009 13:19 użytkownik Jerome Glisse gli...@freedesktop.org napisał: On Thu, Dec 17, 2009 at 12:04:02AM +0100, Rafał Miłecki wrote: In future we will execute AtomBIOS commands from contexts (like power management) so we need to make sure we won't execute two commands at same time to prevent locking up GPU. With this patch applied Sedat Dilek (RV515) was able to finally test my PM patch. Also tested on my RV620. -- Rafał I am in favor of a different approach, using a r/w lock and taking the lock in read in all path, and write in powermanager init path. Doc state that we need exclusive access to GPU while doing PM stuff. Thus r/w lock sounds like what we want to do. Should be hard to add that to ioctl modesetting callback. Never the less this patch might be usefull, as for instance we might be doing modesetting at the same time on 2 different head of an avivo gpu and this might lead to // execution of atombios and it's my understanding that atombios code is not safe in this regards. Sorry, I'm confused. So finally: do you think we should use read/write locking? I guess we could make atom_execute_table using read-lock and add new function like atom_execute_table_write_lock using write-lock. Then convert sensitive places (like power management) to use _write_lock instead standard atom_execute_table. Not sure about that modesetting at same time. If we don't want to do 2 modesetting operations at same time, is there really sense to introduce read/write locking? When will we use read lock then? Just for connectors and powerplay_info reading? Sounds like wasting time for that. Also could you explain: Should be hard to add that to ioctl modesetting callback. please? -- Rafał To summup, this patch is good because it will exclude // execution of atom stuff which i think is good. Yet i don't think it's enough for power management. The idea of r/w lock is that we can have any number of reader so the lock won't block anyone in any path. But once you take the lock in write mode you are the only one messing with the hw which is what we want for PM (according to doc). To be effective reader lock must be taken in all ioctl modesetting callback, and write lock in pm path. I think this r/w lock needs discussion, i am not fan of adding another lock to the driver. Cheers, Jerome -- 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 (V6)
On Fri, Dec 18, 2009 at 02:30:34PM +0100, Rafał Miłecki wrote: W dniu 18 grudnia 2009 13:24 użytkownik Jerome Glisse gli...@freedesktop.org napisał: I think it would be better to change : RADEON_PM_ACTION_NONE - PM_NONE ... We already know we are in the radeon module so this is redundant to put it in the name again. And i don't think PM_NONE will conflict with other kernel symbol. Same apply to all other name. Thanks. I guess you meant PM_ACTION_NONE? I think it'll easier to understand code when we include ACTION string. I wish to convert radeon module to use dev_err, dev_info, ... instead of DRM_DEBUG, DRM_INFO. Motivation behind that is multi GPU computer. It's not common yet but i think we will want to support that in the future. Convertion to match this can be done as a latter patch. There is few things that might be improved but that shouldn't matter that much. As that's general issue (we use DRM_*... everywhere) I would prefer to make this patch follow general design for now. Thanks for comments. -- Rafał No we don't use DRM_* everywhere. I slowly convert to dev_* when doing a patch. But as i said i could do the conversion myself latter. Cheers, Jerome -- 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 (V6)
W dniu 18 grudnia 2009 15:18 użytkownik Jerome Glisse gli...@freedesktop.org napisał: On Fri, Dec 18, 2009 at 02:30:34PM +0100, Rafał Miłecki wrote: W dniu 18 grudnia 2009 13:24 użytkownik Jerome Glisse gli...@freedesktop.org napisał: I think it would be better to change : RADEON_PM_ACTION_NONE - PM_NONE ... We already know we are in the radeon module so this is redundant to put it in the name again. And i don't think PM_NONE will conflict with other kernel symbol. Same apply to all other name. Thanks. I guess you meant PM_ACTION_NONE? I think it'll easier to understand code when we include ACTION string. I wish to convert radeon module to use dev_err, dev_info, ... instead of DRM_DEBUG, DRM_INFO. Motivation behind that is multi GPU computer. It's not common yet but i think we will want to support that in the future. Convertion to match this can be done as a latter patch. There is few things that might be improved but that shouldn't matter that much. As that's general issue (we use DRM_*... everywhere) I would prefer to make this patch follow general design for now. Thanks for comments. -- Rafał No we don't use DRM_* everywhere. I slowly convert to dev_* when doing a patch. But as i said i could do the conversion myself latter. Ups, sorry, didn't notice that :) -- Rafał -- 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: prevent parallel AtomBIOS calls
W dniu 18 grudnia 2009 15:17 użytkownik Jerome Glisse gli...@freedesktop.org napisał: On Fri, Dec 18, 2009 at 02:27:57PM +0100, Rafał Miłecki wrote: W dniu 18 grudnia 2009 13:19 użytkownik Jerome Glisse gli...@freedesktop.org napisał: On Thu, Dec 17, 2009 at 12:04:02AM +0100, Rafał Miłecki wrote: In future we will execute AtomBIOS commands from contexts (like power management) so we need to make sure we won't execute two commands at same time to prevent locking up GPU. With this patch applied Sedat Dilek (RV515) was able to finally test my PM patch. Also tested on my RV620. -- Rafał I am in favor of a different approach, using a r/w lock and taking the lock in read in all path, and write in powermanager init path. Doc state that we need exclusive access to GPU while doing PM stuff. Thus r/w lock sounds like what we want to do. Should be hard to add that to ioctl modesetting callback. Never the less this patch might be usefull, as for instance we might be doing modesetting at the same time on 2 different head of an avivo gpu and this might lead to // execution of atombios and it's my understanding that atombios code is not safe in this regards. Sorry, I'm confused. So finally: do you think we should use read/write locking? I guess we could make atom_execute_table using read-lock and add new function like atom_execute_table_write_lock using write-lock. Then convert sensitive places (like power management) to use _write_lock instead standard atom_execute_table. Not sure about that modesetting at same time. If we don't want to do 2 modesetting operations at same time, is there really sense to introduce read/write locking? When will we use read lock then? Just for connectors and powerplay_info reading? Sounds like wasting time for that. Also could you explain: Should be hard to add that to ioctl modesetting callback. please? -- Rafał To summup, this patch is good because it will exclude // execution of atom stuff which i think is good. Yet i don't think it's enough for power management. The idea of r/w lock is that we can have any number of reader so the lock won't block anyone in any path. But once you take the lock in write mode you are the only one messing with the hw which is what we want for PM (according to doc). To be effective reader lock must be taken in all ioctl modesetting callback, and write lock in pm path. I think this r/w lock needs discussion, i am not fan of adding another lock to the driver. But I'm not sure if we have much more time if we want to still include PM in 2.6.33 :| Is that patch OK for now? And eventually to be improved later? Not sure what do you need to discuss, but I think proposed solution would match your description. By adding read_lock in current atom.c::atom_execute_table we would make all current code (including ioctl and modesetting) use read_lock. Then adding proposed atom.c::atom_execute_table_write_lock and using it in radeon_pm.c would give as excluding access to hardware for powermanagement operations. Is there anything lacking in that? Not sure why you like or not locking, but I don't think we can solve this problem without locks :) -- Rafał -- 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] drivers/radeon/kms: Workaround RV410/R420 CP errata.
On Fri, 2009-12-18 at 01:11 -0800, Corbin Simpson wrote:
[...]
@@ -194,6 +225,9 @@ static int r420_startup(struct radeon_device *rdev)
dev_err(rdev-dev, failled initializing CP (%d).\n, r);
return r;
}
+/* Handle CP errata. */
+r420_cp_errata_init(rdev);
+
r = r100_wb_init(rdev);
if (r) {
On a purely cosmetic POV, it looks like you indent with spaces in a file
previously indented with tabs.
Xav
--
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
[Bug 25707] Problems with DRI on ATI Radeon HD3850
http://bugs.freedesktop.org/show_bug.cgi?id=25707 --- Comment #4 from Rafał Miłecki zaj...@gmail.com 2009-12-18 06:38:47 PST --- Important part: (II) [drm] DRM interface version 1.3 (II) [drm] DRM open master succeeded. (II) RADEON(0): [drm] Using the DRM lock SAREA also for drawables. (II) RADEON(0): [drm] framebuffer handle = 0xe800 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): X context handle = 0x1 (II) RADEON(0): [drm] installed DRM signal handler (WW) RADEON(0): [agp] AGP not available (EE) RADEON(0): [agp] AGP failed to initialize. Disabling the DRI. (II) RADEON(0): [agp] You may want to make sure the agpgart kernel module is loaded before the radeon kernel module. (II) RADEON(0): [drm] removed 1 reserved context for kernel (II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0xf8025000 at 0xb714e000 (II) RADEON(0): [drm] Closed DRM master. (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0x010700e8 0x00ff00e0 (II) RADEON(0): MC_AGP_LOCATION : 0x003f (==) RADEON(0): Backing store disabled (WW) RADEON(0): Direct rendering disabled (EE) RADEON(0): Acceleration initialization failed (II) RADEON(0): Acceleration disabled -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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: radeon KMS causes GART Table Walk Errors (was: K8 ECC error with linux-2.6.32)
On Fri, Dec 18, 2009 at 02:47:00PM +0100, Johannes Hirte wrote: Am Mittwoch 16 Dezember 2009 20:31:48 schrieb Johannes Hirte: Am Mittwoch 16 Dezember 2009 19:41:48 schrieb Jerome Glisse: On Wed, Dec 16, 2009 at 03:58:30PM +0100, Johannes Hirte wrote: Am Mittwoch 16 Dezember 2009 08:14:43 schrieb Borislav Petkov: On Tue, Dec 15, 2009 at 11:00:46PM +0100, Johannes Hirte wrote: This patch (as the BIOS option) will only disable the error reports. The error itself will still occur, right? So necessary to find out why the radeon driver trigger this error. Because the graphics driver does aperture accesses with no matching GART translation, and the hw generates mchecks for that. The whole story on GART table walk errors is in section 13.10.1 GART Table Walk Error Reporting in the document here: http://support.amd.com/us/Processor_TechDocs/32559.pdf I can't say for sure about your BIOS, but if it is done as described in the abovementioned section, the BIOS option should disable logging of the error, which implies reporting too. The patch is still needed for machines that do not have that BIOS option. Disabling in BIOS doesn't made any difference. The errors were still reported. Your patch disabled it. But I think this will make work harder for driver developers as they won't get this error anymore. Could this be made changeable on runtime/boottime? I've added drm people to CC as they're responsible for this error. regards, Johannes More context would be usefull. Are you using KMS ? If so is your userspace KMS capable ? Does this GART error happen all the time or only after sometimes or when doing somethings specific ? Yes I'm using KMS when this error occours. Hardware: - Tyan Tiger K8W S8875 (AMD8151 Northbridge) - Radeon HD3650 AGP (RV635) Software: - linux-2.6.32 - libdrm-2.4.16 - mesa-7.7_rc2 - xf86-video-ati- (latest git everytime) - KDE-4.3.4 with compositing enabled (OpenGL) The errors occours after a while of normal desktop work. I haven't tested without KMS or compisiting. Will do this as well. It's KMS related but not to compositing. Without KMS the errors don't occur. I found at least two log entries where the error occurred on initializing KMS. It happens reliable after a while working with X. regards, Johannes Can you give me the full reference of your motherboard ? Cheers, Jerome -- 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
[Bug 25707] Problems with DRI on ATI Radeon HD3850
http://bugs.freedesktop.org/show_bug.cgi?id=25707 --- Comment #5 from Maxim kolma...@gmail.com 2009-12-18 06:51:15 PST --- You mean this line: (II) RADEON(0): [agp] You may want to make sure the agpgart kernel module is loaded before the radeon kernel module. I`m sure that agpgart is loaded before radeon. Here`s my /etc/modules.autoload.d/kernel-2.6: # /etc/modules.autoload.d/kernel-2.6: kernel modules to load when system boots. # # Note that this file is for 2.6 kernels. # # Add the names of modules that you'd like to load when the system # starts into this file, one per line. Comments begin with # and # are ignored. Read man modules.autoload for additional details. # For example: # aic7xxx ati-agp agpgart drm radeon vboxdrv vboxnetflt vboxnetadp -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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] drivers/radeon/kms: Workaround RV410/R420 CP errata.
On Fri, Dec 18, 2009 at 01:11:45AM -0800, Corbin Simpson wrote: From 7c1de3201bd4e965da7c1d542c46d8b2725bf42d Mon Sep 17 00:00:00 2001 From: Corbin Simpson mostawesomed...@gmail.com Date: Fri, 18 Dec 2009 01:00:57 -0800 Subject: [PATCH] drivers/radeon/kms: Workaround RV410/R420 CP errata. Long story short, this fixes sporadic hardlocks with my rv410 during times of intense 2D acceleration (Flash on Fx3). Signed-off-by: Corbin Simpson mostawesomed...@gmail.com --- Beside the tab issue you should also avoid to reallocate scratch register if it was already allocated. Maybe init the scratch to -1 and test for that. Otherwise after few suspend/resume you won't have scratch reg left. Cheers, Jerome -- 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
[Bug 25707] Problems with DRI on ATI Radeon HD3850
http://bugs.freedesktop.org/show_bug.cgi?id=25707 --- Comment #6 from Alex Deucher ag...@yahoo.com 2009-12-18 07:54:09 PST --- Please attach your dmesg. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 25708] Suppress FBO debug output
http://bugs.freedesktop.org/show_bug.cgi?id=25708 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Alex Deucher ag...@yahoo.com 2009-12-18 08:05:28 PST --- pushed: c8de081dc1f077a026a962244117ec69f0ba7055 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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] drm/radeon/kms: never combine LVDS with another encoder
From 08a7a77cc9928007048264616c7e6cf71480b294 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Fri, 18 Dec 2009 11:28:22 -0500
Subject: [PATCH] drm/radeon/kms: never combine LVDS with another encoder
When linking multiple encoders to a connector, make sure
to not link LVDS with another connector. Some bioses
have the same i2c line for LVDS and VGA.
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_atombios.c | 49 ++
1 files changed, 23 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index b5912c2..321044b 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -745,8 +745,7 @@ bool
radeon_get_atom_connector_info_from_supported_devices_table(struct
else
radeon_add_legacy_encoder(dev,
radeon_get_encoder_id(dev,
- (1
-i),
+ (1
i),
dac),
(1 i));
}
@@ -758,32 +757,30 @@ bool
radeon_get_atom_connector_info_from_supported_devices_table(struct
if (bios_connectors[j].valid (i != j)) {
if (bios_connectors[i].line_mux ==
bios_connectors[j].line_mux) {
- if (((bios_connectors[i].
- devices
- (ATOM_DEVICE_DFP_SUPPORT))
- (bios_connectors[j].
-devices
-
(ATOM_DEVICE_CRT_SUPPORT)))
- ||
- ((bios_connectors[j].
- devices
- (ATOM_DEVICE_DFP_SUPPORT))
- (bios_connectors[i].
-devices
-
(ATOM_DEVICE_CRT_SUPPORT {
- bios_connectors[i].
- devices |=
- bios_connectors[j].
- devices;
- bios_connectors[i].
- connector_type =
-
DRM_MODE_CONNECTOR_DVII;
- if
(bios_connectors[j].devices
-
(ATOM_DEVICE_DFP_SUPPORT))
+ /* make sure not to combine
LVDS */
+ if (bios_connectors[i].devices
(ATOM_DEVICE_LCD_SUPPORT)) {
+
bios_connectors[i].line_mux = 53;
+
bios_connectors[i].ddc_bus.valid = false;
+ continue;
+ }
+ if (bios_connectors[j].devices
(ATOM_DEVICE_LCD_SUPPORT)) {
+
bios_connectors[j].line_mux = 53;
+
bios_connectors[j].ddc_bus.valid = false;
+ continue;
+ }
+ /* combine analog and digital
for DVI-I */
+ if
(((bios_connectors[i].devices (ATOM_DEVICE_DFP_SUPPORT))
+
(bios_connectors[j].devices (ATOM_DEVICE_CRT_SUPPORT))) ||
+
((bios_connectors[j].devices (ATOM_DEVICE_DFP_SUPPORT))
+
(bios_connectors[i].devices (ATOM_DEVICE_CRT_SUPPORT {
+
bios_connectors[i].devices |=
+
Re: radeon KMS causes GART Table Walk Errors (was: K8 ECC error with linux-2.6.32)
Am Mittwoch 16 Dezember 2009 20:31:48 schrieb Johannes Hirte: Am Mittwoch 16 Dezember 2009 19:41:48 schrieb Jerome Glisse: On Wed, Dec 16, 2009 at 03:58:30PM +0100, Johannes Hirte wrote: Am Mittwoch 16 Dezember 2009 08:14:43 schrieb Borislav Petkov: On Tue, Dec 15, 2009 at 11:00:46PM +0100, Johannes Hirte wrote: This patch (as the BIOS option) will only disable the error reports. The error itself will still occur, right? So necessary to find out why the radeon driver trigger this error. Because the graphics driver does aperture accesses with no matching GART translation, and the hw generates mchecks for that. The whole story on GART table walk errors is in section 13.10.1 GART Table Walk Error Reporting in the document here: http://support.amd.com/us/Processor_TechDocs/32559.pdf I can't say for sure about your BIOS, but if it is done as described in the abovementioned section, the BIOS option should disable logging of the error, which implies reporting too. The patch is still needed for machines that do not have that BIOS option. Disabling in BIOS doesn't made any difference. The errors were still reported. Your patch disabled it. But I think this will make work harder for driver developers as they won't get this error anymore. Could this be made changeable on runtime/boottime? I've added drm people to CC as they're responsible for this error. regards, Johannes More context would be usefull. Are you using KMS ? If so is your userspace KMS capable ? Does this GART error happen all the time or only after sometimes or when doing somethings specific ? Yes I'm using KMS when this error occours. Hardware: - Tyan Tiger K8W S8875 (AMD8151 Northbridge) - Radeon HD3650 AGP (RV635) Software: - linux-2.6.32 - libdrm-2.4.16 - mesa-7.7_rc2 - xf86-video-ati- (latest git everytime) - KDE-4.3.4 with compositing enabled (OpenGL) The errors occours after a while of normal desktop work. I haven't tested without KMS or compisiting. Will do this as well. It's KMS related but not to compositing. Without KMS the errors don't occur. I found at least two log entries where the error occurred on initializing KMS. It happens reliable after a while working with X. regards, Johannes -- 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: radeon KMS causes GART Table Walk Errors (was: K8 ECC error with linux-2.6.32)
Am Freitag 18 Dezember 2009 15:44:35 schrieb Jerome Glisse: On Fri, Dec 18, 2009 at 02:47:00PM +0100, Johannes Hirte wrote: Am Mittwoch 16 Dezember 2009 20:31:48 schrieb Johannes Hirte: Am Mittwoch 16 Dezember 2009 19:41:48 schrieb Jerome Glisse: On Wed, Dec 16, 2009 at 03:58:30PM +0100, Johannes Hirte wrote: Am Mittwoch 16 Dezember 2009 08:14:43 schrieb Borislav Petkov: On Tue, Dec 15, 2009 at 11:00:46PM +0100, Johannes Hirte wrote: This patch (as the BIOS option) will only disable the error reports. The error itself will still occur, right? So necessary to find out why the radeon driver trigger this error. Because the graphics driver does aperture accesses with no matching GART translation, and the hw generates mchecks for that. The whole story on GART table walk errors is in section 13.10.1 GART Table Walk Error Reporting in the document here: http://support.amd.com/us/Processor_TechDocs/32559.pdf I can't say for sure about your BIOS, but if it is done as described in the abovementioned section, the BIOS option should disable logging of the error, which implies reporting too. The patch is still needed for machines that do not have that BIOS option. Disabling in BIOS doesn't made any difference. The errors were still reported. Your patch disabled it. But I think this will make work harder for driver developers as they won't get this error anymore. Could this be made changeable on runtime/boottime? I've added drm people to CC as they're responsible for this error. regards, Johannes More context would be usefull. Are you using KMS ? If so is your userspace KMS capable ? Does this GART error happen all the time or only after sometimes or when doing somethings specific ? Yes I'm using KMS when this error occours. Hardware: - Tyan Tiger K8W S8875 (AMD8151 Northbridge) - Radeon HD3650 AGP (RV635) Software: - linux-2.6.32 - libdrm-2.4.16 - mesa-7.7_rc2 - xf86-video-ati- (latest git everytime) - KDE-4.3.4 with compositing enabled (OpenGL) The errors occours after a while of normal desktop work. I haven't tested without KMS or compisiting. Will do this as well. It's KMS related but not to compositing. Without KMS the errors don't occur. I found at least two log entries where the error occurred on initializing KMS. It happens reliable after a while working with X. regards, Johannes Can you give me the full reference of your motherboard ? Cheers, Jerome Tyan Tiger K8W (S2875ANRF) http://tyan.com/product_board_detail.aspx?pid=103 regards, Johannes -- 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 (V7)
2009/12/18 Rafał Miłecki zaj...@gmail.com:
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
You may need to apply patch for AtomBIOS's mutex locking:
http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg45666.html
(I suggest doing that).
Please test this patch for dpms off:
sleep 1s; xset dpms force off; sleep 1s; cat /debugfs/dri/0/radeon_pm_info
Also make sure PM is still working when you come back from dpms off.
This is looking good. two minor things:
--- a/drivers/gpu/drm/radeon/rs600.c
+++ b/drivers/gpu/drm/radeon/rs600.c
@@ -399,10 +399,16 @@ int rs600_irq_process(struct radeon_device *rdev)
if (G_40_SW_INT_EN(status))
radeon_fence_process(rdev);
/* Vertical blank interrupts */
- if (G_007EDC_LB_D1_VBLANK_INTERRUPT(r500_disp_int))
+ if (G_007EDC_LB_D1_VBLANK_INTERRUPT(r500_disp_int)) {
drm_handle_vblank(rdev-ddev, 0);
- if (G_007EDC_LB_D2_VBLANK_INTERRUPT(r500_disp_int))
+ if (rdev-pm.vblank_callback)
+ queue_work(rdev-wq, rdev-pm.reclock_work);
+ }
+ if (G_007EDC_LB_D2_VBLANK_INTERRUPT(r500_disp_int)) {
+ if (rdev-pm.vblank_callback)
+ queue_work(rdev-wq, rdev-pm.reclock_work);
drm_handle_vblank(rdev-ddev, 1);
+ }
if (G_007EDC_DC_HOT_PLUG_DETECT1_INTERRUPT(r500_disp_int)) {
queue_hotplug = true;
DRM_DEBUG(HPD1\n);
Make the order the same for both vblank handlers. I.e.:
drm_handle_vblank(rdev-ddev, 1);
if (rdev-pm.vblank_callback)
queue_work(rdev-wq, rdev-pm.reclock_work);
@@ -1025,6 +1028,9 @@ radeon_atom_encoder_dpms(struct drm_encoder
*encoder, int mode)
atom_execute_table(rdev-mode_info.atom_context, index,
(uint32_t *)args);
}
radeon_atombios_encoder_dpms_scratch_regs(encoder, (mode ==
DRM_MODE_DPMS_ON) ? true : false);
+
+ /* adjust pm to dpms change */
+ radeon_pm_compute_clocks(rdev);
}
@@ -96,6 +96,10 @@ static void radeon_legacy_lvds_dpms(struct
drm_encoder *encoder, int mode)
radeon_atombios_encoder_dpms_scratch_regs(encoder, (mode ==
DRM_MODE_DPMS_ON) ? true : false);
else
radeon_combios_encoder_dpms_scratch_regs(encoder, (mode ==
DRM_MODE_DPMS_ON) ? true : false);
+
+ /* adjust pm to mode change */
+ if (mode == DRM_MODE_DPMS_OFF)
+ radeon_pm_compute_clocks(rdev);
}
You check for DPMS_OFF in the legacy code, but not atom. It should be
consistent.
Alex
--
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] drm/radeon/kms: add dynamic engine reclocking (V8)
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 With Alex suggestions. As always I really suggest using this together with [PATCH] drm/radeon/kms: prevent parallel AtomBIOS calls http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg45666.html To enable use dynpm module parameter (dynpm=1). Set it at boot time (radeon.dynpm=1), at load time (modprobe dynpm=1) or in modprobe.d config. -- Rafał 0001-drm-radeon-kms-add-dynamic-engine-reclocking-V8.patch Description: Binary data -- 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
[Bug 25622] KMS blurry output after initialisation
http://bugs.freedesktop.org/show_bug.cgi?id=25622 --- Comment #6 from Aidan Marks ai...@cisco.com 2009-12-18 11:23:05 PST --- I've noticed on dpms restore that when the corruption occurs, my monitor OSD shows 1280x1600, not 2560x1600. this seems different to the boot blur, where the osd reports 2560x1600. The dpms restore issue is happening very regularly. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 25707] Problems with DRI on ATI Radeon HD3850
http://bugs.freedesktop.org/show_bug.cgi?id=25707 --- Comment #7 from Maxim kolma...@gmail.com 2009-12-18 11:51:03 PST --- Created an attachment (id=32180) -- (http://bugs.freedesktop.org/attachment.cgi?id=32180) dmesg -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[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 #36 from Alex Deucher alexdeuc...@gmail.com 2009-12-18 19:53:01 --- Cool. What git tree are you using? Linus' or Dave's? I wonder what fixed it? The new_pll option isn't applicable to your chip. I guess we can close this bug then, FINALLY :) As the the performance problems, make sure 3D is enabled (KMS requires mesa built with KMS support) and if you are still having a problem, file a bug on https://bugs.freedesktop.org -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- 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
[Bug 25707] Problems with DRI on ATI Radeon HD3850
http://bugs.freedesktop.org/show_bug.cgi?id=25707 --- Comment #8 from Maxim kolma...@gmail.com 2009-12-18 11:55:05 PST --- I think problem is here: 0.234229] uvesafb: failed to execute /sbin/v86d [0.234238] uvesafb: make sure that the v86d helper is installed and executable [0.234246] uvesafb: Getting VBE info block failed (eax=0x4f00, err=-2) [0.234252] uvesafb: vbe_init() failed with -22 [0.234261] uvesafb: probe of uvesafb.0 failed with error -22 [0.234556] vesafb: framebuffer at 0xe800, mapped to 0xf808, using 10240k, total 16384k [0.234564] vesafb: mode is 1280x1024x32, linelength=5120, pages=2 [0.234569] vesafb: protected mode interface info at c000:a176 [0.234575] vesafb: pmi: set display start = c00ca218, set palette = c00ca2d6 [0.234580] vesafb: scrolling: redraw [0.234585] vesafb: Truecolor: size=0:8:8:8, shift=0:16:8:0 Vesa says that framebuffer is mapped to 0xf808, but xorg still wants to acces it from 0xe800 or i don`t understand this thing. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 25707] Problems with DRI on ATI Radeon HD3850
http://bugs.freedesktop.org/show_bug.cgi?id=25707 --- Comment #9 from Alex Deucher ag...@yahoo.com 2009-12-18 11:58:29 PST --- The agp kernel module for your chipset doesn't seem to be loaded. You system has an Intel AGP bridge so it should be using the intel agp module. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 25707] Problems with DRI on ATI Radeon HD3850
http://bugs.freedesktop.org/show_bug.cgi?id=25707 --- Comment #10 from Maxim kolma...@gmail.com 2009-12-18 12:12:22 PST --- OK. I have found it too. I had enabled ati chipset in the kernel. And now i enabled intel chipset anb all works fine. glxgears show ~1100 fps and ut2004-demo goes with little count of lags. Excuse me for disturbing you. P.S. Sorry for my bad English -- i`m 15 years old student from Russia. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 25707] Problems with DRI on ATI Radeon HD3850
http://bugs.freedesktop.org/show_bug.cgi?id=25707 Maxim kolma...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 25707] Problems with DRI on ATI Radeon HD3850
http://bugs.freedesktop.org/show_bug.cgi?id=25707 Rafał Miłecki zaj...@gmail.com changed: What|Removed |Added Resolution|FIXED |INVALID --- Comment #11 from Rafał Miłecki zaj...@gmail.com 2009-12-18 12:25:31 PST --- No problem, great you've this working now :) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 25717] New: Radeon: system locks up when sending many vertices.
http://bugs.freedesktop.org/show_bug.cgi?id=25717 Summary: Radeon: system locks up when sending many vertices. Product: DRI Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: critical Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: monr...@gmail.com Created an attachment (id=32184) -- (http://bugs.freedesktop.org/attachment.cgi?id=32184) program that locks up the system Some programs cause a complete system lock-up here, most notably the program makehuman, and progs/demos/gltestperf. I suspect this is because the GPU or the drm has a problem handling too many vertices. I created a little test program that causes a guaranteed system lock-up here. This is on a RS780, drm-next and mesa master from today. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 25490] kernel crash with 2.6.32, drm and kms enabled.
http://bugs.freedesktop.org/show_bug.cgi?id=25490 --- Comment #1 from dagg stompdagg...@yahoo.com 2009-12-18 12:37:29 PST --- Created an attachment (id=32185) -- (http://bugs.freedesktop.org/attachment.cgi?id=32185) another crash traceback another crash, this time it's seems more informative -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 25490] kernel crash with 2.6.32, drm and kms enabled.
http://bugs.freedesktop.org/show_bug.cgi?id=25490 --- Comment #2 from Rafał Miłecki zaj...@gmail.com 2009-12-18 13:42:05 PST --- Your GPU just locks up but we don't have idea from logs what causes that. Did you do something specific when this has happened? Like some specific application usage, or starting video, or sth? I experience lock up on my 34xx (Sony VAIO) greatly reproducible by using JDownloader. Will debug that after our HDMI and PM issues will calm down. Maybe this will same fix for your case. By the way, could you try running JDownloader for some minutes? With having this on top, maximized. You just download it, unpack and use java -jar JDownloader.jar to start it. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 25718] New: gpu death at radeon_fence_wait
http://bugs.freedesktop.org/show_bug.cgi?id=25718 Summary: gpu death at radeon_fence_wait Product: DRI Version: XOrg CVS Platform: Other OS/Version: All Status: NEW Severity: major Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: ai...@cisco.com randomly during normal kde desktop usage, display goes all gray or similar momentarily, then switches off. rv790, kms, 2.6.31.1 + drm-linus patch (http://files.iniza.org/drm-linus/vanilla-2.6.32/) + V8 pm patch enabled. captured the following similar crashes within minutes of startup: 320.709748] [drm:radeon_fence_wait] *ERROR* fence(88030c20e5c0:0x0001B7CE) 510ms timeout going to reset GPU 320.709758] radeon :02:00.0: GPU softreset 320.709762] radeon :02:00.0: R_008010_GRBM_STATUS=0xE57044A4 320.709766] radeon :02:00.0: R_008014_GRBM_STATUS2=0x00FF3F02 320.709770] radeon :02:00.0: R_000E50_SRBM_STATUS=0x200022C0 320.867374] radeon :02:00.0: Wait for MC idle timedout ! 320.867380] radeon :02:00.0: R_008020_GRBM_SOFT_RESET=0x7FEE 320.867435] radeon :02:00.0: R_008020_GRBM_SOFT_RESET=0x0001 320.867496] radeon :02:00.0: R_000E60_SRBM_SOFT_RESET=0x0C02 320.891743] radeon :02:00.0: R_008010_GRBM_STATUS=0x 320.891746] radeon :02:00.0: R_008014_GRBM_STATUS2=0x 320.891748] radeon :02:00.0: R_000E50_SRBM_STATUS=0x reboot 1219.885702] [drm:radeon_fence_wait] *ERROR* fence(88030cd285c0:0x00064506) 510ms timeout going to reset GPU 1219.885713] radeon :02:00.0: GPU softreset 1219.885717] radeon :02:00.0: R_008010_GRBM_STATUS=0xE57004A4 1219.885721] radeon :02:00.0: R_008014_GRBM_STATUS2=0x00FF0F02 1219.885725] radeon :02:00.0: R_000E50_SRBM_STATUS=0x20001AC0 1220.044073] radeon :02:00.0: Wait for MC idle timedout ! 1220.044081] radeon :02:00.0: R_008020_GRBM_SOFT_RESET=0x7FEE 1220.044136] radeon :02:00.0: R_008020_GRBM_SOFT_RESET=0x0001 1220.044197] radeon :02:00.0: R_000E60_SRBM_SOFT_RESET=0x0C02 1220.068448] radeon :02:00.0: R_008010_GRBM_STATUS=0x 1220.068454] radeon :02:00.0: R_008014_GRBM_STATUS2=0x 1220.068460] radeon :02:00.0: R_000E50_SRBM_STATUS=0x -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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
[Bug 25718] gpu death at radeon_fence_wait
http://bugs.freedesktop.org/show_bug.cgi?id=25718 --- Comment #1 from Aidan Marks ai...@cisco.com 2009-12-18 18:33:51 PST --- typo, should say 2.6.32.1 above. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- 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 0/2] drm/radeon/kms: add support for depth-only rendering and 3DC texture compression on R3xx-R5xx
Hi,
I'd like to propose two patches for kernel DRM.
Currently the R300 CS checker doesn't allow rendering with no color
buffer set. This is needed for depth-only rendering which is required
for rendering into depth textures to generate shadow maps. The first
attached patch removes this restriction by skipping checking the
colorbuffer if both ZB_BW_CNTL.FAST_FILL and
RB3D_BLENDCNTL.READ_ENABLE are disabled, and RB3D_COLOR_CHANNEL_MASK
is 0. When these bits are set, the hardware won't touch the
colorbuffer at all.
The second attached patch adds support for the 3DC texture compression
(formats ATI1N and ATI2N). The former has 64 bits per 4x4 pixel block
(same as DXT1) and is available on R4xx and up, and the latter has 128
bits per 4x4 pixel block (same as DXT3/5) and is available on R5xx.
This functionality can be exposed in OpenGL by
GL_EXT_texture_compression_latc and GL_ARB_texture_compression_rgtc,
which is part of OpenGL 3.0 and will most probably be implemented in
Mesa in future.
Frankly ATI1N can already be used as it occupies the same format bits
as TX_FMT_3_3_2 with the addition that TX_FORMAT2_n.TXFORMAT_MSB must
be set. The CS parser doesn't read the TXFORMAT_MSB bit at all, so it
always interprets the format as 3_3_2. If the MSB bit is set with the
second patch, the CS parser interprets any format as ATI1N, because
the other extended formats won't be used anyway as they are not
exposed by any graphics API. Let me know if you agree with this
behavior.
Please review.
Best regards
Marek Olšák
From 386484e581cf4df96e3a62318103bcaa610bb238 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Thu, 17 Dec 2009 06:02:28 +0100
Subject: [PATCH 1/2] drm/radeon/kms: allow rendering while no colorbuffer is set on r300
Because hardware cannot disable all colorbuffers directly to do depth-only
rendering, a user should:
- disable reading from a colorbuffer in blending
- disable fastfill
- set the color channel mask to 0 to prevent writing to a colorbuffer
---
drivers/gpu/drm/radeon/r100.c |4
drivers/gpu/drm/radeon/r100_track.h |4 +++-
drivers/gpu/drm/radeon/r300.c | 12
3 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 84e5df7..7172746 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -2881,6 +2881,10 @@ int r100_cs_track_check(struct radeon_device *rdev, struct r100_cs_track *track)
for (i = 0; i track-num_cb; i++) {
if (track-cb[i].robj == NULL) {
+ if (!(track-fastfill || track-color_channel_mask ||
+ track-blend_read_enable)) {
+continue;
+ }
DRM_ERROR([drm] No buffer for color buffer %d !\n, i);
return -EINVAL;
}
diff --git a/drivers/gpu/drm/radeon/r100_track.h b/drivers/gpu/drm/radeon/r100_track.h
index 7188c37..b27a699 100644
--- a/drivers/gpu/drm/radeon/r100_track.h
+++ b/drivers/gpu/drm/radeon/r100_track.h
@@ -67,13 +67,15 @@ struct r100_cs_track {
unsigned immd_dwords;
unsigned num_arrays;
unsigned max_indx;
+ unsigned color_channel_mask;
struct r100_cs_track_array arrays[11];
struct r100_cs_track_cb cb[R300_MAX_CB];
struct r100_cs_track_cb zb;
struct r100_cs_track_texture textures[R300_TRACK_MAX_TEXTURE];
boolz_enabled;
boolseparate_cube;
-
+ boolfastfill;
+ boolblend_read_enable;
};
int r100_cs_track_check(struct radeon_device *rdev, struct r100_cs_track *track);
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 83490c2..6a5d117 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -992,6 +992,18 @@ static int r300_packet0_check(struct radeon_cs_parser *p,
}
ib[idx] = idx_value + ((u32)reloc-lobj.gpu_offset);
break;
+ case 0x4e0c:
+ /* RB3D_COLOR_CHANNEL_MASK */
+ track-color_channel_mask = idx_value;
+ break;
+ case 0x4d1c:
+ /* ZB_BW_CNTL */
+ track-fastfill = !!(idx_value (1 2));
+ break;
+ case 0x4e04:
+ /* RB3D_BLENDCNTL */
+ track-blend_read_enable = !!(idx_value (1 2));
+ break;
case 0x4be8:
/* valid register only on RV530 */
if (p-rdev-family == CHIP_RV530)
--
1.6.3.3
From e0d65186af2fbd6a73b3d4968347aee9e884f758 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Sat, 19 Dec 2009 00:23:00 +0100
Subject: [PATCH 2/2] drm/radeom/kms: add 3DC compression support
There are 2 formats:
ATI1N: 64 bits per 4x4 block, one-channel format
ATI2N: 128 bits per 4x4 block, two-channel format
---
drivers/gpu/drm/radeon/r300.c | 18 ++
drivers/gpu/drm/radeon/r300_reg.h |1 +
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 6a5d117..3f2cc9e 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -887,6 +887,14 @@ static int
Re: [PATCH 0/2] drm/radeon/kms: add support for depth-only rendering and 3DC texture compression on R3xx-R5xx
I'd like to propose two patches for kernel DRM. Both these sounds sane to me, I'll push them into a testing tree early next week, Dave. Currently the R300 CS checker doesn't allow rendering with no color buffer set. This is needed for depth-only rendering which is required for rendering into depth textures to generate shadow maps. The first attached patch removes this restriction by skipping checking the colorbuffer if both ZB_BW_CNTL.FAST_FILL and RB3D_BLENDCNTL.READ_ENABLE are disabled, and RB3D_COLOR_CHANNEL_MASK is 0. When these bits are set, the hardware won't touch the colorbuffer at all. The second attached patch adds support for the 3DC texture compression (formats ATI1N and ATI2N). The former has 64 bits per 4x4 pixel block (same as DXT1) and is available on R4xx and up, and the latter has 128 bits per 4x4 pixel block (same as DXT3/5) and is available on R5xx. This functionality can be exposed in OpenGL by GL_EXT_texture_compression_latc and GL_ARB_texture_compression_rgtc, which is part of OpenGL 3.0 and will most probably be implemented in Mesa in future. Frankly ATI1N can already be used as it occupies the same format bits as TX_FMT_3_3_2 with the addition that TX_FORMAT2_n.TXFORMAT_MSB must be set. The CS parser doesn't read the TXFORMAT_MSB bit at all, so it always interprets the format as 3_3_2. If the MSB bit is set with the second patch, the CS parser interprets any format as ATI1N, because the other extended formats won't be used anyway as they are not exposed by any graphics API. Let me know if you agree with this behavior. Please review. Best regards Marek Olšák -- 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
