2.6.35-rc2 completely hosed on intel gfx?
Dear everyone,
(please cc)
I just switched from 2.6.35-rc1 to rc2 and that hosed several things,
all seemingly related to intel graphics card driver:
- suspend suddenly hangs completely on switch, no traces found, not
even sysrq was working
- X often (not 100%) hangs wihth a fix cursor (not blinking) on the
to left corner, I got a stack trace in my syslog for that:
general protection fault: [#1] PREEMPT SMP
last sysfs file: /sys/devices/virtual/backlight/acpi_video0/uevent
CPU 0
Modules linked in: sco bnep rfcomm l2cap crc16 hso binfmt_misc dm_crypt dm_mod
isofs btrfs zlib_deflate crc32c libcrc32c vfat fat fuse vboxdrv loop uinput
snd_hda_codec_realtek arc4 snd_hda_intel iwlagn snd_hda_codec snd_hwdep iwlcore
snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi
snd_rawmidi snd_seq_midi_event snd_seq mac80211 btusb firewire_ohci snd_timer
snd_seq_device firewire_core bluetooth snd cfg80211 sony_laptop tpm_infineon
crc_itu_t rfkill joydev soundcore snd_page_alloc
Pid: 2758, comm: Xorg Not tainted 2.6.35-rc2 #14 VAIO/VGN-Z11VN_B
RIP: 0010:[] []
sysfs_follow_link+0x57/0x170
RSP: 0018:88012fd33df8 EFLAGS: 00010286
RAX: 88012fd33de8 RBX: 88013efa3730 RCX: 88012fd33fd8
RDX: 8800 RSI: RDI: 816282f0
RBP: 88012fd33e38 R08: R09: 0002
R10: 0281 R11: 0002e8c5 R12: 0720072007200720
R13: 88013eea2d20 R14: 88012fd57000 R15: 88012fd57000
FS: 7fa9c98cb700() GS:88000180() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 03d75048 CR3: 00012fd22000 CR4: 06f0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process Xorg (pid: 2758, threadinfo 88012fd32000, task 8801333cb990)
Stack:
03d5e200 88012fd33e58 88012fd33e28 88013ba17900
<0> 7fff82211140 88012fd33e58 7fff82211140 03d5e9cb
<0> 88012fd33f18 810ad2f4 88012fd33eb8 0400
Call Trace:
[] generic_readlink+0x40/0xa3
[] ? current_fs_time+0x22/0x29
[] ? mnt_drop_write+0x43/0x4e
[] ? touch_atime+0x10a/0x125
[] sys_readlinkat+0x63/0x7f
[] sys_readlink+0x16/0x18
[] system_call_fastpath+0x16/0x1b
Code: ff 0f 84 1d 01 00 00 48 8b 83 98 00 00 00 48 c7 c7 f0 82 62 81 48 8b 58
08 4c 8b 68 28 4d 89 fe e8 d7 c2 27 00 eb 34 4d 8b 65 08 <49> 8b 44 24 08 4c 39
e3 74 0a 48 85 c0 74 05 49 89 c4 eb ec 4c
RIP [] sysfs_follow_link+0x57/0x170
RSP
---[ end trace da2e388f90243d4a ]---
2.6.35-rc1 says about intel:
[0.517442] agpgart-intel :00:00.0: Intel GM45 Chipset
[0.519672] agpgart-intel :00:00.0: detected 65532K stolen memory
[0.540521] agpgart-intel :00:00.0: AGP aperture is 256M @ 0xc000
[2.537531] fb0: inteldrmfb frame buffer device
PLese let me know if you need more information, thanks a lot
Best wishes
Norbert
Norbert Preiningpreining@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live & Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
QUABBS (pl.n.)
The substances which emerge when you squeeze a blackhead.
--- Douglas Adams, The Meaning of Liff
[PATCH] drm/radeon/kms/pm: resurrect printing power states
Signed-off-by: Rafa? Mi?ecki
---
Alex you dropped this in "rework power management". Did you have some reason
for doing that? Or was that just accident?
---
drivers/gpu/drm/radeon/radeon_pm.c | 45
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 31da562..bb69588 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -33,6 +33,14 @@
#define RADEON_WAIT_VBLANK_TIMEOUT 200
#define RADEON_WAIT_IDLE_TIMEOUT 200
+static const char *radeon_pm_state_type_name[5] = {
+ "Default",
+ "Powersave",
+ "Battery",
+ "Balanced",
+ "Performance",
+};
+
static void radeon_dynpm_idle_work_handler(struct work_struct *work);
static int radeon_debugfs_pm_init(struct radeon_device *rdev);
static bool radeon_pm_in_vbl(struct radeon_device *rdev);
@@ -281,6 +289,42 @@ static void radeon_pm_set_clocks(struct radeon_device
*rdev)
mutex_unlock(>ddev->struct_mutex);
}
+static void radeon_pm_print_states(struct radeon_device *rdev)
+{
+ int i, j;
+ struct radeon_power_state *power_state;
+ struct radeon_pm_clock_info *clock_info;
+
+ DRM_DEBUG("%d Power State(s)\n", rdev->pm.num_power_states);
+ for (i = 0; i < rdev->pm.num_power_states; i++) {
+ power_state = >pm.power_state[i];
+ DRM_DEBUG("State %d: %s\n", i,
+ radeon_pm_state_type_name[power_state->type]);
+ if (i == rdev->pm.default_power_state_index)
+ DRM_DEBUG("\tDefault");
+ if ((rdev->flags & RADEON_IS_PCIE) && !(rdev->flags &
RADEON_IS_IGP))
+ DRM_DEBUG("\t%d PCIE Lanes\n", power_state->pcie_lanes);
+ if (power_state->flags & RADEON_PM_STATE_SINGLE_DISPLAY_ONLY)
+ DRM_DEBUG("\tSingle display only\n");
+ DRM_DEBUG("\t%d Clock Mode(s)\n", power_state->num_clock_modes);
+ for (j = 0; j < power_state->num_clock_modes; j++) {
+ clock_info = &(power_state->clock_info[j]);
+ if (rdev->flags & RADEON_IS_IGP)
+ DRM_DEBUG("\t\t%d e: %d%s\n",
+ j,
+ clock_info->sclk * 10,
+ clock_info->flags &
RADEON_PM_MODE_NO_DISPLAY ? "\tNo display only" : "");
+ else
+ DRM_DEBUG("\t\t%d e: %d\tm: %d\tv: %d%s\n",
+ j,
+ clock_info->sclk * 10,
+ clock_info->mclk * 10,
+ clock_info->voltage.voltage,
+ clock_info->flags &
RADEON_PM_MODE_NO_DISPLAY ? "\tNo display only" : "");
+ }
+ }
+}
+
static ssize_t radeon_get_pm_profile(struct device *dev,
struct device_attribute *attr,
char *buf)
@@ -408,6 +452,7 @@ int radeon_pm_init(struct radeon_device *rdev)
radeon_atombios_get_power_modes(rdev);
else
radeon_combios_get_power_modes(rdev);
+ radeon_pm_print_states(rdev);
radeon_pm_init_profile(rdev);
rdev->pm.current_power_state_index = -1;
rdev->pm.current_clock_mode_index = -1;
--
1.6.4.2
Glitch in newer drm-next/drm-radeon-testing
Am 06.06.2010 18:47, schrieb James Simmons: > >>> Apologies for such an unspecific description, and for what almost seems >>> like a support request for MythTV. I wouldn't post here if I were not >>> 100% sure it must be related with the recent drm changes. >> >> Note that the DRM APIs are intended for use by userspace components of >> graphics drivers / API libraries, not applications directly. MythTV >> shouldn't use the DRM directly for synchronization but rather use GLX >> synchronization APIs. > > Tho not the case for MythTV on a embedded device requiring apps to use GLX > wuld be to heavy. I would agree libdrm should be used. I have found the cause for the glitch and just filed http://bugs.freedesktop.org/show_bug.cgi?id=28411. Regards Marius
regression: 2.6.35-rc1 hangs on i865G with KMS
On Sun, Jun 6, 2010 at 6:28 AM, Ondrej Zary wrote: > On Saturday 05 June 2010 02:23:27 Eric Anholt wrote: >> On Fri, 4 Jun 2010 22:01:28 +0200, Ondrej Zary > rainbow-software.org> wrote: >> > Hello, >> > I'm testing 2.6.35-rc1 kernel on Asus P4P800-VM (i865G chipset). After >> > loading i915 module, the screen goes blank and the kernel hangs >> > completely (same with 2.6.35-rc1-git2). This does not happen with >> > "i915.modeset=0" parameter. >> > >> > This problem does not appear with 2.6.34. Is this a known regression? >> >> Not known as far as I know -- we'd enjoy a bisect with a bug report on >> bugs.freedesktop.org. Can you try the attached patch? Dave. -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-i915-fix-oops-on-single-crtc-devices.patch Type: application/octet-stream Size: 2532 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20100606/9d00d4e9/attachment.obj>
What happen to drm-fbdev1 branch?
Sorry I have been away. It looks like the drm-fbdev-fix branch has not been merged and it has been abandoned. I tested it on both my setups at home and it worked very well. Will this branch be merged or worked on more?
Glitch in newer drm-next/drm-radeon-testing
> > Apologies for such an unspecific description, and for what almost seems > > like a support request for MythTV. I wouldn't post here if I were not > > 100% sure it must be related with the recent drm changes. > > Note that the DRM APIs are intended for use by userspace components of > graphics drivers / API libraries, not applications directly. MythTV > shouldn't use the DRM directly for synchronization but rather use GLX > synchronization APIs. Tho not the case for MythTV on a embedded device requiring apps to use GLX wuld be to heavy. I would agree libdrm should be used.
[RFC] Try a bit harder to get output on the screen at panic time
> On Fri, 9 Apr 2010 15:10:50 -0700 > Jesse Barnes wrote: > > > This set of 3 patches makes it a little more likely we'll get panic > > output onto the screen even when X is running, assuming a KMS enabled > > stack anyway. > > > > It gets me from a blank or very sparsely populated black screen at > > panic time, to one including the full backtrace and panic output at > > panic time (tested with "echo c > /proc/sysrq-trigger" from an X > > session). > > > > It doesn't cover every case; for instance I think it'll fail when X has > > disabled the display, but those cases need to be handled with separate > > patches anyway (need to add atomic DPMS paths for instance). > > > > Anyway, please test these out and let me know if they work for you. > > Ping Linus & Dave again. Have you guys tried these? Really, it's cool. Is this safe with UMS and vgacon/sticon? With a oops while using vgacon you can now touch the hardware buffer while not in vga text mode.
[Bug 28412] New: Thief 2 crashes in wine with the open source driver and not with fglrx
https://bugs.freedesktop.org/show_bug.cgi?id=28412 Summary: Thief 2 crashes in wine with the open source driver and not with fglrx Product: Mesa Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: i30817 at gmail.com Reproducing this from root is difficult, since there is another bug in the open source driver that caused people not to use it to play this game. This the the http://bugs.winehq.org/show_bug.cgi?id=22427 However i encountered another bug when using the fglrx drivers: http://bugs.winehq.org/show_bug.cgi?id=17900 (name paulo in those comments) And tried to see with a saved game at the right moment if it worked with the open source driver to see if it was fglrx related. It did work (with the normal in game black screen to the mission end menu) but crashed at r600_dri.so as soon as i tried to enter a new level from that menu. If i use the fglrx driver the situation is reversed with the black screen at the menu - that can be overcome if you can click the right buttons in the dark. The crash with the open source driver was this: "wine: Unhandled page fault on read access to 0x7c9cb000 at address 0x7e1b5422 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x7c9cb000 in 32-bit code (0x7e1b5422). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7e1b5422 ESP:0032a244 EBP:0032a2ac EFLAGS:00010202( R- -- I - - - ) EAX:7c9caffd EBX:7e3b8ff4 ECX:0012bf00 EDX:76fd3a04 ESI:00ff EDI: Stack dump: 0x0032a244: 01df 0032a28c 0032a290 0032a288 0x0032a254: 0032a284 7e3b8ff4 0x0032a264: 0001 0280 01df 0x0032a274: 01df 027f 76fd3a04 0x0032a284: 7d48fc94 0001 0x0032a294: 7e3b8ff4 Backtrace: =>0 0x7e1b5422 in r600_dri.so (+0x5b422) (0x0032a2ac) 1 0x7e28a8cb in r600_dri.so (+0x1308ca) (0x0032f33c) 2 0x7e28ab36 _swrast_ReadPixels+0x225() in r600_dri.so (0x0032f39c) 3 0x7e2bcc92 in r600_dri.so (+0x162c91) (0x0032f42c) 4 0x7e222d90 _mesa_CopyTexImage2D+0x1bf() in r600_dri.so (0x0032f49c) 5 0x7e53e957 in wined3d (+0xce956) (0x0032f52c) 6 0x7e4dabd4 in wined3d (+0x6abd3) (0x0032f8dc) 7 0x7e4acd8c in wined3d (+0x3cd8b) (0x0032f92c) 8 0x7e5c00a4 in ddraw (+0x200a3) (0x0032f98c) 9 0x7e5c019c in ddraw (+0x2019b) (0x0032f9ac) 10 0x7e5b867c in ddraw (+0x1867b) (0x0032fa0c) 11 0x005c3664 in thief2 (+0x1c3663) (0x0004) 12 0x (0x) 0x7e1b5422: movl0x0(%eax),%esi Modules: ModuleAddressDebug infoName (112 modules) PE 40- 7db000Export thief2 PE 607- 6094000Deferredconvict.osm PE 62b- 636e000Deferredir50_32 PE1000-1006f000Deferredwitch.osm PE1d24-1d292000Deferredlgvid.ax PE6878-687ef000Deferredtnhscript.osm ELF7b80-7b93c000Deferredkernel32 \-PE7b81-7b93c000\ kernel32 ELF7bc0-7bcb8000Deferredntdll \-PE7bc1-7bcb8000\ ntdll ELF7be7f000-7bf0Deferredmsvcrt \-PE7be9-7bf0\ msvcrt ELF7bf0-7bf04000Deferred ELF7bf73000-7bf9e000Deferredmsvcrt40 \-PE7bf8-7bf9e000\ msvcrt40 ELF7bf9e000-7c00Deferredshlwapi \-PE7bfb-7c00\ shlwapi ELF7c024000-7c10c000Deferredoleaut32 \-PE7c04-7c10c000\ oleaut32 ELF7c10c000-7c1f5000Deferredcomctl32 \-PE7c12-7c1f5000\ comctl32 ELF7c3b8000-7c3cd000Deferredavicap32 \-PE7c3c-7c3cd000\ avicap32 ELF7c3cd000-7c481000Deferredquartz \-PE7c3e-7c481000\ quartz ELF7c62-7c642000Deferreddevenum \-PE7c63-7c642000\ devenum ELF7c642000-7c676000Deferreduxtheme \-PE7c65-7c676000\ uxtheme ELF7c68b000-7c6b1000Deferredmsvfw32 \-PE7c69-7c6b1000\ msvfw32 ELF7d4fa000-7d51Deferredmidimap \-PE7d50-7d51\ midimap ELF7d51-7d536000Deferredmsacm32 \-PE7d52-7d536000\ msacm32 ELF7dd37000-7dd3e000Deferredlibasound_module_pcm_pulse.so ELF7dd3e000-7dd67000Deferredlibvorbis.so.0 ELF7dd67000-7de63000Deferredlibvorbisenc.so.2 ELF7de63000-7debDeferredlibflac.so.8 ELF7deb-7dee9000
[PATCH 2/2] drm/radeon/kms: add trivial debugging for voltage
Signed-off-by: Rafa? Mi?ecki
---
drivers/gpu/drm/radeon/evergreen.c |1 +
drivers/gpu/drm/radeon/r600.c |1 +
drivers/gpu/drm/radeon/radeon_pm.c |2 ++
drivers/gpu/drm/radeon/rv770.c |1 +
4 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index c444808..ff21c97 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -50,6 +50,7 @@ void evergreen_pm_misc(struct radeon_device *rdev)
if ((voltage->type == VOLTAGE_SW) && voltage->voltage) {
radeon_atom_set_voltage(rdev, voltage->voltage);
rdev->pm.current_vddc = voltage->voltage;
+ DRM_DEBUG("Setting: v: %d\n", voltage->voltage);
}
}
}
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index e49bebe..1bcf22c 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -484,6 +484,7 @@ void r600_pm_misc(struct radeon_device *rdev)
if ((voltage->type == VOLTAGE_SW) && voltage->voltage) {
radeon_atom_set_voltage(rdev, voltage->voltage);
rdev->pm.current_vddc = voltage->voltage;
+ DRM_DEBUG("Setting: v: %d\n", voltage->voltage);
}
}
}
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index a046fe7..31da562 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -707,6 +707,8 @@ static int radeon_debugfs_pm_info(struct seq_file *m, void
*data)
seq_printf(m, "default memory clock: %u0 kHz\n",
rdev->clock.default_mclk);
if (rdev->asic->get_memory_clock)
seq_printf(m, "current memory clock: %u0 kHz\n",
radeon_get_memory_clock(rdev));
+ if (rdev->pm.current_vddc)
+ seq_printf(m, "voltage: %u mV\n", rdev->pm.current_vddc);
if (rdev->asic->get_pcie_lanes)
seq_printf(m, "PCIE lanes: %d\n", radeon_get_pcie_lanes(rdev));
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index f310fa8..fd9bf4e 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -53,6 +53,7 @@ void rv770_pm_misc(struct radeon_device *rdev)
if ((voltage->type == VOLTAGE_SW) && voltage->voltage) {
radeon_atom_set_voltage(rdev, voltage->voltage);
rdev->pm.current_vddc = voltage->voltage;
+ DRM_DEBUG("Setting: v: %d\n", voltage->voltage);
}
}
}
--
1.6.4.2
[PATCH 1/2] drm/radeon/kms/r600+: do not set the same voltage as current one
We have similar tracking for engine and memory. We could think about some
solution for older GPUs as well, however there are not strict voltage values
set.
Signed-off-by: Rafa? Mi?ecki
---
drivers/gpu/drm/radeon/evergreen.c |8 ++--
drivers/gpu/drm/radeon/r600.c |8 ++--
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_pm.c |2 ++
drivers/gpu/drm/radeon/rv770.c |8 ++--
5 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 174f718..c444808 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -46,8 +46,12 @@ void evergreen_pm_misc(struct radeon_device *rdev)
struct radeon_power_state *ps = >pm.power_state[req_ps_idx];
struct radeon_voltage *voltage = >clock_info[req_cm_idx].voltage;
- if ((voltage->type == VOLTAGE_SW) && voltage->voltage)
- radeon_atom_set_voltage(rdev, voltage->voltage);
+ if (voltage->voltage != rdev->pm.current_vddc) {
+ if ((voltage->type == VOLTAGE_SW) && voltage->voltage) {
+ radeon_atom_set_voltage(rdev, voltage->voltage);
+ rdev->pm.current_vddc = voltage->voltage;
+ }
+ }
}
void evergreen_pm_prepare(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 94c27d0..e49bebe 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -480,8 +480,12 @@ void r600_pm_misc(struct radeon_device *rdev)
struct radeon_power_state *ps = >pm.power_state[req_ps_idx];
struct radeon_voltage *voltage = >clock_info[req_cm_idx].voltage;
- if ((voltage->type == VOLTAGE_SW) && voltage->voltage)
- radeon_atom_set_voltage(rdev, voltage->voltage);
+ if (voltage->voltage != rdev->pm.current_vddc) {
+ if ((voltage->type == VOLTAGE_SW) && voltage->voltage) {
+ radeon_atom_set_voltage(rdev, voltage->voltage);
+ rdev->pm.current_vddc = voltage->voltage;
+ }
+ }
}
bool r600_gui_idle(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 084221d..04bc867 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -745,6 +745,7 @@ struct radeon_pm {
int default_power_state_index;
u32 current_sclk;
u32 current_mclk;
+ u32 current_vddc;
struct radeon_i2c_chan *i2c_bus;
/* selected pm method */
enum radeon_pm_method pm_method;
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 0228126..a046fe7 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -381,6 +381,7 @@ void radeon_pm_suspend(struct radeon_device *rdev)
rdev->pm.current_clock_mode_index = -1;
rdev->pm.current_sclk = 0;
rdev->pm.current_mclk = 0;
+ rdev->pm.current_vddc = 0;
mutex_unlock(>pm.mutex);
}
@@ -400,6 +401,7 @@ int radeon_pm_init(struct radeon_device *rdev)
rdev->pm.dynpm_can_downclock = true;
rdev->pm.current_sclk = 0;
rdev->pm.current_mclk = 0;
+ rdev->pm.current_vddc = 0;
if (rdev->bios) {
if (rdev->is_atom_bios)
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index f002848..f310fa8 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -49,8 +49,12 @@ void rv770_pm_misc(struct radeon_device *rdev)
struct radeon_power_state *ps = >pm.power_state[req_ps_idx];
struct radeon_voltage *voltage = >clock_info[req_cm_idx].voltage;
- if ((voltage->type == VOLTAGE_SW) && voltage->voltage)
- radeon_atom_set_voltage(rdev, voltage->voltage);
+ if (voltage->voltage != rdev->pm.current_vddc) {
+ if ((voltage->type == VOLTAGE_SW) && voltage->voltage) {
+ radeon_atom_set_voltage(rdev, voltage->voltage);
+ rdev->pm.current_vddc = voltage->voltage;
+ }
+ }
}
/*
--
1.6.4.2
[PATCH 0/2] Little voltage improvements
Patches simply add tracking of voltage and debug setting it. While it may look trivial and not important, having it would save a lot of time in debugging FDO bug #36081. This way I try to say it could be nice to have it in .35 as voltage stuff is new and we still may discover some bugs around it. Rafa? Mi?ecki (2): drm/radeon/kms/r600+: do not set the same voltage as current one drm/radeon/kms: add trivial debugging for voltage drivers/gpu/drm/radeon/evergreen.c |9 +++-- drivers/gpu/drm/radeon/r600.c |9 +++-- drivers/gpu/drm/radeon/radeon.h|1 + drivers/gpu/drm/radeon/radeon_pm.c |4 drivers/gpu/drm/radeon/rv770.c |9 +++-- 5 files changed, 26 insertions(+), 6 deletions(-)
[PATCH V3] drm/radeon/kms/r600+: use voltage from requested clock mode
Signed-off-by: Rafa? Mi?ecki
---
This fixes FDO bug #28375, it's kind of regression, so quite important to have
it for .35.
V2: Fix on RV770+ as well. All other chipsets have only one clock mode per
state.
V3: I'm out of luck today. Grepped for voltage in r*.c and missed evergreen.
---
drivers/gpu/drm/radeon/evergreen.c |7 ---
drivers/gpu/drm/radeon/r600.c |8
drivers/gpu/drm/radeon/rv770.c |7 ---
3 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 69c4b27..174f718 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -41,9 +41,10 @@ void evergreen_fini(struct radeon_device *rdev);
void evergreen_pm_misc(struct radeon_device *rdev)
{
- int requested_index = rdev->pm.requested_power_state_index;
- struct radeon_power_state *ps = >pm.power_state[requested_index];
- struct radeon_voltage *voltage = >clock_info[0].voltage;
+ int req_ps_idx = rdev->pm.requested_power_state_index;
+ int req_cm_idx = rdev->pm.requested_clock_mode_index;
+ struct radeon_power_state *ps = >pm.power_state[req_ps_idx];
+ struct radeon_voltage *voltage = >clock_info[req_cm_idx].voltage;
if ((voltage->type == VOLTAGE_SW) && voltage->voltage)
radeon_atom_set_voltage(rdev, voltage->voltage);
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index d84d7cf..94c27d0 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -475,13 +475,13 @@ void r600_pm_init_profile(struct radeon_device *rdev)
void r600_pm_misc(struct radeon_device *rdev)
{
- int requested_index = rdev->pm.requested_power_state_index;
- struct radeon_power_state *ps = >pm.power_state[requested_index];
- struct radeon_voltage *voltage = >clock_info[0].voltage;
+ int req_ps_idx = rdev->pm.requested_power_state_index;
+ int req_cm_idx = rdev->pm.requested_clock_mode_index;
+ struct radeon_power_state *ps = >pm.power_state[req_ps_idx];
+ struct radeon_voltage *voltage = >clock_info[req_cm_idx].voltage;
if ((voltage->type == VOLTAGE_SW) && voltage->voltage)
radeon_atom_set_voltage(rdev, voltage->voltage);
-
}
bool r600_gui_idle(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 5f76938..f002848 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -44,9 +44,10 @@ void rv770_fini(struct radeon_device *rdev);
void rv770_pm_misc(struct radeon_device *rdev)
{
- int requested_index = rdev->pm.requested_power_state_index;
- struct radeon_power_state *ps = >pm.power_state[requested_index];
- struct radeon_voltage *voltage = >clock_info[0].voltage;
+ int req_ps_idx = rdev->pm.requested_power_state_index;
+ int req_cm_idx = rdev->pm.requested_clock_mode_index;
+ struct radeon_power_state *ps = >pm.power_state[req_ps_idx];
+ struct radeon_voltage *voltage = >clock_info[req_cm_idx].voltage;
if ((voltage->type == VOLTAGE_SW) && voltage->voltage)
radeon_atom_set_voltage(rdev, voltage->voltage);
--
1.6.4.2
[PATCH V2] drm/radeon/kms/r600+: use voltage from requested clock mode
Signed-off-by: Rafa? Mi?ecki
---
This fixes FDO bug #28375, must have for .35
V2: Fix on RV770+ as well. All other chipsets have only one clock mode per
state.
---
drivers/gpu/drm/radeon/r600.c |8
drivers/gpu/drm/radeon/rv770.c |7 ---
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index d84d7cf..94c27d0 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -475,13 +475,13 @@ void r600_pm_init_profile(struct radeon_device *rdev)
void r600_pm_misc(struct radeon_device *rdev)
{
- int requested_index = rdev->pm.requested_power_state_index;
- struct radeon_power_state *ps = >pm.power_state[requested_index];
- struct radeon_voltage *voltage = >clock_info[0].voltage;
+ int req_ps_idx = rdev->pm.requested_power_state_index;
+ int req_cm_idx = rdev->pm.requested_clock_mode_index;
+ struct radeon_power_state *ps = >pm.power_state[req_ps_idx];
+ struct radeon_voltage *voltage = >clock_info[req_cm_idx].voltage;
if ((voltage->type == VOLTAGE_SW) && voltage->voltage)
radeon_atom_set_voltage(rdev, voltage->voltage);
-
}
bool r600_gui_idle(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 5f76938..f002848 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -44,9 +44,10 @@ void rv770_fini(struct radeon_device *rdev);
void rv770_pm_misc(struct radeon_device *rdev)
{
- int requested_index = rdev->pm.requested_power_state_index;
- struct radeon_power_state *ps = >pm.power_state[requested_index];
- struct radeon_voltage *voltage = >clock_info[0].voltage;
+ int req_ps_idx = rdev->pm.requested_power_state_index;
+ int req_cm_idx = rdev->pm.requested_clock_mode_index;
+ struct radeon_power_state *ps = >pm.power_state[req_ps_idx];
+ struct radeon_voltage *voltage = >clock_info[req_cm_idx].voltage;
if ((voltage->type == VOLTAGE_SW) && voltage->voltage)
radeon_atom_set_voltage(rdev, voltage->voltage);
--
1.6.4.2
[PATCH] drm/radeon/kms/r600+: use voltage from requested clock mode
Signed-off-by: Rafa? Mi?ecki
---
This fixes FDO bug #28375, must have for .35
---
drivers/gpu/drm/radeon/r600.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index d84d7cf..94c27d0 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -475,13 +475,13 @@ void r600_pm_init_profile(struct radeon_device *rdev)
void r600_pm_misc(struct radeon_device *rdev)
{
- int requested_index = rdev->pm.requested_power_state_index;
- struct radeon_power_state *ps = >pm.power_state[requested_index];
- struct radeon_voltage *voltage = >clock_info[0].voltage;
+ int req_ps_idx = rdev->pm.requested_power_state_index;
+ int req_cm_idx = rdev->pm.requested_clock_mode_index;
+ struct radeon_power_state *ps = >pm.power_state[req_ps_idx];
+ struct radeon_voltage *voltage = >clock_info[req_cm_idx].voltage;
if ((voltage->type == VOLTAGE_SW) && voltage->voltage)
radeon_atom_set_voltage(rdev, voltage->voltage);
-
}
bool r600_gui_idle(struct radeon_device *rdev)
--
1.6.4.2
regression: 2.6.35-rc1 hangs on i865G with KMS
On Sunday 06 June 2010 11:04:44 Dave Airlie wrote: > On Sun, Jun 6, 2010 at 6:28 AM, Ondrej Zary wrote: > > On Saturday 05 June 2010 02:23:27 Eric Anholt wrote: > >> On Fri, 4 Jun 2010 22:01:28 +0200, Ondrej Zary wrote: > >> > Hello, > >> > I'm testing 2.6.35-rc1 kernel on Asus P4P800-VM (i865G chipset). After > >> > loading i915 module, the screen goes blank and the kernel hangs > >> > completely (same with 2.6.35-rc1-git2). This does not happen with > >> > "i915.modeset=0" parameter. > >> > > >> > This problem does not appear with 2.6.34. Is this a known regression? > >> > >> Not known as far as I know -- we'd enjoy a bisect with a bug report on > >> bugs.freedesktop.org. > > Can you try the attached patch? Thanks, applied it on 2.6.35-rc2 and it seems to work fine. -- Ondrej Zary
Glitch in newer drm-next/drm-radeon-testing
Am 04.06.2010 17:17, schrieb Alex Deucher: > 2010/6/4 Marius Gr?ger: >> Alex Deucher schrieb: >>> 2010/6/4 Marius Gr?ger: Hi All, Michel D?nzer schrieb: > On Mit, 2010-06-02 at 08:07 +0200, Marius Gr?ger wrote: >> Hello All, >> >> I'm trying the top-of-trunk drm-2.6 trees (both drm-next and >> drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The primary >> application is mythtv which uses DRM syncing for the frame >> syncronisation. Now, with the exact same userland software I noticed the >> introduction of sync gliches in the May-timeframe. The >> drm-radeon-testing on May 9 was still ok, but both drm-next and >> drm-radeon-testing at the end of May showed that glitch: every couple of >> seconds there's a very visual hickup, especially in scroll texts. >> >> Apologies for such an unspecific description, and for what almost seems >> like a support request for MythTV. I wouldn't post here if I were not >> 100% sure it must be related with the recent drm changes. > Note that the DRM APIs are intended for use by userspace components of > graphics drivers / API libraries, not applications directly. MythTV > shouldn't use the DRM directly for synchronization but rather use GLX > synchronization APIs. [...] > Any chance you can bisect the problematic commit? I did a second attempt at bisecting and now I'm confident it is this commit which broke my real-time performance in mythtv: commit eb1f8e4f3be898df808e2dfc131099f5831d491d Author: Dave Airlie Date: Fri May 7 06:42:51 2010 + drm/fbdev: rework output polling to be back in the core. (v4) Having found the commit is the good news. The bad news is that this commit is rather large, so again I'd be depended on the experts around here to isolate what's going on. Dave, would you mind giving a hand as well as the author of this commit? Thanks Marius
[PATCH 4/4] drm/radeon: Propagate error from drm_fb_helper_init()
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/radeon/radeon_fb.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c
b/drivers/gpu/drm/radeon/radeon_fb.c
index e192acf..dc1634b 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -363,6 +363,7 @@ int radeon_fbdev_init(struct radeon_device *rdev)
{
struct radeon_fbdev *rfbdev;
int bpp_sel = 32;
+ int ret;
/* select 8 bpp console on RN50 or 16MB cards */
if (ASIC_IS_RN50(rdev) || rdev->mc.real_vram_size <= (32*1024*1024))
@@ -376,9 +377,14 @@ int radeon_fbdev_init(struct radeon_device *rdev)
rdev->mode_info.rfbdev = rfbdev;
rfbdev->helper.funcs = _fb_helper_funcs;
- drm_fb_helper_init(rdev->ddev, >helper,
- rdev->num_crtc,
- RADEONFB_CONN_LIMIT);
+ ret = drm_fb_helper_init(rdev->ddev, >helper,
+rdev->num_crtc,
+RADEONFB_CONN_LIMIT);
+ if (ret) {
+ kfree(rfbdev);
+ return ret;
+ }
+
drm_fb_helper_single_add_all_connectors(>helper);
drm_fb_helper_initial_config(>helper, bpp_sel);
return 0;
--
1.7.1
[PATCH 3/4] drm/nouveau: Propagate error from drm_fb_helper_init()
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index fd4a2df..c9a4a0d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -377,6 +377,7 @@ int nouveau_fbcon_init(struct drm_device *dev)
{
struct drm_nouveau_private *dev_priv = dev->dev_private;
struct nouveau_fbdev *nfbdev;
+ int ret;
nfbdev = kzalloc(sizeof(struct nouveau_fbdev), GFP_KERNEL);
if (!nfbdev)
@@ -386,7 +387,12 @@ int nouveau_fbcon_init(struct drm_device *dev)
dev_priv->nfbdev = nfbdev;
nfbdev->helper.funcs = _fbcon_helper_funcs;
- drm_fb_helper_init(dev, >helper, 2, 4);
+ ret = drm_fb_helper_init(dev, >helper, 2, 4);
+ if (ret) {
+ kfree(nfbdev);
+ return ret;
+ }
+
drm_fb_helper_single_add_all_connectors(>helper);
drm_fb_helper_initial_config(>helper, 32);
return 0;
--
1.7.1
[PATCH 2/4] drm/i915: Propagate error from intel_fbdev_init().
Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_dma.c | 19 ++- 1 files changed, 14 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 84ce956..2df3286 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1400,19 +1400,19 @@ static int i915_load_modeset_init(struct drm_device *dev, /* if we have > 1 VGA cards, then disable the radeon VGA resources */ ret = vga_client_register(dev->pdev, dev, NULL, i915_vga_set_decode); if (ret) - goto destroy_ringbuffer; + goto cleanup_ringbuffer; ret = vga_switcheroo_register_client(dev->pdev, i915_switcheroo_set_state, i915_switcheroo_can_switch); if (ret) - goto destroy_ringbuffer; + goto cleanup_vga_client; intel_modeset_init(dev); ret = drm_irq_install(dev); if (ret) - goto destroy_ringbuffer; + goto cleanup_vga_switcheroo; /* Always safe in the mode setting case. */ /* FIXME: do pre/post-mode set stuff in core KMS code */ @@ -1424,11 +1424,20 @@ static int i915_load_modeset_init(struct drm_device *dev, I915_WRITE(INSTPM, (1 << 5) | (1 << 21)); - intel_fbdev_init(dev); + ret = intel_fbdev_init(dev); + if (ret) + goto cleanup_irq; + drm_kms_helper_poll_init(dev); return 0; -destroy_ringbuffer: +cleanup_irq: + drm_irq_uninstall(dev); +cleanup_vga_switcheroo: + vga_switcheroo_unregister_client(dev->pdev); +cleanup_vga_client: + vga_client_register(dev->pdev, NULL, NULL, NULL); +cleanup_ringbuffer: mutex_lock(>struct_mutex); i915_gem_cleanup_ringbuffer(dev); mutex_unlock(>struct_mutex); -- 1.7.1
[PATCH 1/4] drm/i915: Propagate error from drm_fb_helper_init().
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_fb.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index dfbb0c6..c3c5052 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -245,6 +245,7 @@ int intel_fbdev_init(struct drm_device *dev)
{
struct intel_fbdev *ifbdev;
drm_i915_private_t *dev_priv = dev->dev_private;
+ int ret;
ifbdev = kzalloc(sizeof(struct intel_fbdev), GFP_KERNEL);
if (!ifbdev)
@@ -253,8 +254,13 @@ int intel_fbdev_init(struct drm_device *dev)
dev_priv->fbdev = ifbdev;
ifbdev->helper.funcs = _fb_helper_funcs;
- drm_fb_helper_init(dev, >helper, dev_priv->num_pipe,
- INTELFB_CONN_LIMIT);
+ ret = drm_fb_helper_init(dev, >helper,
+dev_priv->num_pipe,
+INTELFB_CONN_LIMIT);
+ if (ret) {
+ kfree(ifbdev);
+ return ret;
+ }
drm_fb_helper_single_add_all_connectors(>helper);
drm_fb_helper_initial_config(>helper, 32);
--
1.7.1
[Bug 28411] New: Output polling causes latency every 10 seconds
https://bugs.freedesktop.org/show_bug.cgi?id=28411 Summary: Output polling causes latency every 10 seconds Product: DRI Version: DRI CVS Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: major Priority: medium Component: General AssignedTo: dri-devel at lists.freedesktop.org ReportedBy: marius.groeger at web.de The output polling in drm_crtc_helper.c added in this commit: commit eb1f8e4f3be898df808e2dfc131099f5831d491d Author: Dave Airlie Date: Fri May 7 06:42:51 2010 + causes drm latencies every 10 seconds. I observed them in mythtv. Apparently the dev->mode_config.mutex is held for too long; if I remove the mutex_lock/unlock for testing purposes the latencies are gone. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Flickering screen in Neverball on drm-radeon-testing
On Jun 4, 2010, at 7:27 PM, Michel D?nzer wrote: > On Mit, 2010-06-02 at 16:38 +0200, Mario Kleiner wrote: > > I think your analysis is spot on. > > The ideal solution would probably be to make the kernel block in the > command stream (CS) submission ioctl if the CS renders to (and > from?) a > buffer object (BO) which is involved in a pending swap. > > Meanwhile, the attached hacks for xf86-video-ati and Mesa seem to help > here, YMMV. I think that is what the Intel drm does. Your dri2-flicker-mesa.diff patch makes sense to me as a newbie with limited understanding. If this ends up calling DRI2GetBuffers... in the server, it will block in DRI2ThrottleClient until the swap completes. I doubt that the dri2-flicker-xf86-video-ati.diff patch has a real effect? For a regular glXSwapBuffers() command, the code-path isn't taken, where you placed the DRI2BlockClient() call, so it can't have an effect. If it would be taken as part of some call to the new glXSwapBuffersMscOML() function, it would likely do bad things(tm) which are against the purpose of this new extension. -mario * Mario Kleiner Max Planck Institute for Biological Cybernetics Spemannstr. 38 72076 Tuebingen Germany e-mail: mario.kleiner at tuebingen.mpg.de office: +49 (0)7071/601-1623 fax:+49 (0)7071/601-616 www:http://www.kyb.tuebingen.mpg.de/~kleinerm * "For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled." (Richard Feynman)
[Bug 28342] When cold-booting gfx is messed up with latest drm-radeon-testing kernel
https://bugs.freedesktop.org/show_bug.cgi?id=28342 --- Comment #30 from Marc 2010-06-06 09:00:05 PDT --- last patch also fixes X startup here, but now I'm hit by https://bugs.freedesktop.org/show_bug.cgi?id=28381 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28375] [KMS][RV620] Lockup on PM reclock
https://bugs.freedesktop.org/show_bug.cgi?id=28375 --- Comment #18 from Rafa? Mi?ecki 2010-06-06 05:43:20 PDT --- Patch posted: [PATCH V3] drm/radeon/kms/r600+: use voltage from requested clock mode http://lists.freedesktop.org/archives/dri-devel/2010-June/001139.html -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28375] [KMS][RV620] Lockup on PM reclock
https://bugs.freedesktop.org/show_bug.cgi?id=28375 --- Comment #17 from Rafa? Mi?ecki 2010-06-06 03:34:55 PDT --- Created an attachment (id=36082) --> (https://bugs.freedesktop.org/attachment.cgi?id=36082) dmesg with less revoltaging patch applied There you have some results of my debugging tries. Voltage was changed at 86.386427 and it didn't cause any problem. When starting glxgears I expected voltage to be raised but it wasn't the case. Maybe this is the problem? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 28375] [KMS][RV620] Lockup on PM reclock
https://bugs.freedesktop.org/show_bug.cgi?id=28375 --- Comment #16 from Rafa? Mi?ecki 2010-06-06 03:31:16 PDT --- Created an attachment (id=36081) --> (https://bugs.freedesktop.org/attachment.cgi?id=36081) less revoltaging and more deubgging messages -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
Re: Flickering screen in Neverball on drm-radeon-testing
On Jun 4, 2010, at 7:27 PM, Michel Dänzer wrote: On Mit, 2010-06-02 at 16:38 +0200, Mario Kleiner wrote: I think your analysis is spot on. The ideal solution would probably be to make the kernel block in the command stream (CS) submission ioctl if the CS renders to (and from?) a buffer object (BO) which is involved in a pending swap. Meanwhile, the attached hacks for xf86-video-ati and Mesa seem to help here, YMMV. I think that is what the Intel drm does. Your dri2-flicker-mesa.diff patch makes sense to me as a newbie with limited understanding. If this ends up calling DRI2GetBuffers... in the server, it will block in DRI2ThrottleClient until the swap completes. I doubt that the dri2-flicker-xf86-video-ati.diff patch has a real effect? For a regular glXSwapBuffers() command, the code-path isn't taken, where you placed the DRI2BlockClient() call, so it can't have an effect. If it would be taken as part of some call to the new glXSwapBuffersMscOML() function, it would likely do bad things(tm) which are against the purpose of this new extension. -mario * Mario Kleiner Max Planck Institute for Biological Cybernetics Spemannstr. 38 72076 Tuebingen Germany e-mail: mario.klei...@tuebingen.mpg.de office: +49 (0)7071/601-1623 fax:+49 (0)7071/601-616 www:http://www.kyb.tuebingen.mpg.de/~kleinerm * For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled. (Richard Feynman) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: regression: 2.6.35-rc1 hangs on i865G with KMS
On Sun, Jun 6, 2010 at 6:28 AM, Ondrej Zary li...@rainbow-software.org wrote: On Saturday 05 June 2010 02:23:27 Eric Anholt wrote: On Fri, 4 Jun 2010 22:01:28 +0200, Ondrej Zary li...@rainbow-software.org wrote: Hello, I'm testing 2.6.35-rc1 kernel on Asus P4P800-VM (i865G chipset). After loading i915 module, the screen goes blank and the kernel hangs completely (same with 2.6.35-rc1-git2). This does not happen with i915.modeset=0 parameter. This problem does not appear with 2.6.34. Is this a known regression? Not known as far as I know -- we'd enjoy a bisect with a bug report on bugs.freedesktop.org. Can you try the attached patch? Dave. 0001-drm-i915-fix-oops-on-single-crtc-devices.patch Description: Binary data ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Glitch in newer drm-next/drm-radeon-testing
Am 04.06.2010 17:17, schrieb Alex Deucher: 2010/6/4 Marius Grögermarius.groe...@googlemail.com: Alex Deucher schrieb: 2010/6/4 Marius Grögermarius.groe...@googlemail.com: Hi All, Michel Dänzer schrieb: On Mit, 2010-06-02 at 08:07 +0200, Marius Gröger wrote: Hello All, I'm trying the top-of-trunk drm-2.6 trees (both drm-next and drm-radeon-testing) with my Radeon HD 3200 GPU over HDMI. The primary application is mythtv which uses DRM syncing for the frame syncronisation. Now, with the exact same userland software I noticed the introduction of sync gliches in the May-timeframe. The drm-radeon-testing on May 9 was still ok, but both drm-next and drm-radeon-testing at the end of May showed that glitch: every couple of seconds there's a very visual hickup, especially in scroll texts. Apologies for such an unspecific description, and for what almost seems like a support request for MythTV. I wouldn't post here if I were not 100% sure it must be related with the recent drm changes. Note that the DRM APIs are intended for use by userspace components of graphics drivers / API libraries, not applications directly. MythTV shouldn't use the DRM directly for synchronization but rather use GLX synchronization APIs. [...] Any chance you can bisect the problematic commit? I did a second attempt at bisecting and now I'm confident it is this commit which broke my real-time performance in mythtv: commit eb1f8e4f3be898df808e2dfc131099f5831d491d Author: Dave Airlie airl...@redhat.com Date: Fri May 7 06:42:51 2010 + drm/fbdev: rework output polling to be back in the core. (v4) Having found the commit is the good news. The bad news is that this commit is rather large, so again I'd be depended on the experts around here to isolate what's going on. Dave, would you mind giving a hand as well as the author of this commit? Thanks Marius ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] drm/i915: Propagate error from drm_fb_helper_init().
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/i915/intel_fb.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_fb.c b/drivers/gpu/drm/i915/intel_fb.c
index dfbb0c6..c3c5052 100644
--- a/drivers/gpu/drm/i915/intel_fb.c
+++ b/drivers/gpu/drm/i915/intel_fb.c
@@ -245,6 +245,7 @@ int intel_fbdev_init(struct drm_device *dev)
{
struct intel_fbdev *ifbdev;
drm_i915_private_t *dev_priv = dev-dev_private;
+ int ret;
ifbdev = kzalloc(sizeof(struct intel_fbdev), GFP_KERNEL);
if (!ifbdev)
@@ -253,8 +254,13 @@ int intel_fbdev_init(struct drm_device *dev)
dev_priv-fbdev = ifbdev;
ifbdev-helper.funcs = intel_fb_helper_funcs;
- drm_fb_helper_init(dev, ifbdev-helper, dev_priv-num_pipe,
- INTELFB_CONN_LIMIT);
+ ret = drm_fb_helper_init(dev, ifbdev-helper,
+dev_priv-num_pipe,
+INTELFB_CONN_LIMIT);
+ if (ret) {
+ kfree(ifbdev);
+ return ret;
+ }
drm_fb_helper_single_add_all_connectors(ifbdev-helper);
drm_fb_helper_initial_config(ifbdev-helper, 32);
--
1.7.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/nouveau: Propagate error from drm_fb_helper_init()
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
index fd4a2df..c9a4a0d 100644
--- a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
+++ b/drivers/gpu/drm/nouveau/nouveau_fbcon.c
@@ -377,6 +377,7 @@ int nouveau_fbcon_init(struct drm_device *dev)
{
struct drm_nouveau_private *dev_priv = dev-dev_private;
struct nouveau_fbdev *nfbdev;
+ int ret;
nfbdev = kzalloc(sizeof(struct nouveau_fbdev), GFP_KERNEL);
if (!nfbdev)
@@ -386,7 +387,12 @@ int nouveau_fbcon_init(struct drm_device *dev)
dev_priv-nfbdev = nfbdev;
nfbdev-helper.funcs = nouveau_fbcon_helper_funcs;
- drm_fb_helper_init(dev, nfbdev-helper, 2, 4);
+ ret = drm_fb_helper_init(dev, nfbdev-helper, 2, 4);
+ if (ret) {
+ kfree(nfbdev);
+ return ret;
+ }
+
drm_fb_helper_single_add_all_connectors(nfbdev-helper);
drm_fb_helper_initial_config(nfbdev-helper, 32);
return 0;
--
1.7.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/radeon: Propagate error from drm_fb_helper_init()
Signed-off-by: Chris Wilson ch...@chris-wilson.co.uk
---
drivers/gpu/drm/radeon/radeon_fb.c | 12 +---
1 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_fb.c
b/drivers/gpu/drm/radeon/radeon_fb.c
index e192acf..dc1634b 100644
--- a/drivers/gpu/drm/radeon/radeon_fb.c
+++ b/drivers/gpu/drm/radeon/radeon_fb.c
@@ -363,6 +363,7 @@ int radeon_fbdev_init(struct radeon_device *rdev)
{
struct radeon_fbdev *rfbdev;
int bpp_sel = 32;
+ int ret;
/* select 8 bpp console on RN50 or 16MB cards */
if (ASIC_IS_RN50(rdev) || rdev-mc.real_vram_size = (32*1024*1024))
@@ -376,9 +377,14 @@ int radeon_fbdev_init(struct radeon_device *rdev)
rdev-mode_info.rfbdev = rfbdev;
rfbdev-helper.funcs = radeon_fb_helper_funcs;
- drm_fb_helper_init(rdev-ddev, rfbdev-helper,
- rdev-num_crtc,
- RADEONFB_CONN_LIMIT);
+ ret = drm_fb_helper_init(rdev-ddev, rfbdev-helper,
+rdev-num_crtc,
+RADEONFB_CONN_LIMIT);
+ if (ret) {
+ kfree(rfbdev);
+ return ret;
+ }
+
drm_fb_helper_single_add_all_connectors(rfbdev-helper);
drm_fb_helper_initial_config(rfbdev-helper, bpp_sel);
return 0;
--
1.7.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: regression: 2.6.35-rc1 hangs on i865G with KMS
On Sunday 06 June 2010 11:04:44 Dave Airlie wrote: On Sun, Jun 6, 2010 at 6:28 AM, Ondrej Zary li...@rainbow-software.org wrote: On Saturday 05 June 2010 02:23:27 Eric Anholt wrote: On Fri, 4 Jun 2010 22:01:28 +0200, Ondrej Zary li...@rainbow-software.org wrote: Hello, I'm testing 2.6.35-rc1 kernel on Asus P4P800-VM (i865G chipset). After loading i915 module, the screen goes blank and the kernel hangs completely (same with 2.6.35-rc1-git2). This does not happen with i915.modeset=0 parameter. This problem does not appear with 2.6.34. Is this a known regression? Not known as far as I know -- we'd enjoy a bisect with a bug report on bugs.freedesktop.org. Can you try the attached patch? Thanks, applied it on 2.6.35-rc2 and it seems to work fine. -- Ondrej Zary ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28375] [KMS][RV620] Lockup on PM reclock
https://bugs.freedesktop.org/show_bug.cgi?id=28375 --- Comment #16 from Rafał Miłecki zaj...@gmail.com 2010-06-06 03:31:16 PDT --- Created an attachment (id=36081) -- (https://bugs.freedesktop.org/attachment.cgi?id=36081) less revoltaging and more deubgging messages -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28375] [KMS][RV620] Lockup on PM reclock
https://bugs.freedesktop.org/show_bug.cgi?id=28375 --- Comment #17 from Rafał Miłecki zaj...@gmail.com 2010-06-06 03:34:55 PDT --- Created an attachment (id=36082) -- (https://bugs.freedesktop.org/attachment.cgi?id=36082) dmesg with less revoltaging patch applied There you have some results of my debugging tries. Voltage was changed at 86.386427 and it didn't cause any problem. When starting glxgears I expected voltage to be raised but it wasn't the case. Maybe this is the problem? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V2] drm/radeon/kms/r600+: use voltage from requested clock mode
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
This fixes FDO bug #28375, must have for .35
V2: Fix on RV770+ as well. All other chipsets have only one clock mode per
state.
---
drivers/gpu/drm/radeon/r600.c |8
drivers/gpu/drm/radeon/rv770.c |7 ---
2 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index d84d7cf..94c27d0 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -475,13 +475,13 @@ void r600_pm_init_profile(struct radeon_device *rdev)
void r600_pm_misc(struct radeon_device *rdev)
{
- int requested_index = rdev-pm.requested_power_state_index;
- struct radeon_power_state *ps = rdev-pm.power_state[requested_index];
- struct radeon_voltage *voltage = ps-clock_info[0].voltage;
+ int req_ps_idx = rdev-pm.requested_power_state_index;
+ int req_cm_idx = rdev-pm.requested_clock_mode_index;
+ struct radeon_power_state *ps = rdev-pm.power_state[req_ps_idx];
+ struct radeon_voltage *voltage = ps-clock_info[req_cm_idx].voltage;
if ((voltage-type == VOLTAGE_SW) voltage-voltage)
radeon_atom_set_voltage(rdev, voltage-voltage);
-
}
bool r600_gui_idle(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 5f76938..f002848 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -44,9 +44,10 @@ void rv770_fini(struct radeon_device *rdev);
void rv770_pm_misc(struct radeon_device *rdev)
{
- int requested_index = rdev-pm.requested_power_state_index;
- struct radeon_power_state *ps = rdev-pm.power_state[requested_index];
- struct radeon_voltage *voltage = ps-clock_info[0].voltage;
+ int req_ps_idx = rdev-pm.requested_power_state_index;
+ int req_cm_idx = rdev-pm.requested_clock_mode_index;
+ struct radeon_power_state *ps = rdev-pm.power_state[req_ps_idx];
+ struct radeon_voltage *voltage = ps-clock_info[req_cm_idx].voltage;
if ((voltage-type == VOLTAGE_SW) voltage-voltage)
radeon_atom_set_voltage(rdev, voltage-voltage);
--
1.6.4.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH V3] drm/radeon/kms/r600+: use voltage from requested clock mode
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
This fixes FDO bug #28375, it's kind of regression, so quite important to have
it for .35.
V2: Fix on RV770+ as well. All other chipsets have only one clock mode per
state.
V3: I'm out of luck today. Grepped for voltage in r*.c and missed evergreen.
---
drivers/gpu/drm/radeon/evergreen.c |7 ---
drivers/gpu/drm/radeon/r600.c |8
drivers/gpu/drm/radeon/rv770.c |7 ---
3 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 69c4b27..174f718 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -41,9 +41,10 @@ void evergreen_fini(struct radeon_device *rdev);
void evergreen_pm_misc(struct radeon_device *rdev)
{
- int requested_index = rdev-pm.requested_power_state_index;
- struct radeon_power_state *ps = rdev-pm.power_state[requested_index];
- struct radeon_voltage *voltage = ps-clock_info[0].voltage;
+ int req_ps_idx = rdev-pm.requested_power_state_index;
+ int req_cm_idx = rdev-pm.requested_clock_mode_index;
+ struct radeon_power_state *ps = rdev-pm.power_state[req_ps_idx];
+ struct radeon_voltage *voltage = ps-clock_info[req_cm_idx].voltage;
if ((voltage-type == VOLTAGE_SW) voltage-voltage)
radeon_atom_set_voltage(rdev, voltage-voltage);
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index d84d7cf..94c27d0 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -475,13 +475,13 @@ void r600_pm_init_profile(struct radeon_device *rdev)
void r600_pm_misc(struct radeon_device *rdev)
{
- int requested_index = rdev-pm.requested_power_state_index;
- struct radeon_power_state *ps = rdev-pm.power_state[requested_index];
- struct radeon_voltage *voltage = ps-clock_info[0].voltage;
+ int req_ps_idx = rdev-pm.requested_power_state_index;
+ int req_cm_idx = rdev-pm.requested_clock_mode_index;
+ struct radeon_power_state *ps = rdev-pm.power_state[req_ps_idx];
+ struct radeon_voltage *voltage = ps-clock_info[req_cm_idx].voltage;
if ((voltage-type == VOLTAGE_SW) voltage-voltage)
radeon_atom_set_voltage(rdev, voltage-voltage);
-
}
bool r600_gui_idle(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 5f76938..f002848 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -44,9 +44,10 @@ void rv770_fini(struct radeon_device *rdev);
void rv770_pm_misc(struct radeon_device *rdev)
{
- int requested_index = rdev-pm.requested_power_state_index;
- struct radeon_power_state *ps = rdev-pm.power_state[requested_index];
- struct radeon_voltage *voltage = ps-clock_info[0].voltage;
+ int req_ps_idx = rdev-pm.requested_power_state_index;
+ int req_cm_idx = rdev-pm.requested_clock_mode_index;
+ struct radeon_power_state *ps = rdev-pm.power_state[req_ps_idx];
+ struct radeon_voltage *voltage = ps-clock_info[req_cm_idx].voltage;
if ((voltage-type == VOLTAGE_SW) voltage-voltage)
radeon_atom_set_voltage(rdev, voltage-voltage);
--
1.6.4.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/radeon/kms/r600+: do not set the same voltage as current one
We have similar tracking for engine and memory. We could think about some
solution for older GPUs as well, however there are not strict voltage values
set.
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/gpu/drm/radeon/evergreen.c |8 ++--
drivers/gpu/drm/radeon/r600.c |8 ++--
drivers/gpu/drm/radeon/radeon.h|1 +
drivers/gpu/drm/radeon/radeon_pm.c |2 ++
drivers/gpu/drm/radeon/rv770.c |8 ++--
5 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 174f718..c444808 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -46,8 +46,12 @@ void evergreen_pm_misc(struct radeon_device *rdev)
struct radeon_power_state *ps = rdev-pm.power_state[req_ps_idx];
struct radeon_voltage *voltage = ps-clock_info[req_cm_idx].voltage;
- if ((voltage-type == VOLTAGE_SW) voltage-voltage)
- radeon_atom_set_voltage(rdev, voltage-voltage);
+ if (voltage-voltage != rdev-pm.current_vddc) {
+ if ((voltage-type == VOLTAGE_SW) voltage-voltage) {
+ radeon_atom_set_voltage(rdev, voltage-voltage);
+ rdev-pm.current_vddc = voltage-voltage;
+ }
+ }
}
void evergreen_pm_prepare(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 94c27d0..e49bebe 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -480,8 +480,12 @@ void r600_pm_misc(struct radeon_device *rdev)
struct radeon_power_state *ps = rdev-pm.power_state[req_ps_idx];
struct radeon_voltage *voltage = ps-clock_info[req_cm_idx].voltage;
- if ((voltage-type == VOLTAGE_SW) voltage-voltage)
- radeon_atom_set_voltage(rdev, voltage-voltage);
+ if (voltage-voltage != rdev-pm.current_vddc) {
+ if ((voltage-type == VOLTAGE_SW) voltage-voltage) {
+ radeon_atom_set_voltage(rdev, voltage-voltage);
+ rdev-pm.current_vddc = voltage-voltage;
+ }
+ }
}
bool r600_gui_idle(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 084221d..04bc867 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -745,6 +745,7 @@ struct radeon_pm {
int default_power_state_index;
u32 current_sclk;
u32 current_mclk;
+ u32 current_vddc;
struct radeon_i2c_chan *i2c_bus;
/* selected pm method */
enum radeon_pm_method pm_method;
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 0228126..a046fe7 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -381,6 +381,7 @@ void radeon_pm_suspend(struct radeon_device *rdev)
rdev-pm.current_clock_mode_index = -1;
rdev-pm.current_sclk = 0;
rdev-pm.current_mclk = 0;
+ rdev-pm.current_vddc = 0;
mutex_unlock(rdev-pm.mutex);
}
@@ -400,6 +401,7 @@ int radeon_pm_init(struct radeon_device *rdev)
rdev-pm.dynpm_can_downclock = true;
rdev-pm.current_sclk = 0;
rdev-pm.current_mclk = 0;
+ rdev-pm.current_vddc = 0;
if (rdev-bios) {
if (rdev-is_atom_bios)
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index f002848..f310fa8 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -49,8 +49,12 @@ void rv770_pm_misc(struct radeon_device *rdev)
struct radeon_power_state *ps = rdev-pm.power_state[req_ps_idx];
struct radeon_voltage *voltage = ps-clock_info[req_cm_idx].voltage;
- if ((voltage-type == VOLTAGE_SW) voltage-voltage)
- radeon_atom_set_voltage(rdev, voltage-voltage);
+ if (voltage-voltage != rdev-pm.current_vddc) {
+ if ((voltage-type == VOLTAGE_SW) voltage-voltage) {
+ radeon_atom_set_voltage(rdev, voltage-voltage);
+ rdev-pm.current_vddc = voltage-voltage;
+ }
+ }
}
/*
--
1.6.4.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
2.6.35-rc2 completely hosed on intel gfx?
Dear everyone,
(please cc)
I just switched from 2.6.35-rc1 to rc2 and that hosed several things,
all seemingly related to intel graphics card driver:
- suspend suddenly hangs completely on switch, no traces found, not
even sysrq was working
- X often (not 100%) hangs wihth a fix cursor (not blinking) on the
to left corner, I got a stack trace in my syslog for that:
general protection fault: [#1] PREEMPT SMP
last sysfs file: /sys/devices/virtual/backlight/acpi_video0/uevent
CPU 0
Modules linked in: sco bnep rfcomm l2cap crc16 hso binfmt_misc dm_crypt dm_mod
isofs btrfs zlib_deflate crc32c libcrc32c vfat fat fuse vboxdrv loop uinput
snd_hda_codec_realtek arc4 snd_hda_intel iwlagn snd_hda_codec snd_hwdep iwlcore
snd_pcm_oss snd_mixer_oss snd_pcm snd_seq_dummy snd_seq_oss snd_seq_midi
snd_rawmidi snd_seq_midi_event snd_seq mac80211 btusb firewire_ohci snd_timer
snd_seq_device firewire_core bluetooth snd cfg80211 sony_laptop tpm_infineon
crc_itu_t rfkill joydev soundcore snd_page_alloc
Pid: 2758, comm: Xorg Not tainted 2.6.35-rc2 #14 VAIO/VGN-Z11VN_B
RIP: 0010:[810efe19] [810efe19]
sysfs_follow_link+0x57/0x170
RSP: 0018:88012fd33df8 EFLAGS: 00010286
RAX: 88012fd33de8 RBX: 88013efa3730 RCX: 88012fd33fd8
RDX: 8800 RSI: RDI: 816282f0
RBP: 88012fd33e38 R08: R09: 0002
R10: 0281 R11: 0002e8c5 R12: 0720072007200720
R13: 88013eea2d20 R14: 88012fd57000 R15: 88012fd57000
FS: 7fa9c98cb700() GS:88000180() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 03d75048 CR3: 00012fd22000 CR4: 06f0
DR0: DR1: DR2:
DR3: DR6: 0ff0 DR7: 0400
Process Xorg (pid: 2758, threadinfo 88012fd32000, task 8801333cb990)
Stack:
03d5e200 88012fd33e58 88012fd33e28 88013ba17900
0 7fff82211140 88012fd33e58 7fff82211140 03d5e9cb
0 88012fd33f18 810ad2f4 88012fd33eb8 0400
Call Trace:
[810ad2f4] generic_readlink+0x40/0xa3
[81038179] ? current_fs_time+0x22/0x29
[810ba3ee] ? mnt_drop_write+0x43/0x4e
[810b67d8] ? touch_atime+0x10a/0x125
[810a8160] sys_readlinkat+0x63/0x7f
[810a8192] sys_readlink+0x16/0x18
[81001feb] system_call_fastpath+0x16/0x1b
Code: ff 0f 84 1d 01 00 00 48 8b 83 98 00 00 00 48 c7 c7 f0 82 62 81 48 8b 58
08 4c 8b 68 28 4d 89 fe e8 d7 c2 27 00 eb 34 4d 8b 65 08 49 8b 44 24 08 4c 39
e3 74 0a 48 85 c0 74 05 49 89 c4 eb ec 4c
RIP [810efe19] sysfs_follow_link+0x57/0x170
RSP 88012fd33df8
---[ end trace da2e388f90243d4a ]---
2.6.35-rc1 says about intel:
[0.517442] agpgart-intel :00:00.0: Intel GM45 Chipset
[0.519672] agpgart-intel :00:00.0: detected 65532K stolen memory
[0.540521] agpgart-intel :00:00.0: AGP aperture is 256M @ 0xc000
[2.537531] fb0: inteldrmfb frame buffer device
PLese let me know if you need more information, thanks a lot
Best wishes
Norbert
Norbert Preiningprein...@{jaist.ac.jp, logic.at, debian.org}
JAIST, Japan TeX Live Debian Developer
DSA: 0x09C5B094 fp: 14DF 2E6C 0307 BE6D AD76 A9C0 D2BF 4AA3 09C5 B094
QUABBS (pl.n.)
The substances which emerge when you squeeze a blackhead.
--- Douglas Adams, The Meaning of Liff
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Glitch in newer drm-next/drm-radeon-testing
Apologies for such an unspecific description, and for what almost seems like a support request for MythTV. I wouldn't post here if I were not 100% sure it must be related with the recent drm changes. Note that the DRM APIs are intended for use by userspace components of graphics drivers / API libraries, not applications directly. MythTV shouldn't use the DRM directly for synchronization but rather use GLX synchronization APIs. Tho not the case for MythTV on a embedded device requiring apps to use GLX wuld be to heavy. I would agree libdrm should be used. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
What happen to drm-fbdev1 branch?
Sorry I have been away. It looks like the drm-fbdev-fix branch has not been merged and it has been abandoned. I tested it on both my setups at home and it worked very well. Will this branch be merged or worked on more? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Glitch in newer drm-next/drm-radeon-testing
On Mon, Jun 7, 2010 at 3:52 AM, Marius Gröger marius.groe...@googlemail.com wrote: Am 06.06.2010 18:47, schrieb James Simmons: Apologies for such an unspecific description, and for what almost seems like a support request for MythTV. I wouldn't post here if I were not 100% sure it must be related with the recent drm changes. Note that the DRM APIs are intended for use by userspace components of graphics drivers / API libraries, not applications directly. MythTV shouldn't use the DRM directly for synchronization but rather use GLX synchronization APIs. Tho not the case for MythTV on a embedded device requiring apps to use GLX wuld be to heavy. I would agree libdrm should be used. I have found the cause for the glitch and just filed http://bugs.freedesktop.org/show_bug.cgi?id=28411. Okay I can see the problem, now I have to think of a good solution, I probably need to break down the locking a bit further which is a bit messy. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: What happen to drm-fbdev1 branch?
On Mon, Jun 7, 2010 at 3:23 AM, James Simmons jsimm...@infradead.org wrote: Sorry I have been away. It looks like the drm-fbdev-fix branch has not been merged and it has been abandoned. I tested it on both my setups at home and it worked very well. Will this branch be merged or worked on more? It should have all been merged into Linus, probably not with that name, 7fff400be6fbf64f10abca9939718aaf1d61c255 drm-fbdev-cleanup. I had to rebase and also had some different ideas on where polling should be, Since then polling has shown up another issue so I need to rethink the locking a bit more. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH V3] drm/radeon/kms/r600+: use voltage from requested clock mode
2010/6/6 Rafał Miłecki zaj...@gmail.com:
Signed-off-by: Rafał Miłecki zaj...@gmail.com
Good catch.
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
This fixes FDO bug #28375, it's kind of regression, so quite important to have
it for .35.
V2: Fix on RV770+ as well. All other chipsets have only one clock mode per
state.
V3: I'm out of luck today. Grepped for voltage in r*.c and missed evergreen.
---
drivers/gpu/drm/radeon/evergreen.c | 7 ---
drivers/gpu/drm/radeon/r600.c | 8
drivers/gpu/drm/radeon/rv770.c | 7 ---
3 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 69c4b27..174f718 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -41,9 +41,10 @@ void evergreen_fini(struct radeon_device *rdev);
void evergreen_pm_misc(struct radeon_device *rdev)
{
- int requested_index = rdev-pm.requested_power_state_index;
- struct radeon_power_state *ps =
rdev-pm.power_state[requested_index];
- struct radeon_voltage *voltage = ps-clock_info[0].voltage;
+ int req_ps_idx = rdev-pm.requested_power_state_index;
+ int req_cm_idx = rdev-pm.requested_clock_mode_index;
+ struct radeon_power_state *ps = rdev-pm.power_state[req_ps_idx];
+ struct radeon_voltage *voltage = ps-clock_info[req_cm_idx].voltage;
if ((voltage-type == VOLTAGE_SW) voltage-voltage)
radeon_atom_set_voltage(rdev, voltage-voltage);
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index d84d7cf..94c27d0 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -475,13 +475,13 @@ void r600_pm_init_profile(struct radeon_device *rdev)
void r600_pm_misc(struct radeon_device *rdev)
{
- int requested_index = rdev-pm.requested_power_state_index;
- struct radeon_power_state *ps =
rdev-pm.power_state[requested_index];
- struct radeon_voltage *voltage = ps-clock_info[0].voltage;
+ int req_ps_idx = rdev-pm.requested_power_state_index;
+ int req_cm_idx = rdev-pm.requested_clock_mode_index;
+ struct radeon_power_state *ps = rdev-pm.power_state[req_ps_idx];
+ struct radeon_voltage *voltage = ps-clock_info[req_cm_idx].voltage;
if ((voltage-type == VOLTAGE_SW) voltage-voltage)
radeon_atom_set_voltage(rdev, voltage-voltage);
-
}
bool r600_gui_idle(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index 5f76938..f002848 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -44,9 +44,10 @@ void rv770_fini(struct radeon_device *rdev);
void rv770_pm_misc(struct radeon_device *rdev)
{
- int requested_index = rdev-pm.requested_power_state_index;
- struct radeon_power_state *ps =
rdev-pm.power_state[requested_index];
- struct radeon_voltage *voltage = ps-clock_info[0].voltage;
+ int req_ps_idx = rdev-pm.requested_power_state_index;
+ int req_cm_idx = rdev-pm.requested_clock_mode_index;
+ struct radeon_power_state *ps = rdev-pm.power_state[req_ps_idx];
+ struct radeon_voltage *voltage = ps-clock_info[req_cm_idx].voltage;
if ((voltage-type == VOLTAGE_SW) voltage-voltage)
radeon_atom_set_voltage(rdev, voltage-voltage);
--
1.6.4.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm/radeon/kms/r600+: do not set the same voltage as current one
2010/6/6 Rafał Miłecki zaj...@gmail.com:
We have similar tracking for engine and memory. We could think about some
solution for older GPUs as well, however there are not strict voltage values
set.
Signed-off-by: Rafał Miłecki zaj...@gmail.com
I actually had almost the exact same patch in my tree (broken out from
my voltage step patch), I just hadn't gotten around to sending it.
Mine is against drm-linus and has the default voltage level set. See
attached.
Alex
---
drivers/gpu/drm/radeon/evergreen.c | 8 ++--
drivers/gpu/drm/radeon/r600.c | 8 ++--
drivers/gpu/drm/radeon/radeon.h | 1 +
drivers/gpu/drm/radeon/radeon_pm.c | 2 ++
drivers/gpu/drm/radeon/rv770.c | 8 ++--
5 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 174f718..c444808 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -46,8 +46,12 @@ void evergreen_pm_misc(struct radeon_device *rdev)
struct radeon_power_state *ps = rdev-pm.power_state[req_ps_idx];
struct radeon_voltage *voltage = ps-clock_info[req_cm_idx].voltage;
- if ((voltage-type == VOLTAGE_SW) voltage-voltage)
- radeon_atom_set_voltage(rdev, voltage-voltage);
+ if (voltage-voltage != rdev-pm.current_vddc) {
+ if ((voltage-type == VOLTAGE_SW) voltage-voltage) {
+ radeon_atom_set_voltage(rdev, voltage-voltage);
+ rdev-pm.current_vddc = voltage-voltage;
+ }
+ }
}
void evergreen_pm_prepare(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 94c27d0..e49bebe 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -480,8 +480,12 @@ void r600_pm_misc(struct radeon_device *rdev)
struct radeon_power_state *ps = rdev-pm.power_state[req_ps_idx];
struct radeon_voltage *voltage = ps-clock_info[req_cm_idx].voltage;
- if ((voltage-type == VOLTAGE_SW) voltage-voltage)
- radeon_atom_set_voltage(rdev, voltage-voltage);
+ if (voltage-voltage != rdev-pm.current_vddc) {
+ if ((voltage-type == VOLTAGE_SW) voltage-voltage) {
+ radeon_atom_set_voltage(rdev, voltage-voltage);
+ rdev-pm.current_vddc = voltage-voltage;
+ }
+ }
}
bool r600_gui_idle(struct radeon_device *rdev)
diff --git a/drivers/gpu/drm/radeon/radeon.h b/drivers/gpu/drm/radeon/radeon.h
index 084221d..04bc867 100644
--- a/drivers/gpu/drm/radeon/radeon.h
+++ b/drivers/gpu/drm/radeon/radeon.h
@@ -745,6 +745,7 @@ struct radeon_pm {
int default_power_state_index;
u32 current_sclk;
u32 current_mclk;
+ u32 current_vddc;
struct radeon_i2c_chan *i2c_bus;
/* selected pm method */
enum radeon_pm_method pm_method;
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 0228126..a046fe7 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -381,6 +381,7 @@ void radeon_pm_suspend(struct radeon_device *rdev)
rdev-pm.current_clock_mode_index = -1;
rdev-pm.current_sclk = 0;
rdev-pm.current_mclk = 0;
+ rdev-pm.current_vddc = 0;
mutex_unlock(rdev-pm.mutex);
}
@@ -400,6 +401,7 @@ int radeon_pm_init(struct radeon_device *rdev)
rdev-pm.dynpm_can_downclock = true;
rdev-pm.current_sclk = 0;
rdev-pm.current_mclk = 0;
+ rdev-pm.current_vddc = 0;
if (rdev-bios) {
if (rdev-is_atom_bios)
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index f002848..f310fa8 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -49,8 +49,12 @@ void rv770_pm_misc(struct radeon_device *rdev)
struct radeon_power_state *ps = rdev-pm.power_state[req_ps_idx];
struct radeon_voltage *voltage = ps-clock_info[req_cm_idx].voltage;
- if ((voltage-type == VOLTAGE_SW) voltage-voltage)
- radeon_atom_set_voltage(rdev, voltage-voltage);
+ if (voltage-voltage != rdev-pm.current_vddc) {
+ if ((voltage-type == VOLTAGE_SW) voltage-voltage) {
+ radeon_atom_set_voltage(rdev, voltage-voltage);
+ rdev-pm.current_vddc = voltage-voltage;
+ }
+ }
}
/*
--
1.6.4.2
From 043d35d6dca6f9c967bd9fc70abd47516e0649ad Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Fri, 4 Jun 2010 12:45:22 -0400
Subject: [PATCH] drm/radeon/kms/pm: track current voltage
track the current voltage level and avoid setting it
if the requested voltage is already
Re: [PATCH 2/2] drm/radeon/kms: add trivial debugging for voltage
2010/6/6 Rafał Miłecki zaj...@gmail.com:
Signed-off-by: Rafał Miłecki zaj...@gmail.com
Looks good.
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/evergreen.c | 1 +
drivers/gpu/drm/radeon/r600.c | 1 +
drivers/gpu/drm/radeon/radeon_pm.c | 2 ++
drivers/gpu/drm/radeon/rv770.c | 1 +
4 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index c444808..ff21c97 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -50,6 +50,7 @@ void evergreen_pm_misc(struct radeon_device *rdev)
if ((voltage-type == VOLTAGE_SW) voltage-voltage) {
radeon_atom_set_voltage(rdev, voltage-voltage);
rdev-pm.current_vddc = voltage-voltage;
+ DRM_DEBUG(Setting: v: %d\n, voltage-voltage);
}
}
}
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index e49bebe..1bcf22c 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -484,6 +484,7 @@ void r600_pm_misc(struct radeon_device *rdev)
if ((voltage-type == VOLTAGE_SW) voltage-voltage) {
radeon_atom_set_voltage(rdev, voltage-voltage);
rdev-pm.current_vddc = voltage-voltage;
+ DRM_DEBUG(Setting: v: %d\n, voltage-voltage);
}
}
}
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index a046fe7..31da562 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -707,6 +707,8 @@ static int radeon_debugfs_pm_info(struct seq_file *m,
void *data)
seq_printf(m, default memory clock: %u0 kHz\n,
rdev-clock.default_mclk);
if (rdev-asic-get_memory_clock)
seq_printf(m, current memory clock: %u0 kHz\n,
radeon_get_memory_clock(rdev));
+ if (rdev-pm.current_vddc)
+ seq_printf(m, voltage: %u mV\n, rdev-pm.current_vddc);
if (rdev-asic-get_pcie_lanes)
seq_printf(m, PCIE lanes: %d\n, radeon_get_pcie_lanes(rdev));
diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c
index f310fa8..fd9bf4e 100644
--- a/drivers/gpu/drm/radeon/rv770.c
+++ b/drivers/gpu/drm/radeon/rv770.c
@@ -53,6 +53,7 @@ void rv770_pm_misc(struct radeon_device *rdev)
if ((voltage-type == VOLTAGE_SW) voltage-voltage) {
radeon_atom_set_voltage(rdev, voltage-voltage);
rdev-pm.current_vddc = voltage-voltage;
+ DRM_DEBUG(Setting: v: %d\n, voltage-voltage);
}
}
}
--
1.6.4.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms/pm: resurrect printing power states
2010/6/6 Rafał Miłecki zaj...@gmail.com:
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
Alex you dropped this in rework power management. Did you have some reason
for doing that? Or was that just accident?
It was to avoid spamming the kernel log. It should be fine if it's
debug output.
At some point we really ought to clean up the debugging output in
radeon. There's just too much info much of which isn't useful any
more. The new DRM_DEBUG_* macros would be a good start.
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_pm.c | 45
1 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_pm.c
b/drivers/gpu/drm/radeon/radeon_pm.c
index 31da562..bb69588 100644
--- a/drivers/gpu/drm/radeon/radeon_pm.c
+++ b/drivers/gpu/drm/radeon/radeon_pm.c
@@ -33,6 +33,14 @@
#define RADEON_WAIT_VBLANK_TIMEOUT 200
#define RADEON_WAIT_IDLE_TIMEOUT 200
+static const char *radeon_pm_state_type_name[5] = {
+ Default,
+ Powersave,
+ Battery,
+ Balanced,
+ Performance,
+};
+
static void radeon_dynpm_idle_work_handler(struct work_struct *work);
static int radeon_debugfs_pm_init(struct radeon_device *rdev);
static bool radeon_pm_in_vbl(struct radeon_device *rdev);
@@ -281,6 +289,42 @@ static void radeon_pm_set_clocks(struct radeon_device
*rdev)
mutex_unlock(rdev-ddev-struct_mutex);
}
+static void radeon_pm_print_states(struct radeon_device *rdev)
+{
+ int i, j;
+ struct radeon_power_state *power_state;
+ struct radeon_pm_clock_info *clock_info;
+
+ DRM_DEBUG(%d Power State(s)\n, rdev-pm.num_power_states);
+ for (i = 0; i rdev-pm.num_power_states; i++) {
+ power_state = rdev-pm.power_state[i];
+ DRM_DEBUG(State %d: %s\n, i,
+ radeon_pm_state_type_name[power_state-type]);
+ if (i == rdev-pm.default_power_state_index)
+ DRM_DEBUG(\tDefault);
+ if ((rdev-flags RADEON_IS_PCIE) !(rdev-flags
RADEON_IS_IGP))
+ DRM_DEBUG(\t%d PCIE Lanes\n,
power_state-pcie_lanes);
+ if (power_state-flags RADEON_PM_STATE_SINGLE_DISPLAY_ONLY)
+ DRM_DEBUG(\tSingle display only\n);
+ DRM_DEBUG(\t%d Clock Mode(s)\n,
power_state-num_clock_modes);
+ for (j = 0; j power_state-num_clock_modes; j++) {
+ clock_info = (power_state-clock_info[j]);
+ if (rdev-flags RADEON_IS_IGP)
+ DRM_DEBUG(\t\t%d e: %d%s\n,
+ j,
+ clock_info-sclk * 10,
+ clock_info-flags
RADEON_PM_MODE_NO_DISPLAY ? \tNo display only : );
+ else
+ DRM_DEBUG(\t\t%d e: %d\tm: %d\tv: %d%s\n,
+ j,
+ clock_info-sclk * 10,
+ clock_info-mclk * 10,
+ clock_info-voltage.voltage,
+ clock_info-flags
RADEON_PM_MODE_NO_DISPLAY ? \tNo display only : );
+ }
+ }
+}
+
static ssize_t radeon_get_pm_profile(struct device *dev,
struct device_attribute *attr,
char *buf)
@@ -408,6 +452,7 @@ int radeon_pm_init(struct radeon_device *rdev)
radeon_atombios_get_power_modes(rdev);
else
radeon_combios_get_power_modes(rdev);
+ radeon_pm_print_states(rdev);
radeon_pm_init_profile(rdev);
rdev-pm.current_power_state_index = -1;
rdev-pm.current_clock_mode_index = -1;
--
1.6.4.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
