Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
W dniu 1 grudnia 2009 08:33 użytkownik Michel Dänzer mic...@daenzer.net napisał: On Tue, 2009-12-01 at 08:03 +0100, Rafał Miłecki wrote: 2009/12/1 Alex Deucher alexdeuc...@gmail.com: On Mon, Nov 30, 2009 at 2:02 PM, Alex Deucher alexdeuc...@gmail.com wrote: This enables the use of interrupts on r6xx/r7xx hardware. Interrupts are implemented via a ring buffer. The GPU adds interrupts vectors to the ring and the host reads them off in the interrupt handler. The interrupt controller requires firmware like the CP. This firmware must be installed and accessible to the firmware loader for interrupts to function. Updated patch. fixes some minor issues in the previous one. Same issue with updated one. modprobed radeon, not a one VBLANK. Started X and KDE, got first VBLANK on 48sec and received them cyclic until 87sec. Then it just stopped. Note that vblank interrupts are only supposed to be occur while userspace is waiting for vblank events. Could you tell me how can I wait for vblank from kernel space, please? I see there is drm_wait_vblank but this is not yet exported. I tried export this and use this with _DRM_VBLANK_ABSOLUTE so I hit DRM_WAIT_ON(ret, dev-vbl_queue[crtc], 3 * DRM_HZ, but that was busy waiting I think, as my desktop was almost not usable. Also Alex believe I should *not* use drm_* for syncing my kernel module code with vblank. -- Rafał -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
On Tue, 2009-12-01 at 09:43 +0100, Rafał Miłecki wrote: W dniu 1 grudnia 2009 08:33 użytkownik Michel Dänzer mic...@daenzer.net napisał: On Tue, 2009-12-01 at 08:03 +0100, Rafał Miłecki wrote: 2009/12/1 Alex Deucher alexdeuc...@gmail.com: On Mon, Nov 30, 2009 at 2:02 PM, Alex Deucher alexdeuc...@gmail.com wrote: This enables the use of interrupts on r6xx/r7xx hardware. Interrupts are implemented via a ring buffer. The GPU adds interrupts vectors to the ring and the host reads them off in the interrupt handler. The interrupt controller requires firmware like the CP. This firmware must be installed and accessible to the firmware loader for interrupts to function. Updated patch. fixes some minor issues in the previous one. Same issue with updated one. modprobed radeon, not a one VBLANK. Started X and KDE, got first VBLANK on 48sec and received them cyclic until 87sec. Then it just stopped. Note that vblank interrupts are only supposed to be occur while userspace is waiting for vblank events. Could you tell me how can I wait for vblank from kernel space, please? I see there is drm_wait_vblank but this is not yet exported. I tried export this and use this with _DRM_VBLANK_ABSOLUTE so I hit DRM_WAIT_ON(ret, dev-vbl_queue[crtc], 3 * DRM_HZ, but that was busy waiting I think, as my desktop was almost not usable. Also Alex believe I should *not* use drm_* for syncing my kernel module code with vblank. E.g. you could just call drm_vblank_get() before you need vblank interrupts to occur, drm_vblank_put() after you don't need them anymore and handle the rest from the IRQ handler. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
W dniu 1 grudnia 2009 09:59 użytkownik Michel Dänzer mic...@daenzer.net napisał: Could you tell me how can I wait for vblank from kernel space, please? I see there is drm_wait_vblank but this is not yet exported. I tried export this and use this with _DRM_VBLANK_ABSOLUTE so I hit DRM_WAIT_ON(ret, dev-vbl_queue[crtc], 3 * DRM_HZ, but that was busy waiting I think, as my desktop was almost not usable. Also Alex believe I should *not* use drm_* for syncing my kernel module code with vblank. E.g. you could just call drm_vblank_get() before you need vblank interrupts to occur, drm_vblank_put() after you don't need them anymore and handle the rest from the IRQ handler. Thanks you! I'll try that today later. Could you just explain what is drm_wait_vblank for? I expected it to sleep my process and wake it up interruptible on IRQ. But I'm not sure that anymore. Also it expected drm_file parameter which AFAIK is never passed from gpu driver, but from drm to gpu driver. -- Rafał -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
On Tue, 2009-12-01 at 10:01 +0100, Rafał Miłecki wrote: W dniu 1 grudnia 2009 09:59 użytkownik Michel Dänzer mic...@daenzer.net napisał: Could you tell me how can I wait for vblank from kernel space, please? I see there is drm_wait_vblank but this is not yet exported. I tried export this and use this with _DRM_VBLANK_ABSOLUTE so I hit DRM_WAIT_ON(ret, dev-vbl_queue[crtc], 3 * DRM_HZ, but that was busy waiting I think, as my desktop was almost not usable. Also Alex believe I should *not* use drm_* for syncing my kernel module code with vblank. E.g. you could just call drm_vblank_get() before you need vblank interrupts to occur, drm_vblank_put() after you don't need them anymore and handle the rest from the IRQ handler. Thanks you! I'll try that today later. Could you just explain what is drm_wait_vblank for? I expected it to sleep my process and wake it up interruptible on IRQ. That much is correct. But I'm not sure that anymore. Also it expected drm_file parameter which AFAIK is never passed from gpu driver, but from drm to gpu driver. As it is, it's intended for handling ioctl calls from userspace and as such may make assumptions which weren't satisfied in the context you tried using it from. It might be possible to factor out the core functionality such that it would be more usable from within the kernel, but it'll still only be appropriate for a process context which can afford to sleep for relatively long intervals. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Problem KMS: TTM Failed moving buffer. Proposed placement 0x00060004 / Out of aperture space or DRM memory quota invalid framebuffer id
Todays test with KMS w/o AGP (radeon.agopmode=-1) Starting Xorg I got instead of a normal X session a GDM login again, the last dmesg messages are: [ 904.459254] wlan1: associated [ 1459.645513] [TTM] Failed moving buffer. Proposed placement 0x00060004 [ 1459.645525] [TTM] Out of aperture space or DRM memory quota. [ 1459.645533] [drm:radeon_object_list_validate] *ERROR* radeon: failed to validate. [ 1459.645540] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation ! [ 1461.208487] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id [ 1461.218685] [drm] LVDS-13: set mode 1024x768 1e Linux oddysseus 2.6.32-rc8a #7 Tue Dec 1 10:24:42 CET 2009 i686 GNU/Linux This build is from today with the latest pull till commit d6fdb37126aa4f67484a9962b68963c5d3a506af. If more info is needed, I'' try my best so ask for it. Sincerelly yours C. Hartmann -- ..oooO.. .().Oooo... ..)../.() .(_/...)../. ...(_/... ... I WAS .. .. HERE.. ;) -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25354] Blender crashes on startup on Radeon 7500 (and 9000-9200)
http://bugs.freedesktop.org/show_bug.cgi?id=25354 --- Comment #8 from Michael Strecke mstre...@gmx.de 2009-12-01 04:06:24 PST --- A git-bisection against git://anongit.freedesktop.org/mesa/mesa shows that the problem starts with commit bfbad4fbb7420d3b5e8761c08d197574bfcd44b2. This one does NOT cause blender to segfault. gdb reports that the program exists with code 0352. Output from Blender on the console: drmRadeonCmdBuffer: -22. The next commit in line is 4322181e6a07ecb8891c2d1ada74fd48c996a8fc which makes blender segfault. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Problem KMS: TTM Failed moving buffer. Proposed placement 0x00060004 / Out of aperture space or DRM memory quota invalid framebuffer id
On Tue, Dec 01, 2009 at 11:55:03AM +0100, Christian Hartmann wrote: Todays test with KMS w/o AGP (radeon.agopmode=-1) Starting Xorg I got instead of a normal X session a GDM login again, the last dmesg messages are: [ 904.459254] wlan1: associated [ 1459.645513] [TTM] Failed moving buffer. Proposed placement 0x00060004 [ 1459.645525] [TTM] Out of aperture space or DRM memory quota. [ 1459.645533] [drm:radeon_object_list_validate] *ERROR* radeon: failed to validate. [ 1459.645540] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation ! [ 1461.208487] [drm:drm_mode_getfb] *ERROR* invalid framebuffer id [ 1461.218685] [drm] LVDS-13: set mode 1024x768 1e Full dmesg of when this happen will be helpfull. Cheers, Jerome -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25354] [bisected] Blender crashes on startup on Radeon 7500 (and 9000-9200)
http://bugs.freedesktop.org/show_bug.cgi?id=25354 Geir Ove Myhr gom...@gmail.com changed: What|Removed |Added Summary|Blender crashes on startup |[bisected] Blender crashes |on Radeon 7500 (and 9000- |on startup on Radeon 7500 |9200) |(and 9000-9200) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24322] mesa-7.6 7.7 show bogus rendering wih boswars game
http://bugs.freedesktop.org/show_bug.cgi?id=24322 --- Comment #9 from Thierry Vignaud tvign...@mandriva.com 2009-12-01 08:28:39 PST --- After a little holydays and after having fighted the mesa needs flu syndrom, I've tested the master branch of drm+mesa as of today and here's the results: - the failed assertion on exit doesn't happen anymore (I haven't tested but I supposed it's the same in the 7_6 and 7_7 branches) Do you expect me to still test those branches? - the bogus rendering of the ground on the map is fixed with r300 (but it still happens with r300g (gallium) but it's quite a lot faster though [it's the reverse with openarena which is faster with r300 rather than with r300g]) I'll test your r300-blit branch soon for that. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24322] mesa-7.6 7.7 show bogus rendering wih boswars game
http://bugs.freedesktop.org/show_bug.cgi?id=24322 Fabio fabio@libero.it changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #10 from Fabio fabio@libero.it 2009-12-01 08:57:55 PST --- - the failed assertion on exit doesn't happen anymore (I haven't tested but I supposed it's the same in the 7_6 and 7_7 branches) Do you expect me to still test those branches? I already verified it was fixed also on 7_6 and 7_7 branches. - the bogus rendering of the ground on the map is fixed with r300 Nice, closing this bug then. (but it still happens with r300g (gallium) but it's quite a lot faster though [it's the reverse with openarena which is faster with r300 rather than with r300g]) You may want to open new bugs for these issues. Thanks. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24322] mesa-7.6 7.7 show bogus rendering wih boswars game
http://bugs.freedesktop.org/show_bug.cgi?id=24322 --- Comment #11 from Thierry Vignaud tvign...@mandriva.com 2009-12-01 09:25:56 PST --- Btw, the r300-blit branch is as slow as master. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/2] drm/i915: add GETPARAM request for page flipping
On Thu, 19 Nov 2009 10:49:07 -0800, Jesse Barnes jbar...@virtuousgeek.org wrote: From 3dea813806ecc117fadd2751580018040afefd0b Mon Sep 17 00:00:00 2001 From: Jesse Barnes jbar...@virtuousgeek.org Date: Wed, 18 Nov 2009 04:31:47 + Subject: [PATCH 1/2] drm/i915: add GETPARAM request for page flipping Add a GETPARAM request for checking if page flipping is supported. Useful for the 2D driver to enable the flipping path. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org OK, I've applied this series in what I'm guessing was the desired order: 1) pageflipping support 2) core fixup 3) getparam to say it's ready Also, something seems wonky with your patches. The git am gives me: anh...@gaiman:anholt/src/linux-2.6% git log commit b0f57d0ff95c957b278d7a82d9ebdea395652cfa Author: Jesse Barnes jbar...@virtuousgeek.org Date: Thu Nov 19 10:49:07 2009 -0800 drm/i915: add GETPARAM request for page flipping From 3dea813806ecc117fadd2751580018040afefd0b Mon Sep 17 00:00:00 2001 From: Jesse Barnes jbar...@virtuousgeek.org Date: Wed, 18 Nov 2009 04:31:47 + Subject: [PATCH 1/2] drm/i915: add GETPARAM request for page flipping Add a GETPARAM request for checking if page flipping is supported. Useful for the 2D driver to enable the flipping path. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Signed-off-by: Eric Anholt e...@anholt.net Are you not using git send-email? -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/2] drm/i915: add GETPARAM request for page flipping
On Tue, 01 Dec 2009 09:18:51 -0800 Eric Anholt e...@anholt.net wrote: On Thu, 19 Nov 2009 10:49:07 -0800, Jesse Barnes jbar...@virtuousgeek.org wrote: From 3dea813806ecc117fadd2751580018040afefd0b Mon Sep 17 00:00:00 2001 From: Jesse Barnes jbar...@virtuousgeek.org Date: Wed, 18 Nov 2009 04:31:47 + Subject: [PATCH 1/2] drm/i915: add GETPARAM request for page flipping Add a GETPARAM request for checking if page flipping is supported. Useful for the 2D driver to enable the flipping path. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org OK, I've applied this series in what I'm guessing was the desired order: 1) pageflipping support 2) core fixup 3) getparam to say it's ready Also, something seems wonky with your patches. The git am gives me: anh...@gaiman:anholt/src/linux-2.6% git log commit b0f57d0ff95c957b278d7a82d9ebdea395652cfa Author: Jesse Barnes jbar...@virtuousgeek.org Date: Thu Nov 19 10:49:07 2009 -0800 drm/i915: add GETPARAM request for page flipping From 3dea813806ecc117fadd2751580018040afefd0b Mon Sep 17 00:00:00 2001 From: Jesse Barnes jbar...@virtuousgeek.org Date: Wed, 18 Nov 2009 04:31:47 + Subject: [PATCH 1/2] drm/i915: add GETPARAM request for page flipping Add a GETPARAM request for checking if page flipping is supported. Useful for the 2D driver to enable the flipping path. Signed-off-by: Jesse Barnes jbar...@virtuousgeek.org Signed-off-by: Eric Anholt e...@anholt.net Are you not using git send-email? No, I used format-patch and then sent them by hand. git am should still work though, unless I got the -- wrong somehow... -- Jesse Barnes, Intel Open Source Technology Center -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
W dniu 1 grudnia 2009 10:08 użytkownik Michel Dänzer mic...@daenzer.net napisał: But I'm not sure that anymore. Also it expected drm_file parameter which AFAIK is never passed from gpu driver, but from drm to gpu driver. As it is, it's intended for handling ioctl calls from userspace and as such may make assumptions which weren't satisfied in the context you tried using it from. It might be possible to factor out the core functionality such that it would be more usable from within the kernel, but it'll still only be appropriate for a process context which can afford to sleep for relatively long intervals. I need that for reclocking which runs on separated context in driver's own workqueue. So that would be fine. -- Rafał -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
W dniu 1 grudnia 2009 09:59 użytkownik Michel Dänzer mic...@daenzer.net napisał: On Tue, 2009-12-01 at 09:43 +0100, Rafał Miłecki wrote: Could you tell me how can I wait for vblank from kernel space, please? I see there is drm_wait_vblank but this is not yet exported. I tried export this and use this with _DRM_VBLANK_ABSOLUTE so I hit DRM_WAIT_ON(ret, dev-vbl_queue[crtc], 3 * DRM_HZ, but that was busy waiting I think, as my desktop was almost not usable. Also Alex believe I should *not* use drm_* for syncing my kernel module code with vblank. E.g. you could just call drm_vblank_get() before you need vblank interrupts to occur, drm_vblank_put() after you don't need them anymore and handle the rest from the IRQ handler. Are you sure that drm can prevent radeon from receiving interrupts from GPU? As I told, I've added debugging in r600.c:r600_irq_process on D1 vblank. I've tried your method anyway: I call drm_vblank_get(rdev-ddev, 0); when I decide to reclock and then drm_vblank_put(rdev-ddev, 0); when I actually reclock. This didn't help. My log looks like this: [ 182.205078] [drm] [DBG] set planned action to UPCLOCK [ 182.205400] [drm] IH: D1 vblank [ 182.205427] [drm] [DBG] reclocking, setting to 68 kHz [ 182.222075] [drm] IH: D1 vblank [ 182.238723] [drm] IH: D1 vblank [ 182.255438] [drm] IH: D1 vblank [ 182.272118] [drm] IH: D1 vblank [ 182.288796] [drm] IH: D1 vblank [ 182.305090] [drm] [DBG] set planned action to DOWNCLOCK [ 182.305475] [drm] IH: D1 vblank [ 182.305501] [drm] [DBG] reclocking, setting to 34 kHz [ 182.322088] [drm] IH: D1 vblank [ 182.338794] [drm] IH: D1 vblank [ 182.405079] [drm] [DBG] set planned action to UPCLOCK not a one more vblank comes after that I've also tried starting glxgears or openarena, but this didn't make driver receive any more VBLANK IRQ. However when I enabled debugging I've noticed this: [ 279.550094] [drm] r600_irq_process start: rptr 32144, wptr 32160 [ 279.550118] [drm] IH: CP int: 0x [ 279.550240] [drm] r600_irq_process start: rptr 32160, wptr 32176 [ 279.550264] [drm] IH: CP int: 0x [ 279.550404] [drm] r600_irq_process start: rptr 32176, wptr 32192 [ 279.550424] [drm] IH: CP int: 0x [ 279.550483] [drm] r600_irq_process start: rptr 32192, wptr 32208 [ 279.550503] [drm] IH: CP int: 0x [ 279.550668] [drm] r600_irq_process start: rptr 32208, wptr 32224 [ 279.550689] [drm] IH: CP int: 0x [ 279.550744] [drm] r600_irq_process start: rptr 32224, wptr 32240 [ 279.550765] [drm] IH: CP int: 0x [ 279.550928] [drm] r600_irq_process start: rptr 32240, wptr 32256 [ 279.550948] [drm] IH: CP int: 0x [ 279.551003] [drm] r600_irq_process start: rptr 32256, wptr 32272 [ 279.551024] [drm] IH: CP int: 0x [ 279.552428] [drm] r600_irq_process start: rptr 32272, wptr 32288 [ 279.552450] [drm] IH: CP int: 0x After I stop receiving any VBLANK interrupts I receive tons on CP int. Any more tips? :| -- Rafał -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Fix sync to vblank when VGA output is turned off
On Mon, 09 Nov 2009 12:51:22 +0800, Li Peng peng...@linux.intel.com wrote: In current vblank-wait implementation, if we turn off VGA output, drm_wait_vblank will still wait on the disabled pipe until timeout, because vblank on the pipe is assumed be enabled. This would cause slow system response on some system such as moblin. This patch resolve the issue by adding a drm helper function drm_vblank_off which explicitly clear vblank_enabled[crtc], wake up any waiting queue and save last vblank counter before turning off crtc. It also slightly change drm_vblank_get to ensure that we will will return immediately if trying to wait on a disabled pipe. Signed-off-by: Li Peng peng...@intel.com Applied. Thanks! -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm/i915: Fix sync to vblank when VGA output is turned off
On Tue, 01 Dec 2009 10:28:17 -0800 Eric Anholt e...@anholt.net wrote: On Mon, 09 Nov 2009 12:51:22 +0800, Li Peng peng...@linux.intel.com wrote: In current vblank-wait implementation, if we turn off VGA output, drm_wait_vblank will still wait on the disabled pipe until timeout, because vblank on the pipe is assumed be enabled. This would cause slow system response on some system such as moblin. This patch resolve the issue by adding a drm helper function drm_vblank_off which explicitly clear vblank_enabled[crtc], wake up any waiting queue and save last vblank counter before turning off crtc. It also slightly change drm_vblank_get to ensure that we will will return immediately if trying to wait on a disabled pipe. Signed-off-by: Li Peng peng...@intel.com Applied. Thanks! Kristian, I think we'll need to tie into this for outstanding page flips at DPMS off time. If we DPMS off while one is pending, I think we should complete it immediately and send the event. I'm not sure what to do about the case where we received the flip pending interrupt but haven't received the vblank event though... Presumably in that case the base register will have been updated, but if not I'm not sure what will happen... -- Jesse Barnes, Intel Open Source Technology Center -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
On Mon, Nov 30, 2009 at 6:11 PM, Alex Deucher alexdeuc...@gmail.com wrote:
On Mon, Nov 30, 2009 at 2:02 PM, Alex Deucher alexdeuc...@gmail.com wrote:
This enables the use of interrupts on r6xx/r7xx hardware. Interrupts
are implemented via a ring buffer. The GPU adds interrupts vectors to
the ring and the host reads them off in the interrupt handler. The
interrupt controller requires firmware like the CP. This firmware
must be installed and accessible to the firmware loader for interrupts
to function.
Updated patch. fixes some minor issues in the previous one.
Round 3.
Alex
From dba48f0b17c661b7650ff796c38bea172c89b8b3 Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Tue, 1 Dec 2009 13:43:46 -0500
Subject: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips (v3)
This enables the use of interrupts on r6xx/r7xx hardware.
Interrupts are implemented via a ring buffer. The GPU adds
interrupts vectors to the ring and the host reads them off
in the interrupt handler. The interrupt controller requires
firmware like the CP. This firmware must be installed and
accessble to the firmware loader for interrupts to function.
MSIs don't seem to work on my RS780. They work fine on all
my discrete cards. I'm not sure about other RS780s or
RS880s. I've disabled MSIs on RS780 and RS880, but it would
probably be worth checking on some other systems.
v2 - fix some checkpatch.pl problems;
re-read the disp int status reg if we restart the ih;
v3 - remove the irq handler if r600_irq_init() fails;
remove spinlock in r600_ih_ring_fini();
move ih rb overflow check to r600_get_ih_wptr();
move irq ack to separate function;
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/r600.c | 561 +--
drivers/gpu/drm/radeon/r600_blit_kms.c |4 +-
drivers/gpu/drm/radeon/r600d.h | 159 +-
drivers/gpu/drm/radeon/radeon.h | 26 ++-
drivers/gpu/drm/radeon/radeon_asic.h|2 +
drivers/gpu/drm/radeon/radeon_device.c |2 +
drivers/gpu/drm/radeon/radeon_drv.h |1 -
drivers/gpu/drm/radeon/radeon_fence.c | 38 --
drivers/gpu/drm/radeon/radeon_irq_kms.c | 12 +-
drivers/gpu/drm/radeon/rv770.c | 24 ++-
10 files changed, 754 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index 8d6bc12..ed4759d 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -38,8 +38,10 @@
#define PFP_UCODE_SIZE 576
#define PM4_UCODE_SIZE 1792
+#define RLC_UCODE_SIZE 768
#define R700_PFP_UCODE_SIZE 848
#define R700_PM4_UCODE_SIZE 1360
+#define R700_RLC_UCODE_SIZE 1024
/* Firmware Names */
MODULE_FIRMWARE(radeon/R600_pfp.bin);
@@ -62,6 +64,8 @@ MODULE_FIRMWARE(radeon/RV730_pfp.bin);
MODULE_FIRMWARE(radeon/RV730_me.bin);
MODULE_FIRMWARE(radeon/RV710_pfp.bin);
MODULE_FIRMWARE(radeon/RV710_me.bin);
+MODULE_FIRMWARE(radeon/R600_rlc.bin);
+MODULE_FIRMWARE(radeon/R700_rlc.bin);
int r600_debugfs_mc_info_init(struct radeon_device *rdev);
@@ -1110,11 +1114,12 @@ void r600_cp_stop(struct radeon_device *rdev)
WREG32(R_0086D8_CP_ME_CNTL, S_0086D8_CP_ME_HALT(1));
}
-int r600_cp_init_microcode(struct radeon_device *rdev)
+int r600_init_microcode(struct radeon_device *rdev)
{
struct platform_device *pdev;
const char *chip_name;
- size_t pfp_req_size, me_req_size;
+ const char *rlc_chip_name;
+ size_t pfp_req_size, me_req_size, rlc_req_size;
char fw_name[30];
int err;
@@ -1128,30 +1133,62 @@ int r600_cp_init_microcode(struct radeon_device *rdev)
}
switch (rdev-family) {
- case CHIP_R600: chip_name = R600; break;
- case CHIP_RV610: chip_name = RV610; break;
- case CHIP_RV630: chip_name = RV630; break;
- case CHIP_RV620: chip_name = RV620; break;
- case CHIP_RV635: chip_name = RV635; break;
- case CHIP_RV670: chip_name = RV670; break;
+ case CHIP_R600:
+ chip_name = R600;
+ rlc_chip_name = R600;
+ break;
+ case CHIP_RV610:
+ chip_name = RV610;
+ rlc_chip_name = R600;
+ break;
+ case CHIP_RV630:
+ chip_name = RV630;
+ rlc_chip_name = R600;
+ break;
+ case CHIP_RV620:
+ chip_name = RV620;
+ rlc_chip_name = R600;
+ break;
+ case CHIP_RV635:
+ chip_name = RV635;
+ rlc_chip_name = R600;
+ break;
+ case CHIP_RV670:
+ chip_name = RV670;
+ rlc_chip_name = R600;
+ break;
case CHIP_RS780:
- case CHIP_RS880: chip_name = RS780; break;
- case CHIP_RV770: chip_name = RV770; break;
+ case CHIP_RS880:
+ chip_name = RS780;
+ rlc_chip_name = R600;
+ break;
+ case CHIP_RV770:
+ chip_name = RV770;
+ rlc_chip_name = R700;
+ break;
case CHIP_RV730:
- case CHIP_RV740: chip_name = RV730; break;
- case CHIP_RV710: chip_name = RV710; break;
+ case CHIP_RV740:
+ chip_name = RV730;
+ rlc_chip_name = R700;
+ break;
+ case CHIP_RV710:
+ chip_name = RV710;
+ rlc_chip_name = R700;
+ break;
default: BUG();
}
if (rdev-family = CHIP_RV770) {
[PATCH] drm/radeon/kms: add tv standard property to tv connectors
From ca209ade406e572785187a15e7b45ac09cbbf642 Mon Sep 17 00:00:00 2001 From: Alex Deucher alexdeuc...@gmail.com Date: Tue, 1 Dec 2009 14:12:14 -0500 Subject: [PATCH] drm/radeon/kms: add tv standard property to tv connectors Lets user select tv-standard. The property was there, just not hooked up. Signed-off-by: Alex Deucher alexdeuc...@gmail.com --- drivers/gpu/drm/radeon/radeon_connectors.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c index 41fcd5b..93f3d3c 100644 --- a/drivers/gpu/drm/radeon/radeon_connectors.c +++ b/drivers/gpu/drm/radeon/radeon_connectors.c @@ -1106,6 +1106,9 @@ radeon_add_atom_connector(struct drm_device *dev, drm_connector_attach_property(radeon_connector-base, rdev-mode_info.load_detect_property, 1); + drm_connector_attach_property(radeon_connector-base, + rdev-mode_info.tv_std_property, + 1); } break; case DRM_MODE_CONNECTOR_LVDS: @@ -1239,6 +1242,9 @@ radeon_add_legacy_connector(struct drm_device *dev, drm_connector_attach_property(radeon_connector-base, rdev-mode_info.load_detect_property, 1); + drm_connector_attach_property(radeon_connector-base, + rdev-mode_info.tv_std_property, + 1); } break; case DRM_MODE_CONNECTOR_LVDS: -- 1.5.6.3 From ca209ade406e572785187a15e7b45ac09cbbf642 Mon Sep 17 00:00:00 2001 From: Alex Deucher alexdeuc...@gmail.com Date: Tue, 1 Dec 2009 14:12:14 -0500 Subject: [PATCH] drm/radeon/kms: add tv standard property to tv connectors Lets user select tv-standard. The property was there, just not hooked up. Signed-off-by: Alex Deucher alexdeuc...@gmail.com --- drivers/gpu/drm/radeon/radeon_connectors.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c b/drivers/gpu/drm/radeon/radeon_connectors.c index 41fcd5b..93f3d3c 100644 --- a/drivers/gpu/drm/radeon/radeon_connectors.c +++ b/drivers/gpu/drm/radeon/radeon_connectors.c @@ -1106,6 +1106,9 @@ radeon_add_atom_connector(struct drm_device *dev, drm_connector_attach_property(radeon_connector-base, rdev-mode_info.load_detect_property, 1); + drm_connector_attach_property(radeon_connector-base, + rdev-mode_info.tv_std_property, + 1); } break; case DRM_MODE_CONNECTOR_LVDS: @@ -1239,6 +1242,9 @@ radeon_add_legacy_connector(struct drm_device *dev, drm_connector_attach_property(radeon_connector-base, rdev-mode_info.load_detect_property, 1); + drm_connector_attach_property(radeon_connector-base, + rdev-mode_info.tv_std_property, + 1); } break; case DRM_MODE_CONNECTOR_LVDS: -- 1.5.6.3 -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 22852] [r300 KMS] modesetting not accepted by monitor
http://bugs.freedesktop.org/show_bug.cgi?id=22852 --- Comment #12 from Arno Schuring aelschur...@hotmail.com 2009-12-01 12:22:03 PST --- Firstly: this is getting way off from the original problem. Should I change the summary to reflect this? (In reply to comment #10) xrandr's --current option makes use of this call, which is available since xrandr 1.3 and xserver 1.6. Indeed, I can confirm that $ xrandr --current does not make the screen flicker. (In reply to comment #11) If all of your connectors have a monitor connected, the driver shouldn't even be using load detection since it's able to get an edid from the monitor. I think I understand what's going on now. The flickering is caused by load detection on the S-video port (the only one without a monitor). The non-kms configuration defaults to load_detection=0 on that port, but the flicker appears as soon as I set it to 1: aschur...@neminis:~$ xrandr --verbose | egrep ^[A-Z]\|load\|CRT VGA-0 connected [..] CRTC: 0 CRTCs: 0 1 load_detection: 0 (0x) range: (0,1) DVI-0 connected [..] CRTC: 1 CRTCs: 0 1 load_detection: 0 (0x) range: (0,1) S-video disconnected [..] CRTCs: 0 1 load_detection: 1 (0x0001) range: (0,1) In KMS mode however, I can't disable the load detection (or at least it has no effect): aschur...@neminis:~$ xrandr --verbose | egrep ^[A-Z]\|load VGA-0 connected [..] load detection: 0 (0x) range: (1,0) DVI-0 connected [..] load detection: 0 (0x) range: (1,0) S-video disconnected [..] load detection: 0 (0x) range: (1,0) With all load detection set to 0, the screen still flickers. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25290] R600: Doesn't correctly handle glFrontFace(GL_CW)
http://bugs.freedesktop.org/show_bug.cgi?id=25290 --- Comment #1 from Alex Deucher ag...@yahoo.com 2009-12-01 12:47:50 PST --- Created an attachment (id=31633) -- (http://bugs.freedesktop.org/attachment.cgi?id=31633) select proper front/back face in polygon mode This patch seems to fix the issue here. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25297] R600: glEdgeFlag doesn't work
http://bugs.freedesktop.org/show_bug.cgi?id=25297 --- Comment #1 from Alex Deucher ag...@yahoo.com 2009-12-01 12:50:44 PST --- the software renderer doesn't seem to render the test properly for me, however, the patch I included on bug 25290 seems like it renders correctly. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25383] New: DRM: R600 packet issues and IRQs disabled?
http://bugs.freedesktop.org/show_bug.cgi?id=25383 Summary: DRM: R600 packet issues and IRQs disabled? Product: DRI Version: XOrg CVS Platform: x86-64 (AMD64) OS/Version: All Status: NEW Keywords: have-backtrace Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: piroisl...@yahoo.com Sabayon Linux 5.1 X86_64 KDE 4.3 kernel 2.6.32-rc7-git1 mesa 7.6 xorg-server 1.7.1 radeonhd driver 1.3.0 issues found trying to use quantz 64 bit version. (game) http://www.reddit.com/r/linux_gaming/comments/a9x8d/quantz_beta_for_linux_64_bits_alsa_pulseaudio_now/ IRQ's not enabled, falling back to busy waits: 2 0 drmRadeonCmdBuffer: -22. Kernel failed to parse or rejected command stream. See dmesg for more info. [ 3219.949400] [drm:r600_cs_packet_next_reloc_nomm] *ERROR* No packet3 for relocation for packet at 47. [ 3219.949404] [drm:r600_packet3_check] *ERROR* bad SET_CONTEXT_REG 0x28014 [ 3219.949406] [drm:r600_cs_legacy] *ERROR* Invalid command stream ! [ 3221.525359] [drm:r600_cs_packet_next_reloc_nomm] *ERROR* No packet3 for relocation for packet at 47. [ 3221.525363] [drm:r600_packet3_check] *ERROR* bad SET_CONTEXT_REG 0x28014 [ 3221.525366] [drm:r600_cs_legacy] *ERROR* Invalid command stream ! xorg also crashes on first boot. have to login via bash then type /etc/init.d/xdm restart; exit to get x to restart and it works. It always fails the first time. logs show this... (II) XINPUT: Adding extended input device AT Translated Set 2 keyboard (type: KEYBOARD) (**) Option xkb_rules evdev (**) Option xkb_model evdev (**) Option xkb_layout us [mi] EQ overflowing. The server is probably stuck in an infinite loop. Backtrace: 0: /usr/bin/X (xorg_backtrace+0x28) [0x4a6ce8] 1: /usr/bin/X (mieqEnqueue+0x1f4) [0x4a6b64] 2: /usr/bin/X (xf86PostMotionEventP+0xce) [0x48438e] 3: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7ffb08dde000+0x537f) [0x7ffb08de337f] 4: /usr/bin/X (0x40+0x7e2e7) [0x47e2e7] 5: /usr/bin/X (0x40+0x1114a4) [0x5114a4] 6: /lib/libpthread.so.0 (0x7ffb312a9000+0xea10) [0x7ffb312b7a10] 7: /lib/libc.so.6 (__libc_fork+0xb4) [0x7ffb303cebc4] 8: /usr/bin/X (Popen+0xa5) [0x4690a5] 9: /usr/bin/X (XkbDDXLoadKeymapByNames+0x1a9) [0x565549] 10: /usr/bin/X (XkbCompileKeymap+0xc6) [0x5659d6] 11: /usr/bin/X (InitKeyboardDeviceStruct+0x398) [0x4f4bf8] 12: /usr/lib64/xorg/modules/input/evdev_drv.so (0x7ffb08dde000+0x4e2c) [0x7ffb08de2e2c] 13: /usr/bin/X (ActivateDevice+0x46) [0x440896] 14: /usr/bin/X (0x40+0x84976) [0x484976] 15: /usr/bin/X (NewInputDeviceRequest+0x1aa) [0x484c7a] 16: /usr/bin/X (0x40+0x5624b) [0x45624b] 17: /usr/bin/X (0x40+0x56864) [0x456864] 18: /usr/bin/X (0x40+0x56982) [0x456982] 19: /usr/bin/X (0x40+0x56ee5) [0x456ee5] 20: /usr/bin/X (0x40+0x5bad8) [0x45bad8] 21: /usr/bin/X (WaitForSomething+0x4b3) [0x45c073] 22: /usr/bin/X (0x40+0x2a132) [0x42a132] 23: /usr/bin/X (0x40+0x24f3c) [0x424f3c] 24: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7ffb3034fa3d] 25: /usr/bin/X (0x40+0x24ae9) [0x424ae9] (II) config/hal: Adding input device Power Button (**) Power Button: always reports core events (**) Power Button: Device: /dev/input/event1 (II) Power Button: Found keys (II) Power Button: Configuring as keyboard (II) XINPUT: Adding extended input device Power Button (type: KEYBOARD) (**) Option xkb_rules evdev (**) Option xkb_model evdev (**) Option xkb_layout us (II) config/hal: Adding input device Video Bus (**) Video Bus: always reports core events (**) Video Bus: Device: /dev/input/event5 (II) Video Bus: Found keys (II) Video Bus: Configuring as keyboard (II) XINPUT: Adding extended input device Video Bus (type: KEYBOARD) (**) Option xkb_rules evdev (**) Option xkb_model evdev (**) Option xkb_layout us (II) config/hal: Adding input device Power Button (**) Power Button: always reports core events (**) Power Button: Device: /dev/input/event2 (II) Power Button: Found keys (II) Power Button: Configuring as keyboard (II) XINPUT: Adding extended input device Power Button (type: KEYBOARD) (**) Option xkb_rules evdev (**) Option xkb_model evdev (**) Option xkb_layout us (II) AIGLX: Suspending AIGLX clients for VT switch Output LCD1 disable success Blank CRTC 0 success Disable CRTC 0 success Blank CRTC 1 success Disable CRTC 1 success (II) RADEON(0): RADEONRestoreMemMapRegisters() : (II) RADEON(0): MC_FB_LOCATION : 0x00ff00e0 0x00ef00d0 (II) RADEON(0): MC_AGP_LOCATION : 0x (II) RADEON(0): avivo_restore ! Enable CRTC 0 success Unblank CRTC 0 success (II) Power Button: Close (II) UnloadModule: evdev (II) Video Bus: Close (II) UnloadModule: evdev (II) Power Button: Close (II) UnloadModule: evdev (II) AT Translated Set 2 keyboard: Close (II) UnloadModule: evdev (II) ImPS/2 Logitech Wheel Mouse: Close (II) UnloadModule: evdev (II) RADEON(0): [drm] removed 1 reserved context for kernel
[Bug 25354] [bisected] Blender crashes on startup on Radeon 7500 (and 9000-9200)
http://bugs.freedesktop.org/show_bug.cgi?id=25354 --- Comment #9 from Alex Deucher ag...@yahoo.com 2009-12-01 13:27:23 PST --- Created an attachment (id=31638) -- (http://bugs.freedesktop.org/attachment.cgi?id=31638) possible fix for r2xx Does this patch help for the r2xx cards (9000,9200, etc.)? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25383] DRM: R600 packet issues and IRQs disabled?
http://bugs.freedesktop.org/show_bug.cgi?id=25383 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTABUG --- Comment #1 from Alex Deucher ag...@yahoo.com 2009-12-01 13:30:33 PST --- Support for irqs on r6xx+ is not available in your kernel. I just posted the patches to dri-devel today. As to the packet errors, you need a newer mesa; either the 7.6 or 7.7 branch or git master. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25290] R600: Doesn't correctly handle glFrontFace(GL_CW)
http://bugs.freedesktop.org/show_bug.cgi?id=25290 --- Comment #2 from monraaf monr...@gmail.com 2009-12-01 13:54:10 PST --- Hmm, with the patch the test program runs correctly, but if I comment out glFrontFace(GL_CW) in the test program, the situation is reversed. It will render a solid triangle while the software renderer renders an outline triangle. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25297] R600: glEdgeFlag doesn't work
http://bugs.freedesktop.org/show_bug.cgi?id=25297 --- Comment #2 from monraaf monr...@gmail.com 2009-12-01 13:59:22 PST --- The attached image is what I get with the software renderer, and I think is the correct way. With or without that patch I don't get the same image. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25297] R600: glEdgeFlag doesn't work
http://bugs.freedesktop.org/show_bug.cgi?id=25297 --- Comment #3 from monraaf monr...@gmail.com 2009-12-01 14:00:41 PST --- Created an attachment (id=31642) -- (http://bugs.freedesktop.org/attachment.cgi?id=31642) test program run with software renderer -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
2009/12/1 Alex Deucher alexdeuc...@gmail.com: Round 3. This fixed my lose of VBLANK interrupts after few seconds, but I still have issue with fences after applying this. My rdev-fence_drv.emited gets filled when I start glxgears and when I stop, it gets empty. Reverting patch makes rdev-fence_drv.emited filled after starting X for the whole time. -- Rafał -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re:
On Fri, Nov 20, 2009 at 11:29 PM, Jerome Glisse jgli...@redhat.com wrote: This patch series add ttm range validation function. Aim is to include this in 2.6.33 so i have time to iron out issue, comments. I missed these first time around, Thomas if you have any opinions on the TTM stuff please see if you can take a look. ttm: I duplicated a bunch of ttm functions but now i think, best would be to add range to all function and use free list if range cover all the manager space. Doing so we might also be able to simplify mem_space alocation into a simpler function like ttm_bo_mem_space_range radeon: The second patch is a rework/cleanup of radeon object, it solves few issues along the way (i can't remember them now after fews days testing the patches). Biggest change is that we now rely on BO being validated before doing any change to radeon bo structure. As with any big patch i might introduce regressions, so far after testing on AGP:R1XX,R2XX,R3XX,R6XX PCIE:R3XX,R4XX,R5XX,R6XX,R7XX and RS480,RS690 i didn't found anythings obvious (test being X + glxgears + compiz(on hw which support it) + suspend/resume). I'll try and take a look at this here it doesn't seem to depend on the first patch so I can push it separate if needed. Dave. Last patch is smaller, it just use the interface introduced by the first patch. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
945GM crash
Hi guys, A bug reported initially here (Fedora 12) https://bugzilla.redhat.com/show_bug.cgi?id=541879 and then replicated here (Toped) http://code.google.com/p/toped/issues/detail?id=21colspec=ID%20Type%20Summary%20Component%20OpSys%20Owner%20Status%20Priority http://code.google.com/p/toped/issues/detail?id=21colspec=ID%20Type%20Summary%20Component%20OpSys%20Owner%20Status%20Priority You can see from the bug reports that it involves Mesa DRI Intel(R) 945GM GEM 20090712 2009Q2 RC3 driver. The application uses glew library. After calling the glewInit(), the first call to the openGL function which is glGenBuffers is causing the application to crash. It's a cross platform application which works on other graphic platforms/drivers on Linux as well as on Windows. Is there something I'm missing in the initialization sequence? Or there is a problem with the driver? Shall I raise a bug? If that's not the proper mailing list - please advice I'll appreciate your help Regards Svilen -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25193] kwin corruption with 286bf89e5a1fc931dbf523ded861b809859485e2
http://bugs.freedesktop.org/show_bug.cgi?id=25193 --- Comment #17 from Ed Tomlinson e...@aei.ca 2009-12-01 16:29:17 PST --- The corruption still exists at 09325b9ff456ae475069bac5a04cf10a32235e43 on master. It also is present in 7.7-rc1. Reverting 286bf89e5a1fc931dbf523ded861b809859485e2 still fixes it on head. Its probably a good idea to fix this before 7.7-rc2 is released... -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
drm git branches revisited
So I'm going to change the layout of my git branches again, because my current plan isn't working for me. At the moment drm-next is considered the branch to base new work off and to also for downstream trees to pull from, this is changing. I will now maintain drm-core-next : a branch with all the core DRM/KMS changes in it, please base all downstream sub-driver trees from this branch in the future. This branch will not rebase, it may pull in a downstream driver tree in the pre-merge window time, and/or when some patch from that tree is required for a patch to the mainline. This will be the basis of any trees I send to Linus. drm-radeon-next: a tree like Eric's drm-intel-next where radeon specific changes will be queued up. drm-next: This tree will be rebased quite regularly (2-3 days) with a git pull of the latest, drm-core-next, drm-radeon-next and drm-intel-next, so that the code in drm-next is tested better. You should use this tree for testing latest drm stuff with an eye to the next Linus kernel. Radeon (users) drm-radeon-testing: this will be a rebased tree containing drm-core-next, drm-radeon-next and some changes that we aren't fully committed to yet. For radeon KMS users this is probably the best bleeding edge tree. From time to time I will also have throwaway trees for merging to Linus, I'll probably merge these into drm-next and drm-radeon-testing from time to time until Linus pulls them. Hopefully this works out better for me, though I suspect I need some sort of self discipline measures. Dave. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25354] [bisected] Blender crashes on startup on Radeon 7500 (and 9000-9200)
http://bugs.freedesktop.org/show_bug.cgi?id=25354 --- Comment #10 from Geir Ove Myhr gom...@gmail.com 2009-12-01 21:09:00 PST --- (In reply to comment #9) Does this patch help for the r2xx cards (9000,9200, etc.)? I have built the current Ubuntu package (7.6.0 + some patches from 7.6.1) with this patch so that the users with r2xx cards may try it. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: don't use bios dividers for lvds on r4xx
From 7f15ad08efb8b58ea572689dbada7da1d3624a8c Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Wed, 2 Dec 2009 00:59:37 -0500
Subject: [PATCH] drm/radeon/kms: don't use bios dividers for lvds on r4xx
R4xx cards don't have lvds pll dividers since they use atom.
should fix rh bug 541562
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 22 --
1 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index c1e1706..6f3ff8b 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -796,18 +796,20 @@ static void radeon_set_pll(struct drm_crtc
*crtc, struct drm_display_mode *mode)
if (encoder-encoder_type != DRM_MODE_ENCODER_DAC)
pll_flags |= RADEON_PLL_NO_ODD_POST_DIV;
if (encoder-encoder_type == DRM_MODE_ENCODER_LVDS) {
- struct radeon_encoder *radeon_encoder =
to_radeon_encoder(encoder);
- struct radeon_encoder_lvds *lvds = (struct
radeon_encoder_lvds
*)radeon_encoder-enc_priv;
- if (lvds) {
- if (lvds-use_bios_dividers) {
- pll_ref_div =
lvds-panel_ref_divider;
- pll_fb_post_div =
(lvds-panel_fb_divider |
-
(lvds-panel_post_divider 16));
- htotal_cntl = 0;
- use_bios_divs = true;
+ if (!rdev-is_atom_bios) {
+ struct radeon_encoder *radeon_encoder =
to_radeon_encoder(encoder);
+ struct radeon_encoder_lvds *lvds =
(struct radeon_encoder_lvds
*)radeon_encoder-enc_priv;
+ if (lvds) {
+ if (lvds-use_bios_dividers) {
+ pll_ref_div =
lvds-panel_ref_divider;
+ pll_fb_post_div =
(lvds-panel_fb_divider |
+
(lvds-panel_post_divider 16));
+ htotal_cntl = 0;
+ use_bios_divs = true;
+ }
}
+ pll_flags |= RADEON_PLL_USE_REF_DIV;
}
- pll_flags |= RADEON_PLL_USE_REF_DIV;
}
}
}
--
1.5.6.3
From 7f15ad08efb8b58ea572689dbada7da1d3624a8c Mon Sep 17 00:00:00 2001
From: Alex Deucher alexdeuc...@gmail.com
Date: Wed, 2 Dec 2009 00:59:37 -0500
Subject: [PATCH] drm/radeon/kms: don't use bios dividers for lvds on r4xx
R4xx cards don't have lvds pll dividers since they use atom.
should fix rh bug 541562
Signed-off-by: Alex Deucher alexdeuc...@gmail.com
---
drivers/gpu/drm/radeon/radeon_legacy_crtc.c | 22 --
1 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
index c1e1706..6f3ff8b 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_crtc.c
@@ -796,18 +796,20 @@ static void radeon_set_pll(struct drm_crtc *crtc, struct drm_display_mode *mode)
if (encoder-encoder_type != DRM_MODE_ENCODER_DAC)
pll_flags |= RADEON_PLL_NO_ODD_POST_DIV;
if (encoder-encoder_type == DRM_MODE_ENCODER_LVDS) {
-struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
-struct radeon_encoder_lvds *lvds = (struct radeon_encoder_lvds *)radeon_encoder-enc_priv;
-if (lvds) {
- if (lvds-use_bios_dividers) {
- pll_ref_div = lvds-panel_ref_divider;
- pll_fb_post_div = (lvds-panel_fb_divider |
- (lvds-panel_post_divider 16));
- htotal_cntl = 0;
- use_bios_divs = true;
+if (!rdev-is_atom_bios) {
+ struct radeon_encoder *radeon_encoder = to_radeon_encoder(encoder);
+ struct radeon_encoder_lvds *lvds = (struct radeon_encoder_lvds *)radeon_encoder-enc_priv;
+ if (lvds) {
+ if (lvds-use_bios_dividers) {
+ pll_ref_div = lvds-panel_ref_divider;
+ pll_fb_post_div = (lvds-panel_fb_divider |
+ (lvds-panel_post_divider 16));
+ htotal_cntl = 0;
+ use_bios_divs = true;
+ }
}
+ pll_flags |= RADEON_PLL_USE_REF_DIV;
}
-pll_flags |=
Re:
Dave Airlie wrote: On Fri, Nov 20, 2009 at 11:29 PM, Jerome Glisse jgli...@redhat.com wrote: This patch series add ttm range validation function. Aim is to include this in 2.6.33 so i have time to iron out issue, comments. I missed these first time around, Thomas if you have any opinions on the TTM stuff please see if you can take a look. Sure, I'll take a look. /Thomas -- Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
