dri-devel January 2014

dri-devel@lists.freedesktop.org

145 participants
957 discussions

[Bug 73297] Xorg crashes with kernel 3.13-rc7
by bugzilla-daemon＠freedesktop.org 07 Jan '14

07 Jan '14

https://bugs.freedesktop.org/show_bug.cgi?id=73297 Anton Sudak <anton.sudak(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Anton Sudak <anton.sudak(a)gmail.com> --- (In reply to comment #2) > Probably a duplicate of bug 70687. Looks like my issue is really duplicate. Logs are similar and workaround from comment #13 worked for me. *** This bug has been marked as a duplicate of bug 70687 *** -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH] drm/nouveau/bios: fix offset calculation for BMPv1 bioses
by Ilia Mirkin 07 Jan '14

07 Jan '14

The only BIOS on record that needs the 14 offset has a bios major version 2 but BMP version 1.01. Another bunch of BIOSes that need the 18 offset have BMP version 2.01 or 5.01 or higher. So instead of looking at the bios major version, look at the BMP version. BIOSes with BMP version 0 do not contain a detectable script, so always return 0 for them. See https://bugs.freedesktop.org/show_bug.cgi?id=68835 Reported-by: Mauro Molinari <mauromol(a)tiscali.it> Signed-off-by: Ilia Mirkin <imirkin(a)alum.mit.edu> --- Unfortunately the bug reporter doesn't really know how to compile kernels and my bet is that the system his NV04 is in isn't exactly top-of-the-line, so a kernel compile would take forever. I've made similar changes in nvbios, and it seems to now handle every nv04/nv05 bios in our repo, in addition to Mauro's, so I think these changes should be safe-ish. However I'm not tagging for stable yet, in case things don't pan out the way I expected. If Mauro tests a kernel with this and all's well, then I'll send a separate request to stable-ify this patch. I'm betting that some old code used to check the bmp_version_major against 2, but that got changed to bios major in one of the rewrites, although I didn't go digging. drivers/gpu/drm/nouveau/core/subdev/bios/init.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/subdev/bios/init.c b/drivers/gpu/drm/nouveau/core/subdev/bios/init.c index 9f5b81e..df1b1b4 100644 --- a/drivers/gpu/drm/nouveau/core/subdev/bios/init.c +++ b/drivers/gpu/drm/nouveau/core/subdev/bios/init.c @@ -365,13 +365,13 @@ static u16 init_script(struct nouveau_bios *bios, int index) { struct nvbios_init init = { .bios = bios }; - u16 data; + u16 bmp_ver = bmp_version(bios), data; - if (bmp_version(bios) && bmp_version(bios) < 0x0510) { - if (index > 1) + if (bmp_ver && bmp_ver < 0x0510) { + if (index > 1 || bmp_ver < 0x0100) return 0x0000; - data = bios->bmp_offset + (bios->version.major < 2 ? 14 : 18); + data = bios->bmp_offset + (bmp_ver < 0x0200 ? 14 : 18); return nv_ro16(bios, data + (index * 2)); } -- 1.8.3.2

2 1

[PATCH] drm/radeon: warn users when hw_i2c is enabled
by Alex Deucher 07 Jan '14

07 Jan '14

The hw i2c engines are disabled by default as the current implementation is still experimental. Print a warning when users enable it so that it's obvious when the option is enabled. Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/radeon/radeon_i2c.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/radeon/radeon_i2c.c b/drivers/gpu/drm/radeon/radeon_i2c.c index fc60b74..74bfbf8 100644 --- a/drivers/gpu/drm/radeon/radeon_i2c.c +++ b/drivers/gpu/drm/radeon/radeon_i2c.c @@ -1020,6 +1020,9 @@ void radeon_i2c_destroy(struct radeon_i2c_chan *i2c) /* Add the default buses */ void radeon_i2c_init(struct radeon_device *rdev) { + if (radeon_hw_i2c == 1) + DRM_INFO("hw_i2c forced on, you may experience display detection problems!\n"); + if (rdev->is_atom_bios) radeon_atombios_i2c_init(rdev); else -- 1.8.3.1

4 5

[PATCH] drm/radeon: warn users when hw_i2c is enabled (v2)
by Alex Deucher 07 Jan '14

07 Jan '14

The hw i2c engines are disabled by default as the current implementation is still experimental. Print a warning when users enable it so that it's obvious when the option is enabled. v2: check for non-0 rather than 1 Signed-off-by: Alex Deucher <alexander.deucher(a)amd.com> Reviewed-by: Christian König <christian.koenig(a)amd.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/radeon/radeon_i2c.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/radeon/radeon_i2c.c b/drivers/gpu/drm/radeon/radeon_i2c.c index fc60b74..e24ca6a 100644 --- a/drivers/gpu/drm/radeon/radeon_i2c.c +++ b/drivers/gpu/drm/radeon/radeon_i2c.c @@ -1020,6 +1020,9 @@ void radeon_i2c_destroy(struct radeon_i2c_chan *i2c) /* Add the default buses */ void radeon_i2c_init(struct radeon_device *rdev) { + if (radeon_hw_i2c) + DRM_INFO("hw_i2c forced on, you may experience display detection problems!\n"); + if (rdev->is_atom_bios) radeon_atombios_i2c_init(rdev); else -- 1.8.3.1

1 0

[Bug 72223] l4d
by bugzilla-daemon＠freedesktop.org 07 Jan '14

07 Jan '14

https://bugs.freedesktop.org/show_bug.cgi?id=72223 --- Comment #2 from Benjamin Bellec <b.bellec(a)gmail.com> --- Sorry, I even didn't know I created it! Maybe a bad action when searching or opening another one. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 72223] l4d
by bugzilla-daemon＠freedesktop.org 07 Jan '14

07 Jan '14

https://bugs.freedesktop.org/show_bug.cgi?id=72223 Tapani Pälli <lemody(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |NOTABUG --- Comment #1 from Tapani Pälli <lemody(a)gmail.com> --- bad summary and no description, resolving as NOTABUG -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH] drm/ttm: Refuse to fault (prime-) imported pages
by Thomas Hellstrom 07 Jan '14

07 Jan '14

This is illegal for at least two reasons: 1) While it may work on some platforms / iommus, obtaining page pointers from mapped sg-lists is illegal, since the DMA API allows page pointer information to be destroyed in the sg mapping process. 2) TTM has no way of determining the linear kernel map caching state of the underlying pages. PTEs with conflicting caching state pointing to the same pfn is not allowed. TTM operations touching pages of imported sg-tables should be redirected through the proper dma-buf operations. Signed-off-by: Thomas Hellstrom <thellstrom(a)vmware.com> --- drivers/gpu/drm/ttm/ttm_bo_vm.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c index cdda784..12d7f53 100644 --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c @@ -132,6 +132,15 @@ static int ttm_bo_vm_fault(struct vm_area_struct *vma, struct vm_fault *vmf) return VM_FAULT_NOPAGE; } + /* + * Refuse to fault imported pages. This should be handled + * (if at all) by redirecting mmap to the exporter. + */ + if (bo->ttm && (bo->ttm->page_flags & TTM_PAGE_FLAG_SG)) { + retval = VM_FAULT_SIGBUS; + goto out_unlock; + } + if (bdev->driver->fault_reserve_notify) { ret = bdev->driver->fault_reserve_notify(bo); switch (ret) { -- 1.7.10.4

2 2

[PATCH] MAINTAINERS: Updates for drm/i915
by Daniel Vetter 07 Jan '14

07 Jan '14

Jani for co-maintainer! Jani has been a really active bug-scrubber in the past few months. I've asked him whether he wants to do this in a more official capacity and he agreed. I've already chatted with Dave and Jesse and they support this. Note that everyone can't now just relax because "Jani will do all the bug scrubbing" - au contraire expect more nagging and poking now that we have more bandwidth. Longer-term the plan is to share more of the maintainer duties, but we need to fix up the infrastructure a bit first (like moving the git repo to a common location). While at it also add the newly set-up patchwork instance. Cc: Dave Airlie <airlied(a)gmail.com> Cc: Jesse Barnes <jbarnes(a)virtuousgeek.org> Cc: Jani Nikula <jani.nikula(a)linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 13c15c83a46e..1add46156f26 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2827,8 +2827,10 @@ F: include/uapi/drm/ INTEL DRM DRIVERS (excluding Poulsbo, Moorestown and derivative chipsets) M: Daniel Vetter <daniel.vetter(a)ffwll.ch> +M: Jani Nikula <jani.nikula(a)linux.intel.com> L: intel-gfx(a)lists.freedesktop.org L: dri-devel(a)lists.freedesktop.org +Q: http://patchwork.freedesktop.org/project/intel-gfx/ T: git git://people.freedesktop.org/~danvet/drm-intel S: Supported F: drivers/gpu/drm/i915/ -- 1.8.4.3

2 1

[GIT PULL] exynos-drm-next for 3.13
by Inki Dae 07 Jan '14

07 Jan '14

Hi Dave, This pull request adds an anon file for exynos specific mmaper to resolve potential a dead lock issue pointed out by Al Viro, and fixes build break of drm-next. For this, I had already reported it to you. Please see below link, http://www.spinics.net/lists/dri-devel/msg50922.html In addition, we have a big refactoring patch series being reviewed in exynos-drm-next-todo branch yet, and we are wait for next version of the patch series. So I will request git-pull one more time if posted at a good time. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit fe3c703c3d80bd4c2da0d47a7d56930926af7cbc: drm/dp: Clarify automated test constant and add constant for FAUX test pattern (2013-12-18 11:47:43 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos exynos-drm-next for you to fetch changes up to 8dd9ad5d3bf4759399e0c716dd065e7d90eee102: drm/exynos: fix build error caused by removed drm core macros (2014-01-07 16:53:25 +0900) ---------------------------------------------------------------- Inki Dae (1): drm/exynos: use a new anon file for exynos gem mmaper Seung-Woo Kim (1): drm/exynos: fix build error caused by removed drm core macros drivers/gpu/drm/exynos/exynos_drm_drv.c | 21 +++++++++ drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 + drivers/gpu/drm/exynos/exynos_drm_fimd.c | 4 +- drivers/gpu/drm/exynos/exynos_drm_gem.c | 74 ++++++------------------------ drivers/gpu/drm/exynos/exynos_drm_gem.h | 3 ++ 5 files changed, 40 insertions(+), 63 deletions(-)

1 0

[Bug 73343] Recent radeon driver "probed a monitor but no|invalid EDID"
by bugzilla-daemon＠freedesktop.org 07 Jan '14

07 Jan '14

https://bugs.freedesktop.org/show_bug.cgi?id=73343 Michel Dänzer <michel(a)daenzer.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Product|Mesa |DRI Version|git |unspecified Component|Drivers/DRI/Radeon |DRM/Radeon --- Comment #2 from Michel Dänzer <michel(a)daenzer.net> --- Mesa has nothing to do with monitor detection. It's probably the kernel. -- You are receiving this mail because: You are the assignee for the bug.

1 0

← Newer
1
...
89
90
91
92
93
94
95
96
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel January 2014