dri-devel January 2016

dri-devel@lists.freedesktop.org

194 participants
1200 discussions

[PATCH] drm: panel: simple-panel: set appropriate mode type
by Boris Brezillon 18 Apr '16

18 Apr '16

All modes exposed by simple panels should be tagged as driver defined modes. Moreover, if a panel supports only one mode, this mode is obviously the preferred one. Doing this also fix a problem occurring when a 'video=' parameter is passed on the kernel cmdline. In some cases the user provided mode is preferred over the simple panel ones, which might result in unpredictable behavior. Signed-off-by: Boris Brezillon <boris.brezillon(a)free-electrons.com> --- drivers/gpu/drm/panel/panel-simple.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c index d14b904..95ae390 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -111,6 +111,10 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel) continue; } + mode->type |= DRM_MODE_TYPE_DRIVER; + if (panel->desc->num_modes == 1) + mode->type |= DRM_MODE_TYPE_PREFERRED; + drm_display_mode_from_videomode(&vm, mode); drm_mode_probed_add(connector, mode); @@ -127,6 +131,10 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel) continue; } + mode->type |= DRM_MODE_TYPE_DRIVER; + if (panel->desc->num_modes == 1) + mode->type |= DRM_MODE_TYPE_PREFERRED; + drm_mode_set_name(mode); drm_mode_probed_add(connector, mode); -- 1.9.1

3 5

[Bug 103271] New: AMD R9 270X Flickering with DPM Enabled on Linux 4.1 with RadeonSI
by bugzilla-daemon＠bugzilla.kernel.org 15 Apr '16

15 Apr '16

https://bugzilla.kernel.org/show_bug.cgi?id=103271 Bug ID: 103271 Summary: AMD R9 270X Flickering with DPM Enabled on Linux 4.1 with RadeonSI Product: Drivers Version: 2.5 Kernel Version: 4.1.6 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: wittyman37(a)yahoo.com Regression: No I upgraded my system today from the 4.0 kernel to 4.1. After rebooting, I am getting crazy flickering that makes my system unusable. I rebooted and disabled dynamic power management with radeon.dpm=0 as a kernel parameter. The flickering is now gone. I have an R9270X running with the open source drivers. I did a quick search and could not find a similar issue anywhere. Does anyone have any suggestions? UPDATE: I built the kernel using the linux-git package in AUR and have the same issue with DPM. linux-git 4.2rc7 -- You are receiving this mail because: You are watching the assignee of the bug.

1 24

[Bug 93460] [amdgpu] Ooops during shutdown - amdgpu_vm_grab_id
by bugzilla-daemon＠freedesktop.org 15 Apr '16

15 Apr '16

https://bugs.freedesktop.org/show_bug.cgi?id=93460 Bug ID: 93460 Summary: [amdgpu] Ooops during shutdown - amdgpu_vm_grab_id Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: mike(a)fireburn.co.uk This doesn't happen on the powerplay branch but it does happen on Linus's tree 4.4-rc5 As this appears related to the scheduler I can go back to kernel 4.3 and test that and if it doesn't happen try and bisect if you think it's worthwhile -- You are receiving this mail because: You are the assignee for the bug.

1 9

[Bug 89661] New: Kernel panic when trying use amdkfd driver on Kaveri
by bugzilla-daemon＠bugzilla.kernel.org 13 Apr '16

13 Apr '16

https://bugzilla.kernel.org/show_bug.cgi?id=89661 Bug ID: 89661 Summary: Kernel panic when trying use amdkfd driver on Kaveri Product: Drivers Version: 2.5 Kernel Version: 3.18.0 + drm-next branch Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-dri(a)kernel-bugs.osdl.org Reporter: linux(a)bernd-steinhauser.de Regression: No The kernel I tried to use was 3.18.0 and I merged the drm-next branch from git://people.freedesktop.org/~airlied/linux which includes the HSA driver amdkfd. CONFIG_HSA_AMD=y is set. When trying to boot the kernel, I get a kernel panic, as shown in the uploaded picture. CPU is a A10-7800 Kaveri, Motherboard is ASRock FM2A88X Extreme6+. -- You are receiving this mail because: You are watching the assignee of the bug.

1 18

[Bug 80673] New: XCOM: Enemy Unknown - Wrong read access when starting the game
by bugzilla-daemon＠freedesktop.org 12 Apr '16

12 Apr '16

https://bugs.freedesktop.org/show_bug.cgi?id=80673 Priority: medium Bug ID: 80673 Assignee: dri-devel(a)lists.freedesktop.org Summary: XCOM: Enemy Unknown - Wrong read access when starting the game Severity: normal Classification: Unclassified OS: Linux (All) Reporter: freedesktop(a)psydk.org Hardware: x86-64 (AMD64) Status: NEW Version: 10.1 Component: Drivers/Gallium/r600 Product: Mesa Created attachment 101971 --> https://bugs.freedesktop.org/attachment.cgi?id=101971&action=edit callstack of the wrong read access Some background: I am trying to understand why "XCOM: Enemy Uknown" (a game that was released for Linux x64 last week on Steam), leads to crashes when running with the open source Radeon driver. The people who did the port do not officialy support the open source driver but seems to be open to the idea of making it run on it. My system: Ubuntu 14.04 x64 Readon HD 4870 Mesa 10.1.3 Unfortunately that Radeon model is not supported by AMD's closed source driver. However, the game runs very well with the open source driver, with the exception of several random crashes. This bug report is one of the problem I have found and for which I have some information. The main crash I was experimenting was corrupting the heap, so I used a tool to detect illegal read and write accesses. The first problem it found is an illegal read access at the start of the game, after the different logos, when the main menu is about to appear. What is happening is that a memcpy with a size of 1360 bytes is made with a source buffer of only 1280 bytes in u_upload_data(). I will attach the callstack to this ticket. In that context, the entry point in the driver is: vbo_exec_DrawRangeElementsBaseVertex(GLenum mode, GLuint start, GLuint end, GLsizei count, GLenum type, const GLvoid *indices, GLint basevertex) Here are the values of the parameters: --------------------------------------------------------------- mode: 4 (GL_TRIANGLES) start: 0 end: 16 count: 24 type: 5123 (GL_UNSIGNED_SHORT) indices: 72 bytes: 00 00 02 00 03 00 00 00 01 00 02 00 04 00 06 00 07 00 04 00 05 00 06 00 08 00 0a 00 0b 00 08 00 09 00 0a 00 0c 00 0e 00 0f 00 0c 00 0d 00 0e 00 00 00 04 00 06 00 00 00 06 00 02 00 01 00 03 00 07 00 01 00 07 00 05 00 reordered as 36 u16: 0000 0002 0003 0000 0001 0002 0004 0006 0007 0004 0005 0006 0008 000a 000b 0008 0009 000a 000c 000e 000f 000c 000d 000e 0000 0004 0006 0000 0006 0002 0001 0003 0007 0001 0007 0005 basevertex: 0 --------------------------------------------------------------- Now I'm no expert in OpenGL and it is the first time I look at Mesa code, so I can't identify the main reason for the error. Hopefully you will have a clue. A tip to debug the game: if you have Steam and the game, I renamed the main exectuable in ".../Steam/SteamApps/common/XCom-Enemy-Unknown/binaries/linux/" named "game.x86_64" as "game.x86_64_real" and created a shell script named "game.x86_64" that performs necessary settings for debugging and then launch "game.x86_64_real". In my case I am setting LD_PRELOAD with a library that catches malloc() calls and fences the buffer before returning it. -- You are receiving this mail because: You are the assignee for the bug.

1 12

[PATCH v3 0/5] i.MX5/6 mem2mem scaler
by Philipp Zabel 11 Apr '16

11 Apr '16

Hi, this series uses the IPU IC post-processing task to implement a mem2mem device for scaling and colorspace conversion. This version addresses a few review commends, and includes some further cleanup. Changes since v2: - Limit downscaling to 4:1 - Disabled USERPTR memory - Set icc pointer to NULL on error - Dropped currently unused IDMAC channels - Fixed scaler module description - Embedded struct video_device If it is acceptable, I'd like to merge this through drm-next via imx-drm. Mauro reportedly would be ok with that, and currently the potential for conflicts is limited to drivers/media/{Kconfig,Makefile}. If not, I'll postpone the two [media] patches for a release. regards Philipp Philipp Zabel (3): gpu: ipu-v3: Add missing IDMAC channel names gpu: ipu-v3: Add mem2mem image conversion support to IC gpu: ipu-v3: Register scaler platform device Sascha Hauer (2): [media] imx-ipu: Add ipu media common code [media] imx-ipu: Add i.MX IPUv3 scaler driver drivers/gpu/ipu-v3/ipu-common.c | 2 + drivers/gpu/ipu-v3/ipu-ic.c | 754 +++++++++++++++++++++++- drivers/media/platform/Kconfig | 2 + drivers/media/platform/Makefile | 1 + drivers/media/platform/imx/Kconfig | 11 + drivers/media/platform/imx/Makefile | 2 + drivers/media/platform/imx/imx-ipu-scaler.c | 859 ++++++++++++++++++++++++++++ drivers/media/platform/imx/imx-ipu.c | 313 ++++++++++ drivers/media/platform/imx/imx-ipu.h | 36 ++ include/video/imx-ipu-v3.h | 49 +- 10 files changed, 2012 insertions(+), 17 deletions(-) create mode 100644 drivers/media/platform/imx/Kconfig create mode 100644 drivers/media/platform/imx/Makefile create mode 100644 drivers/media/platform/imx/imx-ipu-scaler.c create mode 100644 drivers/media/platform/imx/imx-ipu.c create mode 100644 drivers/media/platform/imx/imx-ipu.h -- 2.1.4

3 12

[Bug 93424] [amdgpu] [powerplay] [runpm] Card doesn't re-init when using powerplay and runpm
by bugzilla-daemon＠freedesktop.org 10 Apr '16

10 Apr '16

https://bugs.freedesktop.org/show_bug.cgi?id=93424 Bug ID: 93424 Summary: [amdgpu] [powerplay] [runpm] Card doesn't re-init when using powerplay and runpm Product: DRI Version: DRI git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel(a)lists.freedesktop.org Reporter: mike(a)fireburn.co.uk Created attachment 120567 --> https://bugs.freedesktop.org/attachment.cgi?id=120567&action=edit Dmesg with reinit problems I think the key messages are: [ 61.153149] SMC address is beyond the SMC RAM area. [ 61.153161] SMC address is beyond the SMC RAM area. [ 61.153511] SMC address is beyond the SMC RAM area. [ 61.153523] SMC address is beyond the SMC RAM area. [ 61.153524] SMC address is beyond the SMC RAM area. [ 61.153524] Failed to initialize ARB table index! [ 61.153526] SMC address is beyond the SMC RAM area. [ 61.153528] Failed to notify no display! [ 61.153536] Failed to enable voltage DPM during DPM Start Function! [ 61.153537] Failed to start DPM! [ 61.313104] [drm:gfx_v8_0_ring_test_ring [amdgpu]] *ERROR* amdgpu: ring 0 test failed (scratch(0xC040)=0xCAFEDEAD) [ 61.313108] [drm:amdgpu_resume [amdgpu]] *ERROR* resume 5 failed -22 -- You are receiving this mail because: You are the assignee for the bug.

1 4

[PATCH v2] drm/gma500: fix double freeing
by Sudip Mukherjee 07 Apr '16

07 Apr '16

We are allocating backing using psbfb_alloc() and so backing->stolen is always true. So we were freeing backing two times. Moreover if we follow the execution path then we should be freeing backing after we have released the helper. So remove the one which frees backing before the helper is released. While at it the error labels are also renamed to give a meaningful name. Cc: Patrik Jakobsson <patrik.r.jakobsson(a)gmail.com> Signed-off-by: Sudip Mukherjee <sudip(a)vectorindia.org> --- Hi Patrik, If you donot like the labels I will change them according to what you have suggested. drivers/gpu/drm/gma500/framebuffer.c | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/gma500/framebuffer.c b/drivers/gpu/drm/gma500/framebuffer.c index 2eaf1b3..52e2bf3 100644 --- a/drivers/gpu/drm/gma500/framebuffer.c +++ b/drivers/gpu/drm/gma500/framebuffer.c @@ -411,7 +411,7 @@ static int psbfb_create(struct psb_fbdev *fbdev, info = drm_fb_helper_alloc_fbi(&fbdev->psb_fb_helper); if (IS_ERR(info)) { ret = PTR_ERR(info); - goto out_err1; + goto err_alloc_fbi; } info->par = fbdev; @@ -419,7 +419,7 @@ static int psbfb_create(struct psb_fbdev *fbdev, ret = psb_framebuffer_init(dev, psbfb, &mode_cmd, backing); if (ret) - goto out_unref; + goto err_framebuffer_init; fb = &psbfb->base; psbfb->fbdev = info; @@ -465,14 +465,9 @@ static int psbfb_create(struct psb_fbdev *fbdev, mutex_unlock(&dev->struct_mutex); return 0; -out_unref: - if (backing->stolen) - psb_gtt_free_range(dev, backing); - else - drm_gem_object_unreference(&backing->gem); - +err_framebuffer_init: drm_fb_helper_release_fbi(&fbdev->psb_fb_helper); -out_err1: +err_alloc_fbi: mutex_unlock(&dev->struct_mutex); psb_gtt_free_range(dev, backing); return ret; -- 1.9.1

2 6

[Bug 92079] Crash during load on wine d3dadapter during Heroes of the Storm loading
by bugzilla-daemon＠freedesktop.org 05 Apr '16

05 Apr '16

https://bugs.freedesktop.org/show_bug.cgi?id=92079 Bug ID: 92079 Summary: Crash during load on wine d3dadapter during Heroes of the Storm loading Product: Mesa Version: 11.0 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: patricknicolas(a)laposte.net QA Contact: dri-devel(a)lists.freedesktop.org Since mesa 11, most of the times game loading crashes, either with a freeze or a blizzard error window. I use a Sandy Bridge IGP and a Radeon HD 7970 with DRI_PRIME, using dri3 and wine with d3dadapter (so it uses mesa d3d state tracker). Sometimes, an error is printed in kernel messages: [ 7481.648047] radeon 0000:01:00.0: GPU fault detected: 146 0x0feb6014 [ 7481.648051] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_ADDR 0x0000EEFF [ 7481.648052] radeon 0000:01:00.0: VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0B060014 I have bisected and the issue seems to come from commit 719f124620d3c9b4d6ce14db3dbfc7af05626e5b Author: Axel Davy <axel.davy(a)ens.fr> Date: Sun Aug 9 19:06:01 2015 +0200 st/nine: Catch setting the same shader This is quite rare that an app does set again the same shaders, but it isn't an expensive check either. Signed-off-by: Axel Davy <axel.davy(a)ens.fr> How can I provide more debugging info so we can find the specific issue in the commit ? -- You are receiving this mail because: You are the assignee for the bug.

1 3

[Bug 78717] New: radeon: Failed to allocate a buffer
by bugzilla-daemon＠freedesktop.org 05 Apr '16

05 Apr '16

https://bugs.freedesktop.org/show_bug.cgi?id=78717 Priority: medium Bug ID: 78717 Assignee: dri-devel(a)lists.freedesktop.org Summary: radeon: Failed to allocate a buffer Severity: normal Classification: Unclassified OS: Linux (All) Reporter: mmstickman(a)gmail.com Hardware: x86-64 (AMD64) Status: NEW Version: 10.1 Component: Drivers/Gallium/radeonsi Product: Mesa When you set shadows to Ultra in the recently released open source game, Tesseract, the game will segfault with the following: radeon: Failed to allocate a buffer: radeon: size : 536870912 bytes radeon: alignment : 32768 bytes radeon: domains : 4 radeon: Failed to allocate a buffer: radeon: size : 536870912 bytes radeon: alignment : 32768 bytes radeon: domains : 4 radeon: Failed to allocate a buffer: radeon: size : 536870912 bytes radeon: alignment : 32768 bytes radeon: domains : 4 radeon: Failed to allocate a buffer: radeon: size : 536870912 bytes radeon: alignment : 32768 bytes radeon: domains : 4 radeon: Failed to allocate a buffer: radeon: size : 536870912 bytes radeon: alignment : 32768 bytes radeon: domains : 4 radeon: Failed to allocate a buffer: radeon: size : 536870912 bytes radeon: alignment : 32768 bytes radeon: domains : 4 failed allocating shadow atlas! MSAA also seems to hang the entire machine -- You are receiving this mail because: You are the assignee for the bug.

1 9

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2016