Re: [git pull] drm request 3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 2010-03-05 22:51 schrieb ty...@mit.edu: On Fri, Mar 05, 2010 at 11:38:46AM -0800, Corbin Simpson wrote: If distros want to run weird experiments on their users, let them! Sure, sometimes bad things happen, but sometimes good things happen too. ConsoleKit, DeviceKit, HAL, NetworkManager, KMS, yaird, dracut, Plymouth, the list goes on and on. So what distro would you recommend for people who want to do kernel development, do kernel testing, and do kernel bisects to help us find bugs? Are you basically saying, Kernel people shouldn't use Fedora? So what should we use instead? It's been Kernel people shouldn't use Nvidia ever since I started tinkering with device drivers for Linux. Of course there's hope that nouveau will one day change that, but we're obviously not quite there yet. Jm2c Tilman -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkuRmMIACgkQQ3+did9BuFvPcgCfesxRGK/XabLxAEY143aDYwdN Z7EAnjAbZKyUutNfzl9enda05vJLSRDV =e26J -END PGP SIGNATURE- -- 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 15186] Radeon KMS: [RV730] Garbled kwin shadows and pixmaps
http://bugzilla.kernel.org/show_bug.cgi?id=15186 --- Comment #22 from Michał Witkowski ne...@o2.pl 2010-03-06 10:58:35 --- I just switched form 2.6.33-rc7 to 2.6.33 final. I also updated mesa/libdrm/glproto/xf86-video-ati from GIT 20100217 to 20100306. The problem with Kwin yellowish shadows is back. Was this fix reverted? -- 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 15186] Radeon KMS: [RV730] Garbled kwin shadows and pixmaps
http://bugzilla.kernel.org/show_bug.cgi?id=15186 --- Comment #23 from Nils Kneuper crazy-ivano...@gmx.net 2010-03-06 11:11:57 --- I have been using 2.6.33 for a while now and not seen any issue so far with KDE/kwin 4.x. So for me things seem to still be fixed. -- 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 15186] Radeon KMS: [RV730] Garbled kwin shadows and pixmaps
http://bugzilla.kernel.org/show_bug.cgi?id=15186 --- Comment #24 from Robert Schedel r.sche...@yahoo.de 2010-03-06 11:48:10 --- Agree with Nils: I constantly pull git master branches from mesa and xf86-video-ati, also some minutes ago. With 2.6.33 still fixed. Suggestion: Revert recent updates one by one, bisect, write new ticket (ref to this). -- 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] i915: fix small leak on error path
Oh, dang. Thanks for catching this. Eric, please merge.
Cc: sta...@kernel.org (for .33)
Reviewed-by: Daniel Vetter dan...@ffwll.ch
On Sat, Mar 06, 2010 at 02:05:39PM +0300, Dan Carpenter wrote:
We should free params before returning.
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/drm/i915/intel_overlay.c
index d355d1d..60595fc 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -1068,14 +1068,18 @@ int intel_overlay_put_image(struct drm_device *dev,
void *data,
drmmode_obj = drm_mode_object_find(dev, put_image_rec-crtc_id,
DRM_MODE_OBJECT_CRTC);
- if (!drmmode_obj)
- return -ENOENT;
+ if (!drmmode_obj) {
+ ret = -ENOENT;
+ goto out_free;
+ }
crtc = to_intel_crtc(obj_to_crtc(drmmode_obj));
new_bo = drm_gem_object_lookup(dev, file_priv,
put_image_rec-bo_handle);
- if (!new_bo)
- return -ENOENT;
+ if (!new_bo) {
+ ret = -ENOENT;
+ goto out_free;
+ }
mutex_lock(dev-mode_config.mutex);
mutex_lock(dev-struct_mutex);
@@ -1165,6 +1169,7 @@ out_unlock:
mutex_unlock(dev-struct_mutex);
mutex_unlock(dev-mode_config.mutex);
drm_gem_object_unreference_unlocked(new_bo);
+out_free:
kfree(params);
return ret;
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
--
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: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote: On Fri, 05 Mar 2010 23:48:48 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 23:18:07 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 22:42:21 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: After quite long period of inactivity, I updated graphical stack on my desktop/server. To say the truth, I did such update about month ago, but found out that X refuses flatly to use DRI modules. I assumed that it was my mistake in compilation process (although it is automated). That generally indicates a build or config problem of some kind. Did you ever narrow it down? Because the same compile process works now, I suspect that wasn't build failure. Well something weird is going on; maybe you didn't build X after Mesa or with the right Mesa includes? I am very sure that this issue isn't relevant now. I do compile (libdrm, mesa, xserver, xf86-intel, and evdev driver in that order, compiling everything from scratch (doing git clean -dfx in all directories) if you just want a working setup, perhaps you should try using something that got (probably) tested by at least some people: http://intellinuxgraphics.org/2009Q4.html cheers, Flo Well, I now have a working setup with mesa ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5 The problem is that I hoped that once all heavy work in regard to KMS was done, there will be no serious regressions in 3D stack, but only bug fixes, because it is very hard to track and fix bugs there. However, once again 3D stack is in bad shape, and this is not good. Best regards, Maxim Levitsky -- 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 0/6] HDMI clean DCE32 support
This patchset cleans our HDMI code and adds support for DCE32. It was tested on: 1) RV620 with HDMI - no regressions 2) RV635 with 2 DVI - no regressions 3) RV730 with HDMI - made it work Would be more than great if we still could get this for 2.6.34. I could not do this work without help from Christian and Alex, so big thanks for them :) Rafał Miłecki (6): drm/radeon/kms: clear HDMI definitions drm/radeon/kms: clean assigning HDMI blocks to encoders drm/radeon/kms: add HDMI code for pre-DCE3 R6xx GPUs drm/radeon/kms: enable audio engine on DCE32 drm/radeon/kms: remove dead audio/HDMI code drm/radeon/kms: improve coding style a little drivers/gpu/drm/radeon/r600_audio.c | 57 +++--- drivers/gpu/drm/radeon/r600_hdmi.c | 191 +++--- drivers/gpu/drm/radeon/r600_reg.h| 10 +- drivers/gpu/drm/radeon/radeon.h |3 +- drivers/gpu/drm/radeon/radeon_encoders.c | 10 +- drivers/gpu/drm/radeon/radeon_mode.h |1 + drivers/gpu/drm/radeon/rv770.c | 15 +++ 7 files changed, 166 insertions(+), 121 deletions(-) -- 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 1/6] drm/radeon/kms: clean HDMI definitions
We already know same offsets are used for different encoders/transmitters, so
just numeric them instead naming incorrectly. Additionaly we found additional
registers needed for RV770+
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/gpu/drm/radeon/r600_hdmi.c | 10 +-
drivers/gpu/drm/radeon/r600_reg.h| 10 +++---
drivers/gpu/drm/radeon/radeon_mode.h |1 +
3 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
b/drivers/gpu/drm/radeon/r600_hdmi.c
index fcc949d..4d09973 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -470,27 +470,27 @@ void r600_hdmi_init(struct drm_encoder *encoder)
case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
- radeon_encoder-hdmi_offset = R600_HDMI_TMDS1;
+ radeon_encoder-hdmi_offset = R600_HDMI_BLOCK1;
break;
case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
switch (r600_audio_tmds_index(encoder)) {
case 0:
- radeon_encoder-hdmi_offset = R600_HDMI_TMDS1;
+ radeon_encoder-hdmi_offset = R600_HDMI_BLOCK1;
break;
case 1:
- radeon_encoder-hdmi_offset = R600_HDMI_TMDS2;
+ radeon_encoder-hdmi_offset = R600_HDMI_BLOCK2;
break;
default:
radeon_encoder-hdmi_offset = 0;
break;
}
case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
- radeon_encoder-hdmi_offset = R600_HDMI_TMDS2;
+ radeon_encoder-hdmi_offset = R600_HDMI_BLOCK2;
break;
case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
- radeon_encoder-hdmi_offset = R600_HDMI_DIG;
+ radeon_encoder-hdmi_offset = R600_HDMI_BLOCK3;
break;
default:
diff --git a/drivers/gpu/drm/radeon/r600_reg.h
b/drivers/gpu/drm/radeon/r600_reg.h
index d0e28ff..7b1d223 100644
--- a/drivers/gpu/drm/radeon/r600_reg.h
+++ b/drivers/gpu/drm/radeon/r600_reg.h
@@ -152,9 +152,9 @@
#define R600_AUDIO_STATUS_BITS0x73d8
/* HDMI base register addresses */
-#define R600_HDMI_TMDS1 0x7400
-#define R600_HDMI_TMDS2 0x7700
-#define R600_HDMI_DIG 0x7800
+#define R600_HDMI_BLOCK1 0x7400
+#define R600_HDMI_BLOCK2 0x7700
+#define R600_HDMI_BLOCK3 0x7800
/* HDMI registers */
#define R600_HDMI_ENABLE 0x00
@@ -185,4 +185,8 @@
#define R600_HDMI_AUDIO_DEBUG_20xe8
#define R600_HDMI_AUDIO_DEBUG_30xec
+/* HDMI additional config base register addresses */
+#define R600_HDMI_CONFIG1 0x7600
+#define R600_HDMI_CONFIG2 0x7a00
+
#endif
diff --git a/drivers/gpu/drm/radeon/radeon_mode.h
b/drivers/gpu/drm/radeon/radeon_mode.h
index 1702b82..ef186a3 100644
--- a/drivers/gpu/drm/radeon/radeon_mode.h
+++ b/drivers/gpu/drm/radeon/radeon_mode.h
@@ -342,6 +342,7 @@ struct radeon_encoder {
struct drm_display_mode native_mode;
void *enc_priv;
int hdmi_offset;
+ int hdmi_config_offset;
int hdmi_audio_workaround;
int hdmi_buffer_status;
};
--
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
[PATCH 3/6] drm/radeon/kms: add HDMI code for pre-DCE3 R6xx GPUs
Older GPUs are little different, HDMI blocks are not hard-wired, but routable.
We should just find some free HDMI block and route it to choosen encoder. In
case of RS6x0 there is only one HDMI block, we don't enable HDMI on RS6x00 yet
however.
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/gpu/drm/radeon/r600_hdmi.c | 71 +++-
1 files changed, 69 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 5275a81..8fbfc73 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -417,6 +417,39 @@ void r600_hdmi_update_audio_settings(struct drm_encoder
*encoder,
WREG32_P(offset+R600_HDMI_CNTL, 0x0400, ~0x0400);
}
+static int r600_hdmi_find_free_block(struct drm_device *dev)
+{
+ struct radeon_device *rdev = dev-dev_private;
+ struct drm_encoder *encoder;
+ struct radeon_encoder *radeon_encoder;
+ bool free_blocks[3] = { true, true, true };
+
+ list_for_each_entry(encoder, dev-mode_config.encoder_list, head) {
+ radeon_encoder = to_radeon_encoder(encoder);
+ switch (radeon_encoder-hdmi_offset) {
+ case R600_HDMI_BLOCK1:
+ free_blocks[0] = false;
+ break;
+ case R600_HDMI_BLOCK2:
+ free_blocks[1] = false;
+ break;
+ case R600_HDMI_BLOCK3:
+ free_blocks[2] = false;
+ break;
+ }
+ }
+
+ if (rdev-family == CHIP_RS600 || rdev-family == CHIP_RS690) {
+ return free_blocks[0] ? R600_HDMI_BLOCK1 : 0;
+ } else if (rdev-family = CHIP_R600) {
+ if (free_blocks[0])
+ return R600_HDMI_BLOCK1;
+ else if (free_blocks[1])
+ return R600_HDMI_BLOCK2;
+ }
+ return 0;
+}
+
static void r600_hdmi_assign_block(struct drm_encoder *encoder)
{
struct drm_device *dev = encoder-dev;
@@ -437,6 +470,8 @@ static void r600_hdmi_assign_block(struct drm_encoder
*encoder)
if (ASIC_IS_DCE32(rdev))
radeon_encoder-hdmi_config_offset = dig-dig_encoder ?
R600_HDMI_CONFIG2 : R600_HDMI_CONFIG1;
+ } else if (rdev-family = CHIP_R600) {
+ radeon_encoder-hdmi_offset = r600_hdmi_find_free_block(dev);
}
}
@@ -458,8 +493,24 @@ void r600_hdmi_enable(struct drm_encoder *encoder)
}
}
- if (ASIC_IS_DCE32(rdev) !ASIC_IS_DCE4(rdev))
+ if (ASIC_IS_DCE32(rdev) !ASIC_IS_DCE4(rdev)) {
WREG32_P(radeon_encoder-hdmi_config_offset + 0x4, 0x1, ~0x1);
+ } else if (rdev-family = CHIP_R600 !ASIC_IS_DCE3(rdev)) {
+ int offset = radeon_encoder-hdmi_offset;
+ switch (radeon_encoder-encoder_id) {
+ case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
+ WREG32_P(AVIVO_TMDSA_CNTL, 0x4, ~0x4);
+ WREG32(offset + R600_HDMI_ENABLE, 0x101);
+ break;
+ case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
+ WREG32_P(AVIVO_LVTMA_CNTL, 0x4, ~0x4);
+ WREG32(offset + R600_HDMI_ENABLE, 0x105);
+ break;
+ default:
+ dev_err(rdev-dev, Unknown HDMI output type\n);
+ break;
+ }
+ }
DRM_DEBUG(Enabling HDMI interface @ 0x%04X for encoder 0x%x\n,
radeon_encoder-hdmi_offset, radeon_encoder-encoder_id);
@@ -482,8 +533,24 @@ void r600_hdmi_disable(struct drm_encoder *encoder)
DRM_DEBUG(Disabling HDMI interface @ 0x%04X for encoder 0x%x\n,
radeon_encoder-hdmi_offset, radeon_encoder-encoder_id);
- if (ASIC_IS_DCE32(rdev) !ASIC_IS_DCE4(rdev))
+ if (ASIC_IS_DCE32(rdev) !ASIC_IS_DCE4(rdev)) {
WREG32_P(radeon_encoder-hdmi_config_offset + 0x4, 0, ~0x1);
+ } else if (rdev-family = CHIP_R600 !ASIC_IS_DCE3(rdev)) {
+ int offset = radeon_encoder-hdmi_offset;
+ switch (radeon_encoder-encoder_id) {
+ case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
+ WREG32_P(AVIVO_TMDSA_CNTL, 0, ~0x4);
+ WREG32(offset + R600_HDMI_ENABLE, 0);
+ break;
+ case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
+ WREG32_P(AVIVO_LVTMA_CNTL, 0, ~0x4);
+ WREG32(offset + R600_HDMI_ENABLE, 0);
+ break;
+ default:
+ dev_err(rdev-dev, Unknown HDMI output type\n);
+ break;
+ }
+ }
radeon_encoder-hdmi_offset = 0;
radeon_encoder-hdmi_config_offset = 0;
--
1.6.4.2
[PATCH 2/6] drm/radeon/kms: clean assigning HDMI blocks to encoders
We almost always used first HDMI block for first encoder and second for sencod.
Exception was KLDSCP_LVTMA. Analyzing code picking DIG encoder shows the same
behaviour. It shows HDMI block are related to DIGs, which relation we now use.
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/gpu/drm/radeon/r600_audio.c | 12 +++-
drivers/gpu/drm/radeon/r600_hdmi.c | 114 +-
drivers/gpu/drm/radeon/radeon.h |3 +-
drivers/gpu/drm/radeon/radeon_encoders.c | 10 ++--
4 files changed, 67 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_audio.c
b/drivers/gpu/drm/radeon/r600_audio.c
index db92801..2897bd7 100644
--- a/drivers/gpu/drm/radeon/r600_audio.c
+++ b/drivers/gpu/drm/radeon/r600_audio.c
@@ -224,8 +224,14 @@ void r600_audio_set_clock(struct drm_encoder *encoder, int
clock)
struct drm_device *dev = encoder-dev;
struct radeon_device *rdev = dev-dev_private;
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+ struct radeon_encoder_atom_dig *dig = radeon_encoder-enc_priv;
int base_rate = 48000;
+ if (!dig) {
+ dev_err(rdev-dev, Setting audio clock on non-dig encoder\n);
+ return;
+ }
+
switch (radeon_encoder-encoder_id) {
case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
@@ -245,7 +251,7 @@ void r600_audio_set_clock(struct drm_encoder *encoder, int
clock)
return;
}
- switch (r600_audio_tmds_index(encoder)) {
+ switch (dig-dig_encoder) {
case 0:
WREG32(R600_AUDIO_PLL1_MUL, base_rate*50);
WREG32(R600_AUDIO_PLL1_DIV, clock*100);
@@ -257,6 +263,10 @@ void r600_audio_set_clock(struct drm_encoder *encoder, int
clock)
WREG32(R600_AUDIO_PLL2_DIV, clock*100);
WREG32(R600_AUDIO_CLK_SRCSEL, 1);
break;
+ default:
+ dev_err(rdev-dev, Unsupported DIG on encoder 0x%02X\n,
+ radeon_encoder-encoder_id);
+ return;
}
}
diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c
b/drivers/gpu/drm/radeon/r600_hdmi.c
index 4d09973..5275a81 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -417,90 +417,74 @@ void r600_hdmi_update_audio_settings(struct drm_encoder
*encoder,
WREG32_P(offset+R600_HDMI_CNTL, 0x0400, ~0x0400);
}
-/*
- * enable/disable the HDMI engine
- */
-void r600_hdmi_enable(struct drm_encoder *encoder, int enable)
+static void r600_hdmi_assign_block(struct drm_encoder *encoder)
{
struct drm_device *dev = encoder-dev;
struct radeon_device *rdev = dev-dev_private;
struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
- uint32_t offset = to_radeon_encoder(encoder)-hdmi_offset;
+ struct radeon_encoder_atom_dig *dig = radeon_encoder-enc_priv;
- if (!offset)
+ if (!dig) {
+ dev_err(rdev-dev, Enabling HDMI on non-dig encoder\n);
return;
+ }
- DRM_DEBUG(%s HDMI interface @ 0x%04X\n, enable ? Enabling :
Disabling, offset);
-
- /* some version of atombios ignore the enable HDMI flag
-* so enabling/disabling HDMI was moved here for TMDS1+2 */
- switch (radeon_encoder-encoder_id) {
- case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
- WREG32_P(AVIVO_TMDSA_CNTL, enable ? 0x4 : 0x0, ~0x4);
- WREG32(offset+R600_HDMI_ENABLE, enable ? 0x101 : 0x0);
- break;
-
- case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
- WREG32_P(AVIVO_LVTMA_CNTL, enable ? 0x4 : 0x0, ~0x4);
- WREG32(offset+R600_HDMI_ENABLE, enable ? 0x105 : 0x0);
- break;
-
- case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
- case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
- case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
- case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
- /* This part is doubtfull in my opinion */
- WREG32(offset+R600_HDMI_ENABLE, enable ? 0x110 : 0x0);
- break;
-
- default:
- DRM_ERROR(unknown HDMI output type\n);
- break;
+ if (ASIC_IS_DCE4(rdev)) {
+ /* TODO */
+ } else if (ASIC_IS_DCE3(rdev)) {
+ radeon_encoder-hdmi_offset = dig-dig_encoder ?
+ R600_HDMI_BLOCK3 : R600_HDMI_BLOCK1;
+ if (ASIC_IS_DCE32(rdev))
+ radeon_encoder-hdmi_config_offset = dig-dig_encoder ?
+ R600_HDMI_CONFIG2 : R600_HDMI_CONFIG1;
}
}
/*
- * determin at which register offset the HDMI encoder is
+ * enable the HDMI engine
*/
-void r600_hdmi_init(struct drm_encoder *encoder)
+void r600_hdmi_enable(struct drm_encoder *encoder)
{
+ struct drm_device *dev = encoder-dev;
+
[PATCH 4/6] drm/radeon/kms: enable audio engine on DCE32
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/gpu/drm/radeon/rv770.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 37887de..8f0c925 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -1013,6 +1013,13 @@ int rv770_resume(struct radeon_device *rdev)
DRM_ERROR(radeon: failled testing IB (%d).\n, r);
return r;
}
+
+ r = r600_audio_init(rdev);
+ if (r) {
+ dev_err(rdev-dev, radeon: audio init failed\n);
+ return r;
+ }
+
return r;
}
@@ -1021,6 +1028,7 @@ int rv770_suspend(struct radeon_device *rdev)
{
int r;
+ r600_audio_fini(rdev);
/* FIXME: we should wait for ring to be empty */
r700_cp_stop(rdev);
rdev-cp.ready = false;
@@ -1144,6 +1152,13 @@ int rv770_init(struct radeon_device *rdev)
}
}
}
+
+ r = r600_audio_init(rdev);
+ if (r) {
+ dev_err(rdev-dev, radeon: audio init failed\n);
+ return r;
+ }
+
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
[PATCH 5/6] drm/radeon/kms: remove dead audio/HDMI code
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/gpu/drm/radeon/r600_audio.c | 35 ---
1 files changed, 0 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_audio.c
b/drivers/gpu/drm/radeon/r600_audio.c
index 2897bd7..1588316 100644
--- a/drivers/gpu/drm/radeon/r600_audio.c
+++ b/drivers/gpu/drm/radeon/r600_audio.c
@@ -182,41 +182,6 @@ int r600_audio_init(struct radeon_device *rdev)
}
/*
- * determin how the encoders and audio interface is wired together
- */
-int r600_audio_tmds_index(struct drm_encoder *encoder)
-{
- struct drm_device *dev = encoder-dev;
- struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
- struct drm_encoder *other;
-
- switch (radeon_encoder-encoder_id) {
- case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_TMDS1:
- case ENCODER_OBJECT_ID_INTERNAL_UNIPHY:
- case ENCODER_OBJECT_ID_INTERNAL_UNIPHY1:
- return 0;
-
- case ENCODER_OBJECT_ID_INTERNAL_LVTM1:
- /* special case check if an TMDS1 is present */
- list_for_each_entry(other, dev-mode_config.encoder_list,
head) {
- if (to_radeon_encoder(other)-encoder_id ==
- ENCODER_OBJECT_ID_INTERNAL_TMDS1)
- return 1;
- }
- return 0;
-
- case ENCODER_OBJECT_ID_INTERNAL_UNIPHY2:
- case ENCODER_OBJECT_ID_INTERNAL_KLDSCP_LVTMA:
- return 1;
-
- default:
- DRM_ERROR(Unsupported encoder type 0x%02X\n,
- radeon_encoder-encoder_id);
- return -1;
- }
-}
-
-/*
* atach the audio codec to the clock source of the encoder
*/
void r600_audio_set_clock(struct drm_encoder *encoder, int clock)
--
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: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Fri, 05 Mar 2010 23:48:48 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 23:18:07 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 22:42:21 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: After quite long period of inactivity, I updated graphical stack on my desktop/server. To say the truth, I did such update about month ago, but found out that X refuses flatly to use DRI modules. I assumed that it was my mistake in compilation process (although it is automated). That generally indicates a build or config problem of some kind. Did you ever narrow it down? Because the same compile process works now, I suspect that wasn't build failure. Well something weird is going on; maybe you didn't build X after Mesa or with the right Mesa includes? I am very sure that this issue isn't relevant now. I do compile (libdrm, mesa, xserver, xf86-intel, and evdev driver in that order, compiling everything from scratch (doing git clean -dfx in all directories) if you just want a working setup, perhaps you should try using something that got (probably) tested by at least some people: http://intellinuxgraphics.org/2009Q4.html cheers, Flo -- 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] i915: fix small leak on error path
We should free params before returning.
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/gpu/drm/i915/intel_overlay.c
b/drivers/gpu/drm/i915/intel_overlay.c
index d355d1d..60595fc 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -1068,14 +1068,18 @@ int intel_overlay_put_image(struct drm_device *dev,
void *data,
drmmode_obj = drm_mode_object_find(dev, put_image_rec-crtc_id,
DRM_MODE_OBJECT_CRTC);
- if (!drmmode_obj)
- return -ENOENT;
+ if (!drmmode_obj) {
+ ret = -ENOENT;
+ goto out_free;
+ }
crtc = to_intel_crtc(obj_to_crtc(drmmode_obj));
new_bo = drm_gem_object_lookup(dev, file_priv,
put_image_rec-bo_handle);
- if (!new_bo)
- return -ENOENT;
+ if (!new_bo) {
+ ret = -ENOENT;
+ goto out_free;
+ }
mutex_lock(dev-mode_config.mutex);
mutex_lock(dev-struct_mutex);
@@ -1165,6 +1169,7 @@ out_unlock:
mutex_unlock(dev-struct_mutex);
mutex_unlock(dev-mode_config.mutex);
drm_gem_object_unreference_unlocked(new_bo);
+out_free:
kfree(params);
return ret;
--
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: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote: On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote: On Fri, 05 Mar 2010 23:48:48 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 23:18:07 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 22:42:21 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: After quite long period of inactivity, I updated graphical stack on my desktop/server. To say the truth, I did such update about month ago, but found out that X refuses flatly to use DRI modules. I assumed that it was my mistake in compilation process (although it is automated). That generally indicates a build or config problem of some kind. Did you ever narrow it down? Because the same compile process works now, I suspect that wasn't build failure. Well something weird is going on; maybe you didn't build X after Mesa or with the right Mesa includes? I am very sure that this issue isn't relevant now. I do compile (libdrm, mesa, xserver, xf86-intel, and evdev driver in that order, compiling everything from scratch (doing git clean -dfx in all directories) if you just want a working setup, perhaps you should try using something that got (probably) tested by at least some people: http://intellinuxgraphics.org/2009Q4.html cheers, Flo Well, I now have a working setup with mesa ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5 The problem is that I hoped that once all heavy work in regard to KMS was done, there will be no serious regressions in 3D stack, but only bug fixes, because it is very hard to track and fix bugs there. However, once again 3D stack is in bad shape, and this is not good. More testing shows the following behaviour: Full screen mode is completely busted. As soon as any 3D application switches to full screen mode, even without changing the resolution, it hangs (note that I didn't see GPU hangs due to that) Compiz is broken (its also a full screen app...). As soon as it starts, it draws few windows, and then stalls. In window mode all applications do work. Now I guess this is worth a bugzilla entry. (If this isn't there yet...) Best regards, Maxim Levitsky -- 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 26915] xf86-video-ati + KMS TV-out PAL stripes
http://bugs.freedesktop.org/show_bug.cgi?id=26915 Alex Deucher ag...@yahoo.com changed: What|Removed |Added AssignedTo|xorg-t...@lists.x.org |dri- ||de...@lists.sourceforge.net Component|DDX/xorg|DRM/Radeon Product|xorg|DRI Version|7.5 |DRI CVS --- Comment #2 from Alex Deucher ag...@yahoo.com 2010-03-06 06:47:53 PST --- fix component. this is a radeon drm bug. -- 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 26915] xf86-video-ati + KMS TV-out PAL stripes
http://bugs.freedesktop.org/show_bug.cgi?id=26915 --- Comment #3 from Alex Deucher ag...@yahoo.com 2010-03-06 06:49:43 PST --- Created an attachment (id=33809) -- (http://bugs.freedesktop.org/attachment.cgi?id=33809) fix pal issues Does this patch fix it? -- 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 26926] New: [KMS][RV635] broken colors/fonts on DVI-0 (DVI-1 is OK)
http://bugs.freedesktop.org/show_bug.cgi?id=26926 Summary: [KMS][RV635] broken colors/fonts on DVI-0 (DVI-1 is OK) Product: DRI Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: zaj...@gmail.com I've just tried KMS on my RV635 and my old D-SUB (analog) LCD displays colors incorrectly when using DVI-0. When switching to DVI-1 it works fine. Any idea what can be a reason? In both cases we use INTERNAL_KLDSCP_DACx. -- 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 26926] [KMS][RV635] broken colors/fonts on DVI-0 (DVI-1 is OK)
http://bugs.freedesktop.org/show_bug.cgi?id=26926 --- Comment #2 from Rafał Miłecki zaj...@gmail.com 2010-03-06 07:04:15 PST --- Created an attachment (id=33811) -- (http://bugs.freedesktop.org/attachment.cgi?id=33811) colors1 bad (photo) -- 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 26926] [KMS][RV635] broken colors/fonts on DVI-0 (DVI-1 is OK)
http://bugs.freedesktop.org/show_bug.cgi?id=26926 --- Comment #3 from Rafał Miłecki zaj...@gmail.com 2010-03-06 07:04:29 PST --- Created an attachment (id=33812) -- (http://bugs.freedesktop.org/attachment.cgi?id=33812) colors1 good (screenshot) -- 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 26926] [KMS][RV635] broken colors/fonts on DVI-0 (DVI-1 is OK)
http://bugs.freedesktop.org/show_bug.cgi?id=26926 --- Comment #4 from Rafał Miłecki zaj...@gmail.com 2010-03-06 07:04:55 PST --- Created an attachment (id=33813) -- (http://bugs.freedesktop.org/attachment.cgi?id=33813) colors2 bad (photo) -- 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 26926] [KMS][RV635] broken colors/fonts on DVI-0 (DVI-1 is OK)
http://bugs.freedesktop.org/show_bug.cgi?id=26926 --- Comment #5 from Rafał Miłecki zaj...@gmail.com 2010-03-06 07:05:16 PST --- Created an attachment (id=33814) -- (http://bugs.freedesktop.org/attachment.cgi?id=33814) colors2 good (screenshot) -- 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 legacy tv-out pal mode
From ad6fcd83e27499e35ef4975fe0e9319f73cbb49e Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Sat, 6 Mar 2010 09:43:41 -0500
Subject: [PATCH] drm/radeon/kms: fix legacy tv-out pal mode
fixes fdo bug 26915
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_legacy_tv.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_tv.c
b/drivers/gpu/drm/radeon/radeon_legacy_tv.c
index 417684d..fdce15b 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_tv.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_tv.c
@@ -623,8 +623,8 @@ void radeon_legacy_tv_mode_set(struct drm_encoder *encoder,
}
flicker_removal = (tmp + 500) / 1000;
- if (flicker_removal 2)
- flicker_removal = 2;
+ if (flicker_removal 3)
+ flicker_removal = 3;
for (i = 0; i ARRAY_SIZE(SLOPE_limit); ++i) {
if (flicker_removal == SLOPE_limit[i])
break;
--
1.5.6.3
0001-drm-radeon-kms-fix-legacy-tv-out-pal-mode.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
[Bug 26915] xf86-video-ati + KMS TV-out PAL stripes
http://bugs.freedesktop.org/show_bug.cgi?id=26915 --- Comment #4 from Da Fox da_...@mad.scientist.com 2010-03-06 07:07:53 PST --- (In reply to comment #3) Created an attachment (id=33809) -- (http://bugs.freedesktop.org/attachment.cgi?id=33809) [details] fix pal issues Does this patch fix it? Yes, that patch fixes the issue for me, thanks! This bug may be closed now :) -- 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 26926] [KMS][RV635] broken colors/fonts on DVI-0 (DVI-1 is OK)
http://bugs.freedesktop.org/show_bug.cgi?id=26926 --- Comment #6 from Alex Deucher ag...@yahoo.com 2010-03-06 07:08:50 PST --- Does UMS work ok? I suspect it's the bg/adj values for the dac. -- 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 26926] [KMS][RV635] broken colors/fonts on DVI-0 (DVI-1 is OK)
http://bugs.freedesktop.org/show_bug.cgi?id=26926 --- Comment #7 from Rafał Miłecki zaj...@gmail.com 2010-03-06 07:11:38 PST --- (In reply to comment #6) Does UMS work ok? I suspect it's the bg/adj values for the dac. At least radeonhd does work fine for both DVIs. Will test radeon soon. Can you point me to some part of code or registers that I can compare? Do we really submit other data for AtomBIOS DAC-controlling commands at all? -- 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 26926] [KMS][RV635] broken colors/fonts on DVI-0 (DVI-1 is OK)
http://bugs.freedesktop.org/show_bug.cgi?id=26926 --- Comment #8 from Alex Deucher ag...@yahoo.com 2010-03-06 07:28:43 PST --- (In reply to comment #7) (In reply to comment #6) Does UMS work ok? I suspect it's the bg/adj values for the dac. At least radeonhd does work fine for both DVIs. Will test radeon soon. Can you point me to some part of code or registers that I can compare? Do we really submit other data for AtomBIOS DAC-controlling commands at all? The bg/dac adj values are golden values set in the atombios dac command tables. It might be a bug in the kms atom parser (I've fixed several of them recently) or a bad paramater passed to one of the tables, or something else completely unrelated. Make sure your kms tree has this patch: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=6a8a2d702b33c6ed5c789f21b4e89fdf221f01ca I'd suggest using avivotool to dump the regs and compare. The dac regs are at 0x7000-0x706c,0x7ef0-0x7ef8 (DAC1) and 0x7100-0x716c,0x7ff0-0x7ff8 (DAC2) the second set in each group are the dac bgadj and macro regs. -- 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 26915] xf86-video-ati + KMS TV-out PAL stripes
http://bugs.freedesktop.org/show_bug.cgi?id=26915 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Alex Deucher ag...@yahoo.com 2010-03-06 07:30:07 PST --- patch sent to Dave. -- 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 25741] [R600/KMS] external display flickering
http://bugs.freedesktop.org/show_bug.cgi?id=25741 Philipp Claves pcla...@web.de changed: What|Removed |Added CC||pcla...@web.de --- Comment #15 from Philipp Claves pcla...@web.de 2010-03-06 07:56:45 PST --- I have the same VGA ripple effect. 01:00.0 VGA compatible controller: ATI Technologies Inc M76 [Radeon Mobility HD 2600 Series] agd5f on IRC suggested to try 'avivotool regset 0x458 0x' or 'avivotool regset 0x45c 0x'. The first command fixes it (didn't try the second one). avivotool is a part of radeontool and can be found here: http://cgit.freedesktop.org/~airlied/radeontool -- 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: [git pull] drm request 3
Hi, On Thu, 2010-03-04 at 10:43 -0800, Linus Torvalds wrote: it difficult to have some libdrm that can handle both versions. You shouldn't expect, by now, upgrade drm kernel without update libdrm or at least recompile libdrm. So when you saw a error message driver nouveau 0.0.n+1 and have 0.0.n is completely right. Is not a perfect world, but as talked on xorg mailing list, some time ago, we do not have resources to test it in all versions. Is better focus on just one combination. Best regards, -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature -- 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 25741] [R600/KMS] external display flickering
http://bugs.freedesktop.org/show_bug.cgi?id=25741 --- Comment #16 from Philipp Claves pcla...@web.de 2010-03-06 07:58:07 PST --- Created an attachment (id=33815) -- (http://bugs.freedesktop.org/attachment.cgi?id=33815) dmesg with 2.6.33 KMS enabled -- 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 25741] [R600/KMS] external display flickering
http://bugs.freedesktop.org/show_bug.cgi?id=25741 --- Comment #17 from Philipp Claves pcla...@web.de 2010-03-06 07:59:25 PST --- Created an attachment (id=33816) -- (http://bugs.freedesktop.org/attachment.cgi?id=33816) Xorg log with Kernel 2.6.33 KMS -- 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: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Sat, 06 Mar 2010 16:40:27 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote: On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote: On Fri, 05 Mar 2010 23:48:48 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 23:18:07 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 22:42:21 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: After quite long period of inactivity, I updated graphical stack on my desktop/server. To say the truth, I did such update about month ago, but found out that X refuses flatly to use DRI modules. I assumed that it was my mistake in compilation process (although it is automated). That generally indicates a build or config problem of some kind. Did you ever narrow it down? Because the same compile process works now, I suspect that wasn't build failure. Well something weird is going on; maybe you didn't build X after Mesa or with the right Mesa includes? I am very sure that this issue isn't relevant now. I do compile (libdrm, mesa, xserver, xf86-intel, and evdev driver in that order, compiling everything from scratch (doing git clean -dfx in all directories) if you just want a working setup, perhaps you should try using something that got (probably) tested by at least some people: http://intellinuxgraphics.org/2009Q4.html cheers, Flo Well, I now have a working setup with mesa ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5 The problem is that I hoped that once all heavy work in regard to KMS was done, there will be no serious regressions in 3D stack, but only bug fixes, because it is very hard to track and fix bugs there. However, once again 3D stack is in bad shape, and this is not good. More testing shows the following behaviour: Full screen mode is completely busted. As soon as any 3D application switches to full screen mode, even without changing the resolution, it hangs (note that I didn't see GPU hangs due to that) Compiz is broken (its also a full screen app...). As soon as it starts, it draws few windows, and then stalls. In window mode all applications do work. Now I guess this is worth a bugzilla entry. (If this isn't there yet...) I'm not seeing this on GM45. I just installed a totally fresh stack on a new F12 installation and compiz and games work well. But please file a bug and include everything needed (see intellinuxgraphics.org for the list); hope we can find the issue. -- Jesse Barnes, Intel Open Source Technology Center -- 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 25741] [R600/KMS] external display flickering
http://bugs.freedesktop.org/show_bug.cgi?id=25741 --- Comment #18 from Alex Deucher ag...@yahoo.com 2010-03-06 08:06:50 PST --- Created an attachment (id=33817) -- (http://bugs.freedesktop.org/attachment.cgi?id=33817) possible fix Does this patch 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
[PATCH] drm/radeon/kms/atom: spread spectrum fix
From 1c1c332f0482b8b728ec63af92bc316fa41302a1 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Sat, 6 Mar 2010 10:57:30 -0500
Subject: [PATCH] drm/radeon/kms/atom: spread spectrum fix
The atom spread spectrum table does not always
disable ss. Explicitly disable it and then use
the atom table to enable later if needed (currently
only used for LVDS).
Fixes display issues on some systems.
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/atombios_crtc.c | 57
1 files changed, 50 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/drivers/gpu/drm/radeon/atombios_crtc.c
index dd9fdf5..0c67669 100644
--- a/drivers/gpu/drm/radeon/atombios_crtc.c
+++ b/drivers/gpu/drm/radeon/atombios_crtc.c
@@ -353,12 +353,55 @@ static void atombios_crtc_set_timing(struct
drm_crtc *crtc,
atom_execute_table(rdev-mode_info.atom_context, index, (uint32_t
*)args);
}
+static void atombios_disable_ss(struct drm_crtc *crtc)
+{
+ struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
+ struct drm_device *dev = crtc-dev;
+ struct radeon_device *rdev = dev-dev_private;
+ u32 ss_cntl;
+
+ if (ASIC_IS_DCE4(rdev)) {
+ switch (radeon_crtc-pll_id) {
+ case ATOM_PPLL1:
+ ss_cntl = RREG32(EVERGREEN_P1PLL_SS_CNTL);
+ ss_cntl = ~EVERGREEN_PxPLL_SS_EN;
+ WREG32(EVERGREEN_P1PLL_SS_CNTL, ss_cntl);
+ break;
+ case ATOM_PPLL2:
+ ss_cntl = RREG32(EVERGREEN_P2PLL_SS_CNTL);
+ ss_cntl = ~EVERGREEN_PxPLL_SS_EN;
+ WREG32(EVERGREEN_P2PLL_SS_CNTL, ss_cntl);
+ break;
+ case ATOM_DCPLL:
+ case ATOM_PPLL_INVALID:
+ return;
+ }
+ } else if (ASIC_IS_AVIVO(rdev)) {
+ switch (radeon_crtc-pll_id) {
+ case ATOM_PPLL1:
+ ss_cntl = RREG32(AVIVO_P1PLL_INT_SS_CNTL);
+ ss_cntl = ~1;
+ WREG32(AVIVO_P1PLL_INT_SS_CNTL, ss_cntl);
+ break;
+ case ATOM_PPLL2:
+ ss_cntl = RREG32(AVIVO_P2PLL_INT_SS_CNTL);
+ ss_cntl = ~1;
+ WREG32(AVIVO_P2PLL_INT_SS_CNTL, ss_cntl);
+ break;
+ case ATOM_DCPLL:
+ case ATOM_PPLL_INVALID:
+ return;
+ }
+ }
+}
+
+
union atom_enable_ss {
ENABLE_LVDS_SS_PARAMETERS legacy;
ENABLE_SPREAD_SPECTRUM_ON_PPLL_PS_ALLOCATION v1;
};
-static void atombios_set_ss(struct drm_crtc *crtc, int enable)
+static void atombios_enable_ss(struct drm_crtc *crtc)
{
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
struct drm_device *dev = crtc-dev;
@@ -387,9 +430,9 @@ static void atombios_set_ss(struct drm_crtc *crtc,
int enable)
step = dig-ss-step;
delay = dig-ss-delay;
range = dig-ss-range;
- } else if (enable)
+ } else
return;
- } else if (enable)
+ } else
return;
break;
}
@@ -406,13 +449,13 @@ static void atombios_set_ss(struct drm_crtc
*crtc, int enable)
args.v1.ucSpreadSpectrumDelay = delay;
args.v1.ucSpreadSpectrumRange = range;
args.v1.ucPpll = radeon_crtc-crtc_id ? ATOM_PPLL2 : ATOM_PPLL1;
- args.v1.ucEnable = enable;
+ args.v1.ucEnable = ATOM_ENABLE;
} else {
args.legacy.usSpreadSpectrumPercentage =
cpu_to_le16(percentage);
args.legacy.ucSpreadSpectrumType = type;
args.legacy.ucSpreadSpectrumStepSize_Delay = (step 3) 2;
args.legacy.ucSpreadSpectrumStepSize_Delay |= (delay 7) 4;
- args.legacy.ucEnable = enable;
+ args.legacy.ucEnable = ATOM_ENABLE;
}
atom_execute_table(rdev-mode_info.atom_context, index, (uint32_t
*)args);
}
@@ -1086,12 +1129,12 @@ int atombios_crtc_mode_set(struct drm_crtc *crtc,
/* pick pll */
radeon_crtc-pll_id = radeon_atom_pick_pll(crtc);
- atombios_set_ss(crtc, 0);
+ atombios_disable_ss(crtc);
/* always set DCPLL */
if (ASIC_IS_DCE4(rdev))
atombios_crtc_set_dcpll(crtc);
atombios_crtc_set_pll(crtc, adjusted_mode);
- atombios_set_ss(crtc, 1);
+ atombios_enable_ss(crtc);
if (ASIC_IS_DCE4(rdev))
atombios_set_crtc_dtd_timing(crtc, adjusted_mode);
--
1.5.6.3
[Bug 26927] New: Blank LVDS Dell Studio 17
http://bugs.freedesktop.org/show_bug.cgi?id=26927 Summary: Blank LVDS Dell Studio 17 Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: d...@mirabel-sil.com When using linux-next-20100305 with drm/radeon/kms, the LVDS panel of my laptop (Dell Studio 17) gets blank, and occasionally displays some brief artifacts when the KDM login screen supposed to pop up. Maybe it needs some quirks (as Alex Daucher did for Dell Studio 15) ? -- 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 2/6] drm/radeon/kms: clean assigning HDMI blocks to encoders
Am Samstag, den 06.03.2010, 14:03 +0100 schrieb Rafał Miłecki:
+ struct radeon_encoder_atom_dig *dig = radeon_encoder-enc_priv;
int base_rate = 48000;
+ if (!dig) {
+ dev_err(rdev-dev, Setting audio clock on non-dig encoder\n);
+ return;
+ }
+
...
- switch (r600_audio_tmds_index(encoder)) {
+ switch (dig-dig_encoder) {
case 0:
WREG32(R600_AUDIO_PLL1_MUL, base_rate*50);
WREG32(R600_AUDIO_PLL1_DIV, clock*100);
WREG32(R600_AUDIO_PLL2_DIV, clock*100);
WREG32(R600_AUDIO_CLK_SRCSEL, 1);
break;
+ default:
+ dev_err(rdev-dev, Unsupported DIG on encoder 0x%02X\n,
+ radeon_encoder-encoder_id);
+ return;
I know that I made the suggestion to code it like this, but now I'm
thinking that we should make it depend on the hdmi_offset instead of the
dig_encoder number. First I'm not sure that radeon_encoder-enc_priv
will always point to a radeon_encoder_atom_dig structure, and second I
think the possibility of rerouting the signals on pre DCE3 makes this
decision depend on the wrong index.
Currently checking this out on my hardware, so stay tuned for an update.
Regards,
Christian.
--
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: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Sat, 2010-03-06 at 08:02 -0800, Jesse Barnes wrote: On Sat, 06 Mar 2010 16:40:27 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote: On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote: On Fri, 05 Mar 2010 23:48:48 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 23:18:07 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 22:42:21 +0200 Maxim Levitsky maximlevit...@gmail.com wrote: After quite long period of inactivity, I updated graphical stack on my desktop/server. To say the truth, I did such update about month ago, but found out that X refuses flatly to use DRI modules. I assumed that it was my mistake in compilation process (although it is automated). That generally indicates a build or config problem of some kind. Did you ever narrow it down? Because the same compile process works now, I suspect that wasn't build failure. Well something weird is going on; maybe you didn't build X after Mesa or with the right Mesa includes? I am very sure that this issue isn't relevant now. I do compile (libdrm, mesa, xserver, xf86-intel, and evdev driver in that order, compiling everything from scratch (doing git clean -dfx in all directories) if you just want a working setup, perhaps you should try using something that got (probably) tested by at least some people: http://intellinuxgraphics.org/2009Q4.html cheers, Flo Well, I now have a working setup with mesa ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5 The problem is that I hoped that once all heavy work in regard to KMS was done, there will be no serious regressions in 3D stack, but only bug fixes, because it is very hard to track and fix bugs there. However, once again 3D stack is in bad shape, and this is not good. More testing shows the following behaviour: Full screen mode is completely busted. As soon as any 3D application switches to full screen mode, even without changing the resolution, it hangs (note that I didn't see GPU hangs due to that) Compiz is broken (its also a full screen app...). As soon as it starts, it draws few windows, and then stalls. In window mode all applications do work. Now I guess this is worth a bugzilla entry. (If this isn't there yet...) I'm not seeing this on GM45. I just installed a totally fresh stack on a new F12 installation and compiz and games work well. But please file a bug and include everything needed (see intellinuxgraphics.org for the list); hope we can find the issue. Here, gdb backtrace while running sauerbraten full screen: #2 0xb6e93d80 in ?? () from /usr/lib/libxcb.so.1 #3 0xb6e959d2 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1 #4 0xb7387e7e in _XReply (dpy=0x9023938, rep=0xbfc6a4dc, extra=0, discard=0) at xcb_io.c:454 #5 0xb772ba30 in DRI2GetBuffersWithFormat (dpy=0x9023938, drawable=62914575, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2, outCount=0xbfc6a608) at dri2.c:428 #6 0xb7729f62 in dri2GetBuffersWithFormat (driDrawable=0x93eed50, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2, out_count=0xbfc6a608, loaderPrivate=0x93eecb0) at dri2_glx.c:435 #7 0xb6557bf3 in intel_update_renderbuffers (context=0x905c678, drawable=0x93eed50) at intel_context.c:253 #8 0xb65581d5 in intel_prepare_render (intel=0x90c6c50) at intel_context.c:395 #9 0xb657a423 in brw_try_draw_prims (ctx=value optimized out, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3) at brw_draw.c:340 #10 brw_draw_prims (ctx=value optimized out, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3) at brw_draw.c:441 #11 0xb663ea64 in vbo_exec_vtx_flush (exec=0x9102b30, unmap=1 '\001') at vbo/vbo_exec_draw.c:384 #12 0xb663a42a in vbo_exec_FlushVertices_internal (ctx=0xfdfc, unmap=255 '\377') at vbo/vbo_exec_api.c:872 #13 0xb663c230 in vbo_exec_FlushVertices (ctx=0x90c6c50, flags=1) at vbo/vbo_exec_api.c:906 #14 0xb65daea5 in _mesa_set_enable (ctx=0x90c6c50, cap=3042, state=1 '\001') at main/enable.c:283 #15 0xb65db1bf in _mesa_Enable (cap=3042) at main/enable.c:1007 #16 0x080abf08 in ?? () #17 0x080ad3fc in ?? () #18 0xb7479b56 in __libc_start_main (main=0x80ad0a0, argc=3, ubp_av=0xbfc6abb4, init=0x824a9f0, fini=0x824a9e0, rtld_fini=0xb789cd20 _dl_fini, Best regards, Maxim Levitsky
Re: [PATCH 2/6] drm/radeon/kms: clean assigning HDMI blocks to encoders
W dniu 6 marca 2010 17:26 użytkownik Christian König
deathsim...@vodafone.de napisał:
Am Samstag, den 06.03.2010, 14:03 +0100 schrieb Rafał Miłecki:
+ struct radeon_encoder_atom_dig *dig = radeon_encoder-enc_priv;
int base_rate = 48000;
+ if (!dig) {
+ dev_err(rdev-dev, Setting audio clock on non-dig encoder\n);
+ return;
+ }
+
...
- switch (r600_audio_tmds_index(encoder)) {
+ switch (dig-dig_encoder) {
case 0:
WREG32(R600_AUDIO_PLL1_MUL, base_rate*50);
WREG32(R600_AUDIO_PLL1_DIV, clock*100);
WREG32(R600_AUDIO_PLL2_DIV, clock*100);
WREG32(R600_AUDIO_CLK_SRCSEL, 1);
break;
+ default:
+ dev_err(rdev-dev, Unsupported DIG on encoder 0x%02X\n,
+ radeon_encoder-encoder_id);
+ return;
I know that I made the suggestion to code it like this, but now I'm
thinking that we should make it depend on the hdmi_offset instead of the
dig_encoder number. First I'm not sure that radeon_encoder-enc_priv
will always point to a radeon_encoder_atom_dig structure, and second I
think the possibility of rerouting the signals on pre DCE3 makes this
decision depend on the wrong index.
Not sure about dig pointer... I think it should be always available.
But indeed it can be wrong for pre-DCE3. Thanks for pointing.
--
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 0/6] HDMI clean DCE32 support
2010/3/6 Mike Lothian m...@fireburn.co.uk: 2010/3/6 Rafał Miłecki zaj...@gmail.com: This patchset cleans our HDMI code and adds support for DCE32. It was tested on: 1) RV620 with HDMI - no regressions 2) RV635 with 2 DVI - no regressions 3) RV730 with HDMI - made it work Would be more than great if we still could get this for 2.6.34. I could not do this work without help from Christian and Alex, so big thanks for them :) Rafał Miłecki (6): drm/radeon/kms: clear HDMI definitions drm/radeon/kms: clean assigning HDMI blocks to encoders drm/radeon/kms: add HDMI code for pre-DCE3 R6xx GPUs drm/radeon/kms: enable audio engine on DCE32 drm/radeon/kms: remove dead audio/HDMI code drm/radeon/kms: improve coding style a little drivers/gpu/drm/radeon/r600_audio.c | 57 +++--- drivers/gpu/drm/radeon/r600_hdmi.c | 191 +++--- drivers/gpu/drm/radeon/r600_reg.h | 10 +- drivers/gpu/drm/radeon/radeon.h | 3 +- drivers/gpu/drm/radeon/radeon_encoders.c | 10 +- drivers/gpu/drm/radeon/radeon_mode.h | 1 + drivers/gpu/drm/radeon/rv770.c | 15 +++ 7 files changed, 166 insertions(+), 121 deletions(-) Hi Rafal What kernel do these patches apply cleanly to? Or equally is there a git tree I could pull somewhere? I do not have own tree, I based patches on drm-linus. -- 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 0/6] HDMI clean DCE32 support
2010/3/6 Rafał Miłecki zaj...@gmail.com: This patchset cleans our HDMI code and adds support for DCE32. It was tested on: 1) RV620 with HDMI - no regressions 2) RV635 with 2 DVI - no regressions 3) RV730 with HDMI - made it work Would be more than great if we still could get this for 2.6.34. I could not do this work without help from Christian and Alex, so big thanks for them :) Rafał Miłecki (6): drm/radeon/kms: clear HDMI definitions drm/radeon/kms: clean assigning HDMI blocks to encoders drm/radeon/kms: add HDMI code for pre-DCE3 R6xx GPUs drm/radeon/kms: enable audio engine on DCE32 drm/radeon/kms: remove dead audio/HDMI code drm/radeon/kms: improve coding style a little drivers/gpu/drm/radeon/r600_audio.c | 57 +++--- drivers/gpu/drm/radeon/r600_hdmi.c | 191 +++--- drivers/gpu/drm/radeon/r600_reg.h | 10 +- drivers/gpu/drm/radeon/radeon.h | 3 +- drivers/gpu/drm/radeon/radeon_encoders.c | 10 +- drivers/gpu/drm/radeon/radeon_mode.h | 1 + drivers/gpu/drm/radeon/rv770.c | 15 +++ 7 files changed, 166 insertions(+), 121 deletions(-) Hi Rafal What kernel do these patches apply cleanly to? Or equally is there a git tree I could pull somewhere? Cheers Mike -- 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 26927] Blank LVDS Dell Studio 17
http://bugs.freedesktop.org/show_bug.cgi?id=26927 --- Comment #1 from Alex Deucher ag...@yahoo.com 2010-03-06 09:26:48 PST --- Does radeon.new_pll=0 fix it? -- 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: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
looks this like my problems that i have reported some days ago with Subject Problem using an Mesa based App with recent xorg/mesa/xf86-video-intel (loop?) to Mesa-dev, xorg and intel-gfx list? i have still this issue, but i dont know what you need for informations to fix the issues? with ati driver i dont have problems, only here with intel driver on my Thinkpad X200t with intel HDA Graphics card Stephan Am 06.03.2010 17:46, schrieb Maxim Levitsky: On Sat, 2010-03-06 at 08:02 -0800, Jesse Barnes wrote: On Sat, 06 Mar 2010 16:40:27 +0200 Maxim Levitskymaximlevit...@gmail.com wrote: On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote: On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote: On Fri, 05 Mar 2010 23:48:48 +0200 Maxim Levitskymaximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 23:18:07 +0200 Maxim Levitskymaximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 22:42:21 +0200 Maxim Levitskymaximlevit...@gmail.com wrote: After quite long period of inactivity, I updated graphical stack on my desktop/server. To say the truth, I did such update about month ago, but found out that X refuses flatly to use DRI modules. I assumed that it was my mistake in compilation process (although it is automated). That generally indicates a build or config problem of some kind. Did you ever narrow it down? Because the same compile process works now, I suspect that wasn't build failure. Well something weird is going on; maybe you didn't build X after Mesa or with the right Mesa includes? I am very sure that this issue isn't relevant now. I do compile (libdrm, mesa, xserver, xf86-intel, and evdev driver in that order, compiling everything from scratch (doing git clean -dfx in all directories) if you just want a working setup, perhaps you should try using something that got (probably) tested by at least some people: http://intellinuxgraphics.org/2009Q4.html cheers, Flo Well, I now have a working setup with mesa ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5 The problem is that I hoped that once all heavy work in regard to KMS was done, there will be no serious regressions in 3D stack, but only bug fixes, because it is very hard to track and fix bugs there. However, once again 3D stack is in bad shape, and this is not good. More testing shows the following behaviour: Full screen mode is completely busted. As soon as any 3D application switches to full screen mode, even without changing the resolution, it hangs (note that I didn't see GPU hangs due to that) Compiz is broken (its also a full screen app...). As soon as it starts, it draws few windows, and then stalls. In window mode all applications do work. Now I guess this is worth a bugzilla entry. (If this isn't there yet...) I'm not seeing this on GM45. I just installed a totally fresh stack on a new F12 installation and compiz and games work well. But please file a bug and include everything needed (see intellinuxgraphics.org for the list); hope we can find the issue. Here, gdb backtrace while running sauerbraten full screen: #2 0xb6e93d80 in ?? () from /usr/lib/libxcb.so.1 #3 0xb6e959d2 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1 #4 0xb7387e7e in _XReply (dpy=0x9023938, rep=0xbfc6a4dc, extra=0, discard=0) at xcb_io.c:454 #5 0xb772ba30 in DRI2GetBuffersWithFormat (dpy=0x9023938, drawable=62914575, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2, outCount=0xbfc6a608) at dri2.c:428 #6 0xb7729f62 in dri2GetBuffersWithFormat (driDrawable=0x93eed50, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2, out_count=0xbfc6a608, loaderPrivate=0x93eecb0) at dri2_glx.c:435 #7 0xb6557bf3 in intel_update_renderbuffers (context=0x905c678, drawable=0x93eed50) at intel_context.c:253 #8 0xb65581d5 in intel_prepare_render (intel=0x90c6c50) at intel_context.c:395 #9 0xb657a423 in brw_try_draw_prims (ctx=value optimized out, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3) at brw_draw.c:340 #10 brw_draw_prims (ctx=value optimized out, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3) at brw_draw.c:441 #11 0xb663ea64 in vbo_exec_vtx_flush (exec=0x9102b30, unmap=1 '\001') at vbo/vbo_exec_draw.c:384 #12 0xb663a42a in vbo_exec_FlushVertices_internal (ctx=0xfdfc, unmap=255 '\377') at vbo/vbo_exec_api.c:872 #13 0xb663c230 in vbo_exec_FlushVertices (ctx=0x90c6c50, flags=1) at vbo/vbo_exec_api.c:906 #14 0xb65daea5
Re: [git pull] drm request 3
On Sat, 6 Mar 2010, Sergio Monteiro Basto wrote: You shouldn't expect, by now, upgrade drm kernel without update libdrm or at least recompile libdrm. Why? Why shouldn't I expect that? I already outlined exactly _how_ it could be done. Why are people saying that technology has to suck? So when you saw a error message driver nouveau 0.0.n+1 and have 0.0.n is completely right. No. It's _not_ right. The code knows what is wrong. Considering it a fatal error is _stupid_ and bad technology, when it could have just fixed it. Is not a perfect world, but as talked on xorg mailing list, some time ago, we do not have resources to test it in all versions. Is better focus on just one combination. This is not about testing all versions. It's fine to have just one combination. But why the hell doesn't it _load_ that one combination instead of just dying? IOW, there is a check for a version. It could - instead of dying - just dlopen() the right version instead. Why are people making excuses for bad programming and bad technology? Linus -- 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 0/6] HDMI clean DCE32 support
On 6 March 2010 16:49, Rafał Miłecki zaj...@gmail.com wrote: 2010/3/6 Mike Lothian m...@fireburn.co.uk: 2010/3/6 Rafał Miłecki zaj...@gmail.com: This patchset cleans our HDMI code and adds support for DCE32. It was tested on: 1) RV620 with HDMI - no regressions 2) RV635 with 2 DVI - no regressions 3) RV730 with HDMI - made it work Would be more than great if we still could get this for 2.6.34. I could not do this work without help from Christian and Alex, so big thanks for them :) Rafał Miłecki (6): drm/radeon/kms: clear HDMI definitions drm/radeon/kms: clean assigning HDMI blocks to encoders drm/radeon/kms: add HDMI code for pre-DCE3 R6xx GPUs drm/radeon/kms: enable audio engine on DCE32 drm/radeon/kms: remove dead audio/HDMI code drm/radeon/kms: improve coding style a little drivers/gpu/drm/radeon/r600_audio.c | 57 +++--- drivers/gpu/drm/radeon/r600_hdmi.c | 191 +++--- drivers/gpu/drm/radeon/r600_reg.h | 10 +- drivers/gpu/drm/radeon/radeon.h | 3 +- drivers/gpu/drm/radeon/radeon_encoders.c | 10 +- drivers/gpu/drm/radeon/radeon_mode.h | 1 + drivers/gpu/drm/radeon/rv770.c | 15 +++ 7 files changed, 166 insertions(+), 121 deletions(-) Hi Rafal What kernel do these patches apply cleanly to? Or equally is there a git tree I could pull somewhere? I do not have own tree, I based patches on drm-linus. -- Rafał Apologies I'm not used to patches I used git apply on the drm-radeon-testing branch with the --ignore-whitespace option and it compiled cleanly Not only that I have audio working on my system :-D Thanks for all your hard work in this area it really is appreciated If you're ever in Edinburgh I'll happily take you out for a night of drinking and merriment Cheers Mike -- 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 26927] Blank LVDS Dell Studio 17
http://bugs.freedesktop.org/show_bug.cgi?id=26927 --- Comment #2 from Damien Mir d...@mirabel-sil.com 2010-03-06 09:56:42 PST --- (In reply to comment #1) Does radeon.new_pll=0 fix it? No it doesn't, same result. Note that KMS with mainline 2.6.33 is OK. Seems to occur since recent merges in linux-next. -- 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: [git pull] drm request 3
On Sat, 2010-03-06 at 09:40 -0800, Linus Torvalds wrote: Why are people making excuses for bad programming and bad technology? Is not bad technology is new technology, the API have to change faster , unless you want wait 2 years until get stable . -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm request 3
On Sat, 6 Mar 2010, Sergio Monteiro Basto wrote: On Sat, 2010-03-06 at 09:40 -0800, Linus Torvalds wrote: Why are people making excuses for bad programming and bad technology? Is not bad technology is new technology, the API have to change faster , unless you want wait 2 years until get stable . F*ck me, but people are being dense. With my suggestion, people could change the API _more_, because it wouldn't be as painful. This is not about change the ABI or not. This is about since you change the ABI, do it _well_, so that it doesn't hurt people as much. Linus -- 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 26926] [KMS][RV635] broken colors/fonts on DVI-0 (DVI-1 is OK)
http://bugs.freedesktop.org/show_bug.cgi?id=26926 --- Comment #9 from Rafał Miłecki zaj...@gmail.com 2010-03-06 12:00:15 PST --- I use drm-linus which contains fix shr/shl ops. Thanks a lot for giving registers! It gave nice results :) # diff -u bad.log ok.log --- bad.log 2010-03-06 20:54:42.288325112 +0100 +++ ok.log 2010-03-06 20:52:30.060416677 +0100 @@ -52,7 +52,7 @@ 0x7134: 0x02020200 0x7138: 0x 0x713C: 0x -0x7140: 0x01E6 +0x7140: 0x 0x7144: 0x 0x7148: 0x 0x714C: 0x @@ -66,5 +66,5 @@ 0x716C: 0x rhd_dump: v1.3.0, git branch master, commit d6631a8c 0x7FF0: 0x0020 -0x7FF4: 0x00200102 +0x7FF4: 0x00202902 0x7FF8: 0x00700251 # rhd_dump -w 0x7FF4 0x00202902 1:00.0 It made the trick. Now need just to find out why 0x7FF4 had incorrect value... -- 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 15276] latest git kernel: general protection fault: 0000 [#1]
http://bugzilla.kernel.org/show_bug.cgi?id=15276 --- Comment #49 from Andreas Wallberg andreas.wallb...@gmail.com 2010-03-06 21:37:00 --- For me, the bug never went away, although I noticed that the test case may be taking a little longer to trigger recently. As I wrote above, I am using a dual screen arrangement. When the crash happens, the external screen always goes black. This mostly happens with the internal laptop LCD too, but every now and then it may instead, over a couple of seconds, go from whatever was displayed on the screen into being completely white. At one occasion I also got thin green stripes on the white screen. -- 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
[Q] How to tell we're using the KMS (during suspend/resume) outside the graphics driver
Hi, For at least two reasons it would be beneficial for some code outisde the graphics driver(s) to know if the KMS are used. First, in the non-KMS (ie. UMS) case we probably wouldn't want to call acpi_video_resume(), because that has a potential to mess up with the GPU (it actually is known to do that on at least one system). Second, in the KMS case, we'd be able to skip the kernel VT switch, because the KMS driver uses its own framebuffer anyway. So, is there any reasonable way to check that from the outside of the graphics driver? It should be general enough to cover the cases when there are two graphics adapters with different drivers in the system and so forth. Rafael -- 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: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Sat, 2010-03-06 at 22:35 +0100, Florian Mickler wrote: On Sat, 06 Mar 2010 18:02:51 +0100 Stephan Raue mailingli...@openelec.tv wrote: looks this like my problems that i have reported some days ago with Subject Problem using an Mesa based App with recent xorg/mesa/xf86-video-intel (loop?) to Mesa-dev, xorg and intel-gfx list? i have still this issue, but i dont know what you need for informations to fix the issues? with ati driver i dont have problems, only here with intel driver on my Thinkpad X200t with intel HDA Graphics card I now see that compiz hangs in same way. Attached are backtrace of the compiz, and backtrace of etracer which did start full screen but became hung on resolution change. Best regards, Maxim Levitsky GNU gdb (GDB) 7.0-ubuntu Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i486-linux-gnu. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Attaching to process 4123 Reading symbols from /usr/bin/compiz.real.disabled...(no debugging symbols found)...done. Reading symbols from /usr/lib/libXcomposite.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXcomposite.so.1 Reading symbols from /usr/lib/libXdamage.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXdamage.so.1 Reading symbols from /usr/lib/libXfixes.so.3...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXfixes.so.3 Reading symbols from /usr/local/lib/libXrandr.so.2...done. Loaded symbols for /usr/local/lib/libXrandr.so.2 Reading symbols from /usr/lib/libXinerama.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXinerama.so.1 Reading symbols from /usr/lib/libXcursor.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXcursor.so.1 Reading symbols from /usr/lib/libICE.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libICE.so.6 Reading symbols from /usr/lib/libSM.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libSM.so.6 Reading symbols from /usr/lib/libxslt.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libxslt.so.1 Reading symbols from /usr/lib/libxml2.so.2...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libxml2.so.2 Reading symbols from /usr/lib/libstartup-notification-1.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libstartup-notification-1.so.0 Reading symbols from /usr/local/lib/mesa/lib/libGL.so.1...done. Loaded symbols for /usr/local/lib/mesa/lib/libGL.so.1 Reading symbols from /lib/tls/i686/cmov/libm.so.6...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/libm-2.10.1.so...done. (no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libm.so.6 Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/libpthread-2.10.1.so...done. [Thread debugging using libthread_db enabled] (no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0 Reading symbols from /lib/tls/i686/cmov/libc.so.6...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/libc-2.10.1.so...done. (no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libc.so.6 Reading symbols from /usr/local/lib/libX11.so.6...done. Loaded symbols for /usr/local/lib/libX11.so.6 Reading symbols from /usr/lib/libXext.so.6...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXext.so.6 Reading symbols from /lib/tls/i686/cmov/libdl.so.2...Reading symbols from /usr/lib/debug/lib/tls/i686/cmov/libdl-2.10.1.so...done. (no debugging symbols found)...done. Loaded symbols for /lib/tls/i686/cmov/libdl.so.2 Reading symbols from /usr/lib/libXrender.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libXrender.so.1 Reading symbols from /usr/lib/libxcb.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libxcb.so.1 Reading symbols from /lib/libuuid.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libuuid.so.1 Reading symbols from /lib/libz.so.1...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.1 Reading symbols from /usr/lib/libxcb-aux.so.0...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libxcb-aux.so.0 Reading symbols from /usr/lib/libxcb-event.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libxcb-event.so.1 Reading symbols from /usr/lib/libxcb-atom.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libxcb-atom.so.1 Reading symbols from /usr/lib/libXxf86vm.so.1...(no debugging symbols found)...done. Loaded symbols
Re: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
On Sun, 2010-03-07 at 00:05 +0200, Maxim Levitsky wrote: On Sat, 2010-03-06 at 22:35 +0100, Florian Mickler wrote: On Sat, 06 Mar 2010 18:02:51 +0100 Stephan Raue mailingli...@openelec.tv wrote: looks this like my problems that i have reported some days ago with Subject Problem using an Mesa based App with recent xorg/mesa/xf86-video-intel (loop?) to Mesa-dev, xorg and intel-gfx list? i have still this issue, but i dont know what you need for informations to fix the issues? with ati driver i dont have problems, only here with intel driver on my Thinkpad X200t with intel HDA Graphics card I now see that compiz hangs in same way. Attached are backtrace of the compiz, and backtrace of etracer which did start full screen but became hung on resolution change. Best regards, Maxim Levitsky Other info that might help: I took a look at X and found that it was in normal waiting state sleeping waiting for input. Also, I found when 'unstable' mesa would appear to work when I start the X while 'stable' one is used. It was compiz. When compiz is running using stable mesa, an game does change the resolution 'usualy' without hang even if uses unstable mesa. Best regards, Maxim Levitsky -- 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 26927] Blank LVDS Dell Studio 17
http://bugs.freedesktop.org/show_bug.cgi?id=26927 --- Comment #3 from Alex Deucher ag...@yahoo.com 2010-03-06 15:08:11 PST --- Can you attach the output of lspci -vnn and your video bios? To dump your video bios do the following (as root): cd /sys/bus/pci/devices/pci bus id echo 1 rom cat rom /tmp/vbios.rom echo 0 rom -- 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: [Intel-gfx] [Mesa3d-dev] i965 OpenGL is heavily broken again
It would help to know what the server is doing at this point with the client. It may be that it put the client to sleep and hasn't woken it up yet, or there could be something wrong with our getbuffers code in the new scheme. Jesse On Sat, 06 Mar 2010 18:02:51 +0100 Stephan Raue mailingli...@openelec.tv wrote: looks this like my problems that i have reported some days ago with Subject Problem using an Mesa based App with recent xorg/mesa/xf86-video-intel (loop?) to Mesa-dev, xorg and intel-gfx list? i have still this issue, but i dont know what you need for informations to fix the issues? with ati driver i dont have problems, only here with intel driver on my Thinkpad X200t with intel HDA Graphics card Stephan Am 06.03.2010 17:46, schrieb Maxim Levitsky: On Sat, 2010-03-06 at 08:02 -0800, Jesse Barnes wrote: On Sat, 06 Mar 2010 16:40:27 +0200 Maxim Levitskymaximlevit...@gmail.com wrote: On Sat, 2010-03-06 at 14:10 +0200, Maxim Levitsky wrote: On Sat, 2010-03-06 at 11:18 +0100, Florian Mickler wrote: On Fri, 05 Mar 2010 23:48:48 +0200 Maxim Levitskymaximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 13:36 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 23:18:07 +0200 Maxim Levitskymaximlevit...@gmail.com wrote: On Fri, 2010-03-05 at 12:55 -0800, Jesse Barnes wrote: On Fri, 05 Mar 2010 22:42:21 +0200 Maxim Levitskymaximlevit...@gmail.com wrote: After quite long period of inactivity, I updated graphical stack on my desktop/server. To say the truth, I did such update about month ago, but found out that X refuses flatly to use DRI modules. I assumed that it was my mistake in compilation process (although it is automated). That generally indicates a build or config problem of some kind. Did you ever narrow it down? Because the same compile process works now, I suspect that wasn't build failure. Well something weird is going on; maybe you didn't build X after Mesa or with the right Mesa includes? I am very sure that this issue isn't relevant now. I do compile (libdrm, mesa, xserver, xf86-intel, and evdev driver in that order, compiling everything from scratch (doing git clean -dfx in all directories) if you just want a working setup, perhaps you should try using something that got (probably) tested by at least some people: http://intellinuxgraphics.org/2009Q4.html cheers, Flo Well, I now have a working setup with mesa ebbc73d1aed283c9bc4aa2b37bed4374bbaec5b5 The problem is that I hoped that once all heavy work in regard to KMS was done, there will be no serious regressions in 3D stack, but only bug fixes, because it is very hard to track and fix bugs there. However, once again 3D stack is in bad shape, and this is not good. More testing shows the following behaviour: Full screen mode is completely busted. As soon as any 3D application switches to full screen mode, even without changing the resolution, it hangs (note that I didn't see GPU hangs due to that) Compiz is broken (its also a full screen app...). As soon as it starts, it draws few windows, and then stalls. In window mode all applications do work. Now I guess this is worth a bugzilla entry. (If this isn't there yet...) I'm not seeing this on GM45. I just installed a totally fresh stack on a new F12 installation and compiz and games work well. But please file a bug and include everything needed (see intellinuxgraphics.org for the list); hope we can find the issue. Here, gdb backtrace while running sauerbraten full screen: #2 0xb6e93d80 in ?? () from /usr/lib/libxcb.so.1 #3 0xb6e959d2 in xcb_wait_for_reply () from /usr/lib/libxcb.so.1 #4 0xb7387e7e in _XReply (dpy=0x9023938, rep=0xbfc6a4dc, extra=0, discard=0) at xcb_io.c:454 #5 0xb772ba30 in DRI2GetBuffersWithFormat (dpy=0x9023938, drawable=62914575, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2, outCount=0xbfc6a608) at dri2.c:428 #6 0xb7729f62 in dri2GetBuffersWithFormat (driDrawable=0x93eed50, width=0x93eed74, height=0x93eed78, attachments=0xbfc6a5dc, count=2, out_count=0xbfc6a608, loaderPrivate=0x93eecb0) at dri2_glx.c:435 #7 0xb6557bf3 in intel_update_renderbuffers (context=0x905c678, drawable=0x93eed50) at intel_context.c:253 #8 0xb65581d5 in intel_prepare_render (intel=0x90c6c50) at intel_context.c:395 #9 0xb657a423 in brw_try_draw_prims (ctx=value optimized out, arrays=0x910418c, prim=0x9102c60, nr_prims=1, ib=0x0, index_bounds_valid=1 '\001', min_index=0, max_index=3) at brw_draw.c:340 #10 brw_draw_prims (ctx=value optimized out,
[Bug 26927] Blank LVDS Dell Studio 17
http://bugs.freedesktop.org/show_bug.cgi?id=26927 --- Comment #4 from Damien Mir d...@mirabel-sil.com 2010-03-06 19:28:48 PST --- Created an attachment (id=33822) -- (http://bugs.freedesktop.org/attachment.cgi?id=33822) requested vbios dump -- 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 26927] Blank LVDS Dell Studio 17
http://bugs.freedesktop.org/show_bug.cgi?id=26927 --- Comment #5 from Damien Mir d...@mirabel-sil.com 2010-03-06 19:30:02 PST --- Created an attachment (id=33823) -- (http://bugs.freedesktop.org/attachment.cgi?id=33823) lspci output -- 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: [Mesa3d-dev] [PATCH] mesa/st: Gallium quads, by spec, never change provoking vertex.
The attached patches change softpipe and llvmpipe so that they never provoke
the first vertex for quads. Please review. I think that these and the
Corbin's one could be pushed by now, couldn't they?
-Marek
On Thu, Feb 11, 2010 at 4:03 PM, Brian Paul bri...@vmware.com wrote:
Corbin Simpson wrote:
From 215714d54a7f38b9add236bcc1c795e8b5d92867 Mon Sep 17 00:00:00 2001
From: Corbin Simpson mostawesomed...@gmail.com
Date: Wed, 10 Feb 2010 10:39:18 -0800
Subject: [PATCH] mesa/st: Gallium quads, by spec, never change provoking
vertex.
Fixes glean/clipFlat. Softpipe might be broken; I haven't figured out
how to test it in this new API world. :T
---
src/mesa/state_tracker/st_extensions.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/src/mesa/state_tracker/st_extensions.c
b/src/mesa/state_tracker/st_extensions.c
index d5f5854..e2d871b 100644
--- a/src/mesa/state_tracker/st_extensions.c
+++ b/src/mesa/state_tracker/st_extensions.c
@@ -137,6 +137,9 @@ void st_init_limits(struct st_context *st)
/* XXX separate query for early function return? */
st-ctx-Shader.EmitContReturn =
screen-get_param(screen, PIPE_CAP_TGSI_CONT_SUPPORTED);
+
+ /* Quads always follow GL provoking rules. */
+ c-QuadsFollowProvokingVertexConvention = GL_FALSE;
}
This causes the glean clipFlat test to fail with softpipe. The
gallium softpipe driver _does_ implement the quad follows provoking
vertex convention.
I don't have time right now to update the softpipe driver so this
patch will have to wait a while. Maybe someone else can look at it
sooner.
-Brian
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Mesa3d-dev mailing list
mesa3d-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
From 861dd9a4e5d2fc3e0892d76d8f0ac929e186a88a Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Marek=20Ol=C5=A1=C3=A1k?= mar...@gmail.com
Date: Sun, 7 Mar 2010 04:54:43 +0100
Subject: [PATCH 1/2] llvmpipe: do not follow the provoking vertex convention for quads
---
src/gallium/drivers/llvmpipe/lp_setup_vbuf.c | 129 +++--
1 files changed, 36 insertions(+), 93 deletions(-)
diff --git a/src/gallium/drivers/llvmpipe/lp_setup_vbuf.c b/src/gallium/drivers/llvmpipe/lp_setup_vbuf.c
index 24291da..671e744 100644
--- a/src/gallium/drivers/llvmpipe/lp_setup_vbuf.c
+++ b/src/gallium/drivers/llvmpipe/lp_setup_vbuf.c
@@ -231,57 +231,29 @@ lp_setup_draw(struct vbuf_render *vbr, const ushort *indices, uint nr)
break;
case PIPE_PRIM_QUADS:
- if (setup-flatshade_first) {
- for (i = 3; i nr; i += 4) {
-setup-triangle( setup,
- get_vert(vertex_buffer, indices[i-2], stride),
- get_vert(vertex_buffer, indices[i-1], stride),
- get_vert(vertex_buffer, indices[i-3], stride) );
-setup-triangle( setup,
- get_vert(vertex_buffer, indices[i-1], stride),
- get_vert(vertex_buffer, indices[i-0], stride),
- get_vert(vertex_buffer, indices[i-3], stride) );
- }
- }
- else {
- for (i = 3; i nr; i += 4) {
-setup-triangle( setup,
- get_vert(vertex_buffer, indices[i-3], stride),
- get_vert(vertex_buffer, indices[i-2], stride),
- get_vert(vertex_buffer, indices[i-0], stride) );
+ for (i = 3; i nr; i += 4) {
+ setup-triangle( setup,
+ get_vert(vertex_buffer, indices[i-3], stride),
+ get_vert(vertex_buffer, indices[i-2], stride),
+ get_vert(vertex_buffer, indices[i-0], stride) );
-setup-triangle( setup,
- get_vert(vertex_buffer, indices[i-2], stride),
- get_vert(vertex_buffer, indices[i-1], stride),
- get_vert(vertex_buffer, indices[i-0], stride) );
- }
+ setup-triangle( setup,
+ get_vert(vertex_buffer, indices[i-2], stride),
+ get_vert(vertex_buffer, indices[i-1], stride),
+ get_vert(vertex_buffer, indices[i-0], stride) );
}
break;
case PIPE_PRIM_QUAD_STRIP:
- if (setup-flatshade_first) {
- for (i = 3; i nr; i += 2) {
-setup-triangle( setup,
- get_vert(vertex_buffer, indices[i-0], stride),
- get_vert(vertex_buffer, indices[i-1], stride),
-
