dri-devel August 2010

dri-devel@lists.freedesktop.org

82 participants
335 discussions

[PATCH] drm/radeon/kms: fix nsample tracking in r6xx/r7xx CS tracker
by Alex Deucher 16 Aug '10

16 Aug '10

Initialize nsamples to 1 in case userspace does not emit PA_SC_AA_CONFIG. Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> Cc: Andre Maasikas <amaasikas(a)gmail.com> --- drivers/gpu/drm/radeon/r600_cs.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c index 8e165b2..b03f93b 100644 --- a/drivers/gpu/drm/radeon/r600_cs.c +++ b/drivers/gpu/drm/radeon/r600_cs.c @@ -163,6 +163,7 @@ static void r600_cs_track_init(struct r600_cs_track *track) track->db_depth_size = 0xFFFFFFFF; track->db_depth_size_idx = 0; track->db_depth_control = 0xFFFFFFFF; + track->nsamples = 1; } static inline int r600_cs_track_validate_cb(struct radeon_cs_parser *p, int i) -- 1.7.1.1

3 7

[Bug 29140] New: [rs690] Freeze at Xorg startup when using KMS
by bugzilla-daemon＠freedesktop.org 16 Aug '10

16 Aug '10

https://bugs.freedesktop.org/show_bug.cgi?id=29140 Summary: [rs690] Freeze at Xorg startup when using KMS Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: steckdenis(a)yahoo.fr Created an attachment (id=37174) --> (https://bugs.freedesktop.org/attachment.cgi?id=37174) Complete dmesg (radeon module loaded just after the last line speaking about a segfault of glxinfo) Hello, I have an ATI Radeon X1270 card (rs690m), with 128 Mio of sideport memory and 256 Mio of shared RAM. This memory configuration caused the bug #27529 . I use the 2.6.35-rc5 kernel (linus-tree), Mesa git (as of the 17th of July 2010, commit 184abe8e26f76a50ede43d503aa6bf129d8d6b76, "llvmpipe: Remove unused variable in lp_test_sincos."), libdrm git (as of the first of July 2010, commit b803918f3f77c62edf22e78cb2095be399753423, "drm mode: Return -errno on drmIoctl() failure") and xf86-video-ati git (as of the 15th of July, commit cdeb1949c820242f05a8897d3ddd0718f204dacf, "kms: don't call cursor helper if using software cursor"). Because of the bug #27529, I used to boot my netbook with the "radeon.modeset=0" param, to avoir screen corruptions. Then, I went to vacations. When I returned back to home, I wanted to try the latest versions of all my favorite softwares, especially the shiny new kernel, containing the fix of #27529. I updated all my software stack to the versions I mentionned in the second paragraph, changed "radeon.modeset=0" to "radeon.modeset=1" and rebooted. The reboot was ok. All my services started up nicely, except KDM. When the X server attempts to start, the screen goes black, with a small text cursor at its top left corner. This cursor doesn't move or blinks. The computer doesn't go farther in the boot sequence, it freezes. I rebooted, using the nomodeset option, and killed KDM (which started fine). I launched a small shell loop that continuously write the dmesg output in a file and launched it. While it was running, I unloaded the radeon module and reloaded it with the "modeset=1" parameter. All went fine, my screen was ok, with my text console on it. Then, I restarted KDM, which attempted to start Xorg. The same bug came again. During the "freeze", I was able to see the activity of my hard disk drive (the dmesg loop contains a sync). It makes me thinking that the computer is not hard frozen, only the graphical part. I cannot go to any virtual console at this point, and I rebooted. I attached my complete dmesg, as captured by my small script. Thanks for resolving this bug, I hope it is the last one I will see before having a nice KMS-enabled netbook, and being able to give a try to Gallium3D, which is needed to a have the very nice Blur effect of KWin on my hardware. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 10

[PATCH] drm/radeon/kms: DCE3/4 AdjustPixelPll updates
by Alex Deucher 16 Aug '10

16 Aug '10

Add options necessary bits for: - SS on DP - SS on LVDS - set clocks right for DP - deep color on hdmi (needs additional encoder and edid work as well) Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> --- drivers/gpu/drm/radeon/atombios_crtc.c | 51 +++++++++++++++++++++++++++---- 1 files changed, 44 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c b/drivers/gpu/drm/radeon/atombios_crtc.c index 12ad512..577239a 100644 --- a/drivers/gpu/drm/radeon/atombios_crtc.c +++ b/drivers/gpu/drm/radeon/atombios_crtc.c @@ -471,6 +471,8 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc, struct radeon_encoder *radeon_encoder = NULL; u32 adjusted_clock = mode->clock; int encoder_mode = 0; + u32 dp_clock = mode->clock; + int bpc = 8; /* reset the pll flags */ pll->flags = 0; @@ -513,6 +515,17 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc, if (encoder->crtc == crtc) { radeon_encoder = to_radeon_encoder(encoder); encoder_mode = atombios_get_encoder_mode(encoder); + if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT | ATOM_DEVICE_DFP_SUPPORT)) { + struct drm_connector *connector = radeon_get_connector_for_encoder(encoder); + if (connector) { + struct radeon_connector *radeon_connector = to_radeon_connector(connector); + struct radeon_connector_atom_dig *dig_connector = + radeon_connector->con_priv; + + dp_clock = dig_connector->dp_clock; + } + } + if (ASIC_IS_AVIVO(rdev)) { /* DVO wants 2x pixel clock if the DVO chip is in 12 bit mode */ if (radeon_encoder->encoder_id == ENCODER_OBJECT_ID_INTERNAL_KLDSCP_DVO1) @@ -555,6 +568,14 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc, args.v1.usPixelClock = cpu_to_le16(mode->clock / 10); args.v1.ucTransmitterID = radeon_encoder->encoder_id; args.v1.ucEncodeMode = encoder_mode; + if (encoder_mode == ATOM_ENCODER_MODE_DP) { + /* may want to enable SS on DP eventually */ + /* args.v1.ucConfig |= + ADJUST_DISPLAY_CONFIG_SS_ENABLE;*/ + } else if (encoder_mode == ATOM_ENCODER_MODE_LVDS) { + args.v1.ucConfig |= + ADJUST_DISPLAY_CONFIG_SS_ENABLE; + } atom_execute_table(rdev->mode_info.atom_context, index, (uint32_t *)&args); @@ -568,10 +589,20 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc, if (radeon_encoder->devices & (ATOM_DEVICE_DFP_SUPPORT)) { struct radeon_encoder_atom_dig *dig = radeon_encoder->enc_priv; - if (encoder_mode == ATOM_ENCODER_MODE_DP) + if (encoder_mode == ATOM_ENCODER_MODE_DP) { + /* may want to enable SS on DP/eDP eventually */ + /*args.v3.sInput.ucDispPllConfig |= + DISPPLL_CONFIG_SS_ENABLE;*/ args.v3.sInput.ucDispPllConfig |= DISPPLL_CONFIG_COHERENT_MODE; - else { + /* 16200 or 27000 */ + args.v3.sInput.usPixelClock = cpu_to_le16(dp_clock / 10); + } else { + if (encoder_mode == ATOM_ENCODER_MODE_HDMI) { + /* deep color support */ + args.v3.sInput.usPixelClock = + cpu_to_le16((mode->clock * bpc / 8) / 10); + } if (dig->coherent_mode) args.v3.sInput.ucDispPllConfig |= DISPPLL_CONFIG_COHERENT_MODE; @@ -580,13 +611,19 @@ static u32 atombios_adjust_pll(struct drm_crtc *crtc, DISPPLL_CONFIG_DUAL_LINK; } } else if (radeon_encoder->devices & (ATOM_DEVICE_LCD_SUPPORT)) { - /* may want to enable SS on DP/eDP eventually */ - /*args.v3.sInput.ucDispPllConfig |= - DISPPLL_CONFIG_SS_ENABLE;*/ - if (encoder_mode == ATOM_ENCODER_MODE_DP) + if (encoder_mode == ATOM_ENCODER_MODE_DP) { + /* may want to enable SS on DP/eDP eventually */ + /*args.v3.sInput.ucDispPllConfig |= + DISPPLL_CONFIG_SS_ENABLE;*/ args.v3.sInput.ucDispPllConfig |= DISPPLL_CONFIG_COHERENT_MODE; - else { + /* 16200 or 27000 */ + args.v3.sInput.usPixelClock = cpu_to_le16(dp_clock / 10); + } else if (encoder_mode == ATOM_ENCODER_MODE_LVDS) { + /* want to enable SS on LVDS eventually */ + /*args.v3.sInput.ucDispPllConfig |= + DISPPLL_CONFIG_SS_ENABLE;*/ + } else { if (mode->clock > 165000) args.v3.sInput.ucDispPllConfig |= DISPPLL_CONFIG_DUAL_LINK; -- 1.7.1.1

2 2

[PATCH] drm/radeon/kms/pm: bail early if nothing's changing
by Alex Deucher 16 Aug '10

16 Aug '10

If we aren't changing the power state, no need to take locks and schedule fences, etc. There seem to be lock ordering issues in the CP and fence code in some cases; see bug 29140 below. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=29140 Possibly also: https://bugzilla.kernel.org/show_bug.cgi?id=16581 Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> Cc: stable(a)kernel.org --- drivers/gpu/drm/radeon/radeon_pm.c | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_pm.c b/drivers/gpu/drm/radeon/radeon_pm.c index a3d25f4..9a8031b 100644 --- a/drivers/gpu/drm/radeon/radeon_pm.c +++ b/drivers/gpu/drm/radeon/radeon_pm.c @@ -226,6 +226,11 @@ static void radeon_pm_set_clocks(struct radeon_device *rdev) { int i; + /* no need to take locks, etc. if nothing's going to change */ + if ((rdev->pm.requested_clock_mode_index == rdev->pm.current_clock_mode_index) && + (rdev->pm.requested_power_state_index == rdev->pm.current_power_state_index)) + return; + mutex_lock(&rdev->ddev->struct_mutex); mutex_lock(&rdev->vram_mutex); mutex_lock(&rdev->cp.mutex); -- 1.7.1.1

1 1

[PATCH] drm/radeon/kms: fix GTT/VRAM overlapping test
by jglisse＠redhat.com 16 Aug '10

16 Aug '10

From: Jerome Glisse <jglisse(a)redhat.com> GTT/VRAM overlapping test had a typo which leaded to not detecting case when vram_end > gtt_end. This patch fix the logic and should fix #16574 cc: stable Signed-off-by: Jerome Glisse <jglisse(a)redhat.com> --- drivers/gpu/drm/radeon/radeon_device.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_device.c b/drivers/gpu/drm/radeon/radeon_device.c index 4f7a170..69b3c22 100644 --- a/drivers/gpu/drm/radeon/radeon_device.c +++ b/drivers/gpu/drm/radeon/radeon_device.c @@ -199,7 +199,7 @@ void radeon_vram_location(struct radeon_device *rdev, struct radeon_mc *mc, u64 mc->mc_vram_size = mc->aper_size; } mc->vram_end = mc->vram_start + mc->mc_vram_size - 1; - if (rdev->flags & RADEON_IS_AGP && mc->vram_end > mc->gtt_start && mc->vram_end <= mc->gtt_end) { + if (rdev->flags & RADEON_IS_AGP && mc->vram_end > mc->gtt_start && mc->vram_start <= mc->gtt_end) { dev_warn(rdev->dev, "limiting VRAM to PCI aperture size\n"); mc->real_vram_size = mc->aper_size; mc->mc_vram_size = mc->aper_size; -- 1.7.1

1 0

Intel graphics CPU usage - SDVO detect bogosity?
by Linus Torvalds 16 Aug '10

16 Aug '10

I started wondering why 'top' was showing an otherwise idle system as having a load average of 0.5+, and worker threads constantly using the CPU. So I did a system-wide profile, and got the attached output (look at it in a really wide terminal). There seems to be something _seriously_ wrong with i915 SDVO detect. This is on an Apple Mac Mini (hey, your favorite problem child!), and apparently it spends 20% of its non-idle CPU time just doing udelay's for the i2c SDVO connection detection. That sounds a bit wrong, doesn't it? I don't know how recent this is - it might have been going on for some time without me noticing. It's the wife's computer, and the same thing doesn't seem to happen on my Core i5 desktop Any ideas? Any information I can give about the machine? Linus

6 8

[PATCH] drm/radeon: Fix stack data leak
by Jean Delvare 16 Aug '10

16 Aug '10

Always zero-init a structure on the stack which is returned by a function. Otherwise you may leak random stack data from previous function calls. This fixes the following warning I was seeing: CC [M] drivers/gpu/drm/radeon/radeon_atombios.o drivers/gpu/drm/radeon/radeon_atombios.c: In function "radeon_atom_get_hpd_info_from_gpio": drivers/gpu/drm/radeon/radeon_atombios.c:261: warning: "hpd.plugged_state" is used uninitialized in this function Signed-off-by: Jean Delvare <khali(a)linux-fr.org> Cc: David Airlie <airlied(a)linux.ie> Cc: Alex Deucher <alexdeucher(a)gmail.com> --- As a side, note, passing whole structures on the stack this way seems suboptimal. Passing structures by address would be faster (and safer, as it stands.) drivers/gpu/drm/radeon/radeon_atombios.c | 2 ++ 1 file changed, 2 insertions(+) --- linux-2.6.36-rc0.orig/drivers/gpu/drm/radeon/radeon_atombios.c 2010-08-15 10:24:49.000000000 +0200 +++ linux-2.6.36-rc0/drivers/gpu/drm/radeon/radeon_atombios.c 2010-08-15 13:52:31.000000000 +0200 @@ -226,6 +226,8 @@ static struct radeon_hpd radeon_atom_get struct radeon_hpd hpd; u32 reg; + memset(&hpd, 0, sizeof(struct radeon_hpd)); + if (ASIC_IS_DCE4(rdev)) reg = EVERGREEN_DC_GPIO_HPD_A; else -- Jean Delvare

2 1

[Bug 28402] Kernel 2.6.34 freezes randomly
by bugzilla-daemon＠freedesktop.org 16 Aug '10

16 Aug '10

https://bugs.freedesktop.org/show_bug.cgi?id=28402 --- Comment #11 from Aidan Marks <aidan(a)cisco.com> 2010-08-16 06:14:57 PDT --- (In reply to comment #10) I can't offer much help anymore on this defect, sorry. Soon after my comment, my T60 laptop was returned as part of the company lease cycle and my new thinkpad has an intel gfx chip. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 29438] New: [r300g] glean/glsl1-temp fails with unknown opcode ARL
by bugzilla-daemon＠freedesktop.org 16 Aug '10

16 Aug '10

https://bugs.freedesktop.org/show_bug.cgi?id=29438 Summary: [r300g] glean/glsl1-temp fails with unknown opcode ARL Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: plaes(a)plaes.org Kernel: 2.6.35 Mesa: git master d64a119c28376d7ce069dcec044ff9af7f93ff9c Results for glean/glsl1-temp array with swizzled variable indexing Returncode: 0 Errors: r300 FP: Compiler Error: r300_fragprog_emit.c::translate_rgb_opcode(): translate_rgb_opcode: Unknown opcode ARL Using a dummy shader instead. If there's an 'unknown opcode' message, please file a bug report and attach this log. Output: ---------------------------------------------------------------------- GLSL test 1: test basic Shading Language functionality. glsl1: Running single test: temp array with swizzled variable indexing FAILURE: Shader test: temp array with swizzled variable indexing Expected color: 0.4, 0.4, 0.4, 0.4 Observed color: 0, 0, 0, 1 glsl1: FAIL rgba8, db, z24, s8, win+pmap, id 33 0 tests passed, 1 tests failed. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

[Bug 29383] New: [r300g] Panzers II: terrain textures all black
by bugzilla-daemon＠freedesktop.org 16 Aug '10

16 Aug '10

https://bugs.freedesktop.org/show_bug.cgi?id=29383 Summary: [r300g] Panzers II: terrain textures all black Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/r300 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: fabio.ped(a)libero.it With r300g and wine game Panzers II terrain is all black. It's still not perfect also with classic r300 (there is a stripe effect) but at least textures are visible. Screenshots with both drivers are attached. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 2

← Newer
1
...
19
20
21
22
23
24
25
...
34
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2010