Re: drm/radeon/kms: pm: single frame corruptions on reclocking
2010/1/30 Dave Airlie airl...@gmail.com: 2009/12/24 Rafał Miłecki zaj...@gmail.com: I applied patches from http://www.botchco.com/alex/xorg/pm/ and now engine reclocks between 110MHz and 680MHz. The problem is I see ~10 black horizontal lines for a one frame time on almost every reclock. I tried to fix this or at least understand it somehow but without success. 1) Putting 500ms delay after every reclock doesn't improve anything 2) Reclocking between 110MHz and 130MHz (instead 680MHz) doesn't improve 3) Calling atombios_crtc_set_pll after reclocking doesn't improve 4) Calling ClockSource AtomBIOS commane after reclocking doesn't improve I tested 4th as SetEngineClock seems to play mostly with 0x0180 and ClockSource seems to be the only reading that register. Effects were horrible, don't ever call this AtomBIOS cammand ;) Do you have any other ideas? On top of whats in drm-radeon-testing this avoids reclocking artifacts on my rv530 laptop, I timed the atom calls and they were taking 20ms which is waaay too long, I decoded the tables and it looks like they use udelays. Seems too easy... I used the same approach and even moved the reclock in hard-irq context but I still see corruption (I'm using a M76). Luca -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
W dniu 31 stycznia 2010 14:30 użytkownik Luca Tettamanti kronos...@gmail.com napisał: 2010/1/30 Dave Airlie airl...@gmail.com: 2009/12/24 Rafał Miłecki zaj...@gmail.com: I applied patches from http://www.botchco.com/alex/xorg/pm/ and now engine reclocks between 110MHz and 680MHz. The problem is I see ~10 black horizontal lines for a one frame time on almost every reclock. I tried to fix this or at least understand it somehow but without success. 1) Putting 500ms delay after every reclock doesn't improve anything 2) Reclocking between 110MHz and 130MHz (instead 680MHz) doesn't improve 3) Calling atombios_crtc_set_pll after reclocking doesn't improve 4) Calling ClockSource AtomBIOS commane after reclocking doesn't improve I tested 4th as SetEngineClock seems to play mostly with 0x0180 and ClockSource seems to be the only reading that register. Effects were horrible, don't ever call this AtomBIOS cammand ;) Do you have any other ideas? On top of whats in drm-radeon-testing this avoids reclocking artifacts on my rv530 laptop, I timed the atom calls and they were taking 20ms which is waaay too long, I decoded the tables and it looks like they use udelays. Seems too easy... I used the same approach and even moved the reclock in hard-irq context but I still see corruption (I'm using a M76). Dave thanks for your tip! I've performed more testing and wrote patch for my RV620 to directly operate on GPU registers. In every case corruptions were gone and speed was drastically improved! Please see https://bugs.freedesktop.org/show_bug.cgi?id=26350 for details. -- Rafał -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
2009/12/24 Rafał Miłecki zaj...@gmail.com: I applied patches from http://www.botchco.com/alex/xorg/pm/ and now engine reclocks between 110MHz and 680MHz. The problem is I see ~10 black horizontal lines for a one frame time on almost every reclock. I tried to fix this or at least understand it somehow but without success. 1) Putting 500ms delay after every reclock doesn't improve anything 2) Reclocking between 110MHz and 130MHz (instead 680MHz) doesn't improve 3) Calling atombios_crtc_set_pll after reclocking doesn't improve 4) Calling ClockSource AtomBIOS commane after reclocking doesn't improve I tested 4th as SetEngineClock seems to play mostly with 0x0180 and ClockSource seems to be the only reading that register. Effects were horrible, don't ever call this AtomBIOS cammand ;) Do you have any other ideas? On top of whats in drm-radeon-testing this avoids reclocking artifacts on my rv530 laptop, I timed the atom calls and they were taking 20ms which is waaay too long, I decoded the tables and it looks like they use udelays. Though I suspect if we want to reclock other things like memory we need to do it across a few frames instead of all in one vblank. Dave. 0001-drm-radeon-kms-use-udelay-for-short-delays.patch Description: Binary data -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
On Wed, Dec 30, 2009 at 08:03:53AM +0100, Michel Dänzer wrote: On Tue, 2009-12-29 at 19:35 +0100, Luca Tettamanti wrote: Il Mon, Dec 28, 2009 at 05:27:13PM -0500, Alex Deucher ha scritto: 2009/12/28 Luca Tettamanti kronos...@gmail.com: On Mon, Dec 28, 2009 at 01:32:24PM -0500, Alex Deucher wrote: 2009/12/28 Luca Tettamanti kronos...@gmail.com: 2009/12/28 Alex Deucher alexdeuc...@gmail.com: On Mon, Dec 28, 2009 at 5:53 AM, Luca Tettamanti kronos...@gmail.com wrote: On Sun, Dec 27, 2009 at 1:55 AM, Rafał Miłecki zaj...@gmail.com wrote: W dniu 26 grudnia 2009 20:08 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: It may be that the engine doesn't like to be reclocked while it's running. Perhaps we should use the GUI idle interrupt rather than vblanks to reclock the engine. Could you say something more about GUI idle interrupt, please? It's mentioned in the documentation of the IH (see r600.c); I guess it's enabled by GUI_IDLE_INT_ENABLE. What is this, do we already have code for that? Unless there are more subtleties all is needed it to enabled the interrupt and catch it in r600_irq_process. That's pretty much it. Pre-r6xx asics have a GUI interrupt as well. I can look up the details for that if they are not already documented. I can't find a way to ack the interrupt; I see RADEON_GUI_IDLE_INT_TEST_ACK but I think it's for pre-r6xx cards, right? You don't have to ACK it as the CP generates the interrupt in software; similar to the sw interrupts used for fences. Ok, good: I've got the stub running on my M76. r100 and rs600 parts are untested. Comments? Looks pretty good. I've included the proper defines from the register database below and you'll need to ack the gui idle interrupts on pre-r600 chips. Now you just have to do something when you get the idle interrupt. I've adapted Rafał's patch to do the reclock when the idle interrupt is fired (which btw should take care of the special case for nr CRTCs 1). Unfortunately I still see the black frame when reclocking is performed. So I tried recloking directly from the IH (yeah, I'm ashamed of myself...); this got rid of the black frame, but causes corruption of a horizontal block of the screen (during the reclock, before and after the screen looks fine). If you mean the interrupt handler for the idle interrupt, Yes. have you tried doing it in the interrupt handler for the vblank interrupt instead? Not yet; I've tried a solution similar to what Xavier suggested: lock the ring, wait for idle, reclock (outside the IH), unlock and it still causes corruption (but not the black frame). The next iteration would be: lock cp wait for idle enable vblank wait for vlbank relock unlock cp With reclock that might be moved to the vblank interrupt if it still causes problems. Sounds sensible? This approach however reintroduces the issue with multiple active crtcs... Luca -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
On Wed, Dec 30, 2009 at 10:56 AM, Luca Tettamanti kronos...@gmail.com wrote:
On Wed, Dec 30, 2009 at 08:03:53AM +0100, Michel Dänzer wrote:
On Tue, 2009-12-29 at 19:35 +0100, Luca Tettamanti wrote:
Il Mon, Dec 28, 2009 at 05:27:13PM -0500, Alex Deucher ha scritto:
2009/12/28 Luca Tettamanti kronos...@gmail.com:
On Mon, Dec 28, 2009 at 01:32:24PM -0500, Alex Deucher wrote:
Looks pretty good. I've included the proper defines from the register
database below and you'll need to ack the gui idle interrupts on
pre-r600 chips. Now you just have to do something when you get the
idle interrupt.
I've adapted Rafał's patch to do the reclock when the idle interrupt is
fired (which btw should take care of the special case for nr CRTCs 1).
Unfortunately I still see the black frame when reclocking is performed.
So I tried recloking directly from the IH (yeah, I'm ashamed of
myself...); this got rid of the black frame, but causes corruption of a
horizontal block of the screen (during the reclock, before and after the
screen looks fine).
If you mean the interrupt handler for the idle interrupt,
Yes.
have you tried
doing it in the interrupt handler for the vblank interrupt instead?
Not yet; I've tried a solution similar to what Xavier suggested: lock the
ring,
wait for idle, reclock (outside the IH), unlock and it still causes corruption
(but not the black frame).
The next iteration would be:
lock cp
wait for idle
enable vblank
wait for vlbank
relock
unlock cp
With reclock that might be moved to the vblank interrupt if it still causes
problems. Sounds sensible?
I still see corruption... this is what I'm doing:
driver decides to reclock
take cp.mutex
wait_event(gui_idle)
idle interrupt {
set idle flag
wake_up()
}
drm_vblank_get
vblank interrupt {
reclock()
}
drm_vblank_put
release cp.mutex
-ENOIDEA
Luca
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
2009/12/29 Luca Tettamanti kronos...@gmail.com:
2009/12/28 Alex Deucher alexdeuc...@gmail.com:
2009/12/28 Luca Tettamanti kronos...@gmail.com:
On Mon, Dec 28, 2009 at 01:32:24PM -0500, Alex Deucher wrote:
2009/12/28 Luca Tettamanti kronos...@gmail.com:
2009/12/28 Alex Deucher alexdeuc...@gmail.com:
On Mon, Dec 28, 2009 at 5:53 AM, Luca Tettamanti kronos...@gmail.com
wrote:
Unless there are more subtleties all is needed it to enabled the
interrupt and catch it in r600_irq_process.
That's pretty much it. Pre-r6xx asics have a GUI interrupt as well.
I can look up the details for that if they are not already documented.
I can't find a way to ack the interrupt; I see
RADEON_GUI_IDLE_INT_TEST_ACK but I think it's for pre-r6xx cards,
right?
You don't have to ACK it as the CP generates the interrupt in
software; similar to the sw interrupts used for fences.
Ok, good: I've got the stub running on my M76. r100 and rs600 parts are
untested. Comments?
Looks pretty good. I've included the proper defines from the register
database below and you'll need to ack the gui idle interrupts on
pre-r600 chips. Now you just have to do something when you get the
idle interrupt.
[...]
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/r100.c 2009-12-28
22:30:59.079748392 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/r100.c 2009-12-28
22:41:07.803741755 +0100
@@ -246,6 +246,9 @@
if (rdev-irq.sw_int) {
tmp |= RADEON_SW_INT_ENABLE;
}
+ if (rdev-irq.idle_int) {
+ tmp |= RADEON_GUI_IDLE_INT_ENABLE;
+ }
if (rdev-irq.crtc_vblank_int[0]) {
tmp |= RADEON_CRTC_VBLANK_MASK;
}
@@ -278,7 +281,8 @@
uint32_t irqs = RREG32(RADEON_GEN_INT_STATUS);
uint32_t irq_mask = RADEON_SW_INT_TEST |
RADEON_CRTC_VBLANK_STAT | RADEON_CRTC2_VBLANK_STAT |
- RADEON_FP_DETECT_STAT | RADEON_FP2_DETECT_STAT;
+ RADEON_FP_DETECT_STAT | RADEON_FP2_DETECT_STAT |
+ RADEON_GUI_IDLE_INT_TEST_ACK;
if (irqs) {
WREG32(RADEON_GEN_INT_STATUS, irqs);
@@ -318,6 +322,9 @@
queue_hotplug = true;
DRM_DEBUG(HPD2\n);
}
+ if (status RADEON_GUI_IDLE_INT_TEST_ACK) {
+ DRM_DEBUG(GUI idle\n);
+ }
You'll need to ack this on pre-r6xx.
Clear on write? I've included the relevant bit in irq_mask, so r100
should be ok.
Right. missed that. should be ok.
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/rs600.c 2009-12-28
22:32:30.927884090 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/rs600.c 2009-12-28
22:46:23.211897501 +0100
@@ -318,6 +318,9 @@
if (rdev-irq.sw_int) {
tmp |= S_40_SW_INT_EN(1);
}
+ if (rdev-irq.idle_int) {
+ tmp |= S_40_GUI_IDLE(1);
+ }
if (rdev-irq.crtc_vblank_int[0]) {
mode_int |= S_006540_D1MODE_VBLANK_INT_MASK(1);
}
@@ -411,6 +414,9 @@
queue_hotplug = true;
DRM_DEBUG(HPD2\n);
}
+ if (G_44_GUI_IDLE_STAT(status)) {
+ DRM_DEBUG(GUI idle\n);
+ }
You'll need to ACK this on pre-r6xx chips.
Ok, I was mislead by the name of the file ;-)
rs600 = sort-of-r500?
yes. rs600 (and rs690/rs740) have avivo display engines, but r4xx 3d
engines. The irq stuff is the same as r5xx.
Alex
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
Il Mon, Dec 28, 2009 at 05:27:13PM -0500, Alex Deucher ha scritto:
2009/12/28 Luca Tettamanti kronos...@gmail.com:
On Mon, Dec 28, 2009 at 01:32:24PM -0500, Alex Deucher wrote:
2009/12/28 Luca Tettamanti kronos...@gmail.com:
2009/12/28 Alex Deucher alexdeuc...@gmail.com:
On Mon, Dec 28, 2009 at 5:53 AM, Luca Tettamanti kronos...@gmail.com
wrote:
On Sun, Dec 27, 2009 at 1:55 AM, Rafał Miłecki zaj...@gmail.com
wrote:
W dniu 26 grudnia 2009 20:08 użytkownik Alex Deucher
alexdeuc...@gmail.com napisał:
It may be that the engine doesn't like to be reclocked while it's
running. Perhaps we should use the GUI idle interrupt rather than
vblanks to reclock the engine.
Could you say something more about GUI idle interrupt, please?
It's mentioned in the documentation of the IH (see r600.c); I guess
it's enabled by GUI_IDLE_INT_ENABLE.
What is this, do we already have code for that?
Unless there are more subtleties all is needed it to enabled the
interrupt and catch it in r600_irq_process.
That's pretty much it. Pre-r6xx asics have a GUI interrupt as well.
I can look up the details for that if they are not already documented.
I can't find a way to ack the interrupt; I see
RADEON_GUI_IDLE_INT_TEST_ACK but I think it's for pre-r6xx cards,
right?
You don't have to ACK it as the CP generates the interrupt in
software; similar to the sw interrupts used for fences.
Ok, good: I've got the stub running on my M76. r100 and rs600 parts are
untested. Comments?
Looks pretty good. I've included the proper defines from the register
database below and you'll need to ack the gui idle interrupts on
pre-r600 chips. Now you just have to do something when you get the
idle interrupt.
I've adapted Rafał's patch to do the reclock when the idle interrupt is
fired (which btw should take care of the special case for nr CRTCs 1).
Unfortunately I still see the black frame when reclocking is performed.
So I tried recloking directly from the IH (yeah, I'm ashamed of
myself...); this got rid of the black frame, but causes corruption of a
horizontal block of the screen (during the reclock, before and after the
screen looks fine). In this second case I've added a spinlock to guard
the access to the CP ring, so nothing touches it while reclocking is
performed; however by the time we process the idle interrupt -
especially considering that multiple events might be queued in the IH
ring - someone else (i.e. one of the other cores) might already have
submitted more work; what do you think?
I'm attaching 3 patches; the first one contains the stub idle IH, the
second one is Rafał's patch adapted for idle interrupt (it's not very
polished), the third one moves reclocking to IH (and as is it's just an
ugly hack).
Luca
--
In linea di principio sarei indifferente al natale, se solo il natale
ricambiasse la cortesia e mi lasciasse in pace. -- Marco d'Itri
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/r600.c 2009-12-28 16:38:38.388825742 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/r600.c 2009-12-28 22:03:12.936157804 +0100
@@ -2458,6 +2458,7 @@
int r600_irq_set(struct radeon_device *rdev)
{
u32 cp_int_cntl = CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE;
+ u32 grbm_int_cntl;
u32 mode_int = 0;
u32 hpd1, hpd2, hpd3, hpd4 = 0, hpd5 = 0, hpd6 = 0;
@@ -2465,6 +2466,8 @@
if (!rdev-ih.enabled)
return 0;
+ grbm_int_cntl = RREG32(GRBM_INT_CNTL) ~GUI_IDLE_INT_ENABLE;
+
if (ASIC_IS_DCE3(rdev)) {
hpd1 = RREG32(DC_HPD1_INT_CONTROL) ~DC_HPDx_INT_EN;
hpd2 = RREG32(DC_HPD2_INT_CONTROL) ~DC_HPDx_INT_EN;
@@ -2484,6 +2487,10 @@
DRM_DEBUG(r600_irq_set: sw int\n);
cp_int_cntl |= RB_INT_ENABLE;
}
+ if (rdev-irq.idle_int) {
+ DRM_DEBUG(r600_irq_set: GUI idle int\n);
+ grbm_int_cntl |= GUI_IDLE_INT_ENABLE;
+ }
if (rdev-irq.crtc_vblank_int[0]) {
DRM_DEBUG(r600_irq_set: vblank 0\n);
mode_int |= D1MODE_VBLANK_INT_MASK;
@@ -2518,6 +2525,7 @@
}
WREG32(CP_INT_CNTL, cp_int_cntl);
+ WREG32(GRBM_INT_CNTL, grbm_int_cntl);
WREG32(DxMODE_INT_MASK, mode_int);
if (ASIC_IS_DCE3(rdev)) {
WREG32(DC_HPD1_INT_CONTROL, hpd1);
@@ -2806,6 +2814,9 @@
case 181: /* CP EOP event */
DRM_DEBUG(IH: CP EOP\n);
break;
+ case 233: /* GUI idle event */
+ DRM_DEBUG(IH: GUI idle\n);
+ break;
default:
DRM_ERROR(Unhandled interrupt: %d %d\n, src_id, src_data);
break;
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/radeon.h 2009-12-28 16:38:13.945836481 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/radeon.h 2009-12-28 22:02:48.964001788 +0100
@@ -343,6 +343,7 @@
struct radeon_irq {
bool installed;
bool sw_int;
+ bool idle_int;
/* FIXME: use a define max crtc rather than hardcode it */
bool crtc_vblank_int[2];
/* FIXME: use defines for max hpd/dacs */
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/radeon_irq_kms.c 2009-12-28 16:37:10.669823739 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/radeon_irq_kms.c
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
On Tue, 2009-12-29 at 19:35 +0100, Luca Tettamanti wrote: I've adapted Rafał's patch to do the reclock when the idle interrupt is fired (which btw should take care of the special case for nr CRTCs 1). Unfortunately I still see the black frame when reclocking is performed. So I tried recloking directly from the IH (yeah, I'm ashamed of myself...); this got rid of the black frame, but causes corruption of a horizontal block of the screen (during the reclock, before and after the screen looks fine). In this second case I've added a spinlock to guard the access to the CP ring, so nothing touches it while reclocking is performed; however by the time we process the idle interrupt - especially considering that multiple events might be queued in the IH ring - someone else (i.e. one of the other cores) might already have submitted more work; what do you think? Maybe a spinlock doesn't cut it. How about some mutex you take when you need to reclock, to let tasks trying to add to the CP ring just sleep, and then you unmask the idle interrupt. When you receive the idle interrupt, you reclock, you free the mutex, and voilà. Xav -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
On Tue, 2009-12-29 at 19:35 +0100, Luca Tettamanti wrote: Il Mon, Dec 28, 2009 at 05:27:13PM -0500, Alex Deucher ha scritto: 2009/12/28 Luca Tettamanti kronos...@gmail.com: On Mon, Dec 28, 2009 at 01:32:24PM -0500, Alex Deucher wrote: 2009/12/28 Luca Tettamanti kronos...@gmail.com: 2009/12/28 Alex Deucher alexdeuc...@gmail.com: On Mon, Dec 28, 2009 at 5:53 AM, Luca Tettamanti kronos...@gmail.com wrote: On Sun, Dec 27, 2009 at 1:55 AM, Rafał Miłecki zaj...@gmail.com wrote: W dniu 26 grudnia 2009 20:08 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: It may be that the engine doesn't like to be reclocked while it's running. Perhaps we should use the GUI idle interrupt rather than vblanks to reclock the engine. Could you say something more about GUI idle interrupt, please? It's mentioned in the documentation of the IH (see r600.c); I guess it's enabled by GUI_IDLE_INT_ENABLE. What is this, do we already have code for that? Unless there are more subtleties all is needed it to enabled the interrupt and catch it in r600_irq_process. That's pretty much it. Pre-r6xx asics have a GUI interrupt as well. I can look up the details for that if they are not already documented. I can't find a way to ack the interrupt; I see RADEON_GUI_IDLE_INT_TEST_ACK but I think it's for pre-r6xx cards, right? You don't have to ACK it as the CP generates the interrupt in software; similar to the sw interrupts used for fences. Ok, good: I've got the stub running on my M76. r100 and rs600 parts are untested. Comments? Looks pretty good. I've included the proper defines from the register database below and you'll need to ack the gui idle interrupts on pre-r600 chips. Now you just have to do something when you get the idle interrupt. I've adapted Rafał's patch to do the reclock when the idle interrupt is fired (which btw should take care of the special case for nr CRTCs 1). Unfortunately I still see the black frame when reclocking is performed. So I tried recloking directly from the IH (yeah, I'm ashamed of myself...); this got rid of the black frame, but causes corruption of a horizontal block of the screen (during the reclock, before and after the screen looks fine). If you mean the interrupt handler for the idle interrupt, have you tried doing it in the interrupt handler for the vblank interrupt instead? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
On Sun, Dec 27, 2009 at 1:55 AM, Rafał Miłecki zaj...@gmail.com wrote: W dniu 26 grudnia 2009 20:08 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: It may be that the engine doesn't like to be reclocked while it's running. Perhaps we should use the GUI idle interrupt rather than vblanks to reclock the engine. Could you say something more about GUI idle interrupt, please? It's mentioned in the documentation of the IH (see r600.c); I guess it's enabled by GUI_IDLE_INT_ENABLE. What is this, do we already have code for that? Unless there are more subtleties all is needed it to enabled the interrupt and catch it in r600_irq_process. L -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
On Mon, Dec 28, 2009 at 5:53 AM, Luca Tettamanti kronos...@gmail.com wrote: On Sun, Dec 27, 2009 at 1:55 AM, Rafał Miłecki zaj...@gmail.com wrote: W dniu 26 grudnia 2009 20:08 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: It may be that the engine doesn't like to be reclocked while it's running. Perhaps we should use the GUI idle interrupt rather than vblanks to reclock the engine. Could you say something more about GUI idle interrupt, please? It's mentioned in the documentation of the IH (see r600.c); I guess it's enabled by GUI_IDLE_INT_ENABLE. What is this, do we already have code for that? Unless there are more subtleties all is needed it to enabled the interrupt and catch it in r600_irq_process. That's pretty much it. Pre-r6xx asics have a GUI interrupt as well. I can look up the details for that if they are not already documented. Alex -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
2009/12/28 Alex Deucher alexdeuc...@gmail.com: On Mon, Dec 28, 2009 at 5:53 AM, Luca Tettamanti kronos...@gmail.com wrote: On Sun, Dec 27, 2009 at 1:55 AM, Rafał Miłecki zaj...@gmail.com wrote: W dniu 26 grudnia 2009 20:08 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: It may be that the engine doesn't like to be reclocked while it's running. Perhaps we should use the GUI idle interrupt rather than vblanks to reclock the engine. Could you say something more about GUI idle interrupt, please? It's mentioned in the documentation of the IH (see r600.c); I guess it's enabled by GUI_IDLE_INT_ENABLE. What is this, do we already have code for that? Unless there are more subtleties all is needed it to enabled the interrupt and catch it in r600_irq_process. That's pretty much it. Pre-r6xx asics have a GUI interrupt as well. I can look up the details for that if they are not already documented. I can't find a way to ack the interrupt; I see RADEON_GUI_IDLE_INT_TEST_ACK but I think it's for pre-r6xx cards, right? Luca -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
2009/12/28 Luca Tettamanti kronos...@gmail.com: 2009/12/28 Alex Deucher alexdeuc...@gmail.com: On Mon, Dec 28, 2009 at 5:53 AM, Luca Tettamanti kronos...@gmail.com wrote: On Sun, Dec 27, 2009 at 1:55 AM, Rafał Miłecki zaj...@gmail.com wrote: W dniu 26 grudnia 2009 20:08 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: It may be that the engine doesn't like to be reclocked while it's running. Perhaps we should use the GUI idle interrupt rather than vblanks to reclock the engine. Could you say something more about GUI idle interrupt, please? It's mentioned in the documentation of the IH (see r600.c); I guess it's enabled by GUI_IDLE_INT_ENABLE. What is this, do we already have code for that? Unless there are more subtleties all is needed it to enabled the interrupt and catch it in r600_irq_process. That's pretty much it. Pre-r6xx asics have a GUI interrupt as well. I can look up the details for that if they are not already documented. I can't find a way to ack the interrupt; I see RADEON_GUI_IDLE_INT_TEST_ACK but I think it's for pre-r6xx cards, right? You don't have to ACK it as the CP generates the interrupt in software; similar to the sw interrupts used for fences. Alex -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
On Mon, Dec 28, 2009 at 01:32:24PM -0500, Alex Deucher wrote:
2009/12/28 Luca Tettamanti kronos...@gmail.com:
2009/12/28 Alex Deucher alexdeuc...@gmail.com:
On Mon, Dec 28, 2009 at 5:53 AM, Luca Tettamanti kronos...@gmail.com
wrote:
On Sun, Dec 27, 2009 at 1:55 AM, Rafał Miłecki zaj...@gmail.com wrote:
W dniu 26 grudnia 2009 20:08 użytkownik Alex Deucher
alexdeuc...@gmail.com napisał:
It may be that the engine doesn't like to be reclocked while it's
running. Perhaps we should use the GUI idle interrupt rather than
vblanks to reclock the engine.
Could you say something more about GUI idle interrupt, please?
It's mentioned in the documentation of the IH (see r600.c); I guess
it's enabled by GUI_IDLE_INT_ENABLE.
What is this, do we already have code for that?
Unless there are more subtleties all is needed it to enabled the
interrupt and catch it in r600_irq_process.
That's pretty much it. Pre-r6xx asics have a GUI interrupt as well.
I can look up the details for that if they are not already documented.
I can't find a way to ack the interrupt; I see
RADEON_GUI_IDLE_INT_TEST_ACK but I think it's for pre-r6xx cards,
right?
You don't have to ACK it as the CP generates the interrupt in
software; similar to the sw interrupts used for fences.
Ok, good: I've got the stub running on my M76. r100 and rs600 parts are
untested. Comments?
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/r600.c2009-12-28
16:38:38.388825742 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/r600.c 2009-12-28 22:03:12.936157804
+0100
@@ -2458,6 +2458,7 @@
int r600_irq_set(struct radeon_device *rdev)
{
u32 cp_int_cntl = CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE;
+ u32 grbm_int_cntl;
u32 mode_int = 0;
u32 hpd1, hpd2, hpd3, hpd4 = 0, hpd5 = 0, hpd6 = 0;
@@ -2465,6 +2466,8 @@
if (!rdev-ih.enabled)
return 0;
+ grbm_int_cntl = RREG32(GRBM_INT_CNTL) ~GUI_IDLE_INT_ENABLE;
+
if (ASIC_IS_DCE3(rdev)) {
hpd1 = RREG32(DC_HPD1_INT_CONTROL) ~DC_HPDx_INT_EN;
hpd2 = RREG32(DC_HPD2_INT_CONTROL) ~DC_HPDx_INT_EN;
@@ -2484,6 +2487,10 @@
DRM_DEBUG(r600_irq_set: sw int\n);
cp_int_cntl |= RB_INT_ENABLE;
}
+ if (rdev-irq.idle_int) {
+ DRM_DEBUG(r600_irq_set: GUI idle int\n);
+ grbm_int_cntl |= GUI_IDLE_INT_ENABLE;
+ }
if (rdev-irq.crtc_vblank_int[0]) {
DRM_DEBUG(r600_irq_set: vblank 0\n);
mode_int |= D1MODE_VBLANK_INT_MASK;
@@ -2518,6 +2525,7 @@
}
WREG32(CP_INT_CNTL, cp_int_cntl);
+ WREG32(GRBM_INT_CNTL, grbm_int_cntl);
WREG32(DxMODE_INT_MASK, mode_int);
if (ASIC_IS_DCE3(rdev)) {
WREG32(DC_HPD1_INT_CONTROL, hpd1);
@@ -2806,6 +2814,9 @@
case 181: /* CP EOP event */
DRM_DEBUG(IH: CP EOP\n);
break;
+ case 233: /* GUI idle event */
+ DRM_DEBUG(IH: GUI idle\n);
+ break;
default:
DRM_ERROR(Unhandled interrupt: %d %d\n, src_id,
src_data);
break;
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/radeon.h 2009-12-28
16:38:13.945836481 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/radeon.h 2009-12-28
22:02:48.964001788 +0100
@@ -343,6 +343,7 @@
struct radeon_irq {
boolinstalled;
boolsw_int;
+ boolidle_int;
/* FIXME: use a define max crtc rather than hardcode it */
boolcrtc_vblank_int[2];
/* FIXME: use defines for max hpd/dacs */
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/radeon_irq_kms.c 2009-12-28
16:37:10.669823739 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/radeon_irq_kms.c 2009-12-28
22:03:01.508077338 +0100
@@ -67,6 +67,7 @@
/* Disable *all* interrupts */
rdev-irq.sw_int = false;
+ rdev-irq.idle_int = false;
for (i = 0; i 2; i++) {
rdev-irq.crtc_vblank_int[i] = false;
}
@@ -81,6 +82,7 @@
dev-max_vblank_count = 0x001f;
rdev-irq.sw_int = true;
+ rdev-irq.idle_int = true;
radeon_irq_set(rdev);
return 0;
}
@@ -95,6 +97,7 @@
}
/* Disable *all* interrupts */
rdev-irq.sw_int = false;
+ rdev-irq.idle_int = false;
for (i = 0; i 2; i++) {
rdev-irq.crtc_vblank_int[i] = false;
}
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/r100.c2009-12-28
22:30:59.079748392 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/r100.c 2009-12-28 22:41:07.803741755
+0100
@@ -246,6 +246,9 @@
if (rdev-irq.sw_int) {
tmp |= RADEON_SW_INT_ENABLE;
}
+ if (rdev-irq.idle_int) {
+ tmp |= RADEON_GUI_IDLE_INT_ENABLE;
+ }
if
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
2009/12/28 Luca Tettamanti kronos...@gmail.com:
On Mon, Dec 28, 2009 at 01:32:24PM -0500, Alex Deucher wrote:
2009/12/28 Luca Tettamanti kronos...@gmail.com:
2009/12/28 Alex Deucher alexdeuc...@gmail.com:
On Mon, Dec 28, 2009 at 5:53 AM, Luca Tettamanti kronos...@gmail.com
wrote:
On Sun, Dec 27, 2009 at 1:55 AM, Rafał Miłecki zaj...@gmail.com wrote:
W dniu 26 grudnia 2009 20:08 użytkownik Alex Deucher
alexdeuc...@gmail.com napisał:
It may be that the engine doesn't like to be reclocked while it's
running. Perhaps we should use the GUI idle interrupt rather than
vblanks to reclock the engine.
Could you say something more about GUI idle interrupt, please?
It's mentioned in the documentation of the IH (see r600.c); I guess
it's enabled by GUI_IDLE_INT_ENABLE.
What is this, do we already have code for that?
Unless there are more subtleties all is needed it to enabled the
interrupt and catch it in r600_irq_process.
That's pretty much it. Pre-r6xx asics have a GUI interrupt as well.
I can look up the details for that if they are not already documented.
I can't find a way to ack the interrupt; I see
RADEON_GUI_IDLE_INT_TEST_ACK but I think it's for pre-r6xx cards,
right?
You don't have to ACK it as the CP generates the interrupt in
software; similar to the sw interrupts used for fences.
Ok, good: I've got the stub running on my M76. r100 and rs600 parts are
untested. Comments?
Looks pretty good. I've included the proper defines from the register
database below and you'll need to ack the gui idle interrupts on
pre-r600 chips. Now you just have to do something when you get the
idle interrupt.
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/r600.c 2009-12-28
16:38:38.388825742 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/r600.c 2009-12-28 22:03:12.936157804
+0100
@@ -2458,6 +2458,7 @@
int r600_irq_set(struct radeon_device *rdev)
{
u32 cp_int_cntl = CNTX_BUSY_INT_ENABLE | CNTX_EMPTY_INT_ENABLE;
+ u32 grbm_int_cntl;
u32 mode_int = 0;
u32 hpd1, hpd2, hpd3, hpd4 = 0, hpd5 = 0, hpd6 = 0;
@@ -2465,6 +2466,8 @@
if (!rdev-ih.enabled)
return 0;
+ grbm_int_cntl = RREG32(GRBM_INT_CNTL) ~GUI_IDLE_INT_ENABLE;
+
if (ASIC_IS_DCE3(rdev)) {
hpd1 = RREG32(DC_HPD1_INT_CONTROL) ~DC_HPDx_INT_EN;
hpd2 = RREG32(DC_HPD2_INT_CONTROL) ~DC_HPDx_INT_EN;
@@ -2484,6 +2487,10 @@
DRM_DEBUG(r600_irq_set: sw int\n);
cp_int_cntl |= RB_INT_ENABLE;
}
+ if (rdev-irq.idle_int) {
+ DRM_DEBUG(r600_irq_set: GUI idle int\n);
+ grbm_int_cntl |= GUI_IDLE_INT_ENABLE;
+ }
if (rdev-irq.crtc_vblank_int[0]) {
DRM_DEBUG(r600_irq_set: vblank 0\n);
mode_int |= D1MODE_VBLANK_INT_MASK;
@@ -2518,6 +2525,7 @@
}
WREG32(CP_INT_CNTL, cp_int_cntl);
+ WREG32(GRBM_INT_CNTL, grbm_int_cntl);
WREG32(DxMODE_INT_MASK, mode_int);
if (ASIC_IS_DCE3(rdev)) {
WREG32(DC_HPD1_INT_CONTROL, hpd1);
@@ -2806,6 +2814,9 @@
case 181: /* CP EOP event */
DRM_DEBUG(IH: CP EOP\n);
break;
+ case 233: /* GUI idle event */
+ DRM_DEBUG(IH: GUI idle\n);
+ break;
default:
DRM_ERROR(Unhandled interrupt: %d %d\n, src_id,
src_data);
break;
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/radeon.h 2009-12-28
16:38:13.945836481 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/radeon.h 2009-12-28
22:02:48.964001788 +0100
@@ -343,6 +343,7 @@
struct radeon_irq {
bool installed;
bool sw_int;
+ bool idle_int;
/* FIXME: use a define max crtc rather than hardcode it */
bool crtc_vblank_int[2];
/* FIXME: use defines for max hpd/dacs */
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/radeon_irq_kms.c 2009-12-28
16:37:10.669823739 +0100
+++ linux-2.6.git/drivers/gpu/drm/radeon/radeon_irq_kms.c 2009-12-28
22:03:01.508077338 +0100
@@ -67,6 +67,7 @@
/* Disable *all* interrupts */
rdev-irq.sw_int = false;
+ rdev-irq.idle_int = false;
for (i = 0; i 2; i++) {
rdev-irq.crtc_vblank_int[i] = false;
}
@@ -81,6 +82,7 @@
dev-max_vblank_count = 0x001f;
rdev-irq.sw_int = true;
+ rdev-irq.idle_int = true;
radeon_irq_set(rdev);
return 0;
}
@@ -95,6 +97,7 @@
}
/* Disable *all* interrupts */
rdev-irq.sw_int = false;
+ rdev-irq.idle_int = false;
for (i = 0; i 2; i++) {
rdev-irq.crtc_vblank_int[i] = false;
}
--- linux-2.6.git.orig/drivers/gpu/drm/radeon/r100.c 2009-12-28
22:30:59.079748392 +0100
+++
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
W dniu 26 grudnia 2009 02:46 użytkownik Rafał Miłecki zaj...@gmail.com napisał: There are some my experiments with engine. Reclocking between: 1) 110MHz and 680MHz - 1 corrupted frame on every reclock 2) 200MHz and 680MHz - 1 corrupted frame on almost every reclock 3) 250MHz and 680MHz - no corruptions 4) 340MHz and 680MHz - no corruptions 5) 630MHz and 680MHz - no corruptions Done more testing. Reclocking between: 1) 110MHz and 250MHz - 1 corrupted frame on every reclock 2) 110MHz and 130MHz - 1 corrupted frame on every reclock I don't have more ideas :| -- Rafał -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
On Sat, Dec 26, 2009 at 02:46:29AM +0100, Rafał Miłecki wrote: W dniu 24 grudnia 2009 08:19 użytkownik Michel Dänzer mic...@daenzer.net napisał: I suspect the delay is more likely due to the workqueue than the interrupt itself. Way back when I implemented DRI1 tear-free buffer swaps for i945, I had to use a tasklet to reliably do work within the vertical blank period. I can not use tasklet as I need to sleep in setting engine function (AtomBIOS command does it). First of all I converted Alex's code to take requested mode before handling IRQ. Unfortunately that didn't help. Then I've converted VBLANK sync from work queue to wait_event_interruptible_timeout and wake_up_interruptible (btw. code seems much cleaner). This also didn't help. There are some my experiments with engine. Reclocking between: 1) 110MHz and 680MHz - 1 corrupted frame on every reclock 2) 200MHz and 680MHz - 1 corrupted frame on almost every reclock 3) 250MHz and 680MHz - no corruptions 4) 340MHz and 680MHz - no corruptions 5) 630MHz and 680MHz - no corruptions Maybe it's just downclocking to very low 110MHz that shouldn't happen? My GPU works fine on this engine clock (no corruptions) but still maybe reclocking to so low value can not be performed without corruption? I don't think anymore it's timing related issue. -- Rafał What is the screen resolution ? Cheers, Jerome -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
2009/12/26 Jerome Glisse gli...@freedesktop.org: What is the screen resolution ? It's 1600x900 panel driven by INTERNAL_KLDSCP_LVTMA. I guess you think about minimum clocks needed to drive my display, am I right? It could make sense if I would see general corruptions and not only at reclocking time. -- Rafał -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
2009/12/26 Rafał Miłecki zaj...@gmail.com: W dniu 26 grudnia 2009 02:46 użytkownik Rafał Miłecki zaj...@gmail.com napisał: There are some my experiments with engine. Reclocking between: 1) 110MHz and 680MHz - 1 corrupted frame on every reclock 2) 200MHz and 680MHz - 1 corrupted frame on almost every reclock 3) 250MHz and 680MHz - no corruptions 4) 340MHz and 680MHz - no corruptions 5) 630MHz and 680MHz - no corruptions Done more testing. Reclocking between: 1) 110MHz and 250MHz - 1 corrupted frame on every reclock 2) 110MHz and 130MHz - 1 corrupted frame on every reclock I don't have more ideas :| It may be that the engine doesn't like to be reclocked while it's running. Perhaps we should use the GUI idle interrupt rather than vblanks to reclock the engine. Alex -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
W dniu 26 grudnia 2009 20:08 użytkownik Alex Deucher
alexdeuc...@gmail.com napisał:
It may be that the engine doesn't like to be reclocked while it's
running. Perhaps we should use the GUI idle interrupt rather than
vblanks to reclock the engine.
Could you say something more about GUI idle interrupt, please? What is
this, do we already have code for that?
I've tried following:
if (reclock_decision) {
mutex_lock(rdev-cp.mutex);
radeon_fence_wait_last(rdev);
wait_event_interruptible_timeout(...)
radeon_set_power_state(rdev);
mutex_unlock(rdev-cp.mutex);
}
but this didn't help. And of course it wouldn't be perfect solution
because we make engine stop receiving new tasks, not sure if this is
nice way.
--
Rafał
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
W dniu 26 grudnia 2009 02:46 użytkownik Rafał Miłecki zaj...@gmail.com napisał: W dniu 24 grudnia 2009 08:19 użytkownik Michel Dänzer mic...@daenzer.net napisał: I suspect the delay is more likely due to the workqueue than the interrupt itself. Way back when I implemented DRI1 tear-free buffer swaps for i945, I had to use a tasklet to reliably do work within the vertical blank period. I can not use tasklet as I need to sleep in setting engine function (AtomBIOS command does it). First of all I converted Alex's code to take requested mode before handling IRQ. Unfortunately that didn't help. Then I've converted VBLANK sync from work queue to wait_event_interruptible_timeout and wake_up_interruptible (btw. code seems much cleaner). This also didn't help. There are some my experiments with engine. Reclocking between: 1) 110MHz and 680MHz - 1 corrupted frame on every reclock 2) 200MHz and 680MHz - 1 corrupted frame on almost every reclock 3) 250MHz and 680MHz - no corruptions 4) 340MHz and 680MHz - no corruptions 5) 630MHz and 680MHz - no corruptions Maybe it's just downclocking to very low 110MHz that shouldn't happen? My GPU works fine on this engine clock (no corruptions) but still maybe reclocking to so low value can not be performed without corruption? I don't think anymore it's timing related issue. [ 12.638290] [drm] 6 Power State(s) [ 12.638292] [drm] State 0 Default (default) [ 12.638293] [drm]16 PCIE Lanes [ 12.638295] [drm]3 Clock Mode(s) [ 12.638297] [drm]0 engine/memory: 68/80 [ 12.638298] [drm]1 engine/memory: 68/80 [ 12.638300] [drm]2 engine/memory: 68/80 [ 12.638302] [drm] State 1 Performance [ 12.638303] [drm]16 PCIE Lanes [ 12.638304] [drm]3 Clock Mode(s) [ 12.638306] [drm]0 engine/memory: 11/405000 [ 12.638308] [drm]1 engine/memory: 30/405000 [ 12.638310] [drm]2 engine/memory: 68/80 [ 12.638311] [drm] State 2 Battery [ 12.638313] [drm]16 PCIE Lanes [ 12.638314] [drm]3 Clock Mode(s) [ 12.638316] [drm]0 engine/memory: 11/405000 [ 12.638317] [drm]1 engine/memory: 11/405000 [ 12.638319] [drm]2 engine/memory: 30/405000 [ 12.638321] [drm] State 3 Default [ 12.638322] [drm]16 PCIE Lanes [ 12.638323] [drm]3 Clock Mode(s) [ 12.638325] [drm]0 engine/memory: 30/40 [ 12.638327] [drm]1 engine/memory: 55/70 [ 12.638328] [drm]2 engine/memory: 55/70 [ 12.638330] [drm] State 4 Performance [ 12.638331] [drm]16 PCIE Lanes [ 12.638333] [drm]3 Clock Mode(s) [ 12.638334] [drm]0 engine/memory: 30/80 [ 12.638336] [drm]1 engine/memory: 30/80 [ 12.638338] [drm]2 engine/memory: 68/80 [ 12.638339] [drm] State 5 Battery [ 12.638341] [drm]16 PCIE Lanes [ 12.638342] [drm]3 Clock Mode(s) [ 12.638344] [drm]0 engine/memory: 30/405000 [ 12.638345] [drm]1 engine/memory: 30/405000 [ 12.638347] [drm]2 engine/memory: 30/405000 -- Rafał -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
W dniu 24 grudnia 2009 08:19 użytkownik Michel Dänzer mic...@daenzer.net napisał: I suspect the delay is more likely due to the workqueue than the interrupt itself. Way back when I implemented DRI1 tear-free buffer swaps for i945, I had to use a tasklet to reliably do work within the vertical blank period. I can not use tasklet as I need to sleep in setting engine function (AtomBIOS command does it). First of all I converted Alex's code to take requested mode before handling IRQ. Unfortunately that didn't help. Then I've converted VBLANK sync from work queue to wait_event_interruptible_timeout and wake_up_interruptible (btw. code seems much cleaner). This also didn't help. There are some my experiments with engine. Reclocking between: 1) 110MHz and 680MHz - 1 corrupted frame on every reclock 2) 200MHz and 680MHz - 1 corrupted frame on almost every reclock 3) 250MHz and 680MHz - no corruptions 4) 340MHz and 680MHz - no corruptions 5) 630MHz and 680MHz - no corruptions Maybe it's just downclocking to very low 110MHz that shouldn't happen? My GPU works fine on this engine clock (no corruptions) but still maybe reclocking to so low value can not be performed without corruption? I don't think anymore it's timing related issue. -- Rafał -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
2009/12/23 Rafał Miłecki zaj...@gmail.com: I applied patches from http://www.botchco.com/alex/xorg/pm/ and now engine reclocks between 110MHz and 680MHz. The problem is I see ~10 black horizontal lines for a one frame time on almost every reclock. I tried to fix this or at least understand it somehow but without success. 1) Putting 500ms delay after every reclock doesn't improve anything 2) Reclocking between 110MHz and 130MHz (instead 680MHz) doesn't improve 3) Calling atombios_crtc_set_pll after reclocking doesn't improve No need to mess with the pixel clocks. 4) Calling ClockSource AtomBIOS commane after reclocking doesn't improve You shouldn't need to mess with this either. Do you have any other ideas? I suspect the reclock is missing the blanking period. Try removing the debugging output in my patch as that adds additional latency. Also, if the latency of the reclock is too long, we may want to trigger the reclock on a vline irq say 3/4 of the way down the screen to give us some additional time. Alex -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
W dniu 24 grudnia 2009 02:59 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2009/12/23 Rafał Miłecki zaj...@gmail.com: Do you have any other ideas? I suspect the reclock is missing the blanking period. Try removing the debugging output in my patch as that adds additional latency. Also, if the latency of the reclock is too long, we may want to trigger the reclock on a vline irq say 3/4 of the way down the screen to give us some additional time. I remove DRM_INFOs and also moved radeon_get_power_state calls from IRQ handler to line before rdev-pm.vblank_callback = true;. This didn't help. I guess you may be right with this VBLANK. We may receive that too late and don't hit vblank. Maybe with low engine we even parse IRQs slower? Does VLINE come just always? It doesn't seem we enable this interrupt anywhere. -- Rafał -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
2009/12/23 Rafał Miłecki zaj...@gmail.com: W dniu 24 grudnia 2009 02:59 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2009/12/23 Rafał Miłecki zaj...@gmail.com: Do you have any other ideas? I suspect the reclock is missing the blanking period. Try removing the debugging output in my patch as that adds additional latency. Also, if the latency of the reclock is too long, we may want to trigger the reclock on a vline irq say 3/4 of the way down the screen to give us some additional time. I remove DRM_INFOs and also moved radeon_get_power_state calls from IRQ handler to line before rdev-pm.vblank_callback = true;. This didn't help. Too bad. I guess you may be right with this VBLANK. We may receive that too late and don't hit vblank. Maybe with low engine we even parse IRQs slower? Nope. the CPU processes interrupts. The irq handler is part of the driver and runs on the host. Does VLINE come just always? It doesn't seem we enable this interrupt anywhere. It's not enabled at the moment as nothing uses it. You can set it to fire an interrupt at a particular vline during scanout. The info needed is in the r5xx and r6xx modesetting docs and in the reg headers and code in the driver. One possible problem is that we use the vline stuff (not the interrupt, just the vline) for Xv anti-tearing stuff, so you may run into issues there. Alex -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
On Thu, 2009-12-24 at 03:24 +0100, Rafał Miłecki wrote: W dniu 24 grudnia 2009 02:59 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: 2009/12/23 Rafał Miłecki zaj...@gmail.com: Do you have any other ideas? I suspect the reclock is missing the blanking period. Try removing the debugging output in my patch as that adds additional latency. Also, if the latency of the reclock is too long, we may want to trigger the reclock on a vline irq say 3/4 of the way down the screen to give us some additional time. I remove DRM_INFOs and also moved radeon_get_power_state calls from IRQ handler to line before rdev-pm.vblank_callback = true;. This didn't help. I guess you may be right with this VBLANK. We may receive that too late and don't hit vblank. Maybe with low engine we even parse IRQs slower? I suspect the delay is more likely due to the workqueue than the interrupt itself. Way back when I implemented DRI1 tear-free buffer swaps for i945, I had to use a tasklet to reliably do work within the vertical blank period. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
