Re: [PATCH] drm/radeon/kms: Add support for interrupts on r6xx/r7xx chips

2009-12-07 Thread Mike Lothian
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-07 Thread Alex Deucher
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-07 Thread Mike Lothian
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

2009-12-07 Thread Alex Deucher
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-07 Thread Mike Lothian
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-07 Thread Mike Lothian
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

2009-12-01 Thread Rafał Miłecki
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

2009-12-01 Thread Michel Dänzer
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

2009-12-01 Thread Rafał Miłecki
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

2009-12-01 Thread Michel Dänzer
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

2009-12-01 Thread Rafał Miłecki
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

2009-12-01 Thread Rafał Miłecki
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

2009-12-01 Thread Alex Deucher
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-01 Thread Rafał Miłecki
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

2009-11-30 Thread Alex Deucher
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 Thread Rafał Miłecki
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 Thread Rafał Miłecki
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

2009-11-30 Thread Alex Deucher
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

2009-11-30 Thread Dave Airlie

 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

2009-11-30 Thread Dave Airlie

 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

2009-11-30 Thread Dave Airlie
 
  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-11-30 Thread Rafał Miłecki
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

2009-11-30 Thread Michel Dänzer
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