[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout
https://bugs.freedesktop.org/show_bug.cgi?id=89685 Ivan Fomin changed: What|Removed |Added Version|10.5|git --- Comment #4 from Ivan Fomin --- I got same issue when using llvm-3.6.0. With llvm-3.5.0 works perfect. AMD R9 280X with linux 3.19.3 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150404/2a25bca2/attachment.html>
[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout
https://bugs.freedesktop.org/show_bug.cgi?id=89685 Ivan Fomin changed: What|Removed |Added CC||snowman.sp at gmail.com --- Comment #5 from Ivan Fomin --- Created attachment 114857 --> https://bugs.freedesktop.org/attachment.cgi?id=114857&action=edit Xorg.0.log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150404/151f6228/attachment.html>
[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout
https://bugs.freedesktop.org/show_bug.cgi?id=89685 --- Comment #6 from Ivan Fomin --- Created attachment 114858 --> https://bugs.freedesktop.org/attachment.cgi?id=114858&action=edit glxinfo -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150404/37bf44e0/attachment.html>
[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout
https://bugs.freedesktop.org/show_bug.cgi?id=89685 --- Comment #7 from Ivan Fomin --- Created attachment 114859 --> https://bugs.freedesktop.org/attachment.cgi?id=114859&action=edit kernel messages -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150404/ea9f957b/attachment-0001.html>
[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout
https://bugs.freedesktop.org/show_bug.cgi?id=89685 --- Comment #8 from Ivan Fomin --- my apitrace output https://drive.google.com/file/d/0B1OEKuwhkMlRajBUMGYtSXpSeHc/view?usp=sharing -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150404/3890a354/attachment.html>
[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout
https://bugs.freedesktop.org/show_bug.cgi?id=89685 Ivan Fomin changed: What|Removed |Added Version|git |10.5 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150404/fedfc495/attachment.html>
[Bug 94061] [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst
https://bugzilla.kernel.org/show_bug.cgi?id=94061 --- Comment #7 from Klaus Maier --- Tested your suggestion to activate the powergating by removing the comments you mentioned above w/ 3.19.3 and radeon.bapm=1. This even raised the power consumption about 5 W more as w/o it. This "feature" is completely broken. I recompiled the *complete* kernel to test your suggestion. This is a pain. Is there an external radeon module which can be compiled outside of the complete kernel and which can be used with more than one kernel version - like fglrx? It's much more easy to change the complete video stack with catalyst as with radeon. The radeon stack architecture is completely unusable because it is spread over the whole system and I even have to always change the complete kernel if there is a problem w/ the graphics driver. The kernel change most often results in other problems w/ other hardware which is broken on other versions because of missing QA. Another question: Why can't you see this while programming? Didn't you check your code w/ a ammeter? According to http://xorg.freedesktop.org/wiki/RadeonFeature/ DPM is done for Kaveri. This is obviously wrong and you know about it but you're nevertheless claiming the opposite. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 3/3] drm/msm: drop redundant output in debug message
wait_for_completion_timeout returns 0 in case of timeout so printing the
return value here will always yield 0 and is therefor redundant - dropped.
Signed-off-by: Nicholas Mc Guire
---
This was compile tested with qcom_defconfig +
CONFIG_DRM=m (implies CONFIG_DRM_MSM=m)
Patch is against 4.0-rc6 (localversion-next is -next-20150402)
drivers/gpu/drm/msm/edp/edp_aux.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/edp/edp_aux.c
b/drivers/gpu/drm/msm/edp/edp_aux.c
index d1b6833..645ea07 100644
--- a/drivers/gpu/drm/msm/edp/edp_aux.c
+++ b/drivers/gpu/drm/msm/edp/edp_aux.c
@@ -157,7 +157,7 @@ ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux, struct
drm_dp_aux_msg *msg)
*/
edp_write(aux->base + REG_EDP_AUX_TRANS_CTRL, 0);
msm_edp_aux_ctrl(aux, 1);
- pr_err("%s: aux timeout, %lu\n", __func__, time_left);
+ pr_err("%s: aux timeout,\n", __func__);
ret = -ETIMEDOUT;
goto unlock_exit;
}
--
1.7.10.4
[PATCH] drm/msm: fix build warning - missing prototype
fix build warning when building edp/edp_aux.o due to missing prototype for edp_aux_transfer. Signed-off-by: Nicholas Mc Guire --- building drivers/gpu/drm/msm/msm.ko gives the following warning: drivers/gpu/drm/msm/edp/edp_aux.c:118:9: warning: no previous prototype for 'edp_aux_transfer' [-Wmissing-prototypes] ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux, struct drm_dp_aux_msg *msg) ^ the fix is to simply add the missing prototype to drivers/gpu/drm/msm/edp/edp.h This was compile tested with qcom_defconfig + CONFIG_DRM=m (implies CONFIG_DRM_MSM=m) Patch is against 4.0-rc6 (localversion-next is -next-20150402) drivers/gpu/drm/msm/edp/edp.h |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/msm/edp/edp.h b/drivers/gpu/drm/msm/edp/edp.h index ba5bedd..93d819c 100644 --- a/drivers/gpu/drm/msm/edp/edp.h +++ b/drivers/gpu/drm/msm/edp/edp.h @@ -58,6 +58,8 @@ void *msm_edp_aux_init(struct device *dev, void __iomem *regbase, void msm_edp_aux_destroy(struct device *dev, struct edp_aux *aux); irqreturn_t msm_edp_aux_irq(struct edp_aux *aux, u32 isr); void msm_edp_aux_ctrl(struct edp_aux *aux, int enable); +ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux, +struct drm_dp_aux_msg *msg); /* Phy */ bool msm_edp_phy_ready(struct edp_phy *phy); -- 1.7.10.4
[PATCH 2/3] drm/msm: fix HZ dependency of timeout
The timeout is passed as a constant which makes it HZ dependent because
jiffies are expected so it should be converted to jiffies. The actual
value is not clear from the code - my best guess is that this should be
300 milliseconds given that other timeouts are in milliseconds based on
looking at other drm drivers (e.g. exynos_drm_dsi.c:356 300ms,
tegra/dpaux.c:188 250ms) - this needs to be confirmed by someone who
knows the details of the driver.
Signed-off-by: Nicholas Mc Guire
---
This was compile tested with qcom_defconfig +
CONFIG_DRM=m (implies CONFIG_DRM_MSM=m)
Patch is against 4.0-rc6 (localversion-next is -next-20150402)
drivers/gpu/drm/msm/edp/edp_aux.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/edp/edp_aux.c
b/drivers/gpu/drm/msm/edp/edp_aux.c
index 91a1a67..d1b6833 100644
--- a/drivers/gpu/drm/msm/edp/edp_aux.c
+++ b/drivers/gpu/drm/msm/edp/edp_aux.c
@@ -148,7 +148,8 @@ ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux, struct
drm_dp_aux_msg *msg)
goto unlock_exit;
DBG("wait_for_completion");
- time_left = wait_for_completion_timeout(&aux->msg_comp, 300);
+ time_left = wait_for_completion_timeout(&aux->msg_comp,
+ msecs_to_jiffies(300));
if (!time_left) {
/*
* Clear GO and reset AUX channel
--
1.7.10.4
[PATCH 1/3] drm/msm: fixup wait_for_completion_timeout handling
wait_for_completion_timeout return >= 0 but never negative so the check
logic looks inconsistent. Further the return value of
wait_for_completion_timeout was being passed up the call chain but the
x call sites as drm_dp_i2c_do_msg()/drm_dp_dpcd_access() check for < 0
thus timeout was being treated as success case.
drivers/gpu/drm/drm_dp_helper.c:drm_dp_i2c_do_msg()
mutex_lock(&aux->hw_mutex);
ret = aux->transfer(aux, msg);
mutex_unlock(&aux->hw_mutex);
if (ret < 0) {
logic in edp_aux_transfer() seems incorrect as it could return 0 (timeout)
but checks of <= 0 to indicate error so the return probably should be
-ETIMEDOUT in case wait_for_completion_timeout returns 0 (timeout
occurred).
Signed-off-by: Nicholas Mc Guire
---
This was compile tested with qcom_defconfig +
CONFIG_DRM=m (implies CONFIG_DRM_MSM=m)
Patch is against 4.0-rc6 (localversion-next is -next-20150402)
drivers/gpu/drm/msm/edp/edp_aux.c |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/edp/edp_aux.c
b/drivers/gpu/drm/msm/edp/edp_aux.c
index 5f5a84f..1d2ccdf 100644
--- a/drivers/gpu/drm/msm/edp/edp_aux.c
+++ b/drivers/gpu/drm/msm/edp/edp_aux.c
@@ -119,6 +119,7 @@ ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux, struct
drm_dp_aux_msg *msg)
{
struct edp_aux *aux = to_edp_aux(drm_aux);
ssize_t ret;
+ unsigned long time_left;
bool native = msg->request & (DP_AUX_NATIVE_WRITE & DP_AUX_NATIVE_READ);
bool read = msg->request & (DP_AUX_I2C_READ & DP_AUX_NATIVE_READ);
@@ -147,15 +148,16 @@ ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux,
struct drm_dp_aux_msg *msg)
goto unlock_exit;
DBG("wait_for_completion");
- ret = wait_for_completion_timeout(&aux->msg_comp, 300);
- if (ret <= 0) {
+ time_left = wait_for_completion_timeout(&aux->msg_comp, 300);
+ if (!time_left) {
/*
* Clear GO and reset AUX channel
* to cancel the current transaction.
*/
edp_write(aux->base + REG_EDP_AUX_TRANS_CTRL, 0);
msm_edp_aux_ctrl(aux, 1);
- pr_err("%s: aux timeout, %d\n", __func__, ret);
+ pr_err("%s: aux timeout, %lu\n", __func__, time_left);
+ ret = -ETIMEDOUT;
goto unlock_exit;
}
DBG("completion");
--
1.7.10.4
[PATCH] drm/msm: fix build warning - missing prototype
On Fri, Apr 3, 2015 at 10:39 PM, Nicholas Mc Guire wrote: > fix build warning when building edp/edp_aux.o due to missing > prototype for edp_aux_transfer. > > Signed-off-by: Nicholas Mc Guire > --- > building drivers/gpu/drm/msm/msm.ko gives the following warning: > drivers/gpu/drm/msm/edp/edp_aux.c:118:9: warning: no previous prototype for > 'edp_aux_transfer' [-Wmissing-prototypes] > ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux, struct drm_dp_aux_msg > *msg) > ^ > thx.. fwiw, looks like edp_aux_transfer is only used in that one file.. so probably it actually wants to be static instead.. BR, -R > the fix is to simply add the missing prototype to > drivers/gpu/drm/msm/edp/edp.h > > This was compile tested with qcom_defconfig + > CONFIG_DRM=m (implies CONFIG_DRM_MSM=m) > > Patch is against 4.0-rc6 (localversion-next is -next-20150402) > > drivers/gpu/drm/msm/edp/edp.h |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/msm/edp/edp.h b/drivers/gpu/drm/msm/edp/edp.h > index ba5bedd..93d819c 100644 > --- a/drivers/gpu/drm/msm/edp/edp.h > +++ b/drivers/gpu/drm/msm/edp/edp.h > @@ -58,6 +58,8 @@ void *msm_edp_aux_init(struct device *dev, void __iomem > *regbase, > void msm_edp_aux_destroy(struct device *dev, struct edp_aux *aux); > irqreturn_t msm_edp_aux_irq(struct edp_aux *aux, u32 isr); > void msm_edp_aux_ctrl(struct edp_aux *aux, int enable); > +ssize_t edp_aux_transfer(struct drm_dp_aux *drm_aux, > +struct drm_dp_aux_msg *msg); > > /* Phy */ > bool msm_edp_phy_ready(struct edp_phy *phy); > -- > 1.7.10.4 >
[Bug 94061] [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst
https://bugzilla.kernel.org/show_bug.cgi?id=94061 John Bridgman changed: What|Removed |Added CC||john.bridgman at amd.com --- Comment #8 from John Bridgman --- >>Is there an external radeon module which can be compiled outside of the >>complete kernel and which can be used with more than one kernel version - >>like fglrx? Upstream kernel drivers are coded for the kernel version that they live in, ie kernel core and kernel drivers evolve together. Not sure if code to support other kernel versions is absolutely forbidden or just very strongly discouraged but I don't think any upstream driver includes support for other kernel versions today. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 89906] Account request for DRM
https://bugs.freedesktop.org/show_bug.cgi?id=89906 Bug ID: 89906 Summary: Account request for DRM Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/other Assignee: dri-devel at lists.freedesktop.org Reporter: lukas at wunner.de Created attachment 114866 --> https://bugs.freedesktop.org/attachment.cgi?id=114866&action=edit pgp public key I've started working on vga_switcheroo and the DRM kernel code and would like to publish the results so others can review and pull them. Lukas Wunner Preferred account name "lukas" -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150404/4d1f03ae/attachment.html>
[Bug 89906] Account request for DRM
https://bugs.freedesktop.org/show_bug.cgi?id=89906 --- Comment #1 from lukas at wunner.de --- Created attachment 114867 --> https://bugs.freedesktop.org/attachment.cgi?id=114867&action=edit ssh public key -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150404/a8b19812/attachment.html>
[Bug 66963] Rv6xx dpm problems
https://bugs.freedesktop.org/show_bug.cgi?id=66963 --- Comment #256 from Guram Savinov --- What is the progress of this issue? I have this bug for a long time since I set DPM on for my HD3650(RV635 chip). My current kernel is 3.13.0-48-generic from Ubuntu. Few days ago I set this two kernel parameters: radeon.hard_reset=1 radeon.lockup_timeout=2, but I'm not sure that it helps. I think that workoround with setting high performance level is not a solution, because it same as turning off DPM at all. People say that this workaround doesn't make GPU too hotter, but I think it's not true for every graphic card. HD3650 with performance profile (before DPM was developed I used profiles) make it very hot, cooler buzz loudly trying to decrease GPU temperature. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150404/24ecf6e0/attachment.html>
[Bug 94061] [radeon - Kaveri] dpm works badly - much to high power consumption compared to catalyst
https://bugzilla.kernel.org/show_bug.cgi?id=94061 --- Comment #9 from Klaus Maier --- (In reply to John Bridgman from comment #8) > Upstream kernel drivers are coded for the kernel version that they live in. That exactly is the problem - the missing downward compatibility. But there are a lot of drivers which can be used w/ older kernels: https://www.kernel.org/pub/linux/kernel/projects/backports/stable/ This makes it possible to run the old working kernel w/o having the need to run a bleeding edge kernel which most of the time breaks some other devices (as w/ 3.19., which breaks USB on boot up here). And it makes it possible to compile just the module which is needed - de facto the same handling as it is provided by Catalyst. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout
https://bugs.freedesktop.org/show_bug.cgi?id=89685 --- Comment #9 from Kevin --- (In reply to Tom Stellard from comment #3) > Can you run the game with R600_DEBUG=ps,vs,gs and post the output? OK, sorry, I just saw this. So I know some of what I'm doing by not a lot. I do `export R600_DEBUG=ps,vs,gs` and then run the game? Where and how do I get output? dmesg? jounralctl? Something else? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150404/b1efa86d/attachment.html>
[Bug 89746] Mesa and LLVM 3.6+ break opengl for genymotion
https://bugs.freedesktop.org/show_bug.cgi?id=89746 --- Comment #18 from Kevin --- I think this goes along with my issue in this bug report https://bugs.freedesktop.org/show_bug.cgi?id=89685 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150404/5628aa32/attachment.html>
[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout
https://bugs.freedesktop.org/show_bug.cgi?id=89685 --- Comment #10 from Kevin --- I think this may be the problem and solution. I see there is a patch but I'm not sure how to test it. Is this patch currently part of mesa git? Will this patch be coming to mesa 10.5.3? https://bugs.freedesktop.org/show_bug.cgi?id=89746 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150404/8a1d24ce/attachment.html>
[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout
https://bugs.freedesktop.org/show_bug.cgi?id=89685 --- Comment #11 from Kevin --- (In reply to Kevin from comment #9) > (In reply to Tom Stellard from comment #3) > > Can you run the game with R600_DEBUG=ps,vs,gs and post the output? > > OK, sorry, I just saw this. So I know some of what I'm doing by not a lot. I > do `export R600_DEBUG=ps,vs,gs` and then run the game? Where and how do I > get output? dmesg? jounralctl? Something else? I'm not sure if this is what you are looking for, but I am attaching new journalctl and dmesg outputs after enabling R600_DEBUG=ps,vs,gs -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150404/f6becf81/attachment.html>
[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout
https://bugs.freedesktop.org/show_bug.cgi?id=89685 Kevin changed: What|Removed |Added Attachment #114625|0 |1 is obsolete|| --- Comment #12 from Kevin --- Created attachment 114868 --> https://bugs.freedesktop.org/attachment.cgi?id=114868&action=edit dmesg output with R600_DEBUG -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150404/0f70cc60/attachment.html>
[Bug 89685] Cripling Dota 2 freeze with Morphling at hero selection or loadout
https://bugs.freedesktop.org/show_bug.cgi?id=89685 Kevin changed: What|Removed |Added Attachment #114624|0 |1 is obsolete|| --- Comment #13 from Kevin --- Created attachment 114869 --> https://bugs.freedesktop.org/attachment.cgi?id=114869&action=edit journalctl output with R600_DEBUG -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20150404/53980d20/attachment-0001.html>
