[PULL] drm-amdkfd-next
Hi Dave, A few amdkfd patches for 4.8. One patch replaces deprecated kernel api call (create_workqueue) and the other patch properly cleans up resources in case of failing to create a process object. Thanks, Oded The following changes since commit dac2c48ca5ac9bb2d6339aaa733c60d5b801ee86: Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu into drm-next (2016-07-02 16:21:35 +1000) are available in the git repository at: git://people.freedesktop.org/~gabbayo/linux tags/drm-amdkfd-next-2016-07-03 for you to fetch changes up to 7fd5e03ca6b41a591bd9fda083362b8a07cfb5f7: drm/amdkfd: destroy mutex if process creation fails (2016-07-03 08:05:45 +0300) Bhaktipriya Shridhar (1): drm/amdkfd: Remove create_workqueue() Oded Gabbay (1): drm/amdkfd: destroy mutex if process creation fails drivers/gpu/drm/amd/amdkfd/kfd_process.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
[Bug 96790] frame stuttering in ut2004
https://bugs.freedesktop.org/show_bug.cgi?id=96790 Bug ID: 96790 Summary: frame stuttering in ut2004 Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: network723 at rkmail.ru QA Contact: dri-devel at lists.freedesktop.org My hardware: HD7950 & Phenom II x6 1090 The problem: intensive frame stuttering and frame rate drops below 30 fps while playing UT2004. Drops usually happen when there is intensive shooting, but it may also happen on maps with complex geometry. Also, in-game fps counter shows 'avg fps' about 90-200, with rare jumps to 300-400 fps, even with vblank_mode=0 set. 64 bit version of the game on Windows shows stable 300+ fps with OpenGL renderer. I wonder if this may be related to AMD CPU, since various test results on Phoronix show much greater performance (up to 5 times) with Intel CPU and same GPU. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160703/d20a26ee/attachment.html>
[Bug 89534] radeonsi GPU lockup / crash with wine
https://bugs.freedesktop.org/show_bug.cgi?id=89534 --- Comment #29 from hedlx --- (In reply to PsychoDariusz from comment #27) > it happens to me to in wine with rocket league, orion prelude and hard > reset, after a few minutes the game stalls and if go for a terminal output > what i get is [this](http://imgur.com/a/PYyR0). > > it happens both with the r7 250 i had before and my new r7 260x on ubuntu > 15.10 with [padoka > ppa](https://launchpad.net/~paulo-miguel-dias/+archive/ubuntu/mesa). > > any suggestions how to post better debug info? Same here, GPU lockup after 10-15 minutes in Rocket League, 4.7-rc3 kernel & latest for current date mesa+llvm from padoka-ppa (12.1), wine version is 1.9.13 Always lockup with "radeon failed to deallocate virtual address for buffer" error, even in wine without gallium nine patches. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160703/e4e97041/attachment.html>
[Bug 80419] XCOM: Enemy Unknown Causes lockup
https://bugs.freedesktop.org/show_bug.cgi?id=80419 --- Comment #136 from Daniel Exner --- I tried with: * Kernel 4.7.0-rc5-00309-gdbdc3bb * LLVM: 274446 * Mesa: 01ccb0d This time I could play for a solid hour without crash. Will try again later to confirm. @Devs: any idea if there is something that might have fixed this? Or just luck? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160703/90217f85/attachment.html>
[Bug 96794] VM_CONTEXT1_PROTECTION_FAULT_ADDR
https://bugs.freedesktop.org/show_bug.cgi?id=96794 Bug ID: 96794 Summary: VM_CONTEXT1_PROTECTION_FAULT_ADDR Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel at lists.freedesktop.org Reporter: t.hirsch at web.de My OpenGL game freezes and I see the following errors in dmesg as soon as the video sequences have finished and the game should start: [Jul 3 23:16] amdgpu :01:00.0: GPU fault detected: 147 0x4402 [ +0,05] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ +0,02] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0C044002 [ +0,02] VM fault (0x02, vmid 6) at page 0, read from 'TC5' (0x54433500) (68) [ +0,06] amdgpu :01:00.0: GPU fault detected: 147 0x4402 [ +0,02] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x [ +0,02] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0C044002 [ +0,02] VM fault (0x02, vmid 6) at page 0, read from 'TC5' (0x54433500) (68) [ +11,325151] amdgpu :01:00.0: GPU fault detected: 147 0x07588801 [ +0,04] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x041200EB [ +0,02] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0C088001 [ +0,02] VM fault (0x01, vmid 6) at page 68288747, read from 'TC6' (0x54433600) (136) [ +0,05] amdgpu :01:00.0: GPU fault detected: 147 0x05788401 [ +0,01] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x001235E8 [ +0,02] amdgpu :01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0C00802C [ +0,02] VM fault (0x2c, vmid 6) at page 1193448, read from 'TC0' (0x54433000) (8) The game is Alien Isolation (steam version). GPU: AMD Radeon RX 480 OS: ArchLinux Kernel: 4.7.0-rc2-g0812a94 (polaris-test branch of linux-git repo from freedesktop.org with latest firmware) mesa/libdrm/llvm/xf86-video-amdgpu are all built from git -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160703/d6d5f005/attachment.html>
[PATCH] drm/mediatek: fix error handling
This is likely that checking 'phy_provider' instead of 'phy' is
expected here.
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
index cf8f38d..1c366f8 100644
--- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
+++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
@@ -431,7 +431,7 @@ static int mtk_mipi_tx_probe(struct platform_device *pdev)
phy_set_drvdata(phy, mipi_tx);
phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
- if (IS_ERR(phy)) {
+ if (IS_ERR(phy_provider)) {
ret = PTR_ERR(phy_provider);
return ret;
}
--
2.7.4
[PATCH] drm/mediatek: fix error handling
On 07/03/2016 07:37 AM, Christophe JAILLET wrote:
> This is likely that checking 'phy_provider' instead of 'phy' is
> expected here.
>
> Signed-off-by: Christophe JAILLET
> ---
> drivers/gpu/drm/mediatek/mtk_mipi_tx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> index cf8f38d..1c366f8 100644
> --- a/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> +++ b/drivers/gpu/drm/mediatek/mtk_mipi_tx.c
> @@ -431,7 +431,7 @@ static int mtk_mipi_tx_probe(struct platform_device *pdev)
> phy_set_drvdata(phy, mipi_tx);
>
> phy_provider = devm_of_phy_provider_register(dev, of_phy_simple_xlate);
> - if (IS_ERR(phy)) {
> + if (IS_ERR(phy_provider)) {
Dan already send a patch for that:
http://www.spinics.net/lists/dri-devel/msg112031.html
Regards,
Matthias
> ret = PTR_ERR(phy_provider);
> return ret;
> }
>
[PATCH] drm/tegra: fix error handling
This is likely that checking 'gr3d->clk_secondary' instead of 'gr3d->clk'
is expected here.
Signed-off-by: Christophe JAILLET
---
drivers/gpu/drm/tegra/gr3d.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tegra/gr3d.c b/drivers/gpu/drm/tegra/gr3d.c
index 0b3f2b9..13f0d1b 100644
--- a/drivers/gpu/drm/tegra/gr3d.c
+++ b/drivers/gpu/drm/tegra/gr3d.c
@@ -268,9 +268,9 @@ static int gr3d_probe(struct platform_device *pdev)
if (of_device_is_compatible(np, "nvidia,tegra30-gr3d")) {
gr3d->clk_secondary = devm_clk_get(&pdev->dev, "3d2");
- if (IS_ERR(gr3d->clk)) {
+ if (IS_ERR(gr3d->clk_secondary)) {
dev_err(&pdev->dev, "cannot get secondary clock\n");
- return PTR_ERR(gr3d->clk);
+ return PTR_ERR(gr3d->clk_secondary);
}
gr3d->rst_secondary = devm_reset_control_get(&pdev->dev,
--
2.7.4
[Bug 96672] [radeonsi][LLVM 3.9] ARK: Survival Evolved, Missing text glyphs
https://bugs.freedesktop.org/show_bug.cgi?id=96672 --- Comment #3 from Shawn Starr --- http://reviews.llvm.org/D21961 Fixes this bug -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160703/58d34f11/attachment-0001.html>
[GIT PULL] drm/mediatek: MT8173 gamma & dither support
Hi Bibby, On 27 June 2016 at 12:29, Bibby Hsieh wrote: > On Mon, 2016-06-27 at 12:20 +0200, Matthias Brugger wrote: >> >> On 06/24/2016 09:27 AM, Bibby Hsieh wrote: >> > Hi Dave, >> > >> > Please consider merging this tag, which contains the v2 MT8173 gamma & >> > dither function patches I sent on 2016-06-17, rebased onto v4.7-rc1. There >> > have been no further comments. >> > >> > Thanks >> > Bibby >> > >> > The following changes since commit >> > 1a695a905c18548062509178b98bc91e67510864: >> > >> > Linux 4.7-rc1 (2016-05-29 16:29:24 GMT) >> > >> > are available in the git repository at: >> > >> > git at github.com:BibbyHsieh/linux4.7-rc1.git >> > >> > for you to fetch changes up to dd0eb773bc125f5e6bca735d19c08500dc3730f9: >> > >> > drm/mediatek: Add gamma correction >> > >> > - >> >> As far as I can see, your branch has 3 patches on top from Eddie. It >> seems to me as if you didn't send your patches to the mailinglist before? >> Anyway this branch does not fulfill the rules to get merged into the >> linux kernel. >> >> Why do you send a pull request? The normal process is to send the >> patches via email and if the maintainer wants you can send a pull >> request once the patches are ready to be merged. >> >> Regards, >> Matthias >> > > I sent v1 and v2 on 2016-06-14 and 06-17 respectively [0-8]. > After I made some modifications according to Daniel Vetter's comments, > there had been no further comments and I sent the pull request as the > other sub-sys. > > I'm sorry for my mistake, I will re-arrange the tree for upstream. > Next time, I will check with maintainer by email first, and sent the > pull request. > It might be a bit hard to find out who's the maintainer considering MAINTAINERS has no entry for this driver. Looking at how things are going Philipp Zabel will be the more likely person for the task, yet I would be nice if someone from the Mediatek squad is helping him out - CK Hu perhaps ? Regards, Emil
[PATCH v7 2/2] drm/panel: Add JDI LT070ME05000 WUXGA DSI Panel
On 28 June 2016 at 16:59, Vinay Simha wrote: > hi, > > Any further comments or reviews? > You still haven't covered my earlier suggestions, as such I cannot give you a r-b :-( They are not blockers by any means, but it'll be up-to the maintainer to ack/pick this up. Thierry ? Regards, Emil
