dri-devel August 2015

dri-devel@lists.freedesktop.org

178 participants
1142 discussions

[PATCH 1/3] drm/nouveau: Use drm_vblank_on/off consistently
by Daniel Vetter 07 Aug '15

07 Aug '15

In commit 9cba5efab5a8145ae6c52ea273553f069c294482 Author: Mario Kleiner <mario.kleiner.de(a)gmail.com> Date: Tue Jul 29 02:36:44 2014 +0200 drm/nouveau: Dis/Enable vblank irqs during suspend/resume drm_vblank_on/off calls where added around suspend/resume to make sure vblank stay doesn't go boom over that transition. But nouveau already used drm_vblank_pre/post_modeset over modesets. Instead use drm_vblank_on/off everyhwere. The slight change here is that after _off drm_vblank_get will refuse to work right away, but nouveau doesn't seem to depend upon that anywhere outside of the pageflip paths. The longer-term plan here is to switch all kms drivers to drm_vblank_on/off so that common code like pending event cleanup can be done there, while drm_vblank_pre/post_modeset will be purely drm internal for the old UMS ioctl. Note that the drm_vblank_off still seems required in the suspend path since nouveau doesn't explicitly disable crtcs. But on the resume side drm_helper_resume_force_mode should end up calling drm_vblank_on through the nouveau crtc hooks already. Hence remove the call in the resume code. Cc: Mario Kleiner <mario.kleiner.de(a)gmail.com> Cc: Ben Skeggs <bskeggs(a)redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- drivers/gpu/drm/nouveau/dispnv04/crtc.c | 4 ++-- drivers/gpu/drm/nouveau/nouveau_display.c | 4 ---- 2 files changed, 2 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c b/drivers/gpu/drm/nouveau/dispnv04/crtc.c index 3d96b49fe662..dab24066fa21 100644 --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c @@ -708,7 +708,7 @@ static void nv_crtc_prepare(struct drm_crtc *crtc) if (nv_two_heads(dev)) NVSetOwner(dev, nv_crtc->index); - drm_vblank_pre_modeset(dev, nv_crtc->index); + drm_vblank_off(dev, nv_crtc->index); funcs->dpms(crtc, DRM_MODE_DPMS_OFF); NVBlankScreen(dev, nv_crtc->index, true); @@ -740,7 +740,7 @@ static void nv_crtc_commit(struct drm_crtc *crtc) #endif funcs->dpms(crtc, DRM_MODE_DPMS_ON); - drm_vblank_post_modeset(dev, nv_crtc->index); + drm_vblank_on(dev, nv_crtc->index); } static void nv_crtc_destroy(struct drm_crtc *crtc) diff --git a/drivers/gpu/drm/nouveau/nouveau_display.c b/drivers/gpu/drm/nouveau/nouveau_display.c index 8670d90cdc11..d824023f9fc6 100644 --- a/drivers/gpu/drm/nouveau/nouveau_display.c +++ b/drivers/gpu/drm/nouveau/nouveau_display.c @@ -620,10 +620,6 @@ nouveau_display_resume(struct drm_device *dev, bool runtime) nv_crtc->lut.depth = 0; } - /* Make sure that drm and hw vblank irqs get resumed if needed. */ - for (head = 0; head < dev->mode_config.num_crtc; head++) - drm_vblank_on(dev, head); - /* This should ensure we don't hit a locking problem when someone * wakes us up via a connector. We should never go into suspend * while the display is on anyways. -- 2.1.4

4 17

[Bug 91302] radeon.audio=1 causes weird issues with 7950
by bugzilla-daemon＠freedesktop.org 06 Aug '15

06 Aug '15

https://bugs.freedesktop.org/show_bug.cgi?id=91302 Bug ID: 91302 Summary: radeon.audio=1 causes weird issues with 7950 Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: contrib(a)kliznoe.com When I have radeon.audio set to 1, My displayport audio output is deeper then normal and my hdmi screen becomes blurry and has a pink line to the left of it. This doesn't happen when radeon.audio is set to 0 or in Windows. OS : Arch Linux with Gnome3 and xf86-video-ati-git from the AUR -- You are receiving this mail because: You are the assignee for the bug.

1 9

[PATCH] scripts/kernel-doc Allow struct arguments documentation in struct body
by Danilo Cesar Lemes de Paula 06 Aug '15

06 Aug '15

Describing arguments at top of a struct definition works fine for small/medium size structs, but it definitely doesn't work well for struct with a huge list of elements. Keeping the arguments list inside the struct body makes it easier to maintain the documentation. ie: /** * struct my_struct - short description * @a: first member * @b: second member * * Longer description */ struct my_struct { int a; int b; /** * @c: This is longer description of C * * You can use paragraphs to describe arguments * using this method. */ int c; }; This patch allows the use of this kind of syntax. Only one argument per comment and user can use how many paragraphs he needs. It should start with /**, which is already being used by kernel-doc. If those comment doesn't follow those rules, it will be ignored. Signed-off-by: Danilo Cesar Lemes de Paula <danilo.cesar(a)collabora.co.uk> Cc: Randy Dunlap <rdunlap(a)infradead.org> Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Laurent Pinchart <laurent.pinchart(a)ideasonboard.com> Cc: Jonathan Corbet <corbet(a)lwn.net> Cc: Herbert Xu <herbert(a)gondor.apana.org.au> Cc: Stephan Mueller <smueller(a)chronox.de> Cc: Michal Marek <mmarek(a)suse.cz> Cc: linux-kernel(a)vger.kernel.org Cc: linux-doc(a)vger.kernel.org Cc: intel-gfx <intel-gfx(a)lists.freedesktop.org> Cc: dri-devel <dri-devel(a)lists.freedesktop.org> --- scripts/kernel-doc | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 78 insertions(+), 2 deletions(-) diff --git a/scripts/kernel-doc b/scripts/kernel-doc index 9922e66..9bfa8b9 100755 --- a/scripts/kernel-doc +++ b/scripts/kernel-doc @@ -133,6 +133,30 @@ use strict; # # All descriptions can be multiline, except the short function description. # +# For really longs structs, you can also describe arguments inside the +# body of the struct. +# eg. +# /** +# * struct my_struct - short description +# * @a: first member +# * @b: second member +# * +# * Longer description +# */ +# struct my_struct { +# int a; +# int b; +# /** +# * @c: This is longer description of C +# * +# * You can use paragraphs to describe arguments +# * using this method. +# */ +# int c; +# }; +# +# This should be use for arguments only. +# # You can also add additional sections. When documenting kernel functions you # should document the "Context:" of the function, e.g. whether the functions # can be called form interrupts. Unlike other sections you can end it with an @@ -287,9 +311,19 @@ my $lineprefix=""; # 2 - scanning field start. # 3 - scanning prototype. # 4 - documentation block +# 5 - gathering documentation outside main block my $state; my $in_doc_sect; +# Split Doc State +# 0 - Invalid (Before start or after finish) +# 1 - Is started (the /** was found inside a struct) +# 2 - The @parameter header was found, start accepting multi paragraph text. +# 3 - Finished (the */ was found) +# 4 - Error - Comment without header was found. Spit a warning as it's not +# proper kernel-doc and ignore the rest. +my $split_doc_state; + #declaration types: can be # 'function', 'struct', 'union', 'enum', 'typedef' my $decl_type; @@ -304,6 +338,9 @@ my $doc_decl = $doc_com . '(\w+)'; my $doc_sect = $doc_com . '([' . $doc_special . ']?[\w\s]+):(.*)'; my $doc_content = $doc_com_body . '(.*)'; my $doc_block = $doc_com . 'DOC:\s*(.*)?'; +my $doc_split_start = '^\s*/\*\*\s*$'; +my $doc_split_sect = '\s*\*\s*(@[\w\s]+):(.*)'; +my $doc_split_end = '^\s*\*/\s*$'; my %constants; my %parameterdescs; @@ -2181,6 +2218,7 @@ sub reset_state { $prototype = ""; $state = 0; + $split_doc_state = 0; } sub tracepoint_munge($) { @@ -2453,7 +2491,6 @@ sub process_file($) { } $section = $newsection; } elsif (/$doc_end/) { - if (($contents ne "") && ($contents ne "\n")) { dump_section($file, $section, xml_escape($contents)); $section = $section_default; @@ -2494,8 +2531,47 @@ sub process_file($) { print STDERR "Warning(${file}:$.): bad line: $_"; ++$warnings; } + } elsif ($state == 5) { # scanning for split parameters + + # First line (state 1) needs to be a @parameter + if ($split_doc_state == 1 && /$doc_split_sect/o) { + $section = $1; + $contents = $2; + if ($contents ne "") { + while ((substr($contents, 0, 1) eq " ") || + substr($contents, 0, 1) eq "\t") { + $contents = substr($contents, 1); + } + $contents .= "\n"; + } + $split_doc_state = 2; + + # End commend */ + } elsif (/$doc_split_end/) { + if (($contents ne "") && ($contents ne "\n")) { + dump_section($file, $section, xml_escape($contents)); + $section = $section_default; + $contents = ""; + } + $state = 3; + $split_doc_state = 0; + + # Regular text + } elsif (/$doc_content/) { + if ($split_doc_state == 2) { + $contents .= $1 . "\n"; + } elsif ($split_doc_state == 1) { + $split_doc_state = 4; + print STDERR "Warning(${file}:$.): "; + print STDERR "Incorrect use of kernel-doc format: $_"; + ++$warnings; + } + } } elsif ($state == 3) { # scanning for function '{' (end of prototype) - if ($decl_type eq 'function') { + if (/$doc_split_start/) { + $state = 5; + $split_doc_state = 1; + } elsif ($decl_type eq 'function') { process_state3_function($_, $file); } else { process_state3_type($_, $file); -- 2.4.6

5 10

[Bug 91461] gl_TessLevel* writes have no effect for all but the last TCS invocation
by bugzilla-daemon＠freedesktop.org 06 Aug '15

06 Aug '15

https://bugs.freedesktop.org/show_bug.cgi?id=91461 Bug ID: 91461 Summary: gl_TessLevel* writes have no effect for all but the last TCS invocation Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel(a)lists.freedesktop.org Reporter: daniel(a)constexpr.org QA Contact: dri-devel(a)lists.freedesktop.org The tessellator ignores all writes to gl_TessLevelInner and gl_TessLevelOuter by the tessellation control shader except except those done by the last TCS invocation (gl_InvocationID == patch output vertices - 1). This results in no primitives being generated unless all entries of gl_TessLevelOuter are written in that invocation (the 'initial' values seem to be 0 for gl_TessLevelOuter and 1 for gl_TessLevelInner). Additionally, barrier() does not synchronize changes to the gl_TessLevel* between TCS invocations. Neither of these problems can be reproduced with user-defined 'patch out' variables - writes by any TCS invocation are visible in the evaluation shader and barrier() makes them visible to the other TCS invocations. GPU: Radeon HD 7950 (TAHITI) Mesa: 10.7.0-devel (git-9deb614) LLVM: r243203 -- You are receiving this mail because: You are the assignee for the bug.

1 3

Re: [RFC PATCH 1/8] drm: exynos/dp: fix code style
by Yakir Yang 06 Aug '15

06 Aug '15

Joe, 在 2015/8/6 23:05, Joe Perches 写道: > On Thu, 2015-08-06 at 09:04 -0500, Yakir Yang wrote: >> make checkpatch.pl script happy > That should not be the primary reason to submit a patch. > > Making it easier for human code reader to understand > what the code does should be though. Thanks for your reply, but I do think that fix code style and make checkpatch.pl passed is my primary reason to submit this patch. I can't think out more directly words ;( , >> diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c b/drivers/gpu/drm/exynos/exynos_dp_core.c > [] >> @@ -123,10 +123,11 @@ static int exynos_dp_read_edid(struct exynos_dp_device *dp) >> dev_dbg(dp->dev, "EDID data includes a single extension!\n"); >> >> /* Read EDID data */ >> - retval = exynos_dp_read_bytes_from_i2c(dp, I2C_EDID_DEVICE_ADDR, >> - EDID_HEADER_PATTERN, >> - EDID_BLOCK_LENGTH, >> - &edid[EDID_HEADER_PATTERN]); >> + retval = >> + exynos_dp_read_bytes_from_i2c(dp, I2C_EDID_DEVICE_ADDR, >> + EDID_HEADER_PATTERN, >> + EDID_BLOCK_LENGTH, >> + &edid[EDID_HEADER_PATTERN]); > This is a relatively uncommon style. > > Because the code uses relatively long variable and > function names as well as longish macro #defines, > prefer to ignore the 80 column limit. Okay, I think it would be better to modify like those: retval = exynos_dp_read_bytes_from_i2c( dp, I2C_EDID_DEVICE_ADDR, EDID_HEADER_PATTERN, EDID_BLOCK_LENGTH, &edid[EDID_HEADER_PATTERN]); Is it okay ? - Yakir > > > >

1 0

[GIT PULL] TDA998x I2C driver fixes
by Russell King 06 Aug '15

06 Aug '15

David, Please incorporate the latest TDA998x I2C driver fixes, which can be found at: git://ftp.arm.linux.org.uk/~rmk/linux-arm.git drm-tda998x-fixes with SHA1 4a6ca1a2c2530af4611024476ba7005bf0336dfe. This fixes the double-checksumming of the AVI infoframe which was resulting in the checksum always being zero. It went unnoticed as none of my HDMI devices had a problem with this. This will update the following files: drivers/gpu/drm/i2c/tda998x_drv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) through these changes: Jean-Francois Moine (1): drm/i2c: tda998x: fix bad checksum of the HDMI AVI infoframe Many thanks.

3 4

[Bug 91534] r300 blocking GLX and EGL compositing in KWin (KDE Plasma 5.x)?
by bugzilla-daemon＠freedesktop.org 06 Aug '15

06 Aug '15

https://bugs.freedesktop.org/show_bug.cgi?id=91534 Bug ID: 91534 Summary: r300 blocking GLX and EGL compositing in KWin (KDE Plasma 5.x)? Product: Mesa Version: 10.5 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r300 Assignee: dri-devel(a)lists.freedesktop.org Reporter: aaron.d.pickett(a)gmail.com QA Contact: dri-devel(a)lists.freedesktop.org Created attachment 117488 --> https://bugs.freedesktop.org/attachment.cgi?id=117488&action=edit Attempt to force EGL-based OpenGL compositing I have an old laptop with ATI RS480 graphics (Radeon Xpress 200M), and I've been testing KDE Plasma 5.x in KUbuntu 15.04 (currently version 5.3 from the backports PPA). In all the versions I've tried, OpenGL compositing fails. For the GLX API, I assume this is because r300 *almost* supports OpenGL 2.1, but falls short on NPOT texture support. After some reading (http://blog.martin-graesslin.com/blog/2011/07/running-kwin-with-opengl-es-2…), I thought I might try the EGL API for OpenGL ES compositing. The GUI wouldn't let me select EGL, so I forced it using environment variables (https://community.kde.org/KWin/Environment_Variables) as follows: KWIN_OPENGL_INTERFACE=egl KWIN_COMPOSE=O1 (I also tried O2, same result) Unfortunately, the (truncated) result is: kwin_core: OpenGL driver recommends XRender based compositing. Falling back to XRender. ... kwin_core: Failed to initialize compositing, compositing disabled >From what I've read, the r300 should have full OpenGL ES 2.0 support, so is the driver blocking EGL compositing unnecessarily? The full log of my attempt to force EGL-based compositing is attached. -- You are receiving this mail because: You are the assignee for the bug.

1 3

[PATCH 0/2] mmap on the dma-buf directly
by Tiago Vignatti 06 Aug '15

06 Aug '15

Hi, I've tested these two patches (in drm-intel-nightly, but also in CrOS kernel v3.14) and they seem just enough for what we want to do: the idea is to create a GEM bo in one process and pass the prime handle of the it to another process, which in turn uses the handle only to map and write. This could be useful for Chrome OS architecture, where the Web content ("unpriviledged process") maps and CPU-draws a buffer, which was previously allocated in the GPU process ("priviledged process"). I'm using a modified igt mostly to test these things. PTAL here: https://github.com/tiagovignatti/intel-gpu-tools/commits/prime_mmap Thank you, Tiago Daniel Thompson (1): drm: prime: Honour O_RDWR during prime-handle-to-fd Tiago Vignatti (1): drm/i915: Use CPU mapping for userspace dma-buf mmap() drivers/gpu/drm/drm_prime.c | 10 +++------- drivers/gpu/drm/i915/i915_gem_dmabuf.c | 21 ++++++++++++++++++++- include/uapi/drm/drm.h | 1 + 3 files changed, 24 insertions(+), 8 deletions(-) -- 2.1.0

3 7

[Bug 91041] Purple line is visible on left side of screen and the screen is blurry using HTMI output with AMD radeon
by bugzilla-daemon＠freedesktop.org 06 Aug '15

06 Aug '15

https://bugs.freedesktop.org/show_bug.cgi?id=91041 Bug ID: 91041 Summary: Purple line is visible on left side of screen and the screen is blurry using HTMI output with AMD radeon Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: minor Priority: medium Component: DRM/Radeon Assignee: dri-devel(a)lists.freedesktop.org Reporter: robotbuilderfiletransfer(a)gmail.com The problem can be sloved by executing this command: "xrandr --output HDMI-0 --auto --set audio off". I found a simillar, but very old (6 years old), bug here: https://bugs.freedesktop.org/show_bug.cgi?id=23384. -- You are receiving this mail because: You are the assignee for the bug.

1 20

[PATCH] drm/atomic: Call ww_acquire_done after check phase is complete
by Daniel Vetter 06 Aug '15

06 Aug '15

We want to make sure that no one tries to acquire more locks and states, and ww mutexes provide debug facilities for that. So use them. Cc: Rob Clark <robdclark(a)gmail.com> Cc: Maarten Lankhorst <maarten.lankhorst(a)linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter(a)intel.com> --- drivers/gpu/drm/drm_atomic.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 422183e7ee7d..5ea609f270ea 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -1268,6 +1268,8 @@ int drm_atomic_check_only(struct drm_atomic_state *state) } } + ww_acquire_done(&state->acquire_ctx->ww_ctx); + return ret; } EXPORT_SYMBOL(drm_atomic_check_only); -- 2.5.0

3 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel August 2015