Re: [PATCH] [rfc] drm/radeon/kms: pm debugging check for vbl.
2010/2/18 Dave Airlie airl...@gmail.com: From: Dave Airlie airl...@redhat.com This patch adds a check on avivo chips to see if we are in the VBL region for the active crtcs when we trigger the engine change. I appear to have glitches locally on pm transistion (not sure all fixes are in yet) and this at least seems to be correct here, maybe others can test on systems with no glitches. Because we are totally out of sync with VBLANK. If we correctly sync with it, it's just a lucky case. Please check my [PATCH] drm/radeon/kms: really wait for VBLANK in PM code and reply in thread where I posted it. + /* check if we are in vblank */ + radeon_pm_debug_check_in_vbl(rdev, false); radeon_set_power_state(rdev); + radeon_pm_debug_check_in_vbl(rdev, true); rdev-pm.planned_action = PM_ACTION_NONE; It adds some reading printing steps before every reclock, while we really want it to happen as soon as possible. Maybe you could execute this only on some #ifdef RADEON_PM_DEBUG ? -- Rafał -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] [rfc] drm/radeon/kms: pm debugging check for vbl.
2010/2/18 Rafał Miłecki zaj...@gmail.com: 2010/2/18 Dave Airlie airl...@gmail.com: From: Dave Airlie airl...@redhat.com This patch adds a check on avivo chips to see if we are in the VBL region for the active crtcs when we trigger the engine change. I appear to have glitches locally on pm transistion (not sure all fixes are in yet) and this at least seems to be correct here, maybe others can test on systems with no glitches. Because we are totally out of sync with VBLANK. If we correctly sync with it, it's just a lucky case. Please check my [PATCH] drm/radeon/kms: really wait for VBLANK in PM code and reply in thread where I posted it. Yeah I'll put this in when I've ran it here, it looks sane. It adds some reading printing steps before every reclock, while we really want it to happen as soon as possible. Maybe you could execute this only on some #ifdef RADEON_PM_DEBUG I don't think it'll be a major overhead, though doing it under a debug would be fine, but it would be nice to make it into a WARN_ON so we could track where this actually happens for ppl with something like kerneloops. Dave. -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] [rfc] drm/radeon/kms: pm debugging check for vbl.
It adds some reading printing steps before every reclock, while we really want it to happen as soon as possible. Maybe you could execute this only on some btw you won't get the print if you are in vblank, and if you aren't well the print doesn't matter, I'm also thinking the engine change reads/writes a lot of regs, so two more might not matter so much. Dave. -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26214] HDMI Audio with r600 KMS doesn't survive suspend to ram
http://bugs.freedesktop.org/show_bug.cgi?id=26214 Fabio Pedretti fabio@libero.it changed: What|Removed |Added CC||fabio@libero.it Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Fabio Pedretti fabio@libero.it 2010-02-18 00:53:46 PST --- Patch applied in 2.6.33-rc8. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] [rfc] drm/radeon/kms: pm debugging check for vbl.
W dniu 18 lutego 2010 09:28 użytkownik Dave Airlie airl...@gmail.com napisał: It adds some reading printing steps before every reclock, while we really want it to happen as soon as possible. Maybe you could execute this only on some btw you won't get the print if you are in vblank, and if you aren't well the print doesn't matter, I'm also thinking the engine change reads/writes a lot of regs, so two more might not matter so much. Yeah, maybe that's right. While your idea of testing being in VBLANK is sane :) it could happen we start reclocking in VBLANK (first test will pass), we reclock out of VBLANK (not wanted, possible corruption), and we hit next VBLANK in second test. In such situation (machine) I'm sure we will hit false in test anyway (sooner or later) but maybe we could improve in anyway somehow? To make sure it's sill the same VBLANK? -- Rafał -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] [rfc] drm/radeon/kms: pm debugging check for vbl.
2010/2/18 Rafał Miłecki zaj...@gmail.com: W dniu 18 lutego 2010 09:28 użytkownik Dave Airlie airl...@gmail.com napisał: It adds some reading printing steps before every reclock, while we really want it to happen as soon as possible. Maybe you could execute this only on some btw you won't get the print if you are in vblank, and if you aren't well the print doesn't matter, I'm also thinking the engine change reads/writes a lot of regs, so two more might not matter so much. Yeah, maybe that's right. While your idea of testing being in VBLANK is sane :) it could happen we start reclocking in VBLANK (first test will pass), we reclock out of VBLANK (not wanted, possible corruption), and we hit next VBLANK in second test. In such situation (machine) I'm sure we will hit false in test anyway (sooner or later) but maybe we could improve in anyway somehow? To make sure it's sill the same VBLANK? That could be possible, though if a reclock takes a full scanout to operate we've got other issues as it would never be possible by the sounds of it. The check on the way out could be toned down alright, its probably not as important, btw I've still got problems even with that other patch applied, I get reclocking in the middle of the frame, Reverting 73a6d3fc104827db574e4bd206a025299fef0bb1 drm/radeon/kms: use wait queue (events) for VBLANK sync still fixes it for me here. Dave. -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: implement reading PCIE lanes on R600+
W dniu 18 lutego 2010 05:57 użytkownik Dave Airlie airl...@gmail.com napisał: 2010/2/18 Rafał Miłecki zaj...@gmail.com: Ported from DDX The PCIE regs on r600 are the same offsets at the ones on rv370 from what I can see probably don't need to add a new PCIE_P struct at all I think the rv370 functions should work. Err, not really? # egrep --color define.*PCIE_(PORT_)?INDEX ./*h ./r600_reg.h:#define R600_PCIE_PORT_INDEX0x0038 ./radeon_reg.h:#define RADEON_PCIE_INDEX 0x0030 # egrep --color define.*PCIE_(PORT_)?DATA ./*h ./r600_reg.h:#define R600_PCIE_PORT_DATA 0x003c ./radeon_reg.h:#define RADEON_PCIE_DATA0x0034 -- Rafał -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6624] AIGLX reports not supported visuals
http://bugs.freedesktop.org/show_bug.cgi?id=6624 Olivier Le Thanh Duong oliv...@lethanh.be changed: What|Removed |Added Blocks||26481 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 6624] AIGLX reports not supported visuals
http://bugs.freedesktop.org/show_bug.cgi?id=6624 Olivier Le Thanh Duong oliv...@lethanh.be changed: What|Removed |Added Blocks|26481 | -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: free fence IB if it wasn't emited at IB free time
If at IB free time fence wasn't emited that means the IB wasn't
scheduled because an error occured somewhere, thus we can free
then fence and mark the IB as free.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/radeon_ring.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ring.c
b/drivers/gpu/drm/radeon/radeon_ring.c
index 38fa144..95c991a 100644
--- a/drivers/gpu/drm/radeon/radeon_ring.c
+++ b/drivers/gpu/drm/radeon/radeon_ring.c
@@ -130,6 +130,8 @@ void radeon_ib_free(struct radeon_device *rdev, struct
radeon_ib **ib)
if (tmp == NULL) {
return;
}
+ if (!tmp-fence-emited)
+ radeon_fence_unref(tmp-fence);
mutex_lock(rdev-ib_pool.mutex);
tmp-free = true;
mutex_unlock(rdev-ib_pool.mutex);
--
1.6.6
--
Download Intelreg; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: fix R3XX/R4XX memory controller initialization
Version 2 of memory controller did break the initialization for
R3XX/R4XX hardware. This patch fix it.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/r300.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 7f8dd10..765c4e5 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -505,7 +505,8 @@ int r300_gpu_reset(struct radeon_device *rdev)
*/
void r300_mc_init(struct radeon_device *rdev)
{
- uint32_t tmp;
+ u64 base;
+ u32 tmp;
/* DDR for all card after R300 IGP */
rdev-mc.vram_is_ddr = true;
@@ -518,6 +519,10 @@ void r300_mc_init(struct radeon_device *rdev)
default: rdev-mc.vram_width = 128; break;
}
r100_vram_init_sizes(rdev);
+ base = rdev-mc.aper_base;
+ if (rdev-flags RADEON_IS_IGP)
+ base = (RREG32(RADEON_NB_TOM) 0x) 16;
+ radeon_vram_location(rdev, rdev-mc, base);
if (!(rdev-flags RADEON_IS_AGP))
radeon_gtt_location(rdev, rdev-mc);
}
--
1.6.6
--
Download Intelreg; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: implement reading PCIE lanes on R600+
2010/2/17 Dave Airlie airl...@gmail.com: 2010/2/18 Rafał Miłecki zaj...@gmail.com: Ported from DDX The PCIE regs on r600 are the same offsets at the ones on rv370 from what I can see probably don't need to add a new PCIE_P struct at all I think the rv370 functions should work. There are PCIE index regs at the same offset, but the PCIE lane controls moved to the PCIE PORT index. Alex Dave. -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Download Intelreg; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: implement reading PCIE lanes on R600+
2010/2/17 Rafał Miłecki zaj...@gmail.com:
Ported from DDX
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/gpu/drm/radeon/r300.c | 5 -
drivers/gpu/drm/radeon/radeon.h | 14 ++
drivers/gpu/drm/radeon/radeon_asic.h | 4 ++--
drivers/gpu/drm/radeon/radeon_pm.c | 2 ++
4 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 654aca1..cd92880 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -593,7 +593,10 @@ int rv370_get_pcie_lanes(struct radeon_device *rdev)
/* FIXME wait for idle */
- link_width_cntl = RREG32_PCIE(RADEON_PCIE_LC_LINK_WIDTH_CNTL);
+ if (rdev-family CHIP_R600)
+ link_width_cntl = RREG32_PCIE(RADEON_PCIE_LC_LINK_WIDTH_CNTL);
+ else
+ link_width_cntl =
RREG32_PCIE_P(RADEON_PCIE_LC_LINK_WIDTH_CNTL);
switch ((link_width_cntl RADEON_PCIE_LC_LINK_WIDTH_RD_MASK)
RADEON_PCIE_LC_LINK_WIDTH_RD_SHIFT) {
case RADEON_PCIE_LC_LINK_WIDTH_X0:
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index b533411..db98924 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1009,6 +1009,8 @@ static inline void r100_mm_wreg(struct radeon_device
*rdev, uint32_t reg, uint32
#define WREG32_MC(reg, v) rdev-mc_wreg(rdev, (reg), (v))
#define RREG32_PCIE(reg) rv370_pcie_rreg(rdev, (reg))
#define WREG32_PCIE(reg, v) rv370_pcie_wreg(rdev, (reg), (v))
+#define RREG32_PCIE_P(reg) r600_pcie_port_rreg(rdev, (reg))
+#define WREG32_PCIE_P(reg, v) r600_pcie_port_wreg(rdev, (reg), (v))
#define WREG32_P(reg, val, mask) \
do { \
uint32_t tmp_ = RREG32(reg); \
@@ -1043,6 +1045,18 @@ static inline void rv370_pcie_wreg(struct
radeon_device *rdev, uint32_t reg, uin
WREG32(RADEON_PCIE_DATA, (v));
}
+static inline uint32_t r600_pcie_port_rreg(struct radeon_device *rdev,
uint32_t reg)
+{
+ WREG32(R600_PCIE_PORT_INDEX, ((reg) rdev-pcie_reg_mask));
+ return RREG32(R600_PCIE_PORT_DATA);
+}
+
+static inline void r600_pcie_port_wreg(struct radeon_device *rdev, uint32_t
reg, uint32_t v)
+{
+ WREG32(R600_PCIE_PORT_INDEX, ((reg) rdev-pcie_reg_mask));
+ WREG32(R600_PCIE_PORT_DATA, (v));
+}
+
These already exist in r600.c:
r600_pciep_rreg
r600_pciep_wreg
Alex
void r100_pll_errata_after_index(struct radeon_device *rdev);
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index 4b0cb67..735d594 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -547,7 +547,7 @@ static struct radeon_asic r600_asic = {
.set_engine_clock = radeon_atom_set_engine_clock,
.get_memory_clock = radeon_atom_get_memory_clock,
.set_memory_clock = radeon_atom_set_memory_clock,
- .get_pcie_lanes = NULL,
+ .get_pcie_lanes = rv370_get_pcie_lanes,
.set_pcie_lanes = NULL,
.set_clock_gating = NULL,
.set_surface_reg = r600_set_surface_reg,
@@ -593,7 +593,7 @@ static struct radeon_asic rv770_asic = {
.set_engine_clock = radeon_atom_set_engine_clock,
.get_memory_clock = radeon_atom_get_memory_clock,
.set_memory_clock = radeon_atom_set_memory_clock,
- .get_pcie_lanes = NULL,
+ .get_pcie_lanes = rv370_get_pcie_lanes,
.set_pcie_lanes = NULL,
.set_clock_gating = radeon_atom_set_clock_gating,
.set_surface_reg = r600_set_surface_reg,
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 8426aff..3b00202 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -441,6 +441,8 @@ static int radeon_debugfs_pm_info(struct seq_file *m,
void *data)
seq_printf(m, default memory clock: %u0 kHz\n,
rdev-clock.default_mclk);
if (rdev-asic-get_memory_clock)
seq_printf(m, current memory clock: %u0 kHz\n,
radeon_get_memory_clock(rdev));
+ if (rdev-asic-get_pcie_lanes)
+ seq_printf(m, PCIE lanes: %d\n,
radeon_get_pcie_lanes(rdev));
return 0;
}
--
1.6.4.2
--
Download Intelreg; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15328] high load avg, extreme sluggishness on T41 w/ Radeon Mobility M7
http://bugzilla.kernel.org/show_bug.cgi?id=15328 Jérôme Glisse gli...@freedesktop.org changed: What|Removed |Added CC||gli...@freedesktop.org --- Comment #7 from Jérôme Glisse gli...@freedesktop.org 2010-02-18 15:44:56 --- Yes, radeon is wrong, i am tracking down why we are doing WC - UC or UC - WC -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26631] New: R600 AGP KMS + dynpm,dynclks = stalls
http://bugs.freedesktop.org/show_bug.cgi?id=26631 Summary: R600 AGP KMS + dynpm,dynclks = stalls Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: li...@andyfurniss.entadsl.com I notice that if I boot KMS git with modeset=1 agpmode=8 dynpm=1 dynclks=1 that I get stalls during games, and lots of corresponding messages as in attached dmesg. Doesn't happen if I don't use dynpm=1 dynclks=1. Card is RV670 AGP, running git ddx,mesa,libdrm drm-radeon-testing. I don't usually boot with pm (it doesn't ever reduce clocks for me eg. in dpms) so don't know if it ever worked. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26631] R600 AGP KMS + dynpm,dynclks = stalls
http://bugs.freedesktop.org/show_bug.cgi?id=26631 --- Comment #1 from Andy Furniss li...@andyfurniss.entadsl.com 2010-02-18 07:54:53 PST --- Created an attachment (id=33386) -- (http://bugs.freedesktop.org/attachment.cgi?id=33386) dmesg -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Vmwgfx: lack of 3D acceleration
Hallo, I'trying to use the vmwgfx driver to anable 3D accellarion on vmware player, but xorg still use swrast driver. I'm using kernel 2.6.33-rc7-00213-g0706f50 self comiled with vmwgfx driver enabled. I'm using mesa_7_7_branch because is the only one vmwgfx works in xorg (master still doesn't work in xorg) and xorg 1.7.99.3 dated 20100121. It seems that drm recognize 3D capabilities, but Xorg doesn't This is what I get from dmesg: [4.470260] [drm] Initialized drm 1.1.0 20060810 [4.470304] initcall drm_core_init+0x0/0x100 [drm] returned 0 after 220 usecs [4.488209] [drm:drm_init], [4.488231] [drm:drm_get_dev], [4.488253] [drm:drm_get_minor], [4.489182] [drm:drm_get_minor], new minor assigned 64 [4.489204] [drm:drm_get_minor], [4.489372] [drm:drm_get_minor], new minor assigned 0 [4.490037] [drm] Capabilities: [4.491037] [drm] Rect copy. [4.491059] [drm] Cursor. [4.491080] [drm] Cursor bypass. [4.491102] [drm] Cursor bypass 2. [4.491124] [drm] 8bit emulation. [4.491146] [drm] Alpha cursor. [4.491167] [drm] 3D. [4.491189] [drm] Extended Fifo. [4.491211] [drm] Multimon. [4.491233] [drm] Pitchlock. [4.491254] [drm] Display Topology. [4.491276] [drm] VRAM at 0xf000 size is 131072 kiB [4.491298] [drm] MMIO at 0xe800 size is 2048 kiB [4.491320] [drm] global init. [4.495033] [drm] width 640 [4.495055] [drm] height 480 [4.495076] [drm] bpp 32 [4.496038] [drm] Fifo max 0x0020 min 0x1000 cap 0x007f [4.498031] [drm:vmw_fb_init], width 2560 [4.498053] [drm:vmw_fb_init], height 1600 [4.498075] [drm:vmw_fb_init], width 2048 [4.498097] [drm:vmw_fb_init], height 1600 [4.498118] [drm:vmw_fb_init], bpp32 [4.498140] [drm:vmw_fb_init], depth 24 [4.498162] [drm:vmw_fb_init], bpl8192 [4.498184] [drm:vmw_fb_init], r mask 00ff [4.498205] [drm:vmw_fb_init], g mask ff00 [4.498227] [drm:vmw_fb_init], b mask 00ff [4.498247] [drm:vmw_fb_init], fb_offset 0x [4.498266] [drm:vmw_fb_init], fb_pitch 8192 [4.498288] [drm:vmw_fb_init], fb_size 12800 kiB [4.524038] [drm] Have 3D [4.524059] [drm] Initialized vmwgfx 1.0.0 20100209 for :00:0f.0 on minor 0 [ 24.434211] [drm:drm_stub_open], [ 24.434390] [drm:drm_open_helper], pid = 2335, minor = 0 [ 24.435062] [drm] Master create. [ 24.435242] [drm] Master set. [ 24.436399] [drm:drm_setup], What Xorg says is this: II) vmwgfx(0): Using exact sizes for initial modes II) vmwgfx(0): Output LVDS1 using initial mode 800x600 II) vmwgfx(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated. ==) vmwgfx(0): DPI set to (96, 96) II) vmwgfx(0): 2D Acceleration is disabled II) vmwgfx(0): Fallback debugging is enabled II) vmwgfx(0): 3D Acceleration is disabled ==) vmwgfx(0): Backing store disabled ==) vmwgfx(0): Silken mouse enabled II) vmwgfx(0): RandR 1.2 enabled, ignore the following RandR disabled message. ==) vmwgfx(0): DPMS enabled II) vmwgfx(0): Damage tracking initialized II) vmwgfx(0): Setting screen physical size to 211 x 158 This is what glxinfo says: name of display: :0.0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: SGI server glx version string: 1.4 server glx extensions: GLX_ARB_multisample, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_OML_swap_method, GLX_SGI_make_current_read, GLX_SGIS_multisample, GLX_SGIX_hyperpipe, GLX_SGIX_swap_barrier, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_MESA_copy_sub_buffer, GLX_INTEL_swap_event client glx vendor string: Mesa Project and SGI client glx version string: 1.4 client glx extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_MESA_allocate_memory, GLX_MESA_copy_sub_buffer, GLX_MESA_swap_control, GLX_MESA_swap_frame_usage, GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_EXT_texture_from_pixmap GLX version: 1.4 GLX extensions: GLX_ARB_get_proc_address, GLX_ARB_multisample, GLX_EXT_import_context, GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer OpenGL vendor string: Mesa Project OpenGL renderer string: Software Rasterizer OpenGL version string: 2.1 Mesa 7.7.1-DEVEL OpenGL shading language version string: 1.20 It seems to use swrast. I would expect it to use vmwgfx_dri. Bye Marco -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel
Re: Vmwgfx: lack of 3D acceleration
On Thu, 2010-02-18 at 16:20 +0100, Marco wrote: What Xorg says is this: II) vmwgfx(0): Using exact sizes for initial modes II) vmwgfx(0): Output LVDS1 using initial mode 800x600 II) vmwgfx(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated. ==) vmwgfx(0): DPI set to (96, 96) I wonder why there isn't any mention here of loading the dri2 or at least exa and fb modules... Please provide the full Xorg.0.log file. II) vmwgfx(0): 2D Acceleration is disabled II) vmwgfx(0): Fallback debugging is enabled II) vmwgfx(0): 3D Acceleration is disabled Did you check that DRI2 was enabled for the xserver and Gallium build? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26603] radeon_fence_signaled warnings in kernel log
http://bugs.freedesktop.org/show_bug.cgi?id=26603 --- Comment #2 from Kevin DeKorte kdeko...@yahoo.com 2010-02-18 08:25:05 PST --- Appears to be fixed in git xf86-video-ati in commit a3b730eceb522c7ac1ef3dd6f6c7d773118d03f7 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15328] high load avg, extreme sluggishness on T41 w/ Radeon Mobility M7
http://bugzilla.kernel.org/show_bug.cgi?id=15328 --- Comment #8 from Jérôme Glisse gli...@freedesktop.org 2010-02-18 17:02:45 --- Ok so it's more likely because on non PAT get_page_memtype always return -1 thus we always do set_wb and if page were already wb it likely kill perf. I don't think we ever do WC - UC or UC - WC. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: really wait for VBLANK in PM code
El mié. 17 de feb. de 2010, a las 20:23:28 +0100, Rafał Miłecki escribió:
Signed-off-by: Rafał Miłecki zaj...@gmail.com
Reported-by: Jaime Velasco Juan jsagarri...@gmail.com
---
This should make the trick, Jaime can you check if this works for you? Does it
kill your corruptions?
It doesn't work, it have the same problem than the current code:
[8.682478] [drm] Requested: e: 68000 m: 8 p: 16
[8.880126] [drm] Setting: e: 68000 m: 8 p: 16
[9.280080] [drm] Requested: e: 3 m: 40500 p: 16
[9.480118] [drm] Setting: e: 3 m: 40500 p: 16
What about the attached version, does it seem ok to you?. It seems to fix
the corruptions for me.
Regards
---
drivers/gpu/drm/radeon/radeon_pm.c | 11 ---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index a8e151e..520197f 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -337,10 +337,15 @@ static void radeon_pm_set_clocks(struct radeon_device
*rdev)
rdev-pm.req_vblank |= (1 1);
drm_vblank_get(rdev-ddev, 1);
}
- if (rdev-pm.active_crtcs)
- wait_event_interruptible_timeout(
+ if (rdev-pm.active_crtcs) {
+ /* We call __wait_* directly because of double condition check
+which we do not use. This call is suppossed to sleep until
+a wake_up happens or a timeout elapses */
+ long timeout = msecs_to_jiffies(RADEON_WAIT_VBLANK_TIMEOUT);
+ __wait_event_interruptible_timeout(
rdev-irq.vblank_queue, 0,
- msecs_to_jiffies(RADEON_WAIT_VBLANK_TIMEOUT));
+ timeout);
+ }
if (rdev-pm.req_vblank (1 0)) {
rdev-pm.req_vblank = ~(1 0);
drm_vblank_put(rdev-ddev, 0);
--
1.6.4.2
From b44da60bce551b7119b0eb2e521e2e7635b9b98e Mon Sep 17 00:00:00 2001
From: Jaime Velasco Juan jsagarri...@gmail.com
Date: Mon, 15 Feb 2010 14:50:46 +
Subject: [PATCH] radeon/PM Really wait for vblank before reclocking
The old code used a false condition so it always waited until
timeout.
Signed-off-by: Jaime Velasco Juan jsagarri...@gmail.com
---
drivers/gpu/drm/radeon/radeon_pm.c | 16
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c b/drivers/gpu/drm/radeon/radeon_pm.c
index a8e151e..7d8c5d9 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -337,10 +337,18 @@ static void radeon_pm_set_clocks(struct radeon_device *rdev)
rdev-pm.req_vblank |= (1 1);
drm_vblank_get(rdev-ddev, 1);
}
- if (rdev-pm.active_crtcs)
- wait_event_interruptible_timeout(
- rdev-irq.vblank_queue, 0,
- msecs_to_jiffies(RADEON_WAIT_VBLANK_TIMEOUT));
+ if (rdev-pm.active_crtcs) {
+ /* We code the wait istead of using the usual
+ wait_event_interruptible_timeout because there is not
+ condition to check, we want to be always waken up by
+ the vblank IRQ handler */
+ DEFINE_WAIT(reclock_wait);
+ prepare_to_wait(rdev-irq.vblank_queue,
+reclock_wait, TASK_INTERRUPTIBLE);
+ if (!signal_pending(current))
+ schedule_timeout(msecs_to_jiffies(RADEON_WAIT_VBLANK_TIMEOUT));
+ finish_wait(rdev-irq.vblank_queue, reclock_wait);
+ }
if (rdev-pm.req_vblank (1 0)) {
rdev-pm.req_vblank = ~(1 0);
drm_vblank_put(rdev-ddev, 0);
--
1.7.0
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms/r7xx: fix spelling in struct
From 177c0de810f39fe1567eb05ee02bfd6492397b9c Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Thu, 18 Feb 2010 13:27:11 -0500
Subject: [PATCH] drm/radeon/kms/r7xx: fix spelling in struct
- fize - size
- also move a bit field define next to the
relevant register
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon.h |2 +-
drivers/gpu/drm/radeon/rv770.c | 10 +-
drivers/gpu/drm/radeon/rv770d.h |2 +-
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 9f35bee..814c332 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -831,7 +831,7 @@ struct rv770_asic {
unsigned sx_num_of_sets;
unsigned sc_prim_fifo_size;
unsigned sc_hiz_tile_fifo_size;
- unsigned sc_earlyz_tile_fifo_fize;
+ unsigned sc_earlyz_tile_fifo_size;
unsigned tiling_nbanks;
unsigned tiling_npipes;
unsigned tiling_group_size;
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 2c10fae..3fce1e7 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -490,7 +490,7 @@ static void rv770_gpu_init(struct radeon_device *rdev)
rdev-config.rv770.sx_num_of_sets = 7;
rdev-config.rv770.sc_prim_fifo_size = 0xF9;
rdev-config.rv770.sc_hiz_tile_fifo_size = 0x30;
- rdev-config.rv770.sc_earlyz_tile_fifo_fize = 0x130;
+ rdev-config.rv770.sc_earlyz_tile_fifo_size = 0x130;
break;
case CHIP_RV730:
rdev-config.rv770.max_pipes = 2;
@@ -510,7 +510,7 @@ static void rv770_gpu_init(struct radeon_device *rdev)
rdev-config.rv770.sx_num_of_sets = 7;
rdev-config.rv770.sc_prim_fifo_size = 0xf9;
rdev-config.rv770.sc_hiz_tile_fifo_size = 0x30;
- rdev-config.rv770.sc_earlyz_tile_fifo_fize = 0x130;
+ rdev-config.rv770.sc_earlyz_tile_fifo_size = 0x130;
if (rdev-config.rv770.sx_max_export_pos_size 16) {
rdev-config.rv770.sx_max_export_pos_size -= 16;
rdev-config.rv770.sx_max_export_smx_size += 16;
@@ -534,7 +534,7 @@ static void rv770_gpu_init(struct radeon_device *rdev)
rdev-config.rv770.sx_num_of_sets = 7;
rdev-config.rv770.sc_prim_fifo_size = 0x40;
rdev-config.rv770.sc_hiz_tile_fifo_size = 0x30;
- rdev-config.rv770.sc_earlyz_tile_fifo_fize = 0x130;
+ rdev-config.rv770.sc_earlyz_tile_fifo_size = 0x130;
break;
case CHIP_RV740:
rdev-config.rv770.max_pipes = 4;
@@ -554,7 +554,7 @@ static void rv770_gpu_init(struct radeon_device *rdev)
rdev-config.rv770.sx_num_of_sets = 7;
rdev-config.rv770.sc_prim_fifo_size = 0x100;
rdev-config.rv770.sc_hiz_tile_fifo_size = 0x30;
- rdev-config.rv770.sc_earlyz_tile_fifo_fize = 0x130;
+ rdev-config.rv770.sc_earlyz_tile_fifo_size = 0x130;
if (rdev-config.rv770.sx_max_export_pos_size 16) {
rdev-config.rv770.sx_max_export_pos_size -= 16;
@@ -712,7 +712,7 @@ static void rv770_gpu_init(struct radeon_device *rdev)
WREG32(PA_SC_FIFO_SIZE,
(SC_PRIM_FIFO_SIZE(rdev-config.rv770.sc_prim_fifo_size) |
SC_HIZ_TILE_FIFO_SIZE(rdev-config.rv770.sc_hiz_tile_fifo_size) |
-
SC_EARLYZ_TILE_FIFO_SIZE(rdev-config.rv770.sc_earlyz_tile_fifo_fize)));
+
SC_EARLYZ_TILE_FIFO_SIZE(rdev-config.rv770.sc_earlyz_tile_fifo_size)));
WREG32(PA_SC_MULTI_CHIP_CNTL, 0);
diff --git a/drivers/gpu/drm/radeon/rv770d.h b/drivers/gpu/drm/radeon/rv770d.h
index 9506f8c..2920887 100644
--- a/drivers/gpu/drm/radeon/rv770d.h
+++ b/drivers/gpu/drm/radeon/rv770d.h
@@ -180,6 +180,7 @@
#definePA_SC_FIFO_SIZE 0x8BCC
#defineSC_PRIM_FIFO_SIZE(x)((x)
0)
#defineSC_HIZ_TILE_FIFO_SIZE(x)((x)
12)
+#defineSC_EARLYZ_TILE_FIFO_SIZE(x) ((x)
20)
#definePA_SC_FORCE_EOV_MAX_CNTS0x8B24
#defineFORCE_EOV_MAX_CLK_CNT(x)((x)0)
#defineFORCE_EOV_MAX_REZ_CNT(x)
((x)16)
@@ -187,7 +188,6 @@
#definePA_SC_LINE_STIPPLE_STATE0x8B10
#define PA_SC_MODE_CNTL0x28A4C
#definePA_SC_MULTI_CHIP_CNTL 0x8B20
-#defineSC_EARLYZ_TILE_FIFO_SIZE(x) ((x)
20)
#defineSCRATCH_REG0
[PATCH] drm/radeon/r7xx: fixes to gfx init
From 8f47a2a76ceb0638cfd3b053e7cb2bf3dc1f8b4a Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Thu, 18 Feb 2010 13:39:36 -0500
Subject: [PATCH] drm/radeon/r7xx: fixes to gfx init
- RV740 requires a special backend map
- updated swizzle modes for backend map setup
- fix programming of a few gfx regs
This fixes occulusion queries and rendering errors on RV740.
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/r600_cp.c | 185 +++--
drivers/gpu/drm/radeon/rv770.c | 189 +++---
2 files changed, 272 insertions(+), 102 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cp.c b/drivers/gpu/drm/radeon/r600_cp.c
index d9712a1..b90d9e6 100644
--- a/drivers/gpu/drm/radeon/r600_cp.c
+++ b/drivers/gpu/drm/radeon/r600_cp.c
@@ -1162,7 +1162,8 @@ static void r600_gfx_init(struct drm_device *dev,
}
-static u32 r700_get_tile_pipe_to_backend_map(u32 num_tile_pipes,
+static u32 r700_get_tile_pipe_to_backend_map(drm_radeon_private_t *dev_priv,
+u32 num_tile_pipes,
u32 num_backends,
u32 backend_disable_mask)
{
@@ -1173,6 +1174,7 @@ static u32 r700_get_tile_pipe_to_backend_map(u32
num_tile_pipes,
u32 swizzle_pipe[R7XX_MAX_PIPES];
u32 cur_backend;
u32 i;
+ bool force_no_swizzle;
if (num_tile_pipes R7XX_MAX_PIPES)
num_tile_pipes = R7XX_MAX_PIPES;
@@ -1202,6 +1204,18 @@ static u32
r700_get_tile_pipe_to_backend_map(u32 num_tile_pipes,
if (enabled_backends_count != num_backends)
num_backends = enabled_backends_count;
+ switch (dev_priv-flags RADEON_FAMILY_MASK) {
+ case CHIP_RV770:
+ case CHIP_RV730:
+ force_no_swizzle = false;
+ break;
+ case CHIP_RV710:
+ case CHIP_RV740:
+ default:
+ force_no_swizzle = true;
+ break;
+ }
+
memset((uint8_t *)swizzle_pipe[0], 0, sizeof(u32) * R7XX_MAX_PIPES);
switch (num_tile_pipes) {
case 1:
@@ -1212,49 +1226,100 @@ static u32
r700_get_tile_pipe_to_backend_map(u32 num_tile_pipes,
swizzle_pipe[1] = 1;
break;
case 3:
- swizzle_pipe[0] = 0;
- swizzle_pipe[1] = 2;
- swizzle_pipe[2] = 1;
+ if (force_no_swizzle) {
+ swizzle_pipe[0] = 0;
+ swizzle_pipe[1] = 1;
+ swizzle_pipe[2] = 2;
+ } else {
+ swizzle_pipe[0] = 0;
+ swizzle_pipe[1] = 2;
+ swizzle_pipe[2] = 1;
+ }
break;
case 4:
- swizzle_pipe[0] = 0;
- swizzle_pipe[1] = 2;
- swizzle_pipe[2] = 3;
- swizzle_pipe[3] = 1;
+ if (force_no_swizzle) {
+ swizzle_pipe[0] = 0;
+ swizzle_pipe[1] = 1;
+ swizzle_pipe[2] = 2;
+ swizzle_pipe[3] = 3;
+ } else {
+ swizzle_pipe[0] = 0;
+ swizzle_pipe[1] = 2;
+ swizzle_pipe[2] = 3;
+ swizzle_pipe[3] = 1;
+ }
break;
case 5:
- swizzle_pipe[0] = 0;
- swizzle_pipe[1] = 2;
- swizzle_pipe[2] = 4;
- swizzle_pipe[3] = 1;
- swizzle_pipe[4] = 3;
+ if (force_no_swizzle) {
+ swizzle_pipe[0] = 0;
+ swizzle_pipe[1] = 1;
+ swizzle_pipe[2] = 2;
+ swizzle_pipe[3] = 3;
+ swizzle_pipe[4] = 4;
+ } else {
+ swizzle_pipe[0] = 0;
+ swizzle_pipe[1] = 2;
+ swizzle_pipe[2] = 4;
+ swizzle_pipe[3] = 1;
+ swizzle_pipe[4] = 3;
+ }
break;
case 6:
- swizzle_pipe[0] = 0;
- swizzle_pipe[1] = 2;
- swizzle_pipe[2] = 4;
- swizzle_pipe[3] = 5;
- swizzle_pipe[4] = 3;
- swizzle_pipe[5] = 1;
+ if (force_no_swizzle) {
+ swizzle_pipe[0] = 0;
+ swizzle_pipe[1] = 1;
+ swizzle_pipe[2] = 2;
+ swizzle_pipe[3] = 3;
+ swizzle_pipe[4] = 4;
+ swizzle_pipe[5] = 5;
+ } else {
+ swizzle_pipe[0] = 0;
+ swizzle_pipe[1] = 2;
+ swizzle_pipe[2] = 4;
+ swizzle_pipe[3] = 5;
+
[Bug 15328] high load avg, extreme sluggishness on T41 w/ Radeon Mobility M7
http://bugzilla.kernel.org/show_bug.cgi?id=15328 --- Comment #9 from Francisco Jerez curroje...@riseup.net 2010-02-18 18:53:42 --- Created an attachment (id=25107) -- (http://bugzilla.kernel.org/attachment.cgi?id=25107) ttm_set_caching_nopat.patch I guess the attached patch fixes it. However it might make sense to fix the PAT code instead because this interface is somewhat annoying. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: implement reading PCIE lanes on R600+
W dniu 18 lutego 2010 16:20 użytkownik Alex Deucher
alexdeuc...@gmail.com napisał:
2010/2/17 Rafał Miłecki zaj...@gmail.com:
Ported from DDX
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/gpu/drm/radeon/r300.c | 5 -
drivers/gpu/drm/radeon/radeon.h | 14 ++
drivers/gpu/drm/radeon/radeon_asic.h | 4 ++--
drivers/gpu/drm/radeon/radeon_pm.c | 2 ++
4 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 654aca1..cd92880 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -593,7 +593,10 @@ int rv370_get_pcie_lanes(struct radeon_device *rdev)
/* FIXME wait for idle */
- link_width_cntl = RREG32_PCIE(RADEON_PCIE_LC_LINK_WIDTH_CNTL);
+ if (rdev-family CHIP_R600)
+ link_width_cntl =
RREG32_PCIE(RADEON_PCIE_LC_LINK_WIDTH_CNTL);
+ else
+ link_width_cntl =
RREG32_PCIE_P(RADEON_PCIE_LC_LINK_WIDTH_CNTL);
switch ((link_width_cntl RADEON_PCIE_LC_LINK_WIDTH_RD_MASK)
RADEON_PCIE_LC_LINK_WIDTH_RD_SHIFT) {
case RADEON_PCIE_LC_LINK_WIDTH_X0:
diff --git a/drivers/gpu/drm/radeon/radeon.h
b/drivers/gpu/drm/radeon/radeon.h
index b533411..db98924 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1009,6 +1009,8 @@ static inline void r100_mm_wreg(struct radeon_device
*rdev, uint32_t reg, uint32
#define WREG32_MC(reg, v) rdev-mc_wreg(rdev, (reg), (v))
#define RREG32_PCIE(reg) rv370_pcie_rreg(rdev, (reg))
#define WREG32_PCIE(reg, v) rv370_pcie_wreg(rdev, (reg), (v))
+#define RREG32_PCIE_P(reg) r600_pcie_port_rreg(rdev, (reg))
+#define WREG32_PCIE_P(reg, v) r600_pcie_port_wreg(rdev, (reg), (v))
#define WREG32_P(reg, val, mask) \
do { \
uint32_t tmp_ = RREG32(reg); \
@@ -1043,6 +1045,18 @@ static inline void rv370_pcie_wreg(struct
radeon_device *rdev, uint32_t reg, uin
WREG32(RADEON_PCIE_DATA, (v));
}
+static inline uint32_t r600_pcie_port_rreg(struct radeon_device *rdev,
uint32_t reg)
+{
+ WREG32(R600_PCIE_PORT_INDEX, ((reg) rdev-pcie_reg_mask));
+ return RREG32(R600_PCIE_PORT_DATA);
+}
+
+static inline void r600_pcie_port_wreg(struct radeon_device *rdev, uint32_t
reg, uint32_t v)
+{
+ WREG32(R600_PCIE_PORT_INDEX, ((reg) rdev-pcie_reg_mask));
+ WREG32(R600_PCIE_PORT_DATA, (v));
+}
+
These already exist in r600.c:
r600_pciep_rreg
r600_pciep_wreg
Oh, didn't notice that because it uses duplicated definition:
./r600d.h:#define PCIE_PORT_INDEX 0x0038
./r600_reg.h:#define R600_PCIE_PORT_INDEX0x0038
--
Rafał
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15328] high load avg, extreme sluggishness on T41 w/ Radeon Mobility M7
http://bugzilla.kernel.org/show_bug.cgi?id=15328 Francisco Jerez curroje...@riseup.net changed: What|Removed |Added CC||curroje...@riseup.net --- Comment #10 from Francisco Jerez curroje...@riseup.net 2010-02-18 19:14:55 --- BTW, sorry for not taking care of this before. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms/rs600: add connector quirk
From a2421e417050d9e448d39d1d65e2c3c9aa787c98 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Thu, 18 Feb 2010 14:14:58 -0500
Subject: [PATCH] drm/radeon/kms/rs600: add connector quirk
rs600 board lists DVI port as HDMI.
Fixes fdo bug 26605
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_atombios.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index b41b4a5..7e65b83 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -213,6 +213,15 @@ static bool radeon_atom_apply_quirks(struct
drm_device *dev,
*connector_type = DRM_MODE_CONNECTOR_DVID;
}
+ /* Asrock RS600 board lists the DVI port as HDMI */
+ if ((dev-pdev-device == 0x7941)
+ (dev-pdev-subsystem_vendor == 0x1849)
+ (dev-pdev-subsystem_device == 0x7941)) {
+ if ((*connector_type == DRM_MODE_CONNECTOR_HDMIA)
+ (supported_device == ATOM_DEVICE_DFP3_SUPPORT))
+ *connector_type = DRM_MODE_CONNECTOR_DVID;
+ }
+
/* a-bit f-i90hd - ciaranm on #radeonhd - this board has no DVI */
if ((dev-pdev-device == 0x7941)
(dev-pdev-subsystem_vendor == 0x147b)
--
1.5.6.3
0001-drm-radeon-kms-rs600-add-connector-quirk.patch
Description: application/mbox
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: simplify storing current and requested PM mode
2010/2/17 Rafał Miłecki zaj...@gmail.com:
We kept requested and current modes in many places, depending on current
state.
That was useless, one place for holding that is enough.
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
Tested on my RV620, no problems. Alex: can you review this patch? It's your
code I modify/remove in it.
NACK. Why are you replacing pointers with copies of of the power
state structs? The idea is to keep one array of power states and
pointers to the current one, default one, and requested one. Then
comparing power states is just comparing pointers and when you change
the power state, you just update the pointer rather then memcpying the
entire struct.
Alex
---
drivers/gpu/drm/radeon/radeon.h | 13 +++---
drivers/gpu/drm/radeon/radeon_atombios.c | 22 +++---
drivers/gpu/drm/radeon/radeon_combios.c | 9 +++-
drivers/gpu/drm/radeon/radeon_pm.c | 66
+-
4 files changed, 56 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 993cdf2..b533411 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -652,9 +652,6 @@ struct radeon_power_state {
struct radeon_pm_clock_info clock_info[8];
/* number of valid clock modes in this power state */
int num_clock_modes;
- /* currently selected clock mode */
- struct radeon_pm_clock_info *current_clock_mode;
- struct radeon_pm_clock_info *requested_clock_mode;
struct radeon_pm_clock_info *default_clock_mode;
/* non clock info about this state */
struct radeon_pm_non_clock_info non_clock_info;
@@ -684,10 +681,12 @@ struct radeon_pm {
/* XXX: use a define for num power modes */
struct radeon_power_state power_state[8];
/* number of valid power states */
- int num_power_states;
- struct radeon_power_state *current_power_state;
- struct radeon_power_state *requested_power_state;
- struct radeon_power_state *default_power_state;
+ int num_power_states;
+ struct radeon_pm_clock_info current_clock_mode;
+ int current_pcie_lanes;
+ struct radeon_pm_clock_info requested_clock_mode;
+ int requested_pcie_lanes;
+ struct radeon_power_state *default_power_state;
};
diff --git a/drivers/gpu/drm/radeon/radeon_atombios.c
b/drivers/gpu/drm/radeon/radeon_atombios.c
index 4f7dbce..b8e7e81 100644
--- a/drivers/gpu/drm/radeon/radeon_atombios.c
+++ b/drivers/gpu/drm/radeon/radeon_atombios.c
@@ -1441,7 +1441,6 @@ void radeon_atombios_get_power_modes(struct
radeon_device *rdev)
power_info = (union power_info *)(mode_info-atom_context-bios +
data_offset);
rdev-pm.default_power_state = NULL;
- rdev-pm.current_power_state = NULL;
if (power_info) {
if (frev 4) {
@@ -1508,11 +1507,8 @@ void radeon_atombios_get_power_modes(struct
radeon_device *rdev)
rdev-pm.power_state[state_index].type =
POWER_STATE_TYPE_DEFAULT;
rdev-pm.default_power_state =
rdev-pm.power_state[state_index];
- rdev-pm.current_power_state
= rdev-pm.power_state[state_index];
rdev-pm.power_state[state_index].default_clock_mode =
rdev-pm.power_state[state_index].clock_info[0];
-
rdev-pm.power_state[state_index].current_clock_mode =
-
rdev-pm.power_state[state_index].clock_info[0];
}
state_index++;
break;
@@ -1577,11 +1573,8 @@ void radeon_atombios_get_power_modes(struct
radeon_device *rdev)
rdev-pm.power_state[state_index].type =
POWER_STATE_TYPE_DEFAULT;
rdev-pm.default_power_state =
rdev-pm.power_state[state_index];
- rdev-pm.current_power_state
= rdev-pm.power_state[state_index];
rdev-pm.power_state[state_index].default_clock_mode =
rdev-pm.power_state[state_index].clock_info[0];
-
rdev-pm.power_state[state_index].current_clock_mode =
-
Re: [PATCH] drm/radeon/kms: simplify storing current and requested PM mode
W dniu 18 lutego 2010 20:29 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2010/2/17 Rafał Miłecki zaj...@gmail.com: We kept requested and current modes in many places, depending on current state. That was useless, one place for holding that is enough. Signed-off-by: Rafał Miłecki zaj...@gmail.com --- Tested on my RV620, no problems. Alex: can you review this patch? It's your code I modify/remove in it. NACK. Why are you replacing pointers with copies of of the power state structs? The idea is to keep one array of power states and pointers to the current one, default one, and requested one. Then comparing power states is just comparing pointers and when you change the power state, you just update the pointer rather then memcpying the entire struct. Then first of all we would need to reduce modes pointers. Keeping mode pointer in every state struct is/was useless. About introduced solution (keeping struct and memcpy to it) I introduced that to make hacking requested mode possible. Info from AtomBIOS about PCIE lanes seem to be useless (I've never seen anything else than 16) so I want to hack found mode for DPMS OFF to use 1 PCIE lane. Without keeping whole struct it would be impossible without overwriting original entry in array and loosing original info. -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: simplify storing current and requested PM mode
W dniu 18 lutego 2010 20:39 użytkownik Rafał Miłecki zaj...@gmail.com napisał: W dniu 18 lutego 2010 20:29 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2010/2/17 Rafał Miłecki zaj...@gmail.com: We kept requested and current modes in many places, depending on current state. That was useless, one place for holding that is enough. Signed-off-by: Rafał Miłecki zaj...@gmail.com --- Tested on my RV620, no problems. Alex: can you review this patch? It's your code I modify/remove in it. NACK. Why are you replacing pointers with copies of of the power state structs? The idea is to keep one array of power states and pointers to the current one, default one, and requested one. Then comparing power states is just comparing pointers and when you change the power state, you just update the pointer rather then memcpying the entire struct. Then first of all we would need to reduce modes pointers. Keeping mode pointer in every state struct is/was useless. About introduced solution (keeping struct and memcpy to it) I introduced that to make hacking requested mode possible. Info from AtomBIOS about PCIE lanes seem to be useless (I've never seen anything else than 16) so I want to hack found mode for DPMS OFF to use 1 PCIE lane. Without keeping whole struct it would be impossible without overwriting original entry in array and loosing original info. We may also consider hacking eng/mem clocks in requested mode for DPMS OFF. Maybe we could use chip's minimum instead lowest entry from AtomBIOS table? -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH V2] drm/radeon/kms: implement reading active PCIE lanes on R600+
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
V2: use already implemented functions for reading/writing PCIE PORT
Thanks Alex for reviewing!
---
drivers/gpu/drm/radeon/r300.c|5 -
drivers/gpu/drm/radeon/radeon.h |2 ++
drivers/gpu/drm/radeon/radeon_asic.h |4 ++--
drivers/gpu/drm/radeon/radeon_pm.c |2 ++
4 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 7e9f956..29ef9d8 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -549,7 +549,10 @@ int rv370_get_pcie_lanes(struct radeon_device *rdev)
/* FIXME wait for idle */
- link_width_cntl = RREG32_PCIE(RADEON_PCIE_LC_LINK_WIDTH_CNTL);
+ if (rdev-family CHIP_R600)
+ link_width_cntl = RREG32_PCIE(RADEON_PCIE_LC_LINK_WIDTH_CNTL);
+ else
+ link_width_cntl = RREG32_PCIE_P(RADEON_PCIE_LC_LINK_WIDTH_CNTL);
switch ((link_width_cntl RADEON_PCIE_LC_LINK_WIDTH_RD_MASK)
RADEON_PCIE_LC_LINK_WIDTH_RD_SHIFT) {
case RADEON_PCIE_LC_LINK_WIDTH_X0:
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index b110994..0ed8668 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1014,6 +1014,8 @@ static inline void r100_mm_wreg(struct radeon_device
*rdev, uint32_t reg, uint32
#define WREG32_MC(reg, v) rdev-mc_wreg(rdev, (reg), (v))
#define RREG32_PCIE(reg) rv370_pcie_rreg(rdev, (reg))
#define WREG32_PCIE(reg, v) rv370_pcie_wreg(rdev, (reg), (v))
+#define RREG32_PCIE_P(reg) rdev-pciep_rreg(rdev, (reg))
+#define WREG32_PCIE_P(reg, v) rdev-pciep_rreg(rdev, (reg), (v))
#define WREG32_P(reg, val, mask) \
do {\
uint32_t tmp_ = RREG32(reg);\
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index b7030d7..4572a66 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -626,7 +626,7 @@ static struct radeon_asic r600_asic = {
.set_engine_clock = radeon_atom_set_engine_clock,
.get_memory_clock = radeon_atom_get_memory_clock,
.set_memory_clock = radeon_atom_set_memory_clock,
- .get_pcie_lanes = NULL,
+ .get_pcie_lanes = rv370_get_pcie_lanes,
.set_pcie_lanes = NULL,
.set_clock_gating = NULL,
.set_surface_reg = r600_set_surface_reg,
@@ -672,7 +672,7 @@ static struct radeon_asic rv770_asic = {
.set_engine_clock = radeon_atom_set_engine_clock,
.get_memory_clock = radeon_atom_get_memory_clock,
.set_memory_clock = radeon_atom_set_memory_clock,
- .get_pcie_lanes = NULL,
+ .get_pcie_lanes = rv370_get_pcie_lanes,
.set_pcie_lanes = NULL,
.set_clock_gating = radeon_atom_set_clock_gating,
.set_surface_reg = r600_set_surface_reg,
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index f46d574..0602844 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -442,6 +442,8 @@ static int radeon_debugfs_pm_info(struct seq_file *m, void
*data)
seq_printf(m, default memory clock: %u0 kHz\n,
rdev-clock.default_mclk);
if (rdev-asic-get_memory_clock)
seq_printf(m, current memory clock: %u0 kHz\n,
radeon_get_memory_clock(rdev));
+ if (rdev-asic-get_pcie_lanes)
+ seq_printf(m, PCIE lanes: %d\n, radeon_get_pcie_lanes(rdev));
return 0;
}
--
1.6.4.2
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26635] New: [drm-radeon-testing] warning message that can't be true
http://bugs.freedesktop.org/show_bug.cgi?id=26635 Summary: [drm-radeon-testing] warning message that can't be true Product: DRI Version: DRI CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: liquid.a...@gmx.net CC: jb@gmx.de Created an attachment (id=33396) -- (http://bugs.freedesktop.org/attachment.cgi?id=33396) dmesg output Hi there, just pulled latest drm-radeon-testing and updated xf86-video-ati, libdrm and mesa to git master. Now I get this in the kernel log: You have old broken userspace please consider updating mesa (full log attached) Well this can't be true, since userspace is brand new... Hardware: 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon HD 4770 [RV740] Greets, Tobias -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26631] R600 AGP KMS + dynpm,dynclks = stalls
http://bugs.freedesktop.org/show_bug.cgi?id=26631 --- Comment #2 from Tobias Jakobi liquid.a...@gmx.net 2010-02-18 12:02:47 PST --- Confirming on my RV740 in quake3. q3 performance is good, but every other second the whole rendering slows down for a bit to then accelerate again - very annoying. Deactivated all PM and it's gone. Anyway, thanks to some change in the latest drm-radeon-testing any other game than q3 runs REALLY slow - even the good old CS 1.5 through wine goes to a crawl with around 4fps, compared to something around 60-80fps with older snapshots of drm-radeon-testing. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26603] radeon_fence_signaled warnings in kernel log
http://bugs.freedesktop.org/show_bug.cgi?id=26603 Ladislav Kunc l.k...@sh.cvut.cz changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Ladislav Kunc l.k...@sh.cvut.cz 2010-02-18 12:14:59 PST --- I've just upgraded. It's fixed for me. Thank you and thanks Jerome for the bugfix. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH V3] drm/radeon/kms: implement reading active PCIE lanes on R600+
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
V2: use already implemented functions for reading/writing PCIE PORT
V3: fix rreg/wreg typo in macro
Thanks Alex for reviewing!
---
drivers/gpu/drm/radeon/r300.c|5 -
drivers/gpu/drm/radeon/radeon.h |2 ++
drivers/gpu/drm/radeon/radeon_asic.h |4 ++--
drivers/gpu/drm/radeon/radeon_pm.c |2 ++
4 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 7e9f956..29ef9d8 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -549,7 +549,10 @@ int rv370_get_pcie_lanes(struct radeon_device *rdev)
/* FIXME wait for idle */
- link_width_cntl = RREG32_PCIE(RADEON_PCIE_LC_LINK_WIDTH_CNTL);
+ if (rdev-family CHIP_R600)
+ link_width_cntl = RREG32_PCIE(RADEON_PCIE_LC_LINK_WIDTH_CNTL);
+ else
+ link_width_cntl = RREG32_PCIE_P(RADEON_PCIE_LC_LINK_WIDTH_CNTL);
switch ((link_width_cntl RADEON_PCIE_LC_LINK_WIDTH_RD_MASK)
RADEON_PCIE_LC_LINK_WIDTH_RD_SHIFT) {
case RADEON_PCIE_LC_LINK_WIDTH_X0:
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index b110994..ef55955 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1014,6 +1014,8 @@ static inline void r100_mm_wreg(struct radeon_device
*rdev, uint32_t reg, uint32
#define WREG32_MC(reg, v) rdev-mc_wreg(rdev, (reg), (v))
#define RREG32_PCIE(reg) rv370_pcie_rreg(rdev, (reg))
#define WREG32_PCIE(reg, v) rv370_pcie_wreg(rdev, (reg), (v))
+#define RREG32_PCIE_P(reg) rdev-pciep_rreg(rdev, (reg))
+#define WREG32_PCIE_P(reg, v) rdev-pciep_wreg(rdev, (reg), (v))
#define WREG32_P(reg, val, mask) \
do {\
uint32_t tmp_ = RREG32(reg);\
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index b7030d7..4572a66 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -626,7 +626,7 @@ static struct radeon_asic r600_asic = {
.set_engine_clock = radeon_atom_set_engine_clock,
.get_memory_clock = radeon_atom_get_memory_clock,
.set_memory_clock = radeon_atom_set_memory_clock,
- .get_pcie_lanes = NULL,
+ .get_pcie_lanes = rv370_get_pcie_lanes,
.set_pcie_lanes = NULL,
.set_clock_gating = NULL,
.set_surface_reg = r600_set_surface_reg,
@@ -672,7 +672,7 @@ static struct radeon_asic rv770_asic = {
.set_engine_clock = radeon_atom_set_engine_clock,
.get_memory_clock = radeon_atom_get_memory_clock,
.set_memory_clock = radeon_atom_set_memory_clock,
- .get_pcie_lanes = NULL,
+ .get_pcie_lanes = rv370_get_pcie_lanes,
.set_pcie_lanes = NULL,
.set_clock_gating = radeon_atom_set_clock_gating,
.set_surface_reg = r600_set_surface_reg,
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index f46d574..0602844 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -442,6 +442,8 @@ static int radeon_debugfs_pm_info(struct seq_file *m, void
*data)
seq_printf(m, default memory clock: %u0 kHz\n,
rdev-clock.default_mclk);
if (rdev-asic-get_memory_clock)
seq_printf(m, current memory clock: %u0 kHz\n,
radeon_get_memory_clock(rdev));
+ if (rdev-asic-get_pcie_lanes)
+ seq_printf(m, PCIE lanes: %d\n, radeon_get_pcie_lanes(rdev));
return 0;
}
--
1.6.4.2
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: simplify storing current and requested PM mode
2010/2/18 Rafał Miłecki zaj...@gmail.com: W dniu 18 lutego 2010 20:29 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2010/2/17 Rafał Miłecki zaj...@gmail.com: We kept requested and current modes in many places, depending on current state. That was useless, one place for holding that is enough. Signed-off-by: Rafał Miłecki zaj...@gmail.com --- Tested on my RV620, no problems. Alex: can you review this patch? It's your code I modify/remove in it. NACK. Why are you replacing pointers with copies of of the power state structs? The idea is to keep one array of power states and pointers to the current one, default one, and requested one. Then comparing power states is just comparing pointers and when you change the power state, you just update the pointer rather then memcpying the entire struct. Then first of all we would need to reduce modes pointers. Keeping mode pointer in every state struct is/was useless. What do you mean? There is not a pointer to every state. There are only 3 (1. current, 2. requested 3. default) and they are not useless. You have power states which defines the global state of a particular power state and then each power state has a set of 1 or more clock modes. So within a power state you can switch between clock modes. You need a set of clock pointers to track the current clock mode and the requested clock mode. You also need to know the current and requested power state so you need pointers there as well. We could get rid of the default pointers, but that's mostly there for convenience to avoid having to look up the default state when we need it. For example, say you had the following power tables: 1. 3d power state: a. low clock mode b. medium clock mode c. high clock mode 2. battery power state a. low clock mode b. medium clock mode c. high clock mode 3. default power state a. low clock mode b. medium clock mode c. high clock mode By default state 3 would be selected so the current state would be '3' and the current clock mode would be a say 'a'. The current state pointer would point to '3' and the current clock mode pointer would point to 'a'. If you then went on battery, you'd want power state '2'. At that point, the requested state pointer points to '2' and one of the clock modes gets selected, lets say 'c', so the requested clock mode pointer points to 'c'. When we change the power state, we compare the current and requested power state pointers, if they are the same, no need to change anything. if they are different, we make the changes, then set the current power state pointer to the requested power state pointer and the current clock mode pointer to the requested clock mode pointer. Now say we are in power state '2' and clock mode 'c' (the high clock for power state '2') and the system goes idle; at the point we will want to stay in power state '2', but select clock mode 'a' (the low clock for power state '2'). So we compare the current and requested clock mode pointers and if they are not equal, we change the clock mode, at which time we update the current clock mode pointers to point to the requested clock. About introduced solution (keeping struct and memcpy to it) I introduced that to make hacking requested mode possible. Info from AtomBIOS about PCIE lanes seem to be useless (I've never seen anything else than 16) so I want to hack found mode for DPMS OFF to use 1 PCIE lane. Without keeping whole struct it would be impossible without overwriting original entry in array and loosing original info. That's fine for a local hack, but we don't want that upstream. If you are planning to hack all the power tables, then why even use them? I'm not sure we really change the lanes that often if at all on r6xx+. In my experience, a lot of cards lock up when change the lanes or fail to change properly which results in getting stuck at lower numbers of lanes. Alex -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: simplify storing current and requested PM mode
2010/2/18 Rafał Miłecki zaj...@gmail.com: W dniu 18 lutego 2010 20:39 użytkownik Rafał Miłecki zaj...@gmail.com napisał: W dniu 18 lutego 2010 20:29 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2010/2/17 Rafał Miłecki zaj...@gmail.com: We kept requested and current modes in many places, depending on current state. That was useless, one place for holding that is enough. Signed-off-by: Rafał Miłecki zaj...@gmail.com --- Tested on my RV620, no problems. Alex: can you review this patch? It's your code I modify/remove in it. NACK. Why are you replacing pointers with copies of of the power state structs? The idea is to keep one array of power states and pointers to the current one, default one, and requested one. Then comparing power states is just comparing pointers and when you change the power state, you just update the pointer rather then memcpying the entire struct. Then first of all we would need to reduce modes pointers. Keeping mode pointer in every state struct is/was useless. About introduced solution (keeping struct and memcpy to it) I introduced that to make hacking requested mode possible. Info from AtomBIOS about PCIE lanes seem to be useless (I've never seen anything else than 16) so I want to hack found mode for DPMS OFF to use 1 PCIE lane. Without keeping whole struct it would be impossible without overwriting original entry in array and loosing original info. We may also consider hacking eng/mem clocks in requested mode for DPMS OFF. Maybe we could use chip's minimum instead lowest entry from AtomBIOS table? You could try, but for stability sake, we should try and stick to the tables; that's why there are there. Certain clock combinations just don't work well. Alex -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: implement setting active PCIE lanes on R600+
Ported from DDX
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/gpu/drm/radeon/r600.c| 76 ++
drivers/gpu/drm/radeon/radeon_asic.h |5 +-
drivers/gpu/drm/radeon/radeon_reg.h |5 ++
3 files changed, 84 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 694a4c5..e06eaba 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -2863,6 +2863,82 @@ restart_ih:
return IRQ_HANDLED;
}
+void r600_set_pcie_lanes(struct radeon_device *rdev, int lanes)
+{
+ uint32_t link_width_cntl, mask, target_reg;
+
+ if (rdev-flags RADEON_IS_IGP)
+ return;
+
+ if (!(rdev-flags RADEON_IS_PCIE))
+ return;
+
+ /* FIXME check for multi GPU */
+
+ /* FIXME wait for idle */
+
+ switch (lanes) {
+ case 0:
+ mask = RADEON_PCIE_LC_LINK_WIDTH_X0;
+ break;
+ case 1:
+ mask = RADEON_PCIE_LC_LINK_WIDTH_X1;
+ break;
+ case 2:
+ mask = RADEON_PCIE_LC_LINK_WIDTH_X2;
+ break;
+ case 4:
+ mask = RADEON_PCIE_LC_LINK_WIDTH_X4;
+ break;
+ case 8:
+ mask = RADEON_PCIE_LC_LINK_WIDTH_X8;
+ break;
+ case 12:
+ mask = RADEON_PCIE_LC_LINK_WIDTH_X12;
+ break;
+ case 16:
+ default:
+ mask = RADEON_PCIE_LC_LINK_WIDTH_X16;
+ break;
+ }
+
+ link_width_cntl = RREG32_PCIE_P(RADEON_PCIE_LC_LINK_WIDTH_CNTL);
+
+ if ((link_width_cntl RADEON_PCIE_LC_LINK_WIDTH_RD_MASK) ==
+ (mask RADEON_PCIE_LC_LINK_WIDTH_RD_SHIFT))
+ return;
+
+ link_width_cntl = ~(RADEON_PCIE_LC_LINK_WIDTH_MASK |
+RADEON_PCIE_LC_RECONFIG_NOW |
+R600_PCIE_LC_RECONFIG_ARC_MISSING_ESCAPE |
+R600_PCIE_LC_SHORT_RECONFIG_EN |
+R600_PCIE_LC_RENEGOTIATE_EN);
+ link_width_cntl |= mask;
+#if 0
+ /* some northbridges can renegotiate the link rather than requiring
+* a complete re-config.
+* e.g., AMD 780/790 northbridges (pci ids: 0x5956, 0x5957, 0x5958,
etc.)
+*/
+ if (northbridge can renegotiate)
+ link_width_cntl |= R600_PCIE_LC_RENEGOTIATE_EN;
+ else
+#endif
+ link_width_cntl |= R600_PCIE_LC_RECONFIG_ARC_MISSING_ESCAPE;
+
+ WREG32_PCIE_P(RADEON_PCIE_LC_LINK_WIDTH_CNTL, link_width_cntl);
+ WREG32_PCIE_P(RADEON_PCIE_LC_LINK_WIDTH_CNTL,
+ (link_width_cntl | RADEON_PCIE_LC_RECONFIG_NOW));
+
+ /* wait for lane set to complete */
+ if (rdev-family = CHIP_RV770)
+ target_reg = R700_TARGET_AND_CURRENT_PROFILE_INDEX;
+ else
+ target_reg = R600_TARGET_AND_CURRENT_PROFILE_INDEX;
+ link_width_cntl = RREG32(target_reg);
+ while (link_width_cntl == 0x)
+ link_width_cntl = RREG32(target_reg);
+}
+
/*
* Debugfs info
*/
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index 4572a66..d70b80b 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -601,6 +601,7 @@ bool r600_hpd_sense(struct radeon_device *rdev, enum
radeon_hpd_id hpd);
void r600_hpd_set_polarity(struct radeon_device *rdev,
enum radeon_hpd_id hpd);
extern void r600_ioctl_wait_idle(struct radeon_device *rdev, struct radeon_bo
*bo);
+void r600_set_pcie_lanes(struct radeon_device *rdev, int lanes);
static struct radeon_asic r600_asic = {
.init = r600_init,
@@ -627,7 +628,7 @@ static struct radeon_asic r600_asic = {
.get_memory_clock = radeon_atom_get_memory_clock,
.set_memory_clock = radeon_atom_set_memory_clock,
.get_pcie_lanes = rv370_get_pcie_lanes,
- .set_pcie_lanes = NULL,
+ .set_pcie_lanes = r600_set_pcie_lanes,
.set_clock_gating = NULL,
.set_surface_reg = r600_set_surface_reg,
.clear_surface_reg = r600_clear_surface_reg,
@@ -673,7 +674,7 @@ static struct radeon_asic rv770_asic = {
.get_memory_clock = radeon_atom_get_memory_clock,
.set_memory_clock = radeon_atom_set_memory_clock,
.get_pcie_lanes = rv370_get_pcie_lanes,
- .set_pcie_lanes = NULL,
+ .set_pcie_lanes = r600_set_pcie_lanes,
.set_clock_gating = radeon_atom_set_clock_gating,
.set_surface_reg = r600_set_surface_reg,
.clear_surface_reg = r600_clear_surface_reg,
diff --git a/drivers/gpu/drm/radeon/radeon_reg.h
b/drivers/gpu/drm/radeon/radeon_reg.h
index 5c0dc08..2090aeb 100644
--- a/drivers/gpu/drm/radeon/radeon_reg.h
+++ b/drivers/gpu/drm/radeon/radeon_reg.h
@@ -317,9 +317,14 @@
# define RADEON_PCIE_LC_LINK_WIDTH_X16 6
# define
[Bug 26631] R600 AGP KMS + dynpm,dynclks = stalls
http://bugs.freedesktop.org/show_bug.cgi?id=26631 --- Comment #3 from Rafał Miłecki zaj...@gmail.com 2010-02-18 13:02:11 PST --- Created an attachment (id=33399) -- (http://bugs.freedesktop.org/attachment.cgi?id=33399) drm/radeon/kms/pm: do not take cp mutex Does it help? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH V3] drm/radeon/kms: implement reading active PCIE lanes on R600+
2010/2/18 Rafał Miłecki zaj...@gmail.com:
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
V2: use already implemented functions for reading/writing PCIE PORT
V3: fix rreg/wreg typo in macro
Thanks Alex for reviewing!
---
drivers/gpu/drm/radeon/r300.c | 5 -
drivers/gpu/drm/radeon/radeon.h | 2 ++
drivers/gpu/drm/radeon/radeon_asic.h | 4 ++--
drivers/gpu/drm/radeon/radeon_pm.c | 2 ++
4 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 7e9f956..29ef9d8 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -549,7 +549,10 @@ int rv370_get_pcie_lanes(struct radeon_device *rdev)
/* FIXME wait for idle */
- link_width_cntl = RREG32_PCIE(RADEON_PCIE_LC_LINK_WIDTH_CNTL);
+ if (rdev-family CHIP_R600)
+ link_width_cntl = RREG32_PCIE(RADEON_PCIE_LC_LINK_WIDTH_CNTL);
+ else
+ link_width_cntl =
RREG32_PCIE_P(RADEON_PCIE_LC_LINK_WIDTH_CNTL);
Since you also have a patch to implement setting the number of lanes,
it would be better to create a new r600 version of get_pcie_lanes()
since we may need other r6xx+ specific stuff in it.
Alex
switch ((link_width_cntl RADEON_PCIE_LC_LINK_WIDTH_RD_MASK)
RADEON_PCIE_LC_LINK_WIDTH_RD_SHIFT) {
case RADEON_PCIE_LC_LINK_WIDTH_X0:
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index b110994..ef55955 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -1014,6 +1014,8 @@ static inline void r100_mm_wreg(struct radeon_device
*rdev, uint32_t reg, uint32
#define WREG32_MC(reg, v) rdev-mc_wreg(rdev, (reg), (v))
#define RREG32_PCIE(reg) rv370_pcie_rreg(rdev, (reg))
#define WREG32_PCIE(reg, v) rv370_pcie_wreg(rdev, (reg), (v))
+#define RREG32_PCIE_P(reg) rdev-pciep_rreg(rdev, (reg))
+#define WREG32_PCIE_P(reg, v) rdev-pciep_wreg(rdev, (reg), (v))
#define WREG32_P(reg, val, mask) \
do { \
uint32_t tmp_ = RREG32(reg); \
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index b7030d7..4572a66 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -626,7 +626,7 @@ static struct radeon_asic r600_asic = {
.set_engine_clock = radeon_atom_set_engine_clock,
.get_memory_clock = radeon_atom_get_memory_clock,
.set_memory_clock = radeon_atom_set_memory_clock,
- .get_pcie_lanes = NULL,
+ .get_pcie_lanes = rv370_get_pcie_lanes,
.set_pcie_lanes = NULL,
.set_clock_gating = NULL,
.set_surface_reg = r600_set_surface_reg,
@@ -672,7 +672,7 @@ static struct radeon_asic rv770_asic = {
.set_engine_clock = radeon_atom_set_engine_clock,
.get_memory_clock = radeon_atom_get_memory_clock,
.set_memory_clock = radeon_atom_set_memory_clock,
- .get_pcie_lanes = NULL,
+ .get_pcie_lanes = rv370_get_pcie_lanes,
.set_pcie_lanes = NULL,
.set_clock_gating = radeon_atom_set_clock_gating,
.set_surface_reg = r600_set_surface_reg,
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index f46d574..0602844 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -442,6 +442,8 @@ static int radeon_debugfs_pm_info(struct seq_file *m,
void *data)
seq_printf(m, default memory clock: %u0 kHz\n,
rdev-clock.default_mclk);
if (rdev-asic-get_memory_clock)
seq_printf(m, current memory clock: %u0 kHz\n,
radeon_get_memory_clock(rdev));
+ if (rdev-asic-get_pcie_lanes)
+ seq_printf(m, PCIE lanes: %d\n,
radeon_get_pcie_lanes(rdev));
return 0;
}
--
1.6.4.2
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
Re: [PATCH V3] drm/radeon/kms: implement reading active PCIE lanes on R600+
W dniu 18 lutego 2010 22:04 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2010/2/18 Rafał Miłecki zaj...@gmail.com: Signed-off-by: Rafał Miłecki zaj...@gmail.com --- V2: use already implemented functions for reading/writing PCIE PORT V3: fix rreg/wreg typo in macro Thanks Alex for reviewing! --- drivers/gpu/drm/radeon/r300.c | 5 - drivers/gpu/drm/radeon/radeon.h | 2 ++ drivers/gpu/drm/radeon/radeon_asic.h | 4 ++-- drivers/gpu/drm/radeon/radeon_pm.c | 2 ++ 4 files changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c index 7e9f956..29ef9d8 100644 --- a/drivers/gpu/drm/radeon/r300.c +++ b/drivers/gpu/drm/radeon/r300.c @@ -549,7 +549,10 @@ int rv370_get_pcie_lanes(struct radeon_device *rdev) /* FIXME wait for idle */ - link_width_cntl = RREG32_PCIE(RADEON_PCIE_LC_LINK_WIDTH_CNTL); + if (rdev-family CHIP_R600) + link_width_cntl = RREG32_PCIE(RADEON_PCIE_LC_LINK_WIDTH_CNTL); + else + link_width_cntl = RREG32_PCIE_P(RADEON_PCIE_LC_LINK_WIDTH_CNTL); Since you also have a patch to implement setting the number of lanes, it would be better to create a new r600 version of get_pcie_lanes() since we may need other r6xx+ specific stuff in it. If we get to point where r6xx+ code will differ more, I'm ready to implement that. But if that's matter of just one condition, is that worth splitting it into two functions? -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26639] New: [radeon KMS] switching to res 1024x768 kills output
http://bugs.freedesktop.org/show_bug.cgi?id=26639 Summary: [radeon KMS] switching to res 1024x768 kills output Product: DRI Version: DRI CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: liquid.a...@gmx.net Created an attachment (id=33401) -- (http://bugs.freedesktop.org/attachment.cgi?id=33401) dmesg output Hi there, switching to resolution 1024x768 doesn't work on my hardware (RV740 + IBM P260 CRT), the CRT simply fails to receive a signal and shuts down. xrandr output: Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 8192 x 8192 DVI-0 disconnected (normal left inverted right x axis y axis) DIN disconnected (normal left inverted right x axis y axis) DVI-1 connected 1280x1024+0+0 (normal left inverted right x axis y axis) 388mm x 291mm 1280x1024 85.0*+ 75.0 1600x1200 85.0 1024x768 85.0 75.1 70.1 60.0 960x52975.0 800x60085.1 72.2 75.0 60.3 56.2 640x48085.0 72.8 75.0 60.0 720x40087.8 70.1 1280x1024 is the standard mode and I just tried it: Every other mode works completly fine - just the 1024x768 mode results in no signal. No interesting output in dmesg when switching via xrandr. Kernel is uptodate drm-linux branch of airlied's tree. But this also happens with drm-radeon-testing. Not sure if it's a KMS problem, but at least it happens with KMS enabled. I can try a testrun with modeset disabled, if that helps. Greets, Tobias -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26639] [radeon KMS] switching to res 1024x768 kills output
http://bugs.freedesktop.org/show_bug.cgi?id=26639 Tobias Jakobi liquid.a...@gmx.net changed: What|Removed |Added OS/Version|All |Linux (All) Platform|Other |x86-64 (AMD64) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26639] [radeon KMS] switching to res 1024x768 kills output
http://bugs.freedesktop.org/show_bug.cgi?id=26639 --- Comment #1 from Tobias Jakobi liquid.a...@gmx.net 2010-02-18 13:13:45 PST --- Created an attachment (id=33402) -- (http://bugs.freedesktop.org/attachment.cgi?id=33402) xorg logfile -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26639] [radeon KMS] switching to res 1024x768 kills output
http://bugs.freedesktop.org/show_bug.cgi?id=26639 --- Comment #2 from Tobias Jakobi liquid.a...@gmx.net 2010-02-18 13:24:00 PST --- Created an attachment (id=33403) -- (http://bugs.freedesktop.org/attachment.cgi?id=33403) EDID extracted from P260 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: simplify storing current and requested PM mode
W dniu 18 lutego 2010 21:48 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2010/2/18 Rafał Miłecki zaj...@gmail.com: We may also consider hacking eng/mem clocks in requested mode for DPMS OFF. Maybe we could use chip's minimum instead lowest entry from AtomBIOS table? You could try, but for stability sake, we should try and stick to the tables; that's why there are there. Certain clock combinations just don't work well. That's why I said consider. This would need serious testing. -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: simplify storing current and requested PM mode
W dniu 18 lutego 2010 21:47 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2010/2/18 Rafał Miłecki zaj...@gmail.com: W dniu 18 lutego 2010 20:29 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2010/2/17 Rafał Miłecki zaj...@gmail.com: We kept requested and current modes in many places, depending on current state. That was useless, one place for holding that is enough. Signed-off-by: Rafał Miłecki zaj...@gmail.com --- Tested on my RV620, no problems. Alex: can you review this patch? It's your code I modify/remove in it. NACK. Why are you replacing pointers with copies of of the power state structs? The idea is to keep one array of power states and pointers to the current one, default one, and requested one. Then comparing power states is just comparing pointers and when you change the power state, you just update the pointer rather then memcpying the entire struct. Then first of all we would need to reduce modes pointers. Keeping mode pointer in every state struct is/was useless. What do you mean? There is not a pointer to every state. There are only 3 (1. current, 2. requested 3. default) and they are not useless. You have power states which defines the global state of a particular power state and then each power state has a set of 1 or more clock modes. So within a power state you can switch between clock modes. You need a set of clock pointers to track the current clock mode and the requested clock mode. You also need to know the current and requested power state so you need pointers there as well. We could get rid of the default pointers, but that's mostly there for convenience to avoid having to look up the default state when we need it. For example, say you had the following power tables: 1. 3d power state: a. low clock mode b. medium clock mode c. high clock mode 2. battery power state a. low clock mode b. medium clock mode c. high clock mode 3. default power state a. low clock mode b. medium clock mode c. high clock mode By default state 3 would be selected so the current state would be '3' and the current clock mode would be a say 'a'. The current state pointer would point to '3' and the current clock mode pointer would point to 'a'. If you then went on battery, you'd want power state '2'. At that point, the requested state pointer points to '2' and one of the clock modes gets selected, lets say 'c', so the requested clock mode pointer points to 'c'. When we change the power state, we compare the current and requested power state pointers, if they are the same, no need to change anything. if they are different, we make the changes, then set the current power state pointer to the requested power state pointer and the current clock mode pointer to the requested clock mode pointer. Now say we are in power state '2' and clock mode 'c' (the high clock for power state '2') and the system goes idle; at the point we will want to stay in power state '2', but select clock mode 'a' (the low clock for power state '2'). So we compare the current and requested clock mode pointers and if they are not equal, we change the clock mode, at which time we update the current clock mode pointers to point to the requested clock. Really, you didn't need to explain all of that. I understand current idea and implementation :) The thing is that in your implementation we have 8 (eight!) pointers to current clock mode and 8 pointers to requested clock mode. This part is useless IMO. Let me prepare another patch to show reduction without introducing stuct memcpy. About introduced solution (keeping struct and memcpy to it) I introduced that to make hacking requested mode possible. Info from AtomBIOS about PCIE lanes seem to be useless (I've never seen anything else than 16) so I want to hack found mode for DPMS OFF to use 1 PCIE lane. Without keeping whole struct it would be impossible without overwriting original entry in array and loosing original info. That's fine for a local hack, but we don't want that upstream. If you are planning to hack all the power tables, then why even use them? I'm not sure we really change the lanes that often if at all on r6xx+. In my experience, a lot of cards lock up when change the lanes or fail to change properly which results in getting stuck at lower numbers of lanes. I don't want to hack all power tables, just consider hacking clocks/etc for minimal (dpms off). Don't want to touch other. -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net
[Bug 26631] R600 AGP KMS + dynpm,dynclks = stalls
http://bugs.freedesktop.org/show_bug.cgi?id=26631 --- Comment #4 from Tobias Jakobi liquid.a...@gmx.net 2010-02-18 13:43:17 PST --- This patch helps, but the stalls don't disappear completly. You can try this yourself, I think ioquake3 + demodata or openarena should work for this. It's like the gamespeed changes inbetween - very subtle but extremely annoying. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: simplify storing current and requested PM mode
W dniu 18 lutego 2010 22:36 użytkownik Rafał Miłecki zaj...@gmail.com napisał: W dniu 18 lutego 2010 21:47 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2010/2/18 Rafał Miłecki zaj...@gmail.com: W dniu 18 lutego 2010 20:29 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2010/2/17 Rafał Miłecki zaj...@gmail.com: We kept requested and current modes in many places, depending on current state. That was useless, one place for holding that is enough. Signed-off-by: Rafał Miłecki zaj...@gmail.com --- Tested on my RV620, no problems. Alex: can you review this patch? It's your code I modify/remove in it. NACK. Why are you replacing pointers with copies of of the power state structs? The idea is to keep one array of power states and pointers to the current one, default one, and requested one. Then comparing power states is just comparing pointers and when you change the power state, you just update the pointer rather then memcpying the entire struct. Then first of all we would need to reduce modes pointers. Keeping mode pointer in every state struct is/was useless. What do you mean? There is not a pointer to every state. There are only 3 (1. current, 2. requested 3. default) and they are not useless. You have power states which defines the global state of a particular power state and then each power state has a set of 1 or more clock modes. So within a power state you can switch between clock modes. You need a set of clock pointers to track the current clock mode and the requested clock mode. You also need to know the current and requested power state so you need pointers there as well. We could get rid of the default pointers, but that's mostly there for convenience to avoid having to look up the default state when we need it. For example, say you had the following power tables: 1. 3d power state: a. low clock mode b. medium clock mode c. high clock mode 2. battery power state a. low clock mode b. medium clock mode c. high clock mode 3. default power state a. low clock mode b. medium clock mode c. high clock mode By default state 3 would be selected so the current state would be '3' and the current clock mode would be a say 'a'. The current state pointer would point to '3' and the current clock mode pointer would point to 'a'. If you then went on battery, you'd want power state '2'. At that point, the requested state pointer points to '2' and one of the clock modes gets selected, lets say 'c', so the requested clock mode pointer points to 'c'. When we change the power state, we compare the current and requested power state pointers, if they are the same, no need to change anything. if they are different, we make the changes, then set the current power state pointer to the requested power state pointer and the current clock mode pointer to the requested clock mode pointer. Now say we are in power state '2' and clock mode 'c' (the high clock for power state '2') and the system goes idle; at the point we will want to stay in power state '2', but select clock mode 'a' (the low clock for power state '2'). So we compare the current and requested clock mode pointers and if they are not equal, we change the clock mode, at which time we update the current clock mode pointers to point to the requested clock. Really, you didn't need to explain all of that. I understand current idea and implementation :) The thing is that in your implementation we have 8 (eight!) pointers to current clock mode and 8 pointers to requested clock mode. This part is useless IMO. Let me prepare another patch to show reduction without introducing stuct memcpy. Not tested! -- Rafał fast.idea.show.patch Description: Binary data -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH V3] drm/radeon/kms: implement reading active PCIE lanes on R600+
2010/2/18 Rafał Miłecki zaj...@gmail.com: W dniu 18 lutego 2010 22:04 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2010/2/18 Rafał Miłecki zaj...@gmail.com: Signed-off-by: Rafał Miłecki zaj...@gmail.com --- V2: use already implemented functions for reading/writing PCIE PORT V3: fix rreg/wreg typo in macro Thanks Alex for reviewing! --- drivers/gpu/drm/radeon/r300.c | 5 - drivers/gpu/drm/radeon/radeon.h | 2 ++ drivers/gpu/drm/radeon/radeon_asic.h | 4 ++-- drivers/gpu/drm/radeon/radeon_pm.c | 2 ++ 4 files changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c index 7e9f956..29ef9d8 100644 --- a/drivers/gpu/drm/radeon/r300.c +++ b/drivers/gpu/drm/radeon/r300.c @@ -549,7 +549,10 @@ int rv370_get_pcie_lanes(struct radeon_device *rdev) /* FIXME wait for idle */ - link_width_cntl = RREG32_PCIE(RADEON_PCIE_LC_LINK_WIDTH_CNTL); + if (rdev-family CHIP_R600) + link_width_cntl = RREG32_PCIE(RADEON_PCIE_LC_LINK_WIDTH_CNTL); + else + link_width_cntl = RREG32_PCIE_P(RADEON_PCIE_LC_LINK_WIDTH_CNTL); Since you also have a patch to implement setting the number of lanes, it would be better to create a new r600 version of get_pcie_lanes() since we may need other r6xx+ specific stuff in it. If we get to point where r6xx+ code will differ more, I'm ready to implement that. But if that's matter of just one condition, is that worth splitting it into two functions? I guess it's ok for now. I just don't want to get make it too confusing later on. BTW, does it actually work? I found that generally it always reads back 0 regardless of how many lanes are enabled. Alex -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/r7xx: fixes to gfx init
On Thu, Feb 18, 2010 at 1:45 PM, Alex Deucher alexdeuc...@gmail.com wrote:
From 8f47a2a76ceb0638cfd3b053e7cb2bf3dc1f8b4a Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Thu, 18 Feb 2010 13:39:36 -0500
Subject: [PATCH] drm/radeon/r7xx: fixes to gfx init
- RV740 requires a special backend map
- updated swizzle modes for backend map setup
- fix programming of a few gfx regs
This fixes occulusion queries and rendering errors on RV740.
Hold on on this patch for now. I'm discussing a better fix internally.
Alex
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/r600_cp.c | 185 +++--
drivers/gpu/drm/radeon/rv770.c | 189
+++---
2 files changed, 272 insertions(+), 102 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cp.c
b/drivers/gpu/drm/radeon/r600_cp.c
index d9712a1..b90d9e6 100644
--- a/drivers/gpu/drm/radeon/r600_cp.c
+++ b/drivers/gpu/drm/radeon/r600_cp.c
@@ -1162,7 +1162,8 @@ static void r600_gfx_init(struct drm_device *dev,
}
-static u32 r700_get_tile_pipe_to_backend_map(u32 num_tile_pipes,
+static u32 r700_get_tile_pipe_to_backend_map(drm_radeon_private_t *dev_priv,
+ u32 num_tile_pipes,
u32 num_backends,
u32 backend_disable_mask)
{
@@ -1173,6 +1174,7 @@ static u32 r700_get_tile_pipe_to_backend_map(u32
num_tile_pipes,
u32 swizzle_pipe[R7XX_MAX_PIPES];
u32 cur_backend;
u32 i;
+ bool force_no_swizzle;
if (num_tile_pipes R7XX_MAX_PIPES)
num_tile_pipes = R7XX_MAX_PIPES;
@@ -1202,6 +1204,18 @@ static u32
r700_get_tile_pipe_to_backend_map(u32 num_tile_pipes,
if (enabled_backends_count != num_backends)
num_backends = enabled_backends_count;
+ switch (dev_priv-flags RADEON_FAMILY_MASK) {
+ case CHIP_RV770:
+ case CHIP_RV730:
+ force_no_swizzle = false;
+ break;
+ case CHIP_RV710:
+ case CHIP_RV740:
+ default:
+ force_no_swizzle = true;
+ break;
+ }
+
memset((uint8_t *)swizzle_pipe[0], 0, sizeof(u32) * R7XX_MAX_PIPES);
switch (num_tile_pipes) {
case 1:
@@ -1212,49 +1226,100 @@ static u32
r700_get_tile_pipe_to_backend_map(u32 num_tile_pipes,
swizzle_pipe[1] = 1;
break;
case 3:
- swizzle_pipe[0] = 0;
- swizzle_pipe[1] = 2;
- swizzle_pipe[2] = 1;
+ if (force_no_swizzle) {
+ swizzle_pipe[0] = 0;
+ swizzle_pipe[1] = 1;
+ swizzle_pipe[2] = 2;
+ } else {
+ swizzle_pipe[0] = 0;
+ swizzle_pipe[1] = 2;
+ swizzle_pipe[2] = 1;
+ }
break;
case 4:
- swizzle_pipe[0] = 0;
- swizzle_pipe[1] = 2;
- swizzle_pipe[2] = 3;
- swizzle_pipe[3] = 1;
+ if (force_no_swizzle) {
+ swizzle_pipe[0] = 0;
+ swizzle_pipe[1] = 1;
+ swizzle_pipe[2] = 2;
+ swizzle_pipe[3] = 3;
+ } else {
+ swizzle_pipe[0] = 0;
+ swizzle_pipe[1] = 2;
+ swizzle_pipe[2] = 3;
+ swizzle_pipe[3] = 1;
+ }
break;
case 5:
- swizzle_pipe[0] = 0;
- swizzle_pipe[1] = 2;
- swizzle_pipe[2] = 4;
- swizzle_pipe[3] = 1;
- swizzle_pipe[4] = 3;
+ if (force_no_swizzle) {
+ swizzle_pipe[0] = 0;
+ swizzle_pipe[1] = 1;
+ swizzle_pipe[2] = 2;
+ swizzle_pipe[3] = 3;
+ swizzle_pipe[4] = 4;
+ } else {
+ swizzle_pipe[0] = 0;
+ swizzle_pipe[1] = 2;
+ swizzle_pipe[2] = 4;
+ swizzle_pipe[3] = 1;
+ swizzle_pipe[4] = 3;
+ }
break;
case 6:
- swizzle_pipe[0] = 0;
- swizzle_pipe[1] = 2;
- swizzle_pipe[2] = 4;
- swizzle_pipe[3] = 5;
- swizzle_pipe[4] = 3;
- swizzle_pipe[5] = 1;
+ if (force_no_swizzle) {
+ swizzle_pipe[0] = 0;
+ swizzle_pipe[1] = 1;
+ swizzle_pipe[2] = 2;
+ swizzle_pipe[3] = 3;
+ swizzle_pipe[4] = 4;
Re: [PATCH V3] drm/radeon/kms: implement reading active PCIE lanes on R600+
W dniu 18 lutego 2010 23:36 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2010/2/18 Rafał Miłecki zaj...@gmail.com: W dniu 18 lutego 2010 22:04 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2010/2/18 Rafał Miłecki zaj...@gmail.com: Signed-off-by: Rafał Miłecki zaj...@gmail.com --- V2: use already implemented functions for reading/writing PCIE PORT V3: fix rreg/wreg typo in macro Thanks Alex for reviewing! --- drivers/gpu/drm/radeon/r300.c | 5 - drivers/gpu/drm/radeon/radeon.h | 2 ++ drivers/gpu/drm/radeon/radeon_asic.h | 4 ++-- drivers/gpu/drm/radeon/radeon_pm.c | 2 ++ 4 files changed, 10 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c index 7e9f956..29ef9d8 100644 --- a/drivers/gpu/drm/radeon/r300.c +++ b/drivers/gpu/drm/radeon/r300.c @@ -549,7 +549,10 @@ int rv370_get_pcie_lanes(struct radeon_device *rdev) /* FIXME wait for idle */ - link_width_cntl = RREG32_PCIE(RADEON_PCIE_LC_LINK_WIDTH_CNTL); + if (rdev-family CHIP_R600) + link_width_cntl = RREG32_PCIE(RADEON_PCIE_LC_LINK_WIDTH_CNTL); + else + link_width_cntl = RREG32_PCIE_P(RADEON_PCIE_LC_LINK_WIDTH_CNTL); Since you also have a patch to implement setting the number of lanes, it would be better to create a new r600 version of get_pcie_lanes() since we may need other r6xx+ specific stuff in it. If we get to point where r6xx+ code will differ more, I'm ready to implement that. But if that's matter of just one condition, is that worth splitting it into two functions? I guess it's ok for now. I just don't want to get make it too confusing later on. BTW, does it actually work? I found that generally it always reads back 0 regardless of how many lanes are enabled. It reads fine for me... 16 for default :| Not sure about changing to lower values. -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15276] latest git kernel: general protection fault: 0000 [#1]
http://bugzilla.kernel.org/show_bug.cgi?id=15276 --- Comment #34 from Andreas Wallberg andreas.wallb...@gmail.com 2010-02-18 23:08:34 --- I have been experimenting with various kernel and userland versions this evening, but without much progress I must add. I can trigger the crash with: Kernel: kernel26-git: 2.6.33rc8 as of 20100227 Xorg: (this is what we have in Archlinux atm and the same versions as Michał posted before): xorg-apps 7.5-3 xorg-server 1.7.4.901-1 xorg-server-utils 7.5-3 xorg-utils 7.5-1 xorg-xinit 1.2.0-1 xorg-xkb-utils 7.5-2 DRM and drivers: xf86-video-ati-git 20100217 glproto-git 20100217 driproto-git 20100217 libdrm-git 20100217 mesa-full 20100217 mesa-full is an AUR git package of mesa which provides: libgl mesa freeglut glut ati-dri intel-dri mach64-dri mga-dri r128-dri savage-dri tdfx-dri unichrome-dri Swapping the kernel for an older 2.6.33rc5 version built on 20100126: ... crash! Swapping other git packages to older versions: xf86-video-ati-git 20100118 glproto-git 20100206 driproto-git 20100116 libdrm-git 20100118 mesa-full 20100118 and trying different kernels: kernel26-git 20100227: ... crash! kernel26-git 20100126: ... crash! I do not remember having these crashes back in the second half of January so I wonder if there is something else going on here as well. Do you all use KDE SC 4.4 and/or Kwin? Do you have these problems with other window managers as well? Could it be that the recent builds of KDE have exposed an old bug that was there all along? -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26631] R600 AGP KMS + dynpm,dynclks = stalls
http://bugs.freedesktop.org/show_bug.cgi?id=26631 --- Comment #5 from Andy Furniss li...@andyfurniss.entadsl.com 2010-02-18 15:32:34 PST --- (In reply to comment #3) Created an attachment (id=33399) -- (http://bugs.freedesktop.org/attachment.cgi?id=33399) [details] drm/radeon/kms/pm: do not take cp mutex Does it help? Yes it fixes the stalls for me, I don't see any framerate variation either. I am still getting the same output in dmesg. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: simplify storing current and requested PM mode
2010/2/18 Rafał Miłecki zaj...@gmail.com: W dniu 18 lutego 2010 21:47 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2010/2/18 Rafał Miłecki zaj...@gmail.com: W dniu 18 lutego 2010 20:29 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2010/2/17 Rafał Miłecki zaj...@gmail.com: We kept requested and current modes in many places, depending on current state. That was useless, one place for holding that is enough. Signed-off-by: Rafał Miłecki zaj...@gmail.com --- Tested on my RV620, no problems. Alex: can you review this patch? It's your code I modify/remove in it. NACK. Why are you replacing pointers with copies of of the power state structs? The idea is to keep one array of power states and pointers to the current one, default one, and requested one. Then comparing power states is just comparing pointers and when you change the power state, you just update the pointer rather then memcpying the entire struct. Then first of all we would need to reduce modes pointers. Keeping mode pointer in every state struct is/was useless. What do you mean? There is not a pointer to every state. There are only 3 (1. current, 2. requested 3. default) and they are not useless. You have power states which defines the global state of a particular power state and then each power state has a set of 1 or more clock modes. So within a power state you can switch between clock modes. You need a set of clock pointers to track the current clock mode and the requested clock mode. You also need to know the current and requested power state so you need pointers there as well. We could get rid of the default pointers, but that's mostly there for convenience to avoid having to look up the default state when we need it. For example, say you had the following power tables: 1. 3d power state: a. low clock mode b. medium clock mode c. high clock mode 2. battery power state a. low clock mode b. medium clock mode c. high clock mode 3. default power state a. low clock mode b. medium clock mode c. high clock mode By default state 3 would be selected so the current state would be '3' and the current clock mode would be a say 'a'. The current state pointer would point to '3' and the current clock mode pointer would point to 'a'. If you then went on battery, you'd want power state '2'. At that point, the requested state pointer points to '2' and one of the clock modes gets selected, lets say 'c', so the requested clock mode pointer points to 'c'. When we change the power state, we compare the current and requested power state pointers, if they are the same, no need to change anything. if they are different, we make the changes, then set the current power state pointer to the requested power state pointer and the current clock mode pointer to the requested clock mode pointer. Now say we are in power state '2' and clock mode 'c' (the high clock for power state '2') and the system goes idle; at the point we will want to stay in power state '2', but select clock mode 'a' (the low clock for power state '2'). So we compare the current and requested clock mode pointers and if they are not equal, we change the clock mode, at which time we update the current clock mode pointers to point to the requested clock. Really, you didn't need to explain all of that. I understand current idea and implementation :) The thing is that in your implementation we have 8 (eight!) pointers to current clock mode and 8 pointers to requested clock mode. This part is useless IMO. Ok, I see what you are trying to say. For the current and requested clock modes we could move the pointers up into the pm struct. Alex Let me prepare another patch to show reduction without introducing stuct memcpy. About introduced solution (keeping struct and memcpy to it) I introduced that to make hacking requested mode possible. Info from AtomBIOS about PCIE lanes seem to be useless (I've never seen anything else than 16) so I want to hack found mode for DPMS OFF to use 1 PCIE lane. Without keeping whole struct it would be impossible without overwriting original entry in array and loosing original info. That's fine for a local hack, but we don't want that upstream. If you are planning to hack all the power tables, then why even use them? I'm not sure we really change the lanes that often if at all on r6xx+. In my experience, a lot of cards lock up when change the lanes or fail to change properly which results in getting stuck at lower numbers of lanes. I don't want to hack all power tables, just consider hacking clocks/etc for minimal (dpms off). Don't want to touch other. -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel
[Bug 26641] New: RV730 agp xf86-video-ati with kms poor performance
http://bugs.freedesktop.org/show_bug.cgi?id=26641 Summary: RV730 agp xf86-video-ati with kms poor performance Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: nemr...@gmail.com I use Radeon 4650 AGP (RV730). System: Archlinux. CPU: AMD Athlon(tm) 64 Processor 3000+ I use kernel 2.6.33 rc8 with ati kms support. I have compiled mesa and driver from git (exact compile options in attachments). I can get no more than 600fps in glxgears. glxgears 2529 frames in 5.0 seconds = 505.756 FPS 2415 frames in 5.0 seconds = 482.971 FPS 2440 frames in 5.0 seconds = 487.853 FPS 1905 frames in 5.0 seconds = 380.890 FPS 1901 frames in 5.0 seconds = 380.119 FPS 1935 frames in 5.0 seconds = 386.888 FPS 1887 frames in 5.0 seconds = 377.399 FPS 1843 frames in 5.0 seconds = 368.464 FPS ^C I must say, I didn't do anything when I ran glxgears. What is strange just after I startx, I get 550-600 fps. When I start a few apps (like, psi, firefox, a few urxvt terminals (nothing more is running in background except openbox and tint2) it looks like above. After some time, I have ~ 110fps (as when I'm writing this report now). Tried also extreme tux racer. I can run it ( ~ 9fps), but it crashes after while (1024x768, rest of the options not touched). Inside the attachment I've put all used pkgbuilds, kernel config, glxinfo, X log. If you need any more info, please ask - I'll do my best to answer. Regards -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26631] R600 AGP KMS + dynpm,dynclks = stalls
http://bugs.freedesktop.org/show_bug.cgi?id=26631 --- Comment #6 from Andy Furniss li...@andyfurniss.entadsl.com 2010-02-18 15:43:34 PST --- (In reply to comment #2) Anyway, thanks to some change in the latest drm-radeon-testing any other game than q3 runs REALLY slow - even the good old CS 1.5 through wine goes to a crawl with around 4fps, compared to something around 60-80fps with older snapshots of drm-radeon-testing. I also have a problem with drm-radeon-testing since the 6th, which I have reported to the DRI list. It only affects me using AGP gart and I haven't seen any one else report it - so I guess it may not be what you are seeing, but just in case here's the detail - http://article.gmane.org/gmane.comp.video.dri.devel/42770 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26641] RV730 agp xf86-video-ati with kms poor performance
http://bugs.freedesktop.org/show_bug.cgi?id=26641 --- Comment #1 from Michał Ostrowski nemr...@gmail.com 2010-02-18 15:50:19 PST --- Created an attachment (id=33405) -- (http://bugs.freedesktop.org/attachment.cgi?id=33405) configs and logs -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26631] R600 AGP KMS + dynpm,dynclks = stalls
http://bugs.freedesktop.org/show_bug.cgi?id=26631 --- Comment #7 from Andy Furniss li...@andyfurniss.entadsl.com 2010-02-18 16:37:22 PST --- (In reply to comment #5) I don't see any framerate variation either. Of course this may be explained by my clock never actually getting changed, if it was changed every time I get a line in dmesg then it could be an issue. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26641] RV730 agp xf86-video-ati with kms poor performance
http://bugs.freedesktop.org/show_bug.cgi?id=26641 Martin PERES martin.pe...@ensi-bourges.fr changed: What|Removed |Added CC||martin.pe...@ensi-bourges.fr --- Comment #2 from Martin PERES martin.pe...@ensi-bourges.fr 2010-02-18 16:44:18 PST --- Well, I have also been experiencing the same behaviour for at least one month. I'm using an HD4470 - rv740 with the latest radeon-testing branch. Also, when dragging glxgears in a composited environnement, gears are slowing down to a few fps. Tell me if you need more information. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26631] R600 AGP KMS + dynpm,dynclks = stalls
http://bugs.freedesktop.org/show_bug.cgi?id=26631 --- Comment #8 from Alex Deucher ag...@yahoo.com 2010-02-18 17:17:37 PST --- (In reply to comment #3) Created an attachment (id=33399) -- (http://bugs.freedesktop.org/attachment.cgi?id=33399) [details] drm/radeon/kms/pm: do not take cp mutex Does it help? We need to take the CP lock to avoid scheduling commands when the CP is running. We probably need a better algo for when to adjust clocks. Maybe some sort of self adjusting timer where we only change the clock when the count of submitted command buffers has been static for a certain amount of time. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26631] R600 AGP KMS + dynpm,dynclks = stalls
http://bugs.freedesktop.org/show_bug.cgi?id=26631 --- Comment #9 from Alex Deucher ag...@yahoo.com 2010-02-18 17:18:32 PST --- (In reply to comment #8) We need to take the CP lock to avoid scheduling commands when the CP is running. We need to take the CP lock to avoid scheduling commands when we are changing the clock. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26641] RV730 agp xf86-video-ati with kms poor performance
http://bugs.freedesktop.org/show_bug.cgi?id=26641
--- Comment #3 from Andy Furniss li...@andyfurniss.entadsl.com 2010-02-18
17:25:32 PST ---
(In reply to comment #0)
I use kernel 2.6.33 rc8 with ati kms support.
I have a similar sounding problem on an AGP card since early Feb.
http://article.gmane.org/gmane.comp.video.dri.devel/42770
As I am running git drm-radeon-testing, to fix all I need to do is -
git revert db78e27de7e29a6db6be7caf607cf803d84094aa
I suppose you could try making a normal diff out of the revert below.
Revert drm/ttm: Avoid conflicting reserve_memtype during
ttm_tt_set_page_caching.
This reverts commit db78e27de7e29a6db6be7caf607cf803d84094aa.
diff --git a/drivers/gpu/drm/ttm/ttm_tt.c b/drivers/gpu/drm/ttm/ttm_tt.c
index e2123af..9c2b1cc 100644
--- a/drivers/gpu/drm/ttm/ttm_tt.c
+++ b/drivers/gpu/drm/ttm/ttm_tt.c
@@ -198,26 +198,17 @@ EXPORT_SYMBOL(ttm_tt_populate);
static inline int ttm_tt_set_page_caching(struct page *p,
enum ttm_caching_state c_state)
{
- int ret = 0;
-
if (PageHighMem(p))
return 0;
- if (get_page_memtype(p) != -1) {
- /* p isn't in the default caching state, set it to
-* writeback first to free its current memtype. */
-
- ret = set_pages_wb(p, 1);
- if (ret)
- return ret;
+ switch (c_state) {
+ case tt_cached:
+ return set_pages_wb(p, 1);
+ case tt_wc:
+ return set_memory_wc((unsigned long) page_address(p), 1);
+ default:
+ return set_pages_uc(p, 1);
}
-
- if (c_state == tt_wc)
- ret = set_memory_wc((unsigned long) page_address(p), 1);
- else if (c_state == tt_uncached)
- ret = set_pages_uc(p, 1);
-
- return ret;
}
#else /* CONFIG_X86 */
static inline int ttm_tt_set_page_caching(struct page *p,
--
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26641] RV730 agp xf86-video-ati with kms poor performance
http://bugs.freedesktop.org/show_bug.cgi?id=26641 --- Comment #4 from Alex Deucher ag...@yahoo.com 2010-02-18 17:30:43 PST --- This bug is a duplicate of this one: http://bugzilla.kernel.org/show_bug.cgi?id=15328 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26639] [radeon KMS] switching to res 1024x768 kills output
http://bugs.freedesktop.org/show_bug.cgi?id=26639 --- Comment #3 from Alex Deucher ag...@yahoo.com 2010-02-18 22:57:12 PST --- which 1024x768 mode is problematic? You have 4 of them: 1024x768 85.0 75.1 70.1 60.0 Does loading the radeon module with new_pll=0 help? e.g., modprobe radeon new_pll=0 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: fix shared ddc detection
From 7c94667f1434383c2531a249aa28b15a0e660efe Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Fri, 19 Feb 2010 02:13:56 -0500
Subject: [PATCH] drm/radeon/kms: fix shared ddc detection
Just compare the i2c id since the i2c structs
may be slighly different.
Fixes fdo bug 26616.
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_connectors.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 6e9e7b5..bca8ce2 100644
--- a/drivers/gpu/drm/radeon/radeon_connectors.c
+++ b/drivers/gpu/drm/radeon/radeon_connectors.c
@@ -766,7 +766,7 @@ static enum drm_connector_status
radeon_dvi_detect(struct drm_connector *connect
* connected and the DVI port disconnected. If the
edid doesn't
* say HDMI, vice versa.
*/
- if (radeon_connector-shared_ddc
connector_status_connected) {
+ if (radeon_connector-shared_ddc (ret ==
connector_status_connected)) {
struct drm_device *dev = connector-dev;
struct drm_connector *list_connector;
struct radeon_connector *list_radeon_connector;
@@ -1044,8 +1044,7 @@ radeon_add_atom_connector(struct drm_device *dev,
return;
}
if (radeon_connector-ddc_bus i2c_bus-valid) {
- if (memcmp(radeon_connector-ddc_bus-rec, i2c_bus,
- sizeof(struct radeon_i2c_bus_rec)) == 0) {
+ if (radeon_connector-ddc_bus-rec.i2c_id ==
i2c_bus-i2c_id) {
radeon_connector-shared_ddc = true;
shared_ddc = true;
}
--
1.5.6.3
0001-drm-radeon-kms-fix-shared-ddc-detection.patch
Description: application/mbox
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
