From: Alex D. <ale...@gm...> - 2009-11-30 19:03:00
|
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: Rafał M. <za...@gm...> - 2009-11-30 19:16:53
|
2009/11/30 Alex Deucher <ale...@gm...>: > 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 |
From: Rafał M. <za...@gm...> - 2009-11-30 22:38:30
|
2009/11/30 Alex Deucher <ale...@gm...>: > 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ł |
From: Alex D. <ale...@gm...> - 2009-11-30 23:11:37
|
On Mon, Nov 30, 2009 at 2:02 PM, Alex Deucher <ale...@gm...> 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: Dave A. <ai...@li...> - 2009-12-01 05:24:19
|
> 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. |
From: Dave A. <ai...@li...> - 2009-12-01 05:42:46
|
> 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. |
From: Dave A. <ai...@li...> - 2009-12-01 05:49:51
|
> > > 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: [<ffffffff8102cd56>] __might_sleep+0xfe/0x100 [<ffffffff810b5ffc>] vunmap+0x38/0x47 [<ffffffffa004d313>] ttm_bo_kunmap+0x41/0x5a [ttm] [<ffffffffa007b6b1>] radeon_object_kunmap+0x55/0x5a [radeon] [<ffffffffa009bff1>] r600_ih_ring_fini+0x34/0x7a [radeon] [<ffffffffa009c0c1>] r600_irq_fini+0x8a/0x8e [radeon] [<ffffffffa009f5fb>] rv770_fini+0x21/0x9a [radeon] [<ffffffffa006ec89>] radeon_device_fini+0x2e/0x49 [radeon] [<ffffffffa006f795>] radeon_driver_unload_kms+0x26/0x41 [radeon] [<ffffffffa0017c90>] drm_put_dev+0xda/0x1a7 [drm] [<ffffffffa00590cc>] radeon_pci_remove+0x10/0x14 [radeon] [<ffffffff811a7e20>] pci_device_remove+0x28/0x4c [<ffffffff8121dd6c>] __device_release_driver+0x61/0xa7 [<ffffffff8121de3c>] driver_detach+0x8a/0xb0 [<ffffffff8121d090>] bus_remove_driver+0x86/0xa9 [<ffffffff8121e319>] driver_unregister+0x67/0x6f [<ffffffff811a8050>] pci_unregister_driver+0x3f/0x88 [<ffffffffa0013f17>] drm_exit+0x40/0x79 [drm] [<ffffffffa00ab73c>] radeon_exit+0x10/0x12 [radeon] [<ffffffff81063bbb>] sys_delete_module+0x1b7/0x224 [<ffffffff812fc180>] ? do_page_fault+0x33d/0x36d [<ffffffff810747ad>] ? audit_syscall_entry+0x1e9/0x215 [<ffffffff8100ba6b>] system_call_fastpath+0x16/0x1b don't know if we need to take the lock once we know the irqs are off. Dave. |
From: Rafał M. <za...@gm...> - 2009-12-01 07:04:10
|
2009/12/1 Alex Deucher <ale...@gm...>: > On Mon, Nov 30, 2009 at 2:02 PM, Alex Deucher <ale...@gm...> 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ł |
From: Michel D. <mi...@da...> - 2009-12-01 07:33:19
|
On Tue, 2009-12-01 at 08:03 +0100, Rafał Miłecki wrote: > 2009/12/1 Alex Deucher <ale...@gm...>: > > On Mon, Nov 30, 2009 at 2:02 PM, Alex Deucher <ale...@gm...> 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 |
From: Rafał M. <za...@gm...> - 2009-12-01 08:43:42
|
W dniu 1 grudnia 2009 08:33 użytkownik Michel Dänzer <mi...@da...> napisał: > On Tue, 2009-12-01 at 08:03 +0100, Rafał Miłecki wrote: >> 2009/12/1 Alex Deucher <ale...@gm...>: >> > On Mon, Nov 30, 2009 at 2:02 PM, Alex Deucher <ale...@gm...> 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ł |
From: Michel D. <mi...@da...> - 2009-12-01 08:59:26
|
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 > <mi...@da...> napisał: > > On Tue, 2009-12-01 at 08:03 +0100, Rafał Miłecki wrote: > >> 2009/12/1 Alex Deucher <ale...@gm...>: > >> > On Mon, Nov 30, 2009 at 2:02 PM, Alex Deucher <ale...@gm...> 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 |
From: Rafał M. <za...@gm...> - 2009-12-01 18:20:03
|
W dniu 1 grudnia 2009 09:59 użytkownik Michel Dänzer <mi...@da...> 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 680000 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 340000 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: 0x00000000 [ 279.550240] [drm] r600_irq_process start: rptr 32160, wptr 32176 [ 279.550264] [drm] IH: CP int: 0x00000000 [ 279.550404] [drm] r600_irq_process start: rptr 32176, wptr 32192 [ 279.550424] [drm] IH: CP int: 0x00000000 [ 279.550483] [drm] r600_irq_process start: rptr 32192, wptr 32208 [ 279.550503] [drm] IH: CP int: 0x00000000 [ 279.550668] [drm] r600_irq_process start: rptr 32208, wptr 32224 [ 279.550689] [drm] IH: CP int: 0x00000000 [ 279.550744] [drm] r600_irq_process start: rptr 32224, wptr 32240 [ 279.550765] [drm] IH: CP int: 0x00000000 [ 279.550928] [drm] r600_irq_process start: rptr 32240, wptr 32256 [ 279.550948] [drm] IH: CP int: 0x00000000 [ 279.551003] [drm] r600_irq_process start: rptr 32256, wptr 32272 [ 279.551024] [drm] IH: CP int: 0x00000000 [ 279.552428] [drm] r600_irq_process start: rptr 32272, wptr 32288 [ 279.552450] [drm] IH: CP int: 0x00000000 After I stop receiving any VBLANK interrupts I receive tons on CP int. Any more tips? :| -- Rafał |
From: Rafał M. <za...@gm...> - 2009-12-01 09:02:12
|
W dniu 1 grudnia 2009 09:59 użytkownik Michel Dänzer <mi...@da...> 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ł |
From: Michel D. <mi...@da...> - 2009-12-01 09:09:05
|
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 > <mi...@da...> 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 |
From: Rafał M. <za...@gm...> - 2009-12-01 18:13:42
|
W dniu 1 grudnia 2009 10:08 użytkownik Michel Dänzer <mi...@da...> 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ł |
From: Alex D. <ale...@gm...> - 2009-12-01 18:48:18
|
On Mon, Nov 30, 2009 at 6:11 PM, Alex Deucher <ale...@gm...> wrote: > On Mon, Nov 30, 2009 at 2:02 PM, Alex Deucher <ale...@gm...> 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: Rafał M. <za...@gm...> - 2009-12-01 23:00:51
|
2009/12/1 Alex Deucher <ale...@gm...>: > 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ł |
From: Mike L. <mi...@fi...> - 2009-12-07 18:51:42
|
2009/12/1 Rafał Miłecki <za...@gm...>: > 2009/12/1 Alex Deucher <ale...@gm...>: >> 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...@li... > 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 |
From: Alex D. <ale...@gm...> - 2009-12-07 20:40:07
|
2009/12/7 Mike Lothian <mi...@fi...>: > 2009/12/1 Rafał Miłecki <za...@gm...>: >> 2009/12/1 Alex Deucher <ale...@gm...>: >>> 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...@li... >> 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 |
From: Mike L. <mi...@fi...> - 2009-12-07 22:54:30
|
2009/12/7 Alex Deucher <ale...@gm...>: > 2009/12/7 Mike Lothian <mi...@fi...>: >> 2009/12/1 Rafał Miłecki <za...@gm...>: >>> 2009/12/1 Alex Deucher <ale...@gm...>: >>>> 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...@li... >>> 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 |
From: Alex D. <ale...@gm...> - 2009-12-07 22:57:07
|
On Mon, Dec 7, 2009 at 5:53 PM, Mike Lothian <mi...@fi...> wrote: > 2009/12/7 Alex Deucher <ale...@gm...>: >> 2009/12/7 Mike Lothian <mi...@fi...>: >>> 2009/12/1 Rafał Miłecki <za...@gm...>: >>>> 2009/12/1 Alex Deucher <ale...@gm...>: >>>>> 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...@li... >>>> 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 |
From: Mike L. <mi...@fi...> - 2009-12-07 23:05:01
|
2009/12/7 Alex Deucher <ale...@gm...>: > On Mon, Dec 7, 2009 at 5:53 PM, Mike Lothian <mi...@fi...> wrote: >> 2009/12/7 Alex Deucher <ale...@gm...>: >>> 2009/12/7 Mike Lothian <mi...@fi...>: >>>> 2009/12/1 Rafał Miłecki <za...@gm...>: >>>>> 2009/12/1 Alex Deucher <ale...@gm...>: >>>>>> 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...@li... >>>>> 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 |
From: Mike L. <mi...@fi...> - 2009-12-07 23:34:27
|
2009/12/7 Alex Deucher <ale...@gm...>: > On Mon, Dec 7, 2009 at 5:53 PM, Mike Lothian <mi...@fi...> wrote: >> 2009/12/7 Alex Deucher <ale...@gm...>: >>> 2009/12/7 Mike Lothian <mi...@fi...>: >>>> 2009/12/1 Rafał Miłecki <za...@gm...>: >>>>> 2009/12/1 Alex Deucher <ale...@gm...>: >>>>>> 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...@li... >>>>> 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 |