Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
2009/12/1 Rafał Miłecki zaj...@gmail.com: 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 Hi There I've tested your patches in the drm-radeon-testing tree on a radeon 4650 (RV730) I added the R700 firmware to the firmware makefile too it's compiled into the kernel - before it used to hang waiting on it However when I boot with this kernel, KMS doesn't work correctly - it generates white noise on my HDMI connected screen. Unfortunately I don't have another screen to test this on, not even a VGA one Just wanted to check to see if this was a known issue or if the patches in drm-radeon-testing are stale Cheers Mike -- 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/7 Mike Lothian m...@fireburn.co.uk: 2009/12/1 Rafał Miłecki zaj...@gmail.com: 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 Hi There I've tested your patches in the drm-radeon-testing tree on a radeon 4650 (RV730) I added the R700 firmware to the firmware makefile too it's compiled into the kernel - before it used to hang waiting on it However when I boot with this kernel, KMS doesn't work correctly - it generates white noise on my HDMI connected screen. Unfortunately I don't have another screen to test this on, not even a VGA one Just wanted to check to see if this was a known issue or if the patches in drm-radeon-testing are stale Make sure you are using v3 of the patch or one of the radeon branches in Dave's dri-2.6 tree. Alex -- 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/7 Alex Deucher alexdeuc...@gmail.com: 2009/12/7 Mike Lothian m...@fireburn.co.uk: 2009/12/1 Rafał Miłecki zaj...@gmail.com: 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 Hi There I've tested your patches in the drm-radeon-testing tree on a radeon 4650 (RV730) I added the R700 firmware to the firmware makefile too it's compiled into the kernel - before it used to hang waiting on it However when I boot with this kernel, KMS doesn't work correctly - it generates white noise on my HDMI connected screen. Unfortunately I don't have another screen to test this on, not even a VGA one Just wanted to check to see if this was a known issue or if the patches in drm-radeon-testing are stale Make sure you are using v3 of the patch or one of the radeon branches in Dave's dri-2.6 tree. Alex I was using drm-radeon-testing branch from the dri-2.6 tree which is 5 days old -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ 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, Dec 7, 2009 at 5:53 PM, Mike Lothian m...@fireburn.co.uk wrote: 2009/12/7 Alex Deucher alexdeuc...@gmail.com: 2009/12/7 Mike Lothian m...@fireburn.co.uk: 2009/12/1 Rafał Miłecki zaj...@gmail.com: 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 Hi There I've tested your patches in the drm-radeon-testing tree on a radeon 4650 (RV730) I added the R700 firmware to the firmware makefile too it's compiled into the kernel - before it used to hang waiting on it However when I boot with this kernel, KMS doesn't work correctly - it generates white noise on my HDMI connected screen. Unfortunately I don't have another screen to test this on, not even a VGA one Just wanted to check to see if this was a known issue or if the patches in drm-radeon-testing are stale Make sure you are using v3 of the patch or one of the radeon branches in Dave's dri-2.6 tree. Alex I was using drm-radeon-testing branch from the dri-2.6 tree which is 5 days old Is the drm loading properly? Can you open a bug and attach your xorg log and dmesg output? https://bugs.freedesktop.org Choose DRI and DRM/Radeon as the component. Alex -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ 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/7 Alex Deucher alexdeuc...@gmail.com: On Mon, Dec 7, 2009 at 5:53 PM, Mike Lothian m...@fireburn.co.uk wrote: 2009/12/7 Alex Deucher alexdeuc...@gmail.com: 2009/12/7 Mike Lothian m...@fireburn.co.uk: 2009/12/1 Rafał Miłecki zaj...@gmail.com: 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 Hi There I've tested your patches in the drm-radeon-testing tree on a radeon 4650 (RV730) I added the R700 firmware to the firmware makefile too it's compiled into the kernel - before it used to hang waiting on it However when I boot with this kernel, KMS doesn't work correctly - it generates white noise on my HDMI connected screen. Unfortunately I don't have another screen to test this on, not even a VGA one Just wanted to check to see if this was a known issue or if the patches in drm-radeon-testing are stale Make sure you are using v3 of the patch or one of the radeon branches in Dave's dri-2.6 tree. Alex I was using drm-radeon-testing branch from the dri-2.6 tree which is 5 days old Is the drm loading properly? Can you open a bug and attach your xorg log and dmesg output? https://bugs.freedesktop.org Choose DRI and DRM/Radeon as the component. Alex Hmm it's working fine using the drm-next branch from the dri-2.6 Perhaps it was just stale patches in drm-radeon-testing -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ 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/7 Alex Deucher alexdeuc...@gmail.com: On Mon, Dec 7, 2009 at 5:53 PM, Mike Lothian m...@fireburn.co.uk wrote: 2009/12/7 Alex Deucher alexdeuc...@gmail.com: 2009/12/7 Mike Lothian m...@fireburn.co.uk: 2009/12/1 Rafał Miłecki zaj...@gmail.com: 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 Hi There I've tested your patches in the drm-radeon-testing tree on a radeon 4650 (RV730) I added the R700 firmware to the firmware makefile too it's compiled into the kernel - before it used to hang waiting on it However when I boot with this kernel, KMS doesn't work correctly - it generates white noise on my HDMI connected screen. Unfortunately I don't have another screen to test this on, not even a VGA one Just wanted to check to see if this was a known issue or if the patches in drm-radeon-testing are stale Make sure you are using v3 of the patch or one of the radeon branches in Dave's dri-2.6 tree. Alex I was using drm-radeon-testing branch from the dri-2.6 tree which is 5 days old Is the drm loading properly? Can you open a bug and attach your xorg log and dmesg output? https://bugs.freedesktop.org Choose DRI and DRM/Radeon as the component. Alex I've now reported another bug which is the main reason for me messing with mesa libdrm, the latest kernel code and 32bit chroots in the first place - Warcraft 3 :-D -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ 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 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
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: [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
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
[PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
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. Alex From c415802e12563ea1f1ef3cd46a004ce6cc2300ff Mon Sep 17 00:00:00 2001 From: Alex Deucher alexdeuc...@gmail.com Date: Mon, 30 Nov 2009 13:45:31 -0500 Subject: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips This enabled 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. Signed-off-by: Alex Deucher alexdeuc...@gmail.com --- drivers/gpu/drm/radeon/r600.c | 542 +-- 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 | 23 ++- 10 files changed, 734 insertions(+), 75 deletions(-) diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c index 8d6bc12..2004cf1 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); @@ -69,6 +73,8 @@ int r600_debugfs_mc_info_init(struct radeon_device *rdev); int r600_mc_wait_for_idle(struct radeon_device *rdev); void r600_gpu_init(struct radeon_device *rdev); void r600_fini(struct radeon_device *rdev); +int r600_irq_init(struct radeon_device *rdev); +void r600_irq_fini(struct radeon_device *rdev); /* * R600 PCIE GART @@ -1110,11 +1116,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 +1135,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) { pfp_req_size = R700_PFP_UCODE_SIZE * 4; me_req_size = R700_PM4_UCODE_SIZE * 4; + rlc_req_size = R700_RLC_UCODE_SIZE * 4; } else { pfp_req_size = PFP_UCODE_SIZE * 4; me_req_size = PM4_UCODE_SIZE * 12; + rlc_req_size = RLC_UCODE_SIZE * 4; } - DRM_INFO(Loading %s CP Microcode\n, chip_name); + DRM_INFO(Loading %s Microcode\n, chip_name); snprintf(fw_name, sizeof(fw_name), radeon/%s_pfp.bin
Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
2009/11/30 Alex Deucher alexdeuc...@gmail.com: 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. Just: # git apply 0001-drm-radeon-kms-Add-support-for-interrupts-on-r6xx-r.patch stdin:217: space before tab in indent. r = r600_irq_init(rdev); stdin:218: space before tab in indent. if (r) { stdin:219: space before tab in indent. DRM_ERROR(radeon: IH init failed (%d).\n, r); stdin:221: space before tab in indent. } warning: 4 lines add whitespace errors. if you care. -- Rafa -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ 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/11/30 Alex Deucher alexdeuc...@gmail.com: 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. I've put DRM_INFO on D1 vblank. I modprobe radeon and don't see a one message. I start KDE and then I see messages for something about 60 seconds. After that random amount on time they stop appearing. I've done # cat radeon_fence_info and noticed my rdev-fence_drv.emited is empty. I think it was working fine before patch, however let me double check that tomorrow. -- 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 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. Alex From 4a0f49e1adaa00a098874463ca6136bc15fa03fd Mon Sep 17 00:00:00 2001 From: Alex Deucher alexdeuc...@gmail.com Date: Mon, 30 Nov 2009 18:05:53 -0500 Subject: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips v2 This enabled 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. v2 - fix some checkpatch problems, and re-read the disp int stat reg if we restart the ih Signed-off-by: Alex Deucher alexdeuc...@gmail.com --- drivers/gpu/drm/radeon/r600.c | 540 +-- 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 | 23 ++- 10 files changed, 732 insertions(+), 75 deletions(-) diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c index 8d6bc12..3d0628f 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) { pfp_req_size = R700_PFP_UCODE_SIZE * 4; me_req_size = R700_PM4_UCODE_SIZE * 4; + rlc_req_size = R700_RLC_UCODE_SIZE * 4; } else { pfp_req_size = PFP_UCODE_SIZE * 4; me_req_size = PM4_UCODE_SIZE * 12; + rlc_req_size = RLC_UCODE_SIZE * 4; } - DRM_INFO(Loading %s CP Microcode\n, chip_name); + DRM_INFO(Loading %s Microcode\n, chip_name); snprintf(fw_name, sizeof(fw_name), radeon/%s_pfp.bin, chip_name); err = request_firmware(rdev-pfp_fw, fw_name, pdev-dev); @@ -1175,6 +1212,18 @@ int
Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
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. It might be nice to fail to non-interrupt operation if the firmware can't be found. though I suppose distros can ship it with the DDX if they aren't shipping -firmware 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
Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
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. If the fw isn't installed and you load the driver, it leafves the irq handler installed by the looks of it, adding the fw thenloading the driver really confuses things then. 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
Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
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. If the fw isn't installed and you load the driver, it leafves the irq handler installed by the looks of it, adding the fw thenloading the driver really confuses things then. Another unload issue BUG: sleeping function called from invalid context at /home/airlied/git/drm-2.6/mm/vmalloc.c:1349 in_atomic(): 1, irqs_disabled(): 1, pid: 6885, name: rmmod Pid: 6885, comm: rmmod Not tainted 2.6.31-rc9 #80 Call Trace: [8102cd56] __might_sleep+0xfe/0x100 [810b5ffc] vunmap+0x38/0x47 [a004d313] ttm_bo_kunmap+0x41/0x5a [ttm] [a007b6b1] radeon_object_kunmap+0x55/0x5a [radeon] [a009bff1] r600_ih_ring_fini+0x34/0x7a [radeon] [a009c0c1] r600_irq_fini+0x8a/0x8e [radeon] [a009f5fb] rv770_fini+0x21/0x9a [radeon] [a006ec89] radeon_device_fini+0x2e/0x49 [radeon] [a006f795] radeon_driver_unload_kms+0x26/0x41 [radeon] [a0017c90] drm_put_dev+0xda/0x1a7 [drm] [a00590cc] radeon_pci_remove+0x10/0x14 [radeon] [811a7e20] pci_device_remove+0x28/0x4c [8121dd6c] __device_release_driver+0x61/0xa7 [8121de3c] driver_detach+0x8a/0xb0 [8121d090] bus_remove_driver+0x86/0xa9 [8121e319] driver_unregister+0x67/0x6f [811a8050] pci_unregister_driver+0x3f/0x88 [a0013f17] drm_exit+0x40/0x79 [drm] [a00ab73c] radeon_exit+0x10/0x12 [radeon] [81063bbb] sys_delete_module+0x1b7/0x224 [812fc180] ? do_page_fault+0x33d/0x36d [810747ad] ? audit_syscall_entry+0x1e9/0x215 [8100ba6b] system_call_fastpath+0x16/0x1b don't know if we need to take the lock once we know the irqs are off. 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
Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips
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. -- 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 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. -- 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