Re: [PATCH] vga_switcheroo: initial implementation (v11)
2010/2/26 Dave Airlie airl...@gmail.com: v11: fix bug in resuming Intel for 2nd time. NACK. You totally ignored my previous audio comments. -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 0/3] drm/radeon/kms: little audio stuff cleaning
This patchset is drm-next based, tried to clean all our mistakes :) Rafał Miłecki (3): Revert drm/radeon/kms: disable HDMI audio for now on rv710/rv730 drm/radeon/kms: do not disable audio engine twice drm/radeon/kms: do not preset audio stuff and start timer when not using audio drivers/gpu/drm/radeon/r600_audio.c |9 - 1 files changed, 4 insertions(+), 5 deletions(-) -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/3] Revert drm/radeon/kms: disable HDMI audio for now on rv710/rv730
This commit disabled audio on RV710 and RV740 only, leaving RV770 and RV730.
The order is: CHIP_RV770 CHIP_RV730 CHIP_RV710 CHIP_RV740.
It is not needed anway, as we do not even try to enable audio on RV770 and
newer. We call initializing function in r600.c only, not in rv770.c.
If there is something causing green tinges, it's HDMI mode setting for encoder
and I will try to debug that.
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/gpu/drm/radeon/r600_audio.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_audio.c
b/drivers/gpu/drm/radeon/r600_audio.c
index 387abaa..a8366ce 100644
--- a/drivers/gpu/drm/radeon/r600_audio.c
+++ b/drivers/gpu/drm/radeon/r600_audio.c
@@ -35,7 +35,7 @@
*/
static int r600_audio_chipset_supported(struct radeon_device *rdev)
{
- return (rdev-family = CHIP_R600 rdev-family CHIP_RV710)
+ return rdev-family = CHIP_R600
|| rdev-family == CHIP_RS600
|| rdev-family == CHIP_RS690
|| rdev-family == CHIP_RS740;
--
1.6.4.2
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: suspend and resume audio stuff
Fixes FDO bug #26214
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/gpu/drm/radeon/r600.c |8
drivers/gpu/drm/radeon/r600_audio.c |3 +--
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600.c b/drivers/gpu/drm/radeon/r600.c
index d279089..76d0cdb 100644
--- a/drivers/gpu/drm/radeon/r600.c
+++ b/drivers/gpu/drm/radeon/r600.c
@@ -1944,6 +1944,13 @@ int r600_resume(struct radeon_device *rdev)
DRM_ERROR(radeon: failled testing IB (%d).\n, r);
return r;
}
+
+ r = r600_audio_init(rdev);
+ if (r) {
+ DRM_ERROR(radeon: audio resume failed\n);
+ return r;
+ }
+
return r;
}
@@ -1951,6 +1958,7 @@ int r600_suspend(struct radeon_device *rdev)
{
int r;
+ r600_audio_fini(rdev);
/* FIXME: we should wait for ring to be empty */
r600_cp_stop(rdev);
rdev-cp.ready = false;
diff --git a/drivers/gpu/drm/radeon/r600_audio.c
b/drivers/gpu/drm/radeon/r600_audio.c
index 99e2c38..e90da2e 100644
--- a/drivers/gpu/drm/radeon/r600_audio.c
+++ b/drivers/gpu/drm/radeon/r600_audio.c
@@ -261,7 +261,6 @@ void r600_audio_fini(struct radeon_device *rdev)
if (!r600_audio_chipset_supported(rdev))
return;
- WREG32_P(R600_AUDIO_ENABLE, 0x0, ~0x8100);
-
del_timer(rdev-audio_timer);
+ WREG32_P(R600_AUDIO_ENABLE, 0x0, ~0x8100);
}
--
1.6.4.2
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/3] drm/radeon/kms: do not preset audio stuff and start timer when not using audio
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
drivers/gpu/drm/radeon/r600_audio.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_audio.c
b/drivers/gpu/drm/radeon/r600_audio.c
index 2dd8891..db92801 100644
--- a/drivers/gpu/drm/radeon/r600_audio.c
+++ b/drivers/gpu/drm/radeon/r600_audio.c
@@ -160,10 +160,10 @@ static void r600_audio_engine_enable(struct radeon_device
*rdev, bool enable)
*/
int r600_audio_init(struct radeon_device *rdev)
{
- if (!r600_audio_chipset_supported(rdev))
+ if (!radeon_audio || !r600_audio_chipset_supported(rdev))
return 0;
- r600_audio_engine_enable(rdev, radeon_audio);
+ r600_audio_engine_enable(rdev, true);
rdev-audio_channels = -1;
rdev-audio_rate = -1;
@@ -266,7 +266,7 @@ void r600_audio_set_clock(struct drm_encoder *encoder, int
clock)
*/
void r600_audio_fini(struct radeon_device *rdev)
{
- if (!r600_audio_chipset_supported(rdev))
+ if (!radeon_audio || !r600_audio_chipset_supported(rdev))
return;
del_timer(rdev-audio_timer);
--
1.6.4.2
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/3] drm/radeon/kms: do not disable audio engine twice
Signed-off-by: Rafał Miłecki zaj...@gmail.com --- That's result of taking related patches from 2 branches --- drivers/gpu/drm/radeon/r600_audio.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/radeon/r600_audio.c b/drivers/gpu/drm/radeon/r600_audio.c index a8366ce..2dd8891 100644 --- a/drivers/gpu/drm/radeon/r600_audio.c +++ b/drivers/gpu/drm/radeon/r600_audio.c @@ -270,7 +270,6 @@ void r600_audio_fini(struct radeon_device *rdev) return; del_timer(rdev-audio_timer); - WREG32_P(R600_AUDIO_ENABLE, 0x0, ~0x8100); r600_audio_engine_enable(rdev, false); } -- 1.6.4.2 -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: suspend and resume audio stuff
W dniu 26 lutego 2010 09:44 użytkownik Rafał Miłecki zaj...@gmail.com napisał: Fixes FDO bug #26214 Whoops, I dumped patches to already existing directory. Ignore this one please. Sorry. -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 2/2] vga_switcheroo: initial implementation (v8)
Oh I should probably have dropped all the audio bits, I didn't even see this reply before I updated to v11. The r600 audio code is a bit of disaster area hopefully we can clean it up, like the timer was firing after the device was suspended. I'll repost with all that r600 audio ripped out and you can fix the mess. Don't mess with r600_audio_* there. You call if for all chipsets which is not needed and break nice SR layout, which is chipset specific. I guess you needed that because you didn't work on branch containing my patch: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=38fd2c6ff526e6a59edfa8e08f6f0724646784c4 (you commited it to drm-linus) This patch is now based on Linus tree, but yeah the original version predates your patches. -int radeon_audio = 1; +int radeon_audio = 0; Why?! What for we disable this feature by default?! If you see some reason for that, explain it to others please. I can change my mind, but for now I don't like this. It makes audio an option from just working-out-of-box. Oversights, the audio was just broken in the presence of suspend/resume when I wrote it. Dave. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 2/2] vga_switcheroo: initial implementation (v8)
W dniu 26 lutego 2010 09:50 użytkownik Dave Airlie airl...@gmail.com napisał: Oh I should probably have dropped all the audio bits, I didn't even see this reply before I updated to v11. The r600 audio code is a bit of disaster area hopefully we can clean it up, like the timer was firing after the device was suspended. I'll repost with all that r600 audio ripped out and you can fix the mess. I already did, 3 minutes ago ;) -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26438] [CS checker code][r6xx][2.6.33-rc6 fc76be4 (git snapshot) + drm-radeon-next] playing Second Life cause GPU lockup.
http://bugs.freedesktop.org/show_bug.cgi?id=26438 Fabio Pedretti fabio@libero.it changed: What|Removed |Added CC||fabio@libero.it Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Fabio Pedretti fabio@libero.it 2010-02-26 01:17:03 PST --- Patch applied in 2.6.33. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25506] radeon kms causes 33 second boot delay on kernel v2.6.32
http://bugs.freedesktop.org/show_bug.cgi?id=25506 Fabio Pedretti fabio@libero.it changed: What|Removed |Added CC||fabio@libero.it Status|NEW |RESOLVED Resolution||FIXED --- Comment #18 from Fabio Pedretti fabio@libero.it 2010-02-26 01:17:51 PST --- Fixed in 2.6.33 -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH][RFC] time: add wait_interruptible_timeout macro to sleep (w. timeout) until wake_up
Forwarding to ppl I could often notice in git log time.h
-- Wiadomość przekazana dalej --
From: Rafał Miłecki zaj...@gmail.com
Date: 21 lutego 2010 15:10
Subject: [PATCH][RFC] time: add wait_interruptible_timeout macro to
sleep (w. timeout) until wake_up
To: Linux Kernel Mailing List linux-ker...@vger.kernel.org,
dri-devel@lists.sourceforge.net
CC: Rafał Miłecki zaj...@gmail.com
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
We try to implement some PM in radeon KMS and we need to sync with VLBANK for
reclocking engine/memory. The easiest and cleanest way seems to be sleeping in
timer handler just before reclocking. Then our IRQ handler calls wake_up and we
continue reclocking.
As you see our sleeping is condition-less, we just wait for waking up queue.
We hope this waking will happen from IRQ handler, but for less-happy case we
also use some timeout (this will probably cause some single corruption, but
we can live with it).
Following macro is soemthing that seems to work fine for us, but instead
introducing this to radeon KMS only, I'd like to propose adding this to whole
wait.h. Do you this it's something we should place there? Can someone take this
patch for me? Or maybe you find this rather useless and we should keep this
marco locally?
---
include/linux/wait.h | 25 +
1 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/include/linux/wait.h b/include/linux/wait.h
index a48e16b..998475b 100644
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -332,6 +332,31 @@ do {
\
__ret; \
})
+/**
+ * wait_interruptible_timeout - sleep until a waitqueue is woken up
+ * @wq: the waitqueue to wait on
+ * @timeout: timeout, in jiffies
+ *
+ * The process is put to sleep (TASK_INTERRUPTIBLE) until the waitqueue
+ * @wq is woken up. It can be done manually with wake_up or will happen
+ * if timeout elapses.
+ *
+ * The function returns 0 if the @timeout elapsed, remaining jiffies
+ * if workqueue was waken up earlier.
+ */
+#define wait_interruptible_timeout(wq, timeout)
\
+({ \
+ long __ret = timeout; \
+ \
+ DEFINE_WAIT(__wait); \
+ prepare_to_wait(wq, __wait, TASK_INTERRUPTIBLE); \
+ if (!signal_pending(current)) \
+ __ret = schedule_timeout(__ret); \
+ finish_wait(wq, __wait); \
+ \
+ __ret; \
+})
+
#define __wait_event_interruptible_exclusive(wq, condition, ret) \
do { \
DEFINE_WAIT(__wait); \
--
1.6.4.2
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15276] latest git kernel: general protection fault: 0000 [#1]
http://bugzilla.kernel.org/show_bug.cgi?id=15276 --- Comment #47 from Andreas Wallberg andreas.wallb...@gmail.com 2010-02-26 10:39:08 --- (In reply to comment #44) Well, first of all I haven't touched the ttm_tt patch yet. However, after upgrading userland mesa, libdrm, glproto and xf86-video-ati to latest git from 20100217 to 20100222 I stopped having the crashes using the KWin Present Windows test case. Kernel is still 2.6.33-rc7. To be clear: with version 20100222 and kernel 2.6.33-rc7 I can't reproduce the crashes using the Present Windows test case. The test case caused crashes with version 20100217 with the same kernel. Interesting, my system is just as crash-prone as before, running 2.6.33 stable and a graphics stack from 20100224. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26769] New: r600: wrong fragment shader input when using gl_fragCoord.
http://bugs.freedesktop.org/show_bug.cgi?id=26769 Summary: r600: wrong fragment shader input when using gl_fragCoord. Product: Mesa Version: git Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: wielkie...@gmail.com Created an attachment (id=33583) -- (http://bugs.freedesktop.org/attachment.cgi?id=33583) Fragment shader to reproduce bug Consider simple shader in attachment. It works as expected, samples texture depending on input variable from vertex shader and puts texel as color. Uncommenting first comment shouldn't change anything (gl_FragDepth just defaults to gl_FragCoord.z), but it's not the case. In fact when I do so, fp_texCoord is always vec2(0.0). Well, I'm not sure about that, but it gives same results (e.g. all triangles are red, as is 0.0, 0.0 coordinate). Note that using gl_FragCoord in *any* way (that is not optimized away) causes this failure. For example uncommenting second comment gives same results. I can include vertex shader (that is also simple, just multiplies matrix with gl_Position and copies texCoord into fp_texCoord) and sample program, if that matter. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26195] Green screen on HDMI with RV730
http://bugs.freedesktop.org/show_bug.cgi?id=26195 --- Comment #11 from Rafał Miłecki zaj...@gmail.com 2010-02-26 03:50:27 PST --- Created an attachment (id=33584) -- (http://bugs.freedesktop.org/attachment.cgi?id=33584) fast debugging Please apply this patch, recompile, reboot and provide dmesg output. It just prints messages, does not fix anything. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26195] Green screen on HDMI with RV730
http://bugs.freedesktop.org/show_bug.cgi?id=26195 --- Comment #12 from Rafał Miłecki zaj...@gmail.com 2010-02-26 03:54:18 PST --- Created an attachment (id=33585) -- (http://bugs.freedesktop.org/attachment.cgi?id=33585) do not set hdmi mode After you test first patch and provide output, please apply this one. It can be applied on top of previous one or on clean branch, it does not matter. Does it workaround green screen problem? It is not supposed to fix audio, just check reason. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH][RFC] time: add wait_interruptible_timeout macro to sleep (w. timeout) until wake_up
On Fri, 26 Feb 2010, Rafał Miłecki wrote: Forwarding to ppl I could often notice in git log time.h And how is this related to time.h ? -- Wiadomość przekazana dalej -- From: Rafał Miłecki zaj...@gmail.com Date: 21 lutego 2010 15:10 Subject: [PATCH][RFC] time: add wait_interruptible_timeout macro to sleep (w. timeout) until wake_up To: Linux Kernel Mailing List linux-ker...@vger.kernel.org, dri-devel@lists.sourceforge.net CC: Rafał Miłecki zaj...@gmail.com Signed-off-by: Rafał Miłecki zaj...@gmail.com --- We try to implement some PM in radeon KMS and we need to sync with VLBANK for reclocking engine/memory. The easiest and cleanest way seems to be sleeping in timer handler just before reclocking. Then our IRQ handler calls wake_up and we Sleeping in the timer handler ? In which context runs this timer handler ? continue reclocking. As you see our sleeping is condition-less, we just wait for waking up queue. Your sleep is not condition-less at all. See below. We hope this waking will happen from IRQ handler, but for less-happy case we also use some timeout (this will probably cause some single corruption, but we can live with it). Following macro is soemthing that seems to work fine for us, but instead introducing this to radeon KMS only, I'd like to propose adding this to whole wait.h. Do you this it's something we should place there? Can someone take this patch for me? Or maybe you find this rather useless and we should keep this marco locally? You better delete it right away. It's broken and racy. If the interrupt happens right before you enqueue to the wake queue, then you miss it. The old interruptible_sleep_on_timeout() was replaced by the event wait functions which have a condition exaclty to avoid that race. And you have a condition: Did an interrupt happen? Thanks, tglx -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH][RFC] time: add wait_interruptible_timeout macro to sleep (w. timeout) until wake_up
W dniu 26 lutego 2010 12:55 użytkownik Thomas Gleixner t...@linutronix.de napisał: On Fri, 26 Feb 2010, Rafał Miłecki wrote: Forwarding to ppl I could often notice in git log time.h And how is this related to time.h ? Ouch, time.h vs. wait.h. I'm sorry. -- Wiadomość przekazana dalej -- From: Rafał Miłecki zaj...@gmail.com Date: 21 lutego 2010 15:10 Subject: [PATCH][RFC] time: add wait_interruptible_timeout macro to sleep (w. timeout) until wake_up To: Linux Kernel Mailing List linux-ker...@vger.kernel.org, dri-devel@lists.sourceforge.net CC: Rafał Miłecki zaj...@gmail.com Signed-off-by: Rafał Miłecki zaj...@gmail.com --- We try to implement some PM in radeon KMS and we need to sync with VLBANK for reclocking engine/memory. The easiest and cleanest way seems to be sleeping in timer handler just before reclocking. Then our IRQ handler calls wake_up and we Sleeping in the timer handler ? In which context runs this timer handler ? We have our struct delayed_work which we first init and then we use queue_delayed_work to start this timer. So it's not real-real timer as struct timer_list. So this is actually delayed_work handler. Sorry (again) for my bad naming. Anyway in this handler we just take decision about (down|up)clocking, we wait for VBLANK (to avoid display corrupted picture) and right after it happens, we reclock engine (plus memory in future). continue reclocking. As you see our sleeping is condition-less, we just wait for waking up queue. Your sleep is not condition-less at all. See below. We hope this waking will happen from IRQ handler, but for less-happy case we also use some timeout (this will probably cause some single corruption, but we can live with it). Following macro is soemthing that seems to work fine for us, but instead introducing this to radeon KMS only, I'd like to propose adding this to whole wait.h. Do you this it's something we should place there? Can someone take this patch for me? Or maybe you find this rather useless and we should keep this marco locally? You better delete it right away. It's broken and racy. If the interrupt happens right before you enqueue to the wake queue, then you miss it. The old interruptible_sleep_on_timeout() was replaced by the event wait functions which have a condition exaclty to avoid that race. Well, I'm completely fine with that. After taking decision about reclocking I request hardware to start reporting VBLANK interrupts. Then (without any hurry) I go into sleep and next VBLANK interrupt wake me up. Right after waking up I reclock engine/memory and then (without hurry) I tell hardware to stop reporting VBLANK interrupts. I guess it can be AMD-GPU specific interrupts mechanism there, but that's how it works. I can point responsible code in driver if you wish. And you have a condition: Did an interrupt happen? Yeah, I guess that's kind of condition. I meant that I don't use any driver's variable as condition to stop sleeping. Sorry again for my mistakes mentioned above. -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: modetest + libkms, intel, vmwgfx
Hello. I have been success on VMWare 5.5.2 + official linux-2.6.33. modetest -s 4...@6:800x600 works well. But I have to add : drmModeDirtryFB(fd, fb_id, NULL, 0) after drmModeSetCrtc line. The color squares are displayed, but in dmesg i still have WARN_ON(vmw_framebuffer_dmabuf_pin). So it is moving the right way. Bye - Original Message - From: Peter Hanzel hanzelpe...@gmail.com To: Kristian Høgsberg k...@bitplanet.net Cc: dri-devel@lists.sourceforge.net Sent: Monday, February 22, 2010 10:37 AM Subject: Re: modetest + libkms, intel, vmwgfx Hello. I have made test\modetest\modetest.c to use libkms. I have tested it on intel gfx and also in VMWare with vmwgfx. With intel I was succesfull - but it needed patches to libkms (attached, especially with DRM_I915_GEM_SET_DOMAIN, otherwise you get result like attached picture). But with vmwgfx with same modetest.c it displays only blank screen, but mode is changed. Regards. - Original Message - From: Kristian Høgsberg k...@bitplanet.net To: Peter Hanzel hanzelpe...@gmail.com Cc: dri-devel@lists.sourceforge.net Sent: Tuesday, February 09, 2010 3:14 PM Subject: Re: vmwgfx + VMWare 7.0 - libdrm modetest.c On Tue, Feb 9, 2010 at 8:05 AM, Peter Hanzel hanzelpe...@gmail.com wrote: Hello. I have a question about libdrm/libkms and test/modetest/modetest.c. I am now working with vmwgfx + VMWare 7.0, where vmwgfx had correctly initialized framebuffer and also now using fbcon. Now I want to test it woth modetest.c This program is only for intel so i recoded it to use libkms functions. Could you send the changes to make modetest.c use libkms as a patch? It's a good idea. cheers, Kristian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: fence cleanup + more reliable GPU lockup detection
This patch cleanup the fence code, it drops the timeout field of
fence as the time to complete each IB is unpredictable and shouldn't
be bound.
The fence cleanup lead to GPU lockup detection improvement, this
patch introduce a callback, allowing to do asic specific test for
lockup detection. In this patch the CP is use as a first indicator
of GPU lockup. If CP doesn't make progress during 1second we assume
we are facing a GPU lockup.
To avoid overhead of testing GPU lockup frequently due to fence
taking time to be signaled we query the lockup callback every
100msec. There is plenty code comment explaining the design choise
inside the code.
This have been tested mostly on R3XX/R5XX hw, in normal running
destkop (compiz firefox, quake3 running) the lockup callback wasn't
call once (1 hour session). Also tested with forcing GPU lockup and
lockup was reported after the 1s CP activity timeout.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/evergreen.c|6 ++
drivers/gpu/drm/radeon/r100.c | 84 +++
drivers/gpu/drm/radeon/r300.c | 27 -
drivers/gpu/drm/radeon/r600.c | 33 +-
drivers/gpu/drm/radeon/radeon.h | 101 ++--
drivers/gpu/drm/radeon/radeon_asic.h | 20 ++-
drivers/gpu/drm/radeon/radeon_fence.c | 87 ++--
drivers/gpu/drm/radeon/rv770.c|6 --
8 files changed, 262 insertions(+), 102 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index b8cd119..11688e2 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -485,6 +485,12 @@ int evergreen_mc_init(struct radeon_device *rdev)
return 0;
}
+bool evergreen_gpu_is_lockup(struct radeon_device *rdev)
+{
+ /* FIXME: implement for evergreen */
+ return false;
+}
+
int evergreen_gpu_reset(struct radeon_device *rdev)
{
/* FIXME: implement for evergreen */
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index 932ce24..a77e754 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1780,6 +1780,90 @@ int r100_rb2d_reset(struct radeon_device *rdev)
return -1;
}
+void r100_gpu_lockup_update(struct r100_gpu_lockup *lockup, struct radeon_cp
*cp)
+{
+ lockup-last_cp_rptr = cp-rptr;
+ lockup-last_jiffies = jiffies;
+}
+
+/**
+ * r100_gpu_cp_is_lockup() - check if CP is lockup by recording information
+ * @rdev: radeon device structure
+ * @lockup:r100_gpu_lockup structure holding CP lockup tracking
informations
+ * @cp:radeon_cp structure holding CP information
+ *
+ * We don't need to initialize the lockup tracking information as we will
either
+ * have CP rptr to a different value of jiffies wrap around which will force
+ * initialization of the lockup tracking informations.
+ *
+ * A possible false positivie is if we get call after while and last_cp_rptr ==
+ * the current CP rptr, even if it's unlikely it might happen. To avoid this
+ * if the elapsed time since last call is bigger than 2 second than we return
+ * false and update the tracking information. Due to this the caller must call
+ * r100_gpu_cp_is_lockup several time in less than 2sec for lockup to be
reported
+ * the fencing code should be cautious about that.
+ *
+ * Caller should write to the ring to force CP to do something so we don't get
+ * false positive when CP is just gived nothing to do.
+ *
+ **/
+bool r100_gpu_cp_is_lockup(struct radeon_device *rdev, struct r100_gpu_lockup
*lockup, struct radeon_cp *cp)
+{
+ unsigned long cjiffies, elapsed;
+
+ cjiffies = jiffies;
+ if (!time_after(cjiffies, lockup-last_jiffies)) {
+ /* likely a wrap around */
+ lockup-last_jiffies = jiffies;
+ return false;
+ }
+ if (cp-rptr != lockup-last_cp_rptr) {
+ /* CP is still working no lockup */
+ lockup-last_cp_rptr = cp-rptr;
+ lockup-last_jiffies = jiffies;
+ return false;
+ }
+ elapsed = jiffies_to_msecs(cjiffies - lockup-last_jiffies);
+ if (elapsed = 2000) {
+ /* very likely the improbable case where current
+* rptr is equal to last recorded, a while ago, rptr
+* this is more likely a false positive update tracking
+* information which should force us to be recall at
+* latter point
+*/
+ lockup-last_cp_rptr = cp-rptr;
+ lockup-last_jiffies = jiffies;
+ return false;
+ }
+ if (elapsed = 1000) {
+ dev_err(rdev-dev, GPU lockup CP stall for more than
%lumsec\n, elapsed);
+ return true;
+ }
+ /* give a chance to the GPU ... */
+ return false;
+}
+
+bool
Re: [PATCH][RFC] time: add wait_interruptible_timeout macro to sleep (w. timeout) until wake_up
On Fri, 26 Feb 2010 11:38:59 +0100 Rafa Miecki zaj...@gmail.com wrote:
+#define wait_interruptible_timeout(wq, timeout)
\
+({ \
+long ret = timeout; \
+\
+DEFINE_WAIT(wait); \
+prepare_to_wait(wq, wait, TASK_INTERRUPTIBLE); \
+if (!signal_pending(current)) \
+ret = schedule_timeout(ret);\
+finish_wait(wq, wait); \
+\
+ret; \
+})
It's often a mistake to use signals in-kernel. Signals are more a
userspace thing and it's better to use the lower-level kernel-specific
messaging tools in-kernel. Bear in mind that userspace can
independently and asynchronously send, accept and block signals.
Can KMS use wait_event_interruptible_timeout()?
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/radeon/kms: fence cleanup + more reliable GPU lockup detection
2010/2/26 Jerome Glisse jgli...@redhat.com: The fence cleanup lead to GPU lockup detection improvement, this patch introduce a callback, allowing to do asic specific test for lockup detection. In this patch the CP is use as a first indicator of GPU lockup. If CP doesn't make progress during 1second we assume we are facing a GPU lockup. To avoid overhead of testing GPU lockup frequently due to fence taking time to be signaled we query the lockup callback every 100msec. There is plenty code comment explaining the design choise inside the code. Let me check this with my reproducible lock up :) Can I test this on top of any branch (like drm-next or drm-radeon-testing)? Or does it depend on some specific patches? -- Rafał -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH][RFC] time: add wait_interruptible_timeout macro to sleep (w. timeout) until wake_up
W dniu 26 lutego 2010 17:14 użytkownik Andrew Morton
a...@linux-foundation.org napisał:
On Fri, 26 Feb 2010 11:38:59 +0100 Rafa Miecki zaj...@gmail.com wrote:
+#define wait_interruptible_timeout(wq, timeout)
\
+({ \
+ long ret = timeout; \
+ \
+ DEFINE_WAIT(wait); \
+ prepare_to_wait(wq, wait, TASK_INTERRUPTIBLE); \
+ if (!signal_pending(current)) \
+ ret = schedule_timeout(ret); \
+ finish_wait(wq, wait); \
+ \
+ ret; \
+})
It's often a mistake to use signals in-kernel. Signals are more a
userspace thing and it's better to use the lower-level kernel-specific
messaging tools in-kernel. Bear in mind that userspace can
independently and asynchronously send, accept and block signals.
Can you point me to something kernel-level please?
Can KMS use wait_event_interruptible_timeout()?
No. Please check definition of this:
#define wait_event_interruptible_timeout(wq, condition, timeout)\
({ \
long __ret = timeout; \
if (!(condition)) \
__wait_event_interruptible_timeout(wq, condition, __ret); \
__ret; \
})
It uses condition there, but that's not a big issue. We just need to
pass 0 (false) there and it will work so far.
But then check __wait_event_interruptible_timeout definition, please.
It goes into sleep and after waking up it checks for value returned by
schedule_timeout. That's what breaks our (needed by radeon) sleeping.
If timeout didn't expire it does into sleep again!
What we need is continue reclocking after waking up. If this has
happend before timeout expired, that means we was woken up by VBLANK
interrupt handler. We love that situation and we do not want to go
sleep again.
On the other hand we need to have some timeout in case VBLANK
interrupt won't come.
--
Rafał
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/3] libdrm_nouveau requires libdrm
nouveau_drmif.h includes xf86drm.h.
Signed-off-by: Julien Cristau jcris...@debian.org
---
nouveau/libdrm_nouveau.pc.in |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/nouveau/libdrm_nouveau.pc.in b/nouveau/libdrm_nouveau.pc.in
index 7ef49e5..6ae6287 100644
--- a/nouveau/libdrm_nouveau.pc.in
+++ b/nouveau/libdrm_nouveau.pc.in
@@ -8,3 +8,4 @@ Description: Userspace interface to nouveau kernel DRM services
Version: 0.6
Libs: -L${libdir} -ldrm_nouveau
Cflags: -I${includedir} -I${includedir}/drm -I${includedir}/nouveau
+Requires.private: libdrm
--
1.6.6.1
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 3/3] Install headers to $(includedir)/libdrm
Avoids conflicts with kernel headers.
Signed-off-by: Julien Cristau jcris...@debian.org
---
This was suggested by Eric so distros can let the kernel install drm
headers, but provide updated headers from libdrm so we can build new
drivers regardless of the kernel version.
include/drm/Makefile.am |2 +-
libdrm.pc.in |2 +-
nouveau/Makefile.am |2 +-
nouveau/libdrm_nouveau.pc.in |2 +-
radeon/Makefile.am |2 +-
radeon/libdrm_radeon.pc.in |2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/drm/Makefile.am b/include/drm/Makefile.am
index 9046955..43695bd 100644
--- a/include/drm/Makefile.am
+++ b/include/drm/Makefile.am
@@ -22,7 +22,7 @@
# however, r300 and via need their reg headers installed in order to build.
# better solutions are welcome.
-klibdrmincludedir = ${includedir}/drm
+klibdrmincludedir = ${includedir}/libdrm
klibdrminclude_HEADERS = \
drm.h \
drm_mode.h \
diff --git a/libdrm.pc.in b/libdrm.pc.in
index 6e00597..b46e2a6 100644
--- a/libdrm.pc.in
+++ b/libdrm.pc.in
@@ -7,4 +7,4 @@ Name: libdrm
Description: Userspace interface to kernel DRM services
Version: @PACKAGE_VERSION@
Libs: -L${libdir} -ldrm
-Cflags: -I${includedir} -I${includedir}/drm
+Cflags: -I${includedir} -I${includedir}/libdrm
diff --git a/nouveau/Makefile.am b/nouveau/Makefile.am
index 5d759c5..b6d214a 100644
--- a/nouveau/Makefile.am
+++ b/nouveau/Makefile.am
@@ -34,7 +34,7 @@ libdrm_nouveaucommoninclude_HEADERS = \
nouveau_reloc.h
-libdrm_nouveauincludedir = ${includedir}/drm
+libdrm_nouveauincludedir = ${includedir}/libdrm
libdrm_nouveauinclude_HEADERS = \
nouveau_drmif.h
diff --git a/nouveau/libdrm_nouveau.pc.in b/nouveau/libdrm_nouveau.pc.in
index 6ae6287..c78a28a 100644
--- a/nouveau/libdrm_nouveau.pc.in
+++ b/nouveau/libdrm_nouveau.pc.in
@@ -7,5 +7,5 @@ Name: libdrm_nouveau
Description: Userspace interface to nouveau kernel DRM services
Version: 0.6
Libs: -L${libdir} -ldrm_nouveau
-Cflags: -I${includedir} -I${includedir}/drm -I${includedir}/nouveau
+Cflags: -I${includedir} -I${includedir}/libdrm -I${includedir}/nouveau
Requires.private: libdrm
diff --git a/radeon/Makefile.am b/radeon/Makefile.am
index 29af1df..de78232 100644
--- a/radeon/Makefile.am
+++ b/radeon/Makefile.am
@@ -41,7 +41,7 @@ libdrm_radeon_la_SOURCES = \
radeon_bo.c \
radeon_cs.c
-libdrm_radeonincludedir = ${includedir}/drm
+libdrm_radeonincludedir = ${includedir}/libdrm
libdrm_radeoninclude_HEADERS = \
radeon_bo.h \
radeon_cs.h \
diff --git a/radeon/libdrm_radeon.pc.in b/radeon/libdrm_radeon.pc.in
index ab703e1..68ef0ab 100644
--- a/radeon/libdrm_radeon.pc.in
+++ b/radeon/libdrm_radeon.pc.in
@@ -7,4 +7,4 @@ Name: libdrm_radeon
Description: Userspace interface to kernel DRM services for radeon
Version: @PACKAGE_VERSION@
Libs: -L${libdir} -ldrm_radeon
-Cflags: -I${includedir} -I${includedir}/drm
+Cflags: -I${includedir} -I${includedir}/libdrm
--
1.6.6.1
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 2/3] libdrm_nouveau requires libdrm
On Fri, Feb 26, 2010 at 1:07 PM, Julien Cristau jcris...@debian.org wrote:
nouveau_drmif.h includes xf86drm.h.
If it's a source level dependency it should be a regular Requires: in
the .pc. Requires.private: is only for private libraries you link to
but don't expose their API in your header files. The idea is (AFAIK)
that you can ask pkg-config to list all libraries to link to for
static linking, in which case pkg-config needs a way to find all
needed libraries. It even looks like Requires.private has been
obsoleted by Libs.private in recent pkg-config.
Signed-off-by: Julien Cristau jcris...@debian.org
---
nouveau/libdrm_nouveau.pc.in | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/nouveau/libdrm_nouveau.pc.in b/nouveau/libdrm_nouveau.pc.in
index 7ef49e5..6ae6287 100644
--- a/nouveau/libdrm_nouveau.pc.in
+++ b/nouveau/libdrm_nouveau.pc.in
@@ -8,3 +8,4 @@ Description: Userspace interface to nouveau kernel DRM
services
Version: 0.6
Libs: -L${libdir} -ldrm_nouveau
Cflags: -I${includedir} -I${includedir}/drm -I${includedir}/nouveau
+Requires.private: libdrm
--
1.6.6.1
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH][RFC] time: add wait_interruptible_timeout macro to sleep (w. timeout) until wake_up
On Fri, Feb 26, 2010 at 06:33:57PM +0100, Rafał Miłecki wrote:
W dniu 26 lutego 2010 17:14 użytkownik Andrew Morton
a...@linux-foundation.org napisał:
On Fri, 26 Feb 2010 11:38:59 +0100 Rafa Miecki zaj...@gmail.com wrote:
+#define wait_interruptible_timeout(wq, timeout)
\
+({ \
+ long ret = timeout; \
+ \
+ DEFINE_WAIT(wait); \
+ prepare_to_wait(wq, wait, TASK_INTERRUPTIBLE); \
+ if (!signal_pending(current)) \
+ ret = schedule_timeout(ret); \
+ finish_wait(wq, wait); \
+ \
+ ret; \
+})
It's often a mistake to use signals in-kernel. Signals are more a
userspace thing and it's better to use the lower-level kernel-specific
messaging tools in-kernel. Bear in mind that userspace can
independently and asynchronously send, accept and block signals.
Can you point me to something kernel-level please?
Can KMS use wait_event_interruptible_timeout()?
No. Please check definition of this:
#define wait_event_interruptible_timeout(wq, condition, timeout) \
({\
long __ret = timeout; \
if (!(condition)) \
__wait_event_interruptible_timeout(wq, condition, __ret); \
__ret; \
})
It uses condition there, but that's not a big issue. We just need to
pass 0 (false) there and it will work so far.
Disabling the condition check doesn't make sense.
You could use a completion.
init_completion(vbl_irq);
enable_vbl_irq();
wait_for_completion(vbl_irq);
disable_vbl_irq();
and call complete(vbl_irq) in the interrupt handler.
The same would of course work with just some flag or counter
and a wait queue. Isn't there already a vbl counter that you could
compare in the condition?
--
Ville Syrjälä
syrj...@sci.fi
http://www.sci.fi/~syrjala/
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH 2/3] libdrm_nouveau requires libdrm
2010/2/26 Julien Cristau jcris...@debian.org: On Fri, Feb 26, 2010 at 13:38:59 -0500, Kristian Høgsberg wrote: On Fri, Feb 26, 2010 at 1:07 PM, Julien Cristau jcris...@debian.org wrote: nouveau_drmif.h includes xf86drm.h. If it's a source level dependency it should be a regular Requires: in the .pc. Requires.private: is only for private libraries you link to but don't expose their API in your header files. The idea is (AFAIK) that you can ask pkg-config to list all libraries to link to for static linking, in which case pkg-config needs a way to find all needed libraries. It even looks like Requires.private has been obsoleted by Libs.private in recent pkg-config. That's not what the pkg-config maintainer says... http://err.no/personal/blog/2008/Mar/25 Using Requires.private lets us get the necessary cflags, but avoids linking to the library if not using --static. Oh, I see. Well it sounds like at some point Requires.private did what I thought it did. Thanks for the pointer. Kristian -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/kms: initialize set_surface_reg reg for rs600 asic
rs600 asic was missing set_surface_reg callback leading to
oops.
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/radeon_asic.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_asic.h
b/drivers/gpu/drm/radeon/radeon_asic.h
index 4572a66..d3a157b 100644
--- a/drivers/gpu/drm/radeon/radeon_asic.h
+++ b/drivers/gpu/drm/radeon/radeon_asic.h
@@ -407,6 +407,8 @@ static struct radeon_asic rs600_asic = {
.get_pcie_lanes = NULL,
.set_pcie_lanes = NULL,
.set_clock_gating = radeon_atom_set_clock_gating,
+ .set_surface_reg = r100_set_surface_reg,
+ .clear_surface_reg = r100_clear_surface_reg,
.bandwidth_update = rs600_bandwidth_update,
.hpd_init = rs600_hpd_init,
.hpd_fini = rs600_hpd_fini,
--
1.6.6
--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25093] mesa demo cubemap renders incorrectly with some filter combinations.
http://bugs.freedesktop.org/show_bug.cgi?id=25093 Andy Furniss li...@andyfurniss.entadsl.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Andy Furniss li...@andyfurniss.entadsl.com 2010-02-26 11:34:40 PST --- (In reply to comment #0) Created an attachment (id=31208) -- (http://bugs.freedesktop.org/attachment.cgi?id=31208) [details] incorrect cubemap Git mesa/ddx drm-next on rv670 AGP. I've only just tried this so don't know if it has ever worked. Pressing f several times to cycle through the filter types with mesa/progs/demos/cubemap reveals that some combinations result in incorrect rendering compared to swrast. example attached. This is now working for me. My testing hasn't been that regular recently, so I am not sure when the fix happened. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] drm/radeon/kms: rename gpu_reset to asic_reset V2
Patch rename gpu_reset to asic_reset in prevision of having
gpu_reset doing more stuff than just basic asic reset.
V2 store the last time we had new fence in the fence driver
so on EBUSY/ERESTART we still keep accurate timing information
on how long we have been waiting for a given fence
Signed-off-by: Jerome Glisse jgli...@redhat.com
---
drivers/gpu/drm/radeon/evergreen.c |2 +-
drivers/gpu/drm/radeon/r100.c |6 ++--
drivers/gpu/drm/radeon/r300.c |6 ++--
drivers/gpu/drm/radeon/r420.c |4 +-
drivers/gpu/drm/radeon/r520.c |4 +-
drivers/gpu/drm/radeon/r600.c |2 +-
drivers/gpu/drm/radeon/radeon.h|8 +++---
drivers/gpu/drm/radeon/radeon_asic.h | 36
drivers/gpu/drm/radeon/radeon_device.c |2 +-
drivers/gpu/drm/radeon/radeon_fence.c | 23
drivers/gpu/drm/radeon/rs400.c |4 +-
drivers/gpu/drm/radeon/rs600.c |4 +-
drivers/gpu/drm/radeon/rs690.c |4 +-
drivers/gpu/drm/radeon/rv515.c |8 +++---
14 files changed, 59 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index 11688e2..748c58a 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -491,7 +491,7 @@ bool evergreen_gpu_is_lockup(struct radeon_device *rdev)
return false;
}
-int evergreen_gpu_reset(struct radeon_device *rdev)
+int evergreen_asic_reset(struct radeon_device *rdev)
{
/* FIXME: implement for evergreen */
return 0;
diff --git a/drivers/gpu/drm/radeon/r100.c b/drivers/gpu/drm/radeon/r100.c
index a77e754..029c55d 100644
--- a/drivers/gpu/drm/radeon/r100.c
+++ b/drivers/gpu/drm/radeon/r100.c
@@ -1864,7 +1864,7 @@ bool r100_gpu_is_lockup(struct radeon_device *rdev)
return r100_gpu_cp_is_lockup(rdev, rdev-config.r100.lockup,
rdev-cp);
}
-int r100_gpu_reset(struct radeon_device *rdev)
+int r100_asic_reset(struct radeon_device *rdev)
{
uint32_t status;
@@ -3503,7 +3503,7 @@ int r100_resume(struct radeon_device *rdev)
/* Resume clock before doing reset */
r100_clock_startup(rdev);
/* Reset gpu before posting otherwise ATOM will enter infinite loop */
- if (radeon_gpu_reset(rdev)) {
+ if (radeon_asic_reset(rdev)) {
dev_warn(rdev-dev, GPU reset failed ! (0xE40=0x%08X,
0x7C0=0x%08X)\n,
RREG32(R_000E40_RBBM_STATUS),
RREG32(R_0007C0_CP_STAT));
@@ -3571,7 +3571,7 @@ int r100_init(struct radeon_device *rdev)
return r;
}
/* Reset gpu before posting otherwise ATOM will enter infinite loop */
- if (radeon_gpu_reset(rdev)) {
+ if (radeon_asic_reset(rdev)) {
dev_warn(rdev-dev,
GPU reset failed ! (0xE40=0x%08X, 0x7C0=0x%08X)\n,
RREG32(R_000E40_RBBM_STATUS),
diff --git a/drivers/gpu/drm/radeon/r300.c b/drivers/gpu/drm/radeon/r300.c
index 2c5d272..f033562 100644
--- a/drivers/gpu/drm/radeon/r300.c
+++ b/drivers/gpu/drm/radeon/r300.c
@@ -446,7 +446,7 @@ bool r300_gpu_is_lockup(struct radeon_device *rdev)
return r100_gpu_cp_is_lockup(rdev, rdev-config.r300.lockup,
rdev-cp);
}
-int r300_gpu_reset(struct radeon_device *rdev)
+int r300_asic_reset(struct radeon_device *rdev)
{
uint32_t status;
@@ -1326,7 +1326,7 @@ int r300_resume(struct radeon_device *rdev)
/* Resume clock before doing reset */
r300_clock_startup(rdev);
/* Reset gpu before posting otherwise ATOM will enter infinite loop */
- if (radeon_gpu_reset(rdev)) {
+ if (radeon_asic_reset(rdev)) {
dev_warn(rdev-dev, GPU reset failed ! (0xE40=0x%08X,
0x7C0=0x%08X)\n,
RREG32(R_000E40_RBBM_STATUS),
RREG32(R_0007C0_CP_STAT));
@@ -1396,7 +1396,7 @@ int r300_init(struct radeon_device *rdev)
return r;
}
/* Reset gpu before posting otherwise ATOM will enter infinite loop */
- if (radeon_gpu_reset(rdev)) {
+ if (radeon_asic_reset(rdev)) {
dev_warn(rdev-dev,
GPU reset failed ! (0xE40=0x%08X, 0x7C0=0x%08X)\n,
RREG32(R_000E40_RBBM_STATUS),
diff --git a/drivers/gpu/drm/radeon/r420.c b/drivers/gpu/drm/radeon/r420.c
index e0eb9b6..8e6d852 100644
--- a/drivers/gpu/drm/radeon/r420.c
+++ b/drivers/gpu/drm/radeon/r420.c
@@ -233,7 +233,7 @@ int r420_resume(struct radeon_device *rdev)
/* Resume clock before doing reset */
r420_clock_resume(rdev);
/* Reset gpu before posting otherwise ATOM will enter infinite loop */
- if (radeon_gpu_reset(rdev)) {
+ if (radeon_asic_reset(rdev)) {
dev_warn(rdev-dev, GPU reset failed ! (0xE40=0x%08X,
0x7C0=0x%08X)\n,
[Bug 26334] Thinkpad T400: AMD Mobility Radeon HD 3470 + 2 monitors
http://bugs.freedesktop.org/show_bug.cgi?id=26334 --- Comment #10 from Kirill A. Shutemov kir...@shutemov.name 2010-02-26 14:58:59 PST --- I've gotten working VGA-0 when set default output device in BIOS to VGA-0. In this case, after KMS initialization I can see console on both VGA-0 and LVDS (console occupies only part of VGA-0 which is bigger than LVDS, rest of the screen is white). Unfortunately, this trick works only if I initially boot with connected VGA-0. BIOS fallbacks to boot with LVDS if it doesn't see VGA-0. Any ideas? -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26334] Thinkpad T400: AMD Mobility Radeon HD 3470 + 2 monitors
http://bugs.freedesktop.org/show_bug.cgi?id=26334 --- Comment #11 from Alex Deucher ag...@yahoo.com 2010-02-26 15:07:29 PST --- Does xf86-video-ati from git master (for UMS) or a newer drm (for KMS) help? You might try drm-radeon-testing. These patches might help for KMS: http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=ff4feeadf7581d27704dedcecf0209e65487 http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commitdiff;h=383be5d1789d9a7a2e77dca1cb0aca89507d069e -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26781] New: RV670 Oops with PM and xrandr.
http://bugs.freedesktop.org/show_bug.cgi?id=26781 Summary: RV670 Oops with PM and xrandr. Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/DRI/R600 AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: li...@andyfurniss.entadsl.com Running current drt + pm patch in http://bugs.freedesktop.org/show_bug.cgi?id=26631 While changing res with xrandr today I got a PM Oops, I can't reproduce so maybe it tried to switch power just as xrandr was changing res. There is an added complication that I was testing xrandr due to an issue I have with it - http://bugs.freedesktop.org/show_bug.cgi?id=24532 so it may have been in a non normal state at the time. While grepping my logs for the details, I noticed that it has happened before and this case is reproducible - If I modprobe radeon without first loading fbcon, startx, when I quit X I will get the Oops. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 26781] RV670 Oops with PM and xrandr.
http://bugs.freedesktop.org/show_bug.cgi?id=26781 --- Comment #1 from Andy Furniss li...@andyfurniss.entadsl.com 2010-02-26 15:13:16 PST --- Created an attachment (id=33599) -- (http://bugs.freedesktop.org/attachment.cgi?id=33599) pm oops -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH][RFC] time: add wait_interruptible_timeout macro to sleep (w. timeout) until wake_up
On Fri, 26 Feb 2010, Rafał Miłecki wrote: Following macro is soemthing that seems to work fine for us, but instead introducing this to radeon KMS only, I'd like to propose adding this to whole wait.h. Do you this it's something we should place there? Can someone take this patch for me? Or maybe you find this rather useless and we should keep this marco locally? This does not smell generic to me. In fact, it makes me personally think you're doing something wrong in the first place, but maybe it's ok. But in case it really is ok, I'd still not put it in a generic header file unless you can point to other cases where it really makes sense to do this. Linus -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 15293] Flash video laggy inside Firefox only with KMS
http://bugzilla.kernel.org/show_bug.cgi?id=15293 --- Comment #25 from Pauli suok...@gmail.com 2010-02-27 06:39:33 --- I vote for NOTOURBUG too. Maybe ddx could be a bit better optimized for XGetSubImage that flash is using but in end we can't get it perform well enough anyway without modifying the blob. So what exactly is happening to slow down here: -Flash is playing the video to vram. -Flash calls XGetSubImage multiple times per frame to read back the whole video. -XGetSubImage tries to copy data from VRAM to system memory but there seems to be huge latency for CPU to read the data that was just written by GPU. Hack patch: http://www.youtube.com/watch?v=JLkGGNbBJeI ;) -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
