[Bug 25665] New: [RS690]:Running OpenGL application hangs the system
http://bugs.freedesktop.org/show_bug.cgi?id=25665 Summary: [RS690]:Running OpenGL application hangs the system Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: other Status: NEW Severity: major Priority: high Component: Drivers/DRI/r300 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: hysv...@gmail.com Created an attachment (id=32104) -- (http://bugs.freedesktop.org/attachment.cgi?id=32104) Xorg.log O.S. - Ubuntu-9.10-32bit Chipset - RS690 Details of the X-stack: -- drm: 2.4.5 mesa/mesa : 7.7 xorg/xserver : 1.6.0 xorg/xf86-video-ati: 4th December-2009 Steps to Reproduce: == 1) Install Phoronix-test-suite version 1.8.1 from http://www.phoronix-test-suite.com/download.php?file=phoronix-test-suite-1.8.1 a) untar the phoronix-test-suie b) #cd phoronix-test-suite c) #sh install.sh 2) Install test #phoronix-test-suite install urbanterror 3) #phoronix-test-suite run urbanterror Observed Behaviour : = Application hangs after some time. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25665] [RS690]:Running OpenGL application hangs the system
http://bugs.freedesktop.org/show_bug.cgi?id=25665 --- Comment #1 from samit vats hysv...@gmail.com 2009-12-16 00:20:15 PST --- Created an attachment (id=32105) -- (http://bugs.freedesktop.org/attachment.cgi?id=32105) xorg.conf -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25665] [RS690]:Running OpenGL application hangs the system
http://bugs.freedesktop.org/show_bug.cgi?id=25665 --- Comment #3 from samit vats hysv...@gmail.com 2009-12-16 00:20:48 PST --- Created an attachment (id=32107) -- (http://bugs.freedesktop.org/attachment.cgi?id=32107) lspci -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Testing an AGPGART driver with radeon.test=1
On Tue, 2009-12-15 at 22:26 +0100, Gerhard Pircher wrote: Von: Michel Dänzer mic...@daenzer.net On Tue, 2009-12-15 at 13:37 +0100, Gerhard Pircher wrote: Von: Michel Dänzer mic...@daenzer.net guess there could be many possible causes for the problem, but the most likely seems some kind of coherency issue between the CPU writes and GPU reads. Well, the northbridge doesn't guarantee coherence. So I'm sure you're correct. Although I can only see the problem ATM, when the GPU writes data to system memory, which is later read by the CPU. What exactly does 'can see' mean? :) Well, I didn't verify that this happens on my machine. But I'm sure it is the case with memory allocated by the generic AGP layer functions (as far as I can see they allocate cacheable memory), as the bridge's snoop logic is buggy. As you say, it must be some sort of coherency issue. I don't think we've ever used cacheable memory with any AGP bridge in Linux. I guess the memory used for this test is allocated by the AGP layer and not by the radeon driver? No, it's allocated by radeon/TTM. And this memory is mapped uncacheable by radeon/TTM? Yes. Doesn't that limit the maximum usable memory for radeon/TTM to the vmalloc space? That could only be relevant for kernel mappings. The kernel only maps buffer object (BO) memory when/while necessary, which usually isn't the case. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Another TTM race bug.
Hi guys, There is another TTM race bug that I'm going to fix but which doesn't yet affect any upstream code AFAICT. The effect is that it may cause a deadlock in extremely rare cases if there are two processes validating at the same time, and one process needs to evict a buffer on which ttm_bo_block_reservation has been called. I'll fix that up before we upstream any driver that allows simultaneous validation. AFAIK only openchrome and old Poulsbo did that. vmwgfx probably will at some point. /Thomas -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Another TTM race bug.
On Wed, 2009-12-16 at 11:56 +0100, Thomas Hellstrom wrote: Hi guys, There is another TTM race bug that I'm going to fix but which doesn't yet affect any upstream code AFAICT. The effect is that it may cause a deadlock in extremely rare cases if there are two processes validating at the same time, and one process needs to evict a buffer on which ttm_bo_block_reservation has been called. I'll fix that up before we upstream any driver that allows simultaneous validation. AFAIK only openchrome and old Poulsbo did that. vmwgfx probably will at some point. /Thomas GL app likely endup doing concurrent validation with the ddx on radeon. Jerome -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Another TTM race bug.
Jerome Glisse wrote: On Wed, 2009-12-16 at 11:56 +0100, Thomas Hellstrom wrote: Hi guys, There is another TTM race bug that I'm going to fix but which doesn't yet affect any upstream code AFAICT. The effect is that it may cause a deadlock in extremely rare cases if there are two processes validating at the same time, and one process needs to evict a buffer on which ttm_bo_block_reservation has been called. I'll fix that up before we upstream any driver that allows simultaneous validation. AFAIK only openchrome and old Poulsbo did that. vmwgfx probably will at some point. /Thomas GL app likely endup doing concurrent validation with the ddx on radeon. Jerome I thought you had a command submission mutex that blocked this possibility? If not, you'll need the execbuf utilities to avoid deadlocks resulting from multiple threads trying to reserve the same buffers but in reverse order. /Thomas -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Another TTM race bug.
On Wed, 2009-12-16 at 12:11 +0100, Thomas Hellstrom wrote: Jerome Glisse wrote: On Wed, 2009-12-16 at 11:56 +0100, Thomas Hellstrom wrote: Hi guys, There is another TTM race bug that I'm going to fix but which doesn't yet affect any upstream code AFAICT. The effect is that it may cause a deadlock in extremely rare cases if there are two processes validating at the same time, and one process needs to evict a buffer on which ttm_bo_block_reservation has been called. I'll fix that up before we upstream any driver that allows simultaneous validation. AFAIK only openchrome and old Poulsbo did that. vmwgfx probably will at some point. /Thomas GL app likely endup doing concurrent validation with the ddx on radeon. Jerome I thought you had a command submission mutex that blocked this possibility? If not, you'll need the execbuf utilities to avoid deadlocks resulting from multiple threads trying to reserve the same buffers but in reverse order. Nouveau actually has an implementation of what ttm_eu did (we used it before the initial patch to the kernel which didn't include it) in the driver. Now that ttm_eu exists again I should look at moving back to it. We also have a mutex blocking submission by multiple clients currently, I can't recall why I added it right now, but it's on my TODO list to remove at some point. Ben. /Thomas -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25672] System unable to recover from suspend to disk
http://bugs.freedesktop.org/show_bug.cgi?id=25672 --- Comment #2 from samit vats hysv...@gmail.com 2009-12-16 03:18:06 PST --- Created an attachment (id=32117) -- (http://bugs.freedesktop.org/attachment.cgi?id=32117) glxinfo -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25672] System unable to recover from suspend to disk
http://bugs.freedesktop.org/show_bug.cgi?id=25672 --- Comment #1 from samit vats hysv...@gmail.com 2009-12-16 03:17:42 PST --- Created an attachment (id=32116) -- (http://bugs.freedesktop.org/attachment.cgi?id=32116) xorg.conf -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25672] System unable to recover from suspend to disk
http://bugs.freedesktop.org/show_bug.cgi?id=25672 --- Comment #3 from samit vats hysv...@gmail.com 2009-12-16 03:18:25 PST --- Created an attachment (id=32118) -- (http://bugs.freedesktop.org/attachment.cgi?id=32118) lspci -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
2.6.32 / intel: starts ok but display suddenly blanks out
Heyho! Is this already being investigated? (intel / X from squeeze == sid) X starts ok, but after some time (something like 15min) suddenly decides to blank the screen. ctrl+alt+backspace won't bring back the screen (I have it configured to allow it); ctrl+alt+Fx won't either, but since I can reboot with ctrl+alt+del I guess the console is being activated. Using 2.6.31 kernel is ok. If this is not known I'll try to find out more, but Xorg.0.log (.old after the reboot, of course) nor syslog show anything special that I can see. Seen on an Atom netbook (Acer AOA 150 with intel 945GME) with KMS enabled and on an IBM ThinkStation M58p (no access right now) without KMS. cheers -- vbi -- Penetration testing ... [is] expensive, and you'll get a thick report when the testing is done. [...] Probably the safest thing you can do with the report, after you read it, is shred it. -- Bruce Schneier http://www.schneier.com/blog/archives/2007/05/is_penetration.html signature.asc Description: This is a digitally signed message part. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Another TTM race bug.
Ben Skeggs wrote: On Wed, 2009-12-16 at 12:11 +0100, Thomas Hellstrom wrote: Jerome Glisse wrote: On Wed, 2009-12-16 at 11:56 +0100, Thomas Hellstrom wrote: Hi guys, There is another TTM race bug that I'm going to fix but which doesn't yet affect any upstream code AFAICT. The effect is that it may cause a deadlock in extremely rare cases if there are two processes validating at the same time, and one process needs to evict a buffer on which ttm_bo_block_reservation has been called. I'll fix that up before we upstream any driver that allows simultaneous validation. AFAIK only openchrome and old Poulsbo did that. vmwgfx probably will at some point. /Thomas GL app likely endup doing concurrent validation with the ddx on radeon. Jerome I thought you had a command submission mutex that blocked this possibility? If not, you'll need the execbuf utilities to avoid deadlocks resulting from multiple threads trying to reserve the same buffers but in reverse order. Nouveau actually has an implementation of what ttm_eu did (we used it before the initial patch to the kernel which didn't include it) in the driver. Now that ttm_eu exists again I should look at moving back to it. We also have a mutex blocking submission by multiple clients currently, I can't recall why I added it right now, but it's on my TODO list to remove at some point. Ben. /Thomas OK. vmwgfx and openchrome uses the ttm lock for this, which also enable us to block validation under some other circumstances, but I guess any rw mutex will do. In the normal case, the lock is only taken in read mode, allowing concurrent processes to validate. One thing to keep in mind is that if validation fails due to memory shortage, one should take that rw mutex in write mode, evict everything and retry. This way it's possible to guarantee a certain memory size to user-space. In fact, also if thrashing is anticipated, it might be optimal to take the mutex in write mode. /Thomas -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25567] commit drm/radeon/kms/r600/r700: fallback gracefully on ucode failure introduces screen corruption
http://bugs.freedesktop.org/show_bug.cgi?id=25567 --- Comment #10 from Florian Scandella f...@chilicode.com 2009-12-16 04:43:58 PST --- thx, this fixed my issues. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25567] commit drm/radeon/kms/r600/r700: fallback gracefully on ucode failure introduces screen corruption
http://bugs.freedesktop.org/show_bug.cgi?id=25567 Rafał Miłecki zaj...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BISECTED] drm: random hang since 620f378 drm: prune modes when ...
Hi, You can disable most of that code by loading i915 with 'powersave=0'. If that patch really is at fault the powersave=0 should work around the issue as well. It's been implicated in another issue (some display flicker and underruns) so I'm pretty sure there's something wrong with it in some configurations at least... Could it be also that the powersave feature produces gpu hangs when xserver is run the first time (after a cold boot). I have serious issues the intel drm starting at v2.6.32-rc2 (I can not use the v2.6.32 series on my laptop) while the same xorg stack works well with the v2.6.31 series. I try to bisect this problem and obtained this (sorry it is a bit long): git bisect start 'drivers/gpu' 'arch/x86_64/' # bad: [053fe57ac249a9531c396175778160d9e9509399] Merge git://git.kernel.org/pub /scm/linux/kernel/git/davem/net-2.6 git bisect bad 053fe57ac249a9531c396175778160d9e9509399 # good: [74fca6a42863ffacaf7ba6f1936a9f228950f657] Linux 2.6.31 git bisect good 74fca6a42863ffacaf7ba6f1936a9f228950f657 # bad: [d8a2d0e00c0d5a0d55e14b884bff034205015e51] drm/i915: HDMI hardware workar ound for Ironlake git bisect bad d8a2d0e00c0d5a0d55e14b884bff034205015e51 # bad: [d50ba256b5f1478e15accfcfda9b72fd7a661364] drm/kms: start adding command line interface using fb. git bisect bad d50ba256b5f1478e15accfcfda9b72fd7a661364 # good: [551ebd837c75fc75df81811a18b7136c39cab487] drm/radeon/kms: add rn50/r100 /r200 CS tracker. git bisect good 551ebd837c75fc75df81811a18b7136c39cab487 # good: [fdd5cace733370ab7a518a98ef084e02aa76fdea] drm/radeon/kms: Don't kzalloc memory which is immediately overwritten. git bisect good fdd5cace733370ab7a518a98ef084e02aa76fdea # good: [698443d9ec1a33eff65b27b9514e06998bf57eb3] drm/radeon/kms: disable VGA r endering engine before taking over VRAM git bisect good 698443d9ec1a33eff65b27b9514e06998bf57eb3 # good: [c214271563c00f2721c5111e27b53bf06dabc6e4] drm/radeon: consolidate famil y flags used in pciids. git bisect good c214271563c00f2721c5111e27b53bf06dabc6e4 # good: [93dc6c2b0d97a55508144073838e041140b206cd] drm/edid: Detailed standard t iming blocks have six timings, not five. git bisect good 93dc6c2b0d97a55508144073838e041140b206cd # good: [4bbd4973703bf8a5f00f05eff30a99cd9814f37f] drm/radeon/kms: enable r600 t v outputs. git bisect good 4bbd4973703bf8a5f00f05eff30a99cd9814f37f # good: [513bcb4655e68706594e45dfa1d4b181500110ba] drm/radeon/kms: don't require up to 64k allocations. (v2) git bisect good 513bcb4655e68706594e45dfa1d4b181500110ba Regards Mathieu -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: add dynamic engine reclocking (v5)
--Forwarded to list-- Good job. Card: 01:00.0 VGA compatible controller: ATI Technologies Inc M92 [Mobility Radeon HD 4500 Series] How to: 1)Blacklist radeon module at startup (distro-specific). 2) Add this to /etc/rc.local (might be distro-specific) : modprobe -r -v radeon modprobe -v radeon modeset=1 dynclks=1 Results: --Normal X session-- state: RADEON_PM_STATE_ACTIVE default engine clock: 68 kHz current engine clock: 629430 kHz default memory clock: 80 kHz current memory clock: 796500 kHz --With glxgears running-- state: RADEON_PM_STATE_ACTIVE default engine clock: 68 kHz current engine clock: 678370 kHz default memory clock: 80 kHz current memory clock: 796500 kHz Conclusion: Engine reclocking is working for me. Memory reclocking is not. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Fwd: [PATCH] drm/radeon/kms: add dynamic engine reclocking (v5)
Nezmer tested my patch, I let myself forward his results :) -- Wiadomość przekazana dalej -- Od: nez...@allurelinux.org Data: 16 grudnia 2009 14:27 Temat: Re: [PATCH] drm/radeon/kms: add dynamic engine reclocking (v5) Do: Rafał Miłecki zaj...@gmail.com On Wed, Dec 16, 2009 at 08:45:04AM +0100, Rafał Miłecki wrote: W dniu 16 grudnia 2009 02:50 użytkownik nez...@allurelinux.org napisał: On Wed, Dec 16, 2009 at 12:35:25AM +0100, Rafał Miłecki wrote: V2: reorganize functions, fix modesetting calls V3: rebase patch, use radeon's workqueue V4: enable on tested chipsets only, request VBLANK IRQs V5: enable PM in older hardware (IRQs, mode_fixup, dpms) This should be applied on top of 0001-drm-radeon-kms-init-pm-on-all-chipsets.patch [1] (thanks Sedat). To enable dynamic engine reclocking you need to set dynclks to 1. Then check drm messages to make sure it's enabled. Quite useful is also debugfs/dri/0/radeon_pm_info (mount debugsfs and cat that debugfs file) [1] http://marc.info/?l=dri-develm=126091020609997w=2 -- Rafał Are R7xx cards supported by this patch? Yes, everything never than CHIP_RS600. I guess we could enable this also on hardware older than CHIP_RS600 but we need testers for that. -- Rafał Good job. Card: 01:00.0 VGA compatible controller: ATI Technologies Inc M92 [Mobility Radeon HD 4500 Series] How to: 1)Blacklist radeon module at startup (distro-specific). 2) Add this to /etc/rc.local (might be distro-specific) : modprobe -r -v radeon modprobe -v radeon modeset=1 dynclks=1 Results: --Normal X session-- state: RADEON_PM_STATE_ACTIVE default engine clock: 68 kHz current engine clock: 629430 kHz default memory clock: 80 kHz current memory clock: 796500 kHz --With glxgears running-- state: RADEON_PM_STATE_ACTIVE default engine clock: 68 kHz current engine clock: 678370 kHz default memory clock: 80 kHz current memory clock: 796500 kHz Conclusion: Engine reclocking is working for me. Memory reclocking is not. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BISECTED] drm: random hang since 620f378 drm: prune modes when ...
On Tuesday 15 December 2009, Arnd Bergmann wrote: On Monday 14 December 2009, Jesse Barnes wrote: This patch removes the suspect portion of the dynamic clock control code. Hopefully it'll be as stable as powersave=0 in your config (assuming powersave=0 works :). Ok, great! The machine is still running fine with powersave=0 so far. I'll try your patch after some more uptime. It's working fine so far, no more crashes, but I supposed this effectively disables the power saving on my card again, right? I should probably mention that this machine has had stability problems before and showed single-bit memory corruption, but that problem has disappeared after I installed bigger CPU and northbridge coolers and increased the voltage slightly. Arnd -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
radeon KMS causes GART Table Walk Errors (was: K8 ECC error with linux-2.6.32)
Am Mittwoch 16 Dezember 2009 08:14:43 schrieb Borislav Petkov: On Tue, Dec 15, 2009 at 11:00:46PM +0100, Johannes Hirte wrote: This patch (as the BIOS option) will only disable the error reports. The error itself will still occur, right? So necessary to find out why the radeon driver trigger this error. Because the graphics driver does aperture accesses with no matching GART translation, and the hw generates mchecks for that. The whole story on GART table walk errors is in section 13.10.1 GART Table Walk Error Reporting in the document here: http://support.amd.com/us/Processor_TechDocs/32559.pdf I can't say for sure about your BIOS, but if it is done as described in the abovementioned section, the BIOS option should disable logging of the error, which implies reporting too. The patch is still needed for machines that do not have that BIOS option. Disabling in BIOS doesn't made any difference. The errors were still reported. Your patch disabled it. But I think this will make work harder for driver developers as they won't get this error anymore. Could this be made changeable on runtime/boottime? I've added drm people to CC as they're responsible for this error. regards, Johannes -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Testing an AGPGART driver with radeon.test=1
Original-Nachricht Datum: Wed, 16 Dec 2009 10:54:15 +0100 Von: Michel Dänzer mic...@daenzer.net An: Gerhard Pircher gerhard_pirc...@gmx.net CC: dri-devel@lists.sourceforge.net Betreff: Re: Testing an AGPGART driver with radeon.test=1 I guess the memory used for this test is allocated by the AGP layer and not by the radeon driver? No, it's allocated by radeon/TTM. And this memory is mapped uncacheable by radeon/TTM? Yes. Well, in short I fail to see now how radeon/TTM allocates and maps the memory used for the test into the AGP GART resp. which functions are called the way down from the radeon driver to the AGPGART driver (radeon-TTM-(DRM?)-AGP). I guess I should ask Google for some TTM/DRM documentation. :) Doesn't that limit the maximum usable memory for radeon/TTM to the vmalloc space? That could only be relevant for kernel mappings. The kernel only maps buffer object (BO) memory when/while necessary, which usually isn't the case. Okay. Thanks, Gerhard -- Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon KMS causes GART Table Walk Errors (was: K8 ECC error with linux-2.6.32)
On Wed, Dec 16, 2009 at 03:58:30PM +0100, Johannes Hirte wrote: Am Mittwoch 16 Dezember 2009 08:14:43 schrieb Borislav Petkov: On Tue, Dec 15, 2009 at 11:00:46PM +0100, Johannes Hirte wrote: This patch (as the BIOS option) will only disable the error reports. The error itself will still occur, right? So necessary to find out why the radeon driver trigger this error. Because the graphics driver does aperture accesses with no matching GART translation, and the hw generates mchecks for that. The whole story on GART table walk errors is in section 13.10.1 GART Table Walk Error Reporting in the document here: http://support.amd.com/us/Processor_TechDocs/32559.pdf I can't say for sure about your BIOS, but if it is done as described in the abovementioned section, the BIOS option should disable logging of the error, which implies reporting too. The patch is still needed for machines that do not have that BIOS option. Disabling in BIOS doesn't made any difference. The errors were still reported. Hmm. It would be interesting to know what the BIOS does exactly on your machine. We could easily find that out by installing the x86info tool (either prepackaged for your distro or from here: git://git.choralone.org/git/x86info) and doing as root: lsmsr MC4 -V3 and sending me the output. Make sure the amd64_edac module is not loaded. Your patch disabled it. Thanks for testing. But I think this will make work harder for driver developers as they won't get this error anymore. Could this be made changeable on runtime/boottime? yep, we have that. You have to set 'report_gart_errors' module parameter to 1 when loading amd64_edac and GART TLB errors will be reported. -- Regards/Gruss, Boris. Operating | Advanced Micro Devices GmbH System | Karl-Hammerschmidt-Str. 34, 85609 Dornach b. München, Germany Research | Geschäftsführer: Andrew Bowd, Thomas M. McCoy, Giuliano Meroni Center | Sitz: Dornach, Gemeinde Aschheim, Landkreis München (OSRC) | Registergericht München, HRB Nr. 43632 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon KMS causes GART Table Walk Errors (was: K8 ECC error with linux-2.6.32)
On Wed, Dec 16, 2009 at 03:58:30PM +0100, Johannes Hirte wrote: Am Mittwoch 16 Dezember 2009 08:14:43 schrieb Borislav Petkov: On Tue, Dec 15, 2009 at 11:00:46PM +0100, Johannes Hirte wrote: This patch (as the BIOS option) will only disable the error reports. The error itself will still occur, right? So necessary to find out why the radeon driver trigger this error. Because the graphics driver does aperture accesses with no matching GART translation, and the hw generates mchecks for that. The whole story on GART table walk errors is in section 13.10.1 GART Table Walk Error Reporting in the document here: http://support.amd.com/us/Processor_TechDocs/32559.pdf I can't say for sure about your BIOS, but if it is done as described in the abovementioned section, the BIOS option should disable logging of the error, which implies reporting too. The patch is still needed for machines that do not have that BIOS option. Disabling in BIOS doesn't made any difference. The errors were still reported. Your patch disabled it. But I think this will make work harder for driver developers as they won't get this error anymore. Could this be made changeable on runtime/boottime? I've added drm people to CC as they're responsible for this error. regards, Johannes More context would be usefull. Are you using KMS ? If so is your userspace KMS capable ? Does this GART error happen all the time or only after sometimes or when doing somethings specific ? Cheers, Jerome -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] i915/crt: Always attempt ddc on both GPIOA and GPIOD
On Tue, 8 Dec 2009 17:24:21 +0100, Helge Bahmann helge.bahm...@secunet.com wrote: The small attached patch fixes a failure to fetch EDID for a newly connected display, when the previously connected display did not provide EDID. Overall I have found that hot-plugging displays with different resolutions at run-time does not work too well with KMS, once a mode gets added to a connector, it apparently never goes away, which means that replacing a display with a smaller one at run-time is problematic. Is there any work in progress to improve that? This patch looks good. However, patches to the Linux kernel require a Signed-off-by indicating your acceptance of the Developer's Certificate of Origin, described in linux-2.6/Documentation/SubmittingPatches. Could you resend with that? pgpdKXUuo7wQM.pgp Description: PGP signature -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
2.6.32.1 i915 KMS rmmod failure
Hi,
The following sequence causes the machine to hang hard:
modprobe drm debug=65535
modprobe i915 modeset=1
rmmod i915
Linux 2.6.32.1 x86-64, i915 (the machine is a slimline MSI Hetis 915
barebone), 2 GB RAM etc. Kernel messages captured with a serial console.
Only analog VGA output connected (no EDID, using a pro 5 * BNC cable
to connect to an old analog monitor). There is (unconnected) digital DVI
and a TV encoder. Other details available on request.
The IRQ happens in intel_pipe_set_base()
DRM_DEBUG(Writing base %08lX %08lX %d %d\n, Start, Offset, x, y);
I915_WRITE(dspstride, crtc-fb-pitch);
if (IS_I965G(dev)) {
...
} else {
I915_WRITE(dspbase, Start + Offset);
I915_READ(dspbase);
IRQ seems to be triggered at this point
}
Any ideas?
modprobe:
[drm] Initialized drm 1.1.0 20060810
[drm:drm_init],
[drm:drm_get_dev],
i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16
i915 :00:02.0: setting latency timer to 64
[drm:drm_get_minor],
[drm:drm_get_minor], new minor assigned 64
[drm:drm_get_minor],
[drm:drm_get_minor], new minor assigned 0
[drm:i915_init_phys_hws], Enabled hardware status page
[drm] set up 7M of stolen space
[drm:drm_agp_bind_pages],
[drm:parse_general_definitions], crt_ddc_bus_pin: 2
[drm:parse_sdvo_device_mapping], the SDVO device with slave addr 70 is found on
SDVOB port
[drm:parse_sdvo_device_mapping], the SDVO device with slave addr 72 is found on
SDVOC port
[drm:drm_irq_install], irq=16
[drm:intel_modeset_init], 2 display pipes available.
[drm:drm_sysfs_connector_add], adding VGA-1 to sysfs
[drm:drm_sysfs_hotplug_event], generating hotplug event
[drm:drm_sysfs_connector_add], adding DVI-D-1 to sysfs
[drm:drm_sysfs_hotplug_event], generating hotplug event
[drm:intel_sdvo_init], SDVOB device VID/DID: 02:3C.06, clock range 25MHz -
200MHz, input 1: Y, input 2: N, output 1:
Y, output 2: N
[drm:intel_sdvo_create_enhance_property], h_overscan: max 47, default 32,
current 32
[drm:intel_sdvo_create_enhance_property], v_overscan: max 47, default 32,
current 32
[drm:intel_sdvo_create_enhance_property], h_position: max 1023, default 512,
current 512
[drm:intel_sdvo_create_enhance_property], v_position: max 1023, default 512,
current 512
[drm:intel_sdvo_create_enhance_property], saturation: max 127, default 69,
current 69
[drm:intel_sdvo_create_enhance_property], contrast: max 127, default 64,
current 64
[drm:intel_sdvo_create_enhance_property], hue: max 127, default 64, current 64
[drm:intel_sdvo_create_enhance_property], brightness: max 255, default 128,
current 128
[drm:drm_sysfs_connector_add], adding SVIDEO-1 to sysfs
[drm:drm_sysfs_hotplug_event], generating hotplug event
[drm:intel_sdvo_init], SDVOC device VID/DID: 02:C2.02, clock range 25MHz -
160MHz, input 1: Y, input 2: N, output 1:
Y, output 2: N
[drm:drm_helper_probe_single_connector_modes], VGA-1
[drm:intel_update_watermarks], plane A (pipe 0) clock: 31500
[drm:i9xx_get_fifo_size], FIFO size - (0x1d9c) A: 28
[drm:i9xx_get_fifo_size], FIFO size - (0x1d9c) B: 31
[drm:intel_calculate_wm], FIFO entries required for mode: 9
[drm:intel_calculate_wm], FIFO watermark level: 17
[drm:intel_calculate_wm], FIFO entries required for mode: 0
[drm:intel_calculate_wm], FIFO watermark level: 29
[drm:i9xx_update_wm], FIFO watermarks - A: 17, B: 29
[drm:i9xx_update_wm], self-refresh entries: 12
[drm:i9xx_update_wm], Setting FIFO watermarks - A: 17, B: 29, C: 2, SR 83
[drm:drm_vblank_get], enabling vblank on crtc 0, ret: -22
[drm:intel_crtc_mode_set], Mode for pipe A:
[drm:drm_mode_debug_printmodeline], Modeline 0:640x480 0 31500 640 664 704
832 480 489 491 520 0x10 0xa
[drm:intel_pipe_set_base], No FB bound
[drm:intel_update_watermarks], plane A (pipe 0) clock: 31500
[drm:i9xx_get_fifo_size], FIFO size - (0x1d9c) A: 28
[drm:i9xx_get_fifo_size], FIFO size - (0x1d9c) B: 31
[drm:intel_calculate_wm], FIFO entries required for mode: 9
[drm:intel_calculate_wm], FIFO watermark level: 17
[drm:intel_calculate_wm], FIFO entries required for mode: 0
[drm:intel_calculate_wm], FIFO watermark level: 29
[drm:i9xx_update_wm], FIFO watermarks - A: 17, B: 29
[drm:i9xx_update_wm], self-refresh entries: 12
[drm:i9xx_update_wm], Setting FIFO watermarks - A: 17, B: 29, C: 2, SR 83
[drm] DAC-6: set mode 640x480 0
[drm:intel_update_watermarks], plane A (pipe 0) clock: 31500
[drm:i9xx_get_fifo_size], FIFO size - (0x1d9c) A: 28
[drm:i9xx_get_fifo_size], FIFO size - (0x1d9c) B: 31
[drm:intel_calculate_wm], FIFO entries required for mode: 9
[drm:intel_calculate_wm], FIFO watermark level: 17
[drm:intel_calculate_wm], FIFO entries required for mode: 0
[drm:intel_calculate_wm], FIFO watermark level: 29
[drm:i9xx_update_wm], FIFO watermarks - A: 17, B: 29
[drm:i9xx_update_wm], self-refresh entries: 12
[drm:i9xx_update_wm], Setting FIFO watermarks - A: 17, B: 29, C: 2, SR 83
[drm:drm_helper_probe_single_connector_modes], Probed modes for VGA-1
Re: radeon KMS causes GART Table Walk Errors (was: K8 ECC error with linux-2.6.32)
Am Mittwoch 16 Dezember 2009 19:41:48 schrieb Jerome Glisse: On Wed, Dec 16, 2009 at 03:58:30PM +0100, Johannes Hirte wrote: Am Mittwoch 16 Dezember 2009 08:14:43 schrieb Borislav Petkov: On Tue, Dec 15, 2009 at 11:00:46PM +0100, Johannes Hirte wrote: This patch (as the BIOS option) will only disable the error reports. The error itself will still occur, right? So necessary to find out why the radeon driver trigger this error. Because the graphics driver does aperture accesses with no matching GART translation, and the hw generates mchecks for that. The whole story on GART table walk errors is in section 13.10.1 GART Table Walk Error Reporting in the document here: http://support.amd.com/us/Processor_TechDocs/32559.pdf I can't say for sure about your BIOS, but if it is done as described in the abovementioned section, the BIOS option should disable logging of the error, which implies reporting too. The patch is still needed for machines that do not have that BIOS option. Disabling in BIOS doesn't made any difference. The errors were still reported. Your patch disabled it. But I think this will make work harder for driver developers as they won't get this error anymore. Could this be made changeable on runtime/boottime? I've added drm people to CC as they're responsible for this error. regards, Johannes More context would be usefull. Are you using KMS ? If so is your userspace KMS capable ? Does this GART error happen all the time or only after sometimes or when doing somethings specific ? Yes I'm using KMS when this error occours. Hardware: - Tyan Tiger K8W S8875 (AMD8151 Northbridge) - Radeon HD3650 AGP (RV635) Software: - linux-2.6.32 - libdrm-2.4.16 - mesa-7.7_rc2 - xf86-video-ati- (latest git everytime) - KDE-4.3.4 with compositing enabled (OpenGL) The errors occours after a while of normal desktop work. I haven't tested without KMS or compisiting. Will do this as well. regards, Johannes -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.32.1 i915 KMS rmmod failure
On Wed, 16 Dec 2009 20:08:16 +0100
Krzysztof Halasa k...@pm.waw.pl wrote:
Hi,
The following sequence causes the machine to hang hard:
modprobe drm debug=65535
modprobe i915 modeset=1
rmmod i915
Linux 2.6.32.1 x86-64, i915 (the machine is a slimline MSI Hetis 915
barebone), 2 GB RAM etc. Kernel messages captured with a serial
console. Only analog VGA output connected (no EDID, using a pro 5 *
BNC cable to connect to an old analog monitor). There is
(unconnected) digital DVI and a TV encoder. Other details available
on request.
The IRQ happens in intel_pipe_set_base()
DRM_DEBUG(Writing base %08lX %08lX %d %d\n, Start, Offset,
x, y); I915_WRITE(dspstride, crtc-fb-pitch);
if (IS_I965G(dev)) {
...
} else {
I915_WRITE(dspbase, Start + Offset);
I915_READ(dspbase);
IRQ seems to be triggered at this point
}
Any ideas?
Seems like we should be disabling everything at unload time rather than
trying to set a new mode... If the dspbase we program isn't mapped
anymore we'd definitely get into trouble.
--
Jesse Barnes, Intel Open Source Technology Center
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25679] New: R600: Winding is inverted when rendering to FBO
http://bugs.freedesktop.org/show_bug.cgi?id=25679 Summary: R600: Winding is inverted when rendering to FBO Product: Mesa Version: git Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: monr...@gmail.com Winding is inverted when rendering to FBO. This breaks many games. You can test it by running progs/demos/fbotexture and press 'c' tot toggle back-face culling and compare the image with the output of the software renderer. I found a relevant commit which fixes this bug on r300. http://cgit.freedesktop.org/mesa/mesa/commit/?id=60e60bb3026a269fefe1cfd3312fdf3a7e4c595f -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25679] R600: Winding is inverted when rendering to FBO
http://bugs.freedesktop.org/show_bug.cgi?id=25679 --- Comment #1 from Alex Deucher ag...@yahoo.com 2009-12-16 12:56:30 PST --- Created an attachment (id=32132) -- (http://bugs.freedesktop.org/attachment.cgi?id=32132) fix fbo winding Does this patch work? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25679] R600: Winding is inverted when rendering to FBO
http://bugs.freedesktop.org/show_bug.cgi?id=25679 --- Comment #2 from monraaf monr...@gmail.com 2009-12-16 13:11:21 PST --- (In reply to comment #1) Created an attachment (id=32132) -- (http://bugs.freedesktop.org/attachment.cgi?id=32132) [details] fix fbo winding Does this patch work? Yes it does. thanks! -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25679] R600: Winding is inverted when rendering to FBO
http://bugs.freedesktop.org/show_bug.cgi?id=25679 --- Comment #3 from Rafał Miłecki zaj...@gmail.com 2009-12-16 13:13:27 PST --- It makes r600 render fbotexture same way as software does on my RV620. In both renderers I see some difference when pressing c. Inside of teapot changes between black and transparent (blue in result, due to blue background). Is that expected? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] vmware drm/kms driver under staging
Hi Linus, Please pull the 'drm-vmware-staging' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-vmware-staging ping? Greg is fine with this going in, and its a pretty standalone driver for a very popular virtual GPU. Dave. This adds the VMware KMS driver for their virtual GPU, the Kconfig is under staging until they are happy with the ioctl interface to the 3D driver, which may be quite soon. We now have 4 KMS drivers, hopefully it'll quieten down for a while, while we fix them all up. Dave. drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/vmwgfx/Kconfig | 13 + drivers/gpu/drm/vmwgfx/Makefile | 9 + drivers/gpu/drm/vmwgfx/svga3d_reg.h | 1793 ++ drivers/gpu/drm/vmwgfx/svga_escape.h | 89 ++ drivers/gpu/drm/vmwgfx/svga_overlay.h | 201 drivers/gpu/drm/vmwgfx/svga_reg.h | 1346 ++ drivers/gpu/drm/vmwgfx/svga_types.h | 45 + drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c | 229 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 735 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 511 + drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 516 + drivers/gpu/drm/vmwgfx/vmwgfx_fb.c | 742 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c | 521 + drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c | 213 drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c | 81 ++ drivers/gpu/drm/vmwgfx/vmwgfx_irq.c | 295 + drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 872 +++ drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 102 ++ drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 516 + drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c | 634 +++ drivers/gpu/drm/vmwgfx/vmwgfx_reg.h | 57 + drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 1192 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c | 99 ++ drivers/staging/Kconfig | 2 + include/drm/Kbuild | 1 + include/drm/ttm/ttm_object.h | 6 +- include/drm/vmwgfx_drm.h | 574 ++ 28 files changed, 11394 insertions(+), 1 deletions(-) create mode 100644 drivers/gpu/drm/vmwgfx/Kconfig create mode 100644 drivers/gpu/drm/vmwgfx/Makefile create mode 100644 drivers/gpu/drm/vmwgfx/svga3d_reg.h create mode 100644 drivers/gpu/drm/vmwgfx/svga_escape.h create mode 100644 drivers/gpu/drm/vmwgfx/svga_overlay.h create mode 100644 drivers/gpu/drm/vmwgfx/svga_reg.h create mode 100644 drivers/gpu/drm/vmwgfx/svga_types.h create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_drv.h create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_fb.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_fifo.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_gmr.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_irq.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_kms.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_kms.h create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_overlay.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_reg.h create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_resource.c create mode 100644 drivers/gpu/drm/vmwgfx/vmwgfx_ttm_glue.c create mode 100644 include/drm/vmwgfx_drm.h commit fb1d9738ca053ea8afa5e86af6463155f983b01c Author: Jakob Bornecrantz ja...@vmware.com Date: Thu Dec 10 00:19:58 2009 + drm/vmwgfx: Add DRM driver for VMware Virtual GPU This commit adds the vmwgfx driver for the VWware Virtual GPU aka SVGA. The driver is under staging the same as Nouveau and Radeon KMS. Hopefully the 2D ioctls are bug free and don't need changing, so that part of the API should be stable. But there there is a pretty big chance that the 3D API will change in the future. Signed-off-by: Thomas Hellström thellst...@vmware.com Signed-off-by: Jakob Bornecrantz ja...@vmware.com Signed-off-by: Dave Airlie airl...@redhat.com commit 632f61178d0473861ba77e774bb654b37bc7eccc Author: Jakob Bornecrantz ja...@vmware.com Date: Thu Dec 10 00:19:10 2009 + drm/vmwgfx: Add svga headers for vmwgfx driver These headers are shared between multiple place where different coding standards apply. They will be fixed up at a later time. Signed-off-by: Thomas Hellström thellst...@vmware.com Signed-off-by: Jakob Bornecrantz ja...@vmware.com Signed-off-by: Dave Airlie airl...@redhat.com commit be1cb8689c480228ffd2e4bfccc0dab7156cd9ea Author: Jakob Bornecrantz ja...@vmware.com Date: Mon Dec 14 22:07:45 2009 + drm/ttm: Add more driver type enums Signed-off-by:
[Bug 25679] R600: Winding is inverted when rendering to FBO
http://bugs.freedesktop.org/show_bug.cgi?id=25679 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from Alex Deucher ag...@yahoo.com 2009-12-16 13:19:48 PST --- Pushed: 20ee275974a58cd221031d522ad58a9548af2a31 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BISECTED] drm: random hang since 620f378 drm: prune modes when ...
On Wed, 16 Dec 2009 21:20:34 + Arnd Bergmann a...@arndb.de wrote: On Wednesday 16 December 2009 20:18:23 Jesse Barnes wrote: On Wed, 16 Dec 2009 14:53:11 +0100 Arnd Bergmann a...@arndb.de wrote: It's working fine so far, no more crashes, but I supposed this effectively disables the power saving on my card again, right? The patch just disables one (probably ineffective) power saving feature. So if things are working well for you with it I'll queue up a revert patch. I'm working on a better version of dynamic clock control anyway. It just crashed again after a few hours of uptime with some unrelated reboots in-between, with your patch applied. The symptom was slightly different, now the whole screen was filled with random patterns, not just parts of the screen. Aside from that, it was just the same complete lockup as without the patch. Possibly less frequent, but that's hard to tell after a single sample. But you're sure powersave=0 was solid? Hmm... -- Jesse Barnes, Intel Open Source Technology Center -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25622] KMS blurry output after initialisation
http://bugs.freedesktop.org/show_bug.cgi?id=25622 Aidan Marks ai...@cisco.com changed: What|Removed |Added Summary|KMS occasional blurry output|KMS blurry output after |after initialisation|initialisation --- Comment #4 from Aidan Marks ai...@cisco.com 2009-12-16 14:38:11 PST --- adjusting summary, not actually occasional at all, rather is happening every few reboots. I just wasn't rebooting frequently enough to notice. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm: convert drm_ioctl to unlocked_ioctl
drm_ioctl is called with the Big Kernel Lock held,
which shows up very high in statistics on vfs_ioctl.
Moving the lock into the drm_ioctl function itself
makes sure we blame the right subsystem and it gets
us one step closer to eliminating the locked version
of fops-ioctl.
Since drm_ioctl does not require the lock itself,
we only need to hold it while calling the specific
handler. The 32 bit conversion handlers do not
interact with any other code, so they don't need
the BKL here either and can just call drm_ioctl.
As a bonus, this cleans up all the other users
of drm_ioctl which now no longer have to find
the inode or call lock_kernel.
Signed-off-by: Arnd Bergmann a...@arndb.de
Cc: David Airlie airl...@linux.ie
Cc: dri-devel@lists.sourceforge.net
Cc: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
---
drivers/gpu/drm/drm_drv.c |7 ++-
drivers/gpu/drm/drm_ioc32.c | 89 ++
drivers/gpu/drm/i810/i810_dma.c |2 +-
drivers/gpu/drm/i810/i810_drv.c |2 +-
drivers/gpu/drm/i830/i830_dma.c |2 +-
drivers/gpu/drm/i830/i830_drv.c |2 +-
drivers/gpu/drm/i915/i915_drv.c |2 +-
drivers/gpu/drm/i915/i915_ioc32.c | 23 -
drivers/gpu/drm/mga/mga_drv.c |2 +-
drivers/gpu/drm/mga/mga_ioc32.c | 13 ++---
drivers/gpu/drm/nouveau/nouveau_drv.c |2 +-
drivers/gpu/drm/nouveau/nouveau_ioc32.c |4 +-
drivers/gpu/drm/r128/r128_drv.c |2 +-
drivers/gpu/drm/r128/r128_ioc32.c | 16 ++
drivers/gpu/drm/radeon/radeon_drv.c |4 +-
drivers/gpu/drm/radeon/radeon_ioc32.c | 38 -
drivers/gpu/drm/savage/savage_drv.c |2 +-
drivers/gpu/drm/sis/sis_drv.c |2 +-
drivers/gpu/drm/tdfx/tdfx_drv.c |2 +-
drivers/gpu/drm/via/via_drv.c |2 +-
include/drm/drmP.h |4 +-
21 files changed, 83 insertions(+), 139 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index ff2f104..9f2ff93 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -434,11 +434,11 @@ static int drm_version(struct drm_device *dev, void *data,
* Looks up the ioctl function in the ::ioctls table, checking for root
* previleges if so required, and dispatches to the respective function.
*/
-int drm_ioctl(struct inode *inode, struct file *filp,
+long drm_ioctl(struct file *filp,
unsigned int cmd, unsigned long arg)
{
struct drm_file *file_priv = filp-private_data;
- struct drm_device *dev = file_priv-minor-dev;
+ struct drm_device *dev;
struct drm_ioctl_desc *ioctl;
drm_ioctl_t *func;
unsigned int nr = DRM_IOCTL_NR(cmd);
@@ -446,6 +446,7 @@ int drm_ioctl(struct inode *inode, struct file *filp,
char stack_kdata[128];
char *kdata = NULL;
+ dev = file_priv-minor-dev;
atomic_inc(dev-ioctl_count);
atomic_inc(dev-counts[_DRM_STAT_IOCTLS]);
++file_priv-ioctl_count;
@@ -501,7 +502,9 @@ int drm_ioctl(struct inode *inode, struct file *filp,
goto err_i1;
}
}
+ lock_kernel();
retcode = func(dev, kdata, file_priv);
+ unlock_kernel();
if (cmd IOC_OUT) {
if (copy_to_user((void __user *)arg, kdata,
diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c
index 282d9fd..d61d185 100644
--- a/drivers/gpu/drm/drm_ioc32.c
+++ b/drivers/gpu/drm/drm_ioc32.c
@@ -104,7 +104,7 @@ static int compat_drm_version(struct file *file, unsigned
int cmd,
version-desc))
return -EFAULT;
- err = drm_ioctl(file-f_path.dentry-d_inode, file,
+ err = drm_ioctl(file,
DRM_IOCTL_VERSION, (unsigned long)version);
if (err)
return err;
@@ -145,8 +145,7 @@ static int compat_drm_getunique(struct file *file, unsigned
int cmd,
u-unique))
return -EFAULT;
- err = drm_ioctl(file-f_path.dentry-d_inode, file,
- DRM_IOCTL_GET_UNIQUE, (unsigned long)u);
+ err = drm_ioctl(file, DRM_IOCTL_GET_UNIQUE, (unsigned long)u);
if (err)
return err;
@@ -174,8 +173,7 @@ static int compat_drm_setunique(struct file *file, unsigned
int cmd,
u-unique))
return -EFAULT;
- return drm_ioctl(file-f_path.dentry-d_inode, file,
-DRM_IOCTL_SET_UNIQUE, (unsigned long)u);
+ return drm_ioctl(file, DRM_IOCTL_SET_UNIQUE, (unsigned long)u);
}
typedef struct drm_map32 {
@@ -205,8 +203,7 @@ static int compat_drm_getmap(struct file *file, unsigned
int cmd,
if (__put_user(idx, map-offset))
return -EFAULT;
- err =
Re: [BISECTED] drm: random hang since 620f378 drm: prune modes when ...
On Wednesday 16 December 2009 21:36:36 Arnd Bergmann wrote: On Wednesday 16 December 2009 21:30:05 Jesse Barnes wrote: But you're sure powersave=0 was solid? Hmm... It's hard to be sure when it sometimes takes a day before a broken version crashes. I can keep running this kernel with and without powersave=0 some more and tell you if it stays reproducible. Now it has crashed with i915.powersave=0 plus your patch as well (latest 2.6.32 git), indicating that there is something else wrong with the original 652c393a33 patch. Arnd -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BISECTED] drm: random hang since 620f378 drm: prune modes when ...
On Wednesday 16 December 2009 21:30:05 Jesse Barnes wrote: But you're sure powersave=0 was solid? Hmm... It's hard to be sure when it sometimes takes a day before a broken version crashes. I can keep running this kernel with and without powersave=0 some more and tell you if it stays reproducible. Arnd -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [BISECTED] drm: random hang since 620f378 drm: prune modes when ...
On Wednesday 16 December 2009 20:18:23 Jesse Barnes wrote: On Wed, 16 Dec 2009 14:53:11 +0100 Arnd Bergmann a...@arndb.de wrote: It's working fine so far, no more crashes, but I supposed this effectively disables the power saving on my card again, right? The patch just disables one (probably ineffective) power saving feature. So if things are working well for you with it I'll queue up a revert patch. I'm working on a better version of dynamic clock control anyway. It just crashed again after a few hours of uptime with some unrelated reboots in-between, with your patch applied. The symptom was slightly different, now the whole screen was filled with random patterns, not just parts of the screen. Aside from that, it was just the same complete lockup as without the patch. Possibly less frequent, but that's hard to tell after a single sample. Arnd -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: prevent parallel AtomBIOS calls
In future we will execute AtomBIOS commands from contexts (like power management) so we need to make sure we won't execute two commands at same time to prevent locking up GPU. With this patch applied Sedat Dilek (RV515) was able to finally test my PM patch. Also tested on my RV620. -- Rafał 0001-drm-radeon-kms-prevent-parallel-AtomBIOS-calls.patch Description: Binary data -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.32 / intel: starts ok but display suddenly blanks out
Hello, the same behaviour can be confirmed for 945GM using 2.6.32.1. Cheers, Johannes Am 16.12.2009 11:24, schrieb Adrian von Bidder: Heyho! Is this already being investigated? (intel / X from squeeze == sid) X starts ok, but after some time (something like 15min) suddenly decides to blank the screen. ctrl+alt+backspace won't bring back the screen (I have it configured to allow it); ctrl+alt+Fx won't either, but since I can reboot with ctrl+alt+del I guess the console is being activated. Using 2.6.31 kernel is ok. If this is not known I'll try to find out more, but Xorg.0.log (.old after the reboot, of course) nor syslog show anything special that I can see. Seen on an Atom netbook (Acer AOA 150 with intel 945GME) with KMS enabled and on an IBM ThinkStation M58p (no access right now) without KMS. cheers -- vbi -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: enable memory clock reading on legacy
Tested by bjaglin on IRC on RV250. -- Rafał 0001-drm-radeon-kms-enable-memory-clock-reading-on-legacy.patch Description: Binary data -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: add dynamic engine reclocking (V6)
V2: reorganize functions, fix modesetting calls V3: rebase patch, use radeon's workqueue V4: enable on tested chipsets only, request VBLANK IRQs V5: enable PM on older hardware (IRQs, mode_fixup, dpms) V6: use separate dynpm module parameter Tested on my M82==RV620 and my new M96==RV730. Also tested on RV515 by Sedat where already posted patch for AtomBIOS's mutex was needed. -- Rafał 0001-drm-radeon-kms-add-dynamic-engine-reclocking-V6.patch Description: Binary data -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: add dynamic engine reclocking (V6)
W dniu 17 grudnia 2009 03:02 użytkownik Rafał Miłecki zaj...@gmail.com napisał: V2: reorganize functions, fix modesetting calls V3: rebase patch, use radeon's workqueue V4: enable on tested chipsets only, request VBLANK IRQs V5: enable PM on older hardware (IRQs, mode_fixup, dpms) V6: use separate dynpm module parameter Tested on my M82==RV620 and my new M96==RV730. Also tested on RV515 by Sedat where already posted patch for AtomBIOS's mutex was needed. Also Nezmer's M92==45xx was downclocked fine. And: bjaglin Zajec: looks like your patch is working just fine on my RV250, down and upclocking when running/stopping glxgears :) -- Rafał -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25682] New: radeon drm (linux 2.6.32) loaded with modeset=1 + 2x ATI 4850 (RV770) in CrossfireX= crash and blank screen
http://bugs.freedesktop.org/show_bug.cgi?id=25682 Summary: radeon drm (linux 2.6.32) loaded with modeset=1 + 2x ATI 4850 (RV770) in CrossfireX= crash and blank screen Product: DRI Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: critical Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: 404erro...@gmail.com Created an attachment (id=32136) -- (http://bugs.freedesktop.org/attachment.cgi?id=32136) Log of the crash From the console of a machine equipped of two ATI 4850 (RV770) linked in CrossfireX loading the radeon kernel module with modeset=1 results in a crash (see attached log) and a black screen. Disabling KMS makes the the radeon kernel module being loaded without any issues. When the screen turns black, the LED of my monitor does not blink so a signal seems to be detected by the monitor (digital connection). If I can be of any help, please just mention what I should do to provide more details/traces/etc. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: enable memory clock reading on legacy
2009/12/16 Rafał Miłecki zaj...@gmail.com: Tested by bjaglin on IRC on RV250. Probably shouldn't enable the mem clock stuff on IGP chips since they use system memory. Alex -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: add dynamic engine reclocking (V6)
2009/12/16 Rafał Miłecki zaj...@gmail.com: V2: reorganize functions, fix modesetting calls V3: rebase patch, use radeon's workqueue V4: enable on tested chipsets only, request VBLANK IRQs V5: enable PM on older hardware (IRQs, mode_fixup, dpms) V6: use separate dynpm module parameter Tested on my M82==RV620 and my new M96==RV730. Also tested on RV515 by Sedat where already posted patch for AtomBIOS's mutex was needed. How does re-clocking happen if no crtcs are active? We will want to be much more aggressive when the displays are off. Alex -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25622] KMS blurry output after initialisation
http://bugs.freedesktop.org/show_bug.cgi?id=25622 --- Comment #5 from Aidan Marks ai...@cisco.com 2009-12-16 23:19:34 PST --- Created an attachment (id=32138) -- (http://bugs.freedesktop.org/attachment.cgi?id=32138) kms_rv790_blurry_on_restore_from_dpms corruption on restore from dpms sleep. seen on 2.6.32 + drm-linus patch (http://files.iniza.org/drm-linus/vanilla-2.6.32/) + V6 pm patch. nothing in dmesg. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
