dri-devel May 2011

dri-devel@lists.freedesktop.org

118 participants
495 discussions

[PATCH] drm/radeon: make crtc number check in radeon_get_vblank_timestamp_kmsconsistent with other functions
by Ilija Hadzic 06 May '11

06 May '11

the crtc check in radeon_get_vblank_timestamp_kms should be against the num_crtc field in radeon_device not against num_crtcs in drm_device like it's done in all other functions that handle crtc Signed-off-by: Ilija Hadzic <ihadzic(a)research.bell-labs.com> --- drivers/gpu/drm/radeon/radeon_kms.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_kms.c b/drivers/gpu/drm/radeon/radeon_kms.c index 871df03..f9e968f 100644 --- a/drivers/gpu/drm/radeon/radeon_kms.c +++ b/drivers/gpu/drm/radeon/radeon_kms.c @@ -331,7 +331,7 @@ int radeon_get_vblank_timestamp_kms(struct drm_device *dev, int crtc, struct drm_crtc *drmcrtc; struct radeon_device *rdev = dev->dev_private; - if (crtc < 0 || crtc >= dev->num_crtcs) { + if (crtc < 0 || crtc >= rdev->num_crtc) { DRM_ERROR("Invalid crtc %d\n", crtc); return -EINVAL; } -- 1.7.4.1

3 2

[PATCH] xf86-video-ati/DRI2: fix high-crtc/vblank oversight/bug introduced in f0b7d7b449cc77bb2b281d81108507f8bc2e6018
by Ilija Hadzic 06 May '11

06 May '11

improvements to high-crtc handling done in f0b7d7b449cc77bb2b281d81108507f8bc2e6018 introduced a bug that caused the populate_vbl_request_type to never use the high-crtc field even when it should. The reason is that the offending patch put the code under #ifdef DRM_VBLANK_HIGH_CRTC_MASK which is not visible outside the enum type, so #else was always taken in compilation type. This patch fixes it by basing #ifdef on (pre-processor visible) DRM_VBLANK_HIGH_CRTC_SHIFT constant Signed-off-by: Ilija Hadzic <ihadzic(a)research.bell-labs.com> --- src/radeon_dri2.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/radeon_dri2.c b/src/radeon_dri2.c index e618cc5..bbe1a94 100644 --- a/src/radeon_dri2.c +++ b/src/radeon_dri2.c @@ -778,7 +778,7 @@ static drmVBlankSeqType populate_vbl_request_type(RADEONInfoPtr info, int crtc) if (crtc == 1) type |= DRM_VBLANK_SECONDARY; else if (crtc > 1) -#ifdef DRM_VBLANK_HIGH_CRTC_MASK +#ifdef DRM_VBLANK_HIGH_CRTC_SHIFT type |= (crtc << DRM_VBLANK_HIGH_CRTC_SHIFT) & DRM_VBLANK_HIGH_CRTC_MASK; #else -- 1.7.4.1

2 1

[Bug 35367] New: RV670 AGP lodbias regression since st/mesa: remove unnecessary flushes
by bugzilla-daemon＠freedesktop.org 06 May '11

06 May '11

https://bugs.freedesktop.org/show_bug.cgi?id=35367 Summary: RV670 AGP lodbias regression since st/mesa: remove unnecessary flushes Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: lists(a)andyfurniss.entadsl.com rv670 AGP but running agpmode=-1 as agpgart + gallium locks on this box. kernel d-r-t, git ddx with tiling enabled in xorg.conf. Does not affect my PCIE RV790 box. Mesa demo lodbias does not work normally since commit bdf103894026238c7e896eccb995b141161bfb70 Author: Marek OlÅ¡Ã¡k <maraeo(a)gmail.com> Date: Tue Mar 8 00:28:33 2011 +0100 st/mesa: remove unnecessary flushes The framebuffer cache flush should be implicit when calling set_framebuffer_state. There is no need to flush the command stream either. It disappears to black too quickly between 1.5 and 2.5 and the image is corrupt rather than blurring gradually during this time. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 3

[Bug 14041] glPixelStore effect glCopyTexImage2D with ati driver
by bugzilla-daemon＠freedesktop.org 06 May '11

06 May '11

https://bugs.freedesktop.org/show_bug.cgi?id=14041 Marek Olšák <maraeo(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |WORKSFORME --- Comment #4 from Marek Olšák <maraeo(a)gmail.com> 2011-05-06 05:24:28 PDT --- I guess this predates CopyTexImage acceleration. Closing. -- 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

[PATCH] drm/radeon/kms: ATPX switcheroo fixes
by Alex Deucher 06 May '11

06 May '11

When we switch the display mux, also switch the i2c mux. Also use the start and finish methods to let the sbios know that the switch is happening. Should fix: https://bugs.freedesktop.org/show_bug.cgi?id=35398 Signed-off-by: Alex Deucher <alexdeucher(a)gmail.com> --- drivers/gpu/drm/radeon/radeon_atpx_handler.c | 29 ++++++++++++++++++++++++- 1 files changed, 27 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_atpx_handler.c b/drivers/gpu/drm/radeon/radeon_atpx_handler.c index ed5dfe5..9d95792 100644 --- a/drivers/gpu/drm/radeon/radeon_atpx_handler.c +++ b/drivers/gpu/drm/radeon/radeon_atpx_handler.c @@ -15,6 +15,9 @@ #define ATPX_VERSION 0 #define ATPX_GPU_PWR 2 #define ATPX_MUX_SELECT 3 +#define ATPX_I2C_MUX_SELECT 4 +#define ATPX_SWITCH_START 5 +#define ATPX_SWITCH_END 6 #define ATPX_INTEGRATED 0 #define ATPX_DISCRETE 1 @@ -149,13 +152,35 @@ static int radeon_atpx_switch_mux(acpi_handle handle, int mux_id) return radeon_atpx_execute(handle, ATPX_MUX_SELECT, mux_id); } +static int radeon_atpx_switch_i2c_mux(acpi_handle handle, int mux_id) +{ + return radeon_atpx_execute(handle, ATPX_I2C_MUX_SELECT, mux_id); +} + +static int radeon_atpx_switch_start(acpi_handle handle, int gpu_id) +{ + return radeon_atpx_execute(handle, ATPX_SWITCH_START, gpu_id); +} + +static int radeon_atpx_switch_end(acpi_handle handle, int gpu_id) +{ + return radeon_atpx_execute(handle, ATPX_SWITCH_END, gpu_id); +} static int radeon_atpx_switchto(enum vga_switcheroo_client_id id) { + int gpu_id; + if (id == VGA_SWITCHEROO_IGD) - radeon_atpx_switch_mux(radeon_atpx_priv.atpx_handle, 0); + gpu_id = ATPX_INTEGRATED; else - radeon_atpx_switch_mux(radeon_atpx_priv.atpx_handle, 1); + gpu_id = ATPX_DISCRETE; + + radeon_atpx_switch_start(radeon_atpx_priv.atpx_handle, gpu_id); + radeon_atpx_switch_mux(radeon_atpx_priv.atpx_handle, gpu_id); + radeon_atpx_switch_i2c_mux(radeon_atpx_priv.atpx_handle, gpu_id); + radeon_atpx_switch_end(radeon_atpx_priv.atpx_handle, gpu_id); + return 0; } -- 1.7.1.1

1 0

i915 Sensors
by Jeremy Bush 05 May '11

05 May '11

Hello- I'm trying to use lm-sensors with a core i3. I talked with a developer on IRC about sensors not working, and this is what he had to say: 13:39 khali: zombor: please put the full output of sensors-detect on pastebin 13:39 khali: I'll take a look 13:39 zombor: sure, hold on 13:42 zombor: khali: http://pastebin.com/KPLZbEkd 13:42 zombor: ive got an i3 machine with an asus H61 mobo 14:09 khali: zombor: oh well, it seems that one of the I2C buses on the i915 (graphics) adapter is seriously misbehaving 14:10 zombor: :( 14:10 zombor: yeah, graphics didnt even work until 2.6.38 14:10 khali: basically it claims there's an I2C chip at every possible address 14:10 khali: I've never seen this before 14:11 khali: as a result, the 2 chips for which we have the worse detection are detected 14:11 khali: but I'm 100% certain these are false positives 14:11 khali: I dropped the sbs detection this morning, BTW 14:11 khali: I guess I should do the same now for max6650, for good measure 14:12 zombor: ok, any timeline on planned support for i915? 14:12 khali: zombor: don't ask me, it has nothing to do with lm-sensors 14:13 khali: sensors-detect is just a victim of the bug, it's not responsible for it 14:13 zombor: whats it have to with then? 14:13 khali: you should report to the i915 driver maintainer 14:13 khali: Chris Wilson <chris(a)chris-wilson.co.uk> 14:13 khali: and dri-devel(a)lists.freedesktop.org So, I'm here to report this bug! I'm using kernel 2.6.38. Jeremy

1 0

[Bug 36873] New: [drm:radeon_dvi_detect] *ERROR* HDMI Type A-1: probed a monitor but no|invalid EDID
by bugzilla-daemon＠freedesktop.org 05 May '11

05 May '11

https://bugs.freedesktop.org/show_bug.cgi?id=36873 Summary: [drm:radeon_dvi_detect] *ERROR* HDMI Type A-1: probed a monitor but no|invalid EDID Product: DRI Version: unspecified Platform: Other OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: s.j.turner(a)uqconnect.net Created an attachment (id=46364) --> (https://bugs.freedesktop.org/attachment.cgi?id=46364) dmesg Several users have reported this problem in the Launchpad bug at https://bugs.launchpad.net/ubuntu/+source/linux/+bug/539851 This has been occurring at least since Ubuntu 10.04's 2.6.32-14.20-generic kernel, continued in Ubuntu 10.10 with various 2.6.35-based kernels, and is still occurring in Ubuntu 11.04 with Ubuntu's 2.6.38-7-generic kernel. I have attached the original reporter's dmesg from their 02:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV630 [Radeon HD 2600 Series] [1002:9589] - Subsystem: Info-Tek Corp. Device [18bc:3692] I will follow up with another dmesg snippet from another user's HD4350. -- 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 31943] drm EDID checking is too strict
by bugzilla-daemon＠freedesktop.org 05 May '11

05 May '11

https://bugs.freedesktop.org/show_bug.cgi?id=31943 Alex Deucher <agd5f(a)yahoo.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |s.j.turner(a)uqconnect.net --- Comment #13 from Alex Deucher <agd5f(a)yahoo.com> 2011-05-05 09:14:52 PDT --- *** Bug 36873 has been marked as a duplicate of this bug. *** -- 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 34709] New: with r300 (rv530) kms loaded cannot suspend kernel 2.6.37+ with uswsusp
by bugzilla-daemon＠freedesktop.org 05 May '11

05 May '11

https://bugs.freedesktop.org/show_bug.cgi?id=34709 Summary: with r300 (rv530) kms loaded cannot suspend kernel 2.6.37+ with uswsusp Product: DRI Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel(a)lists.freedesktop.org ReportedBy: hramrach(a)gmail.com After upgrading from kernel 2.6.36 to 2.6.37 I can no longer suspend the system with uswsusp. The suspend operation hangs with displays blanked before the part when "Saving image to disk" takes place. Suspending with "echo disk > /sys/power/state" works but is obviously useless as the system cannot be resumed. Upgrading to 2.6.38 does not help, not loading the radeon module allows to suspend as usual. A pointer to a repo with Radeon changesets between 2.6.36 and 2.6.37 without needlessly intermingled changes to other kernel parts would be appreciated. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 22

[Bug 35969] New: with linux 2.6.38 and later resume from suspend (uswsusp) lockups on rv530 kms
by bugzilla-daemon＠freedesktop.org 05 May '11

05 May '11

https://bugs.freedesktop.org/show_bug.cgi?id=35969 Summary: with linux 2.6.38 and later resume from suspend (uswsusp) lockups on rv530 kms Product: DRI Version: unspecified 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: hramrach(a)gmail.com Depends on: 34709 With the patch from bug 34709 system suspends and resumes on linux 2.6.37 and lockups on resume on 2.6.38 and linus head (2.6.39-rc1+) -- 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
...
43
44
45
46
47
48
49
50
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel May 2011