dri-devel September 2014

dri-devel@lists.freedesktop.org

173 participants
1045 discussions

[PATCH] drm/vmwgfx: Fix drm.h include
by Josh Boyer 22 Sep '14

22 Sep '14

The userspace drm.h include doesn't prefix the drm directory. This can lead to compile failures as /usr/include/drm/ isn't in the standard gcc include paths. Fix it to be <drm/drm.h>, which matches the rest of the driver drm header files that get installed into /usr/include/drm. Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1138759 Fixes: 1d7a5cbf8f74e Reported-by: Jeffrey Bastian <jbastian(a)redhat.com> Signed-off-by: Josh Boyer <jwboyer(a)fedoraproject.org> --- include/uapi/drm/vmwgfx_drm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/uapi/drm/vmwgfx_drm.h b/include/uapi/drm/vmwgfx_drm.h index 4fc66f6b12ce..c472bedbe38e 100644 --- a/include/uapi/drm/vmwgfx_drm.h +++ b/include/uapi/drm/vmwgfx_drm.h @@ -29,7 +29,7 @@ #define __VMWGFX_DRM_H__ #ifndef __KERNEL__ -#include <drm.h> +#include <drm/drm.h> #endif #define DRM_VMW_MAX_SURFACE_FACES 6 -- 1.9.3

5 8

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
by bugzilla-daemon＠freedesktop.org 22 Sep '14

22 Sep '14

https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #43 from Chernovsky Oleg <adonai(a)xaker.ru> --- (In reply to comment #42) >If I got it right, you're giving an option to manually set fan-speed. Yes, you understood it right. For now it's only the option to manually set fan speed. > > Wouldn't it be possible to implement such behaviour in the drm drivers? I > mean like: reading fan profile (like 40°C -> 20%, 60°C -> 25%, 80°C -> 45% > etc. and assuming linear scaling between those values), reading temperatures > and setting fan-speed accordingly? > That's not impossible, and there's an API called Overdrive6 that's both accessible to Windows and Linux (only closed source driver though). Mmiotracing those calls (yeah, actually that thing you mentioned - setting temperature<-->speed pairs) can lead to implementing this behaviour in open-sorce driver. Alex said he can provide some patches for me to start with, let's see if it will cover these demands. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
by bugzilla-daemon＠freedesktop.org 22 Sep '14

22 Sep '14

https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #42 from Tolga Cakir <cevelnet(a)gmail.com> --- I have just reviewed the patch, but I'm unsure, whether I've fully understood it or not. If I got it right, you're giving an option to manually set fan-speed. However, the driver is still lacking an auto-mode, which needs to work out-of-the-box. Fan profiles are usually saved in VBIOS (they are also seperately available in UEFI VBIOS); there is a Windows-only tool called VBE7, which can extract, modify and save such profiles directly to VBIOS (http://www.techpowerup.com/forums/threads/vbe7-vbios-editor-for-radeon-hd-7…). Wouldn't it be possible to implement such behaviour in the drm drivers? I mean like: reading fan profile (like 40°C -> 20%, 60°C -> 25%, 80°C -> 45% etc. and assuming linear scaling between those values), reading temperatures and setting fan-speed accordingly? I have absolutely no idea, how the Windows driver is handling this, but the fan-profile saved in VBIOS doesn't seem to have any value for the open source Radeon drivers, at least for my reference HD7970 card. The card is running in BIOS-level 40% fan-speed, no matter what. I'd prefer an automatic method over setting fan-profiles via user-land tools or manually. Thanks for the great work so far! -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
by bugzilla-daemon＠freedesktop.org 22 Sep '14

22 Sep '14

https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #41 from Chernovsky Oleg <adonai(a)xaker.ru> --- (In reply to comment #40) > I found some time over the last couple of weekends to write up some > preliminary patches that should point you in the right direction; I just > need to run them by the IP team to make sure they are ok to release. I'd > like to avoid including reverse engineered stuff in the driver as it's a lot > harder for us to maintain. I agree about RE stuff. Ok, I'll be waiting for your turn. Reading source code of already implemented things and so on. Though I'll have a lot of questions about where should I place things in the driver and whether some locking required or not. And thanks for helping hand, Alex. Really appreciate it. -- You are receiving this mail because: You are the assignee for the bug.

1 0

nouveau regression: read fault PAGE_NOT_PRESENT with new fence interface
by Ted Percival 22 Sep '14

22 Sep '14

Hi, I noticed a regression in the next-20140903 kernel that was not present in next-20140902. When Xorg starts up, the display is garbled (or contains old image bits) and I see a page fault in the kernel log. X is not usable in this state - there is no pointer and gdm doesn't come up. It works fine after Xorg (gdm3) is restarted. The fault is still present in next-20140918. [drm] Initialized nouveau 1.2.0 20120801 for 0000:01:00.0 on minor 0 nouveau E[ PFIFO][0000:01:00.0] read fault at 0x0001260000 [PAGE_NOT_PRESENT] from PGRAPH/GPC0/TEX on channel 0x001fcd1000 [Xorg[3874]] nouveau E[ PFIFO][0000:01:00.0] PGRAPH engine fault on channel 2, recovering... nouveau E[ PGRAPH][0000:01:00.0] TRAP ch 2 [0x001fcd1000 Xorg[3874]] nouveau E[ PGRAPH][0000:01:00.0] GPC0/TPC0/TEX: 0x80000041 My hardware is: NVIDIA Corporation GF119 [Quadro NVS 4200M] (rev a1) I bisected it down to this commit: commit 29ba89b2371d466ca68973525816cf10debc2655 Author: Maarten Lankhorst <maarten.lankhorst(a)ubuntu.com> Date: Thu Jan 9 11:03:11 2014 +0100 drm/nouveau: rework to new fence interface Signed-off-by: Maarten Lankhorst <maarten.lankhorst(a)canonical.com> Acked-by: Ben Skeggs <bskeggs(a)redhat.com> I tried tracing the DEVICE, PGRAPH, PFIFO & PCE0 engines but nothing obvious stood out before the read fault shown above. Is there any other information I can provide to help track this down? paranoia or spam level logging, for example?

2 2

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
by bugzilla-daemon＠freedesktop.org 22 Sep '14

22 Sep '14

https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #40 from Alex Deucher <agd5f(a)yahoo.com> --- I found some time over the last couple of weekends to write up some preliminary patches that should point you in the right direction; I just need to run them by the IP team to make sure they are ok to release. I'd like to avoid including reverse engineered stuff in the driver as it's a lot harder for us to maintain. -- You are receiving this mail because: You are the assignee for the bug.

1 0

[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
by bugzilla-daemon＠freedesktop.org 22 Sep '14

22 Sep '14

https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #39 from Chernovsky Oleg <adonai(a)xaker.ru> --- (In reply to comment #38) > Good, I left some comments on the patch :) > Where? Could you post a link to it, seems I can't find it... > > When the radeon devs will think the patch is in good-enough shape, they will > likely commit it. Make sure your patch does not change the default behavior > and that should be fine. > > Users willing to have manual fan management will be the testers ;) Hmm, good point. But I'll need dumps for other cards to implement similar behaviour, how can I achieve this goal? -- You are receiving this mail because: You are the assignee for the bug.

1 0

[PATCH] gpu: ipu-v3: Fix IC control register offset
by Philipp Zabel 22 Sep '14

22 Sep '14

The IC register offset is at +0x20000 relative to the control module registers on all IPUv3 versions. This patch fixes wrong values for i.MX51 and i.MX53. Signed-off-by: Philipp Zabel <p.zabel(a)pengutronix.de> --- drivers/gpu/ipu-v3/ipu-common.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c index df65d2b..8e05148 100644 --- a/drivers/gpu/ipu-v3/ipu-common.c +++ b/drivers/gpu/ipu-v3/ipu-common.c @@ -742,7 +742,7 @@ static struct ipu_devtype ipu_type_imx51 = { .tpm_ofs = 0x1f060000, .csi0_ofs = 0x1f030000, .csi1_ofs = 0x1f038000, - .ic_ofs = 0x1f020000, + .ic_ofs = 0x1e020000, .disp0_ofs = 0x1e040000, .disp1_ofs = 0x1e048000, .dc_tmpl_ofs = 0x1f080000, @@ -758,7 +758,7 @@ static struct ipu_devtype ipu_type_imx53 = { .tpm_ofs = 0x07060000, .csi0_ofs = 0x07030000, .csi1_ofs = 0x07038000, - .ic_ofs = 0x07020000, + .ic_ofs = 0x06020000, .disp0_ofs = 0x06040000, .disp1_ofs = 0x06048000, .dc_tmpl_ofs = 0x07080000, -- 2.1.0

1 0

[PATCH 1/5] drm/i915: Merge of visible and !visible paths for primary planes
by Gustavo Padovan 22 Sep '14

22 Sep '14

From: Gustavo Padovan <gustavo.padovan(a)collabora.co.uk> Fold intel_pipe_set_base() in the update primary plane path merging pieces of code that are common to both paths. Basically the the pin/unpin procedures are the same for both paths and some checks can also be shared (some of the were moved to the check() stage) v2: take Ville's comments: - remove unnecessary plane check - move mutex lock to inside the conditional - make the pin fail message a debug one - add a fixme for the fastboot hack - call intel_frontbuffer_flip() after FBC update v3: take more Ville's comments: - fold update code under if (intel_crtc->active), and do the visible/!visible split inside. - check ret inside the same conditional we assign it v4: don't use intel_enable_primary_hw_plane(), the primary_enabled check inside will break page flips Suggested-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Signed-off-by: Gustavo Padovan <gustavo.padovan(a)collabora.co.uk> --- drivers/gpu/drm/i915/intel_display.c | 141 +++++++++++++++++++++-------------- 1 file changed, 84 insertions(+), 57 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 5b05ddb..1fd9b70 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -11792,12 +11792,23 @@ intel_check_primary_plane(struct drm_plane *plane, struct drm_rect *dest = &state->dst; struct drm_rect *src = &state->src; const struct drm_rect *clip = &state->clip; + int ret; - return drm_plane_helper_check_update(plane, crtc, fb, + ret = drm_plane_helper_check_update(plane, crtc, fb, src, dest, clip, DRM_PLANE_HELPER_NO_SCALING, DRM_PLANE_HELPER_NO_SCALING, false, true, &state->visible); + if (ret) + return ret; + + /* no fb bound */ + if (state->visible && !fb) { + DRM_ERROR("No FB bound\n"); + return -EINVAL; + } + + return 0; } static int @@ -11809,6 +11820,8 @@ intel_commit_primary_plane(struct drm_plane *plane, struct drm_device *dev = crtc->dev; struct drm_i915_private *dev_priv = dev->dev_private; struct intel_crtc *intel_crtc = to_intel_crtc(crtc); + enum pipe pipe = intel_crtc->pipe; + struct drm_framebuffer *old_fb = plane->fb; struct drm_i915_gem_object *obj = intel_fb_obj(fb); struct drm_i915_gem_object *old_obj = intel_fb_obj(plane->fb); struct intel_plane *intel_plane = to_intel_plane(plane); @@ -11817,67 +11830,28 @@ intel_commit_primary_plane(struct drm_plane *plane, intel_crtc_wait_for_pending_flips(crtc); - /* - * If clipping results in a non-visible primary plane, we'll disable - * the primary plane. Note that this is a bit different than what - * happens if userspace explicitly disables the plane by passing fb=0 - * because plane->fb still gets set and pinned. - */ - if (!state->visible) { - mutex_lock(&dev->struct_mutex); - - /* - * Try to pin the new fb first so that we can bail out if we - * fail. - */ - if (plane->fb != fb) { - ret = intel_pin_and_fence_fb_obj(dev, obj, NULL); - if (ret) { - mutex_unlock(&dev->struct_mutex); - return ret; - } - } - - i915_gem_track_fb(old_obj, obj, - INTEL_FRONTBUFFER_PRIMARY(intel_crtc->pipe)); - - if (intel_crtc->primary_enabled) - intel_disable_primary_hw_plane(plane, crtc); - - - if (plane->fb != fb) - if (plane->fb) - intel_unpin_fb_obj(old_obj); + if (intel_crtc_has_pending_flip(crtc)) { + DRM_ERROR("pipe is still busy with an old pageflip\n"); + return -EBUSY; + } + if (plane->fb != fb) { + mutex_lock(&dev->struct_mutex); + ret = intel_pin_and_fence_fb_obj(dev, obj, NULL); + if (ret == 0) + i915_gem_track_fb(old_obj, obj, + INTEL_FRONTBUFFER_PRIMARY(pipe)); mutex_unlock(&dev->struct_mutex); - - } else { - if (intel_crtc && intel_crtc->active && - intel_crtc->primary_enabled) { - /* - * FBC does not work on some platforms for rotated - * planes, so disable it when rotation is not 0 and - * update it when rotation is set back to 0. - * - * FIXME: This is redundant with the fbc update done in - * the primary plane enable function except that that - * one is done too late. We eventually need to unify - * this. - */ - if (INTEL_INFO(dev)->gen <= 4 && !IS_G4X(dev) && - dev_priv->fbc.plane == intel_crtc->plane && - intel_plane->rotation != BIT(DRM_ROTATE_0)) { - intel_disable_fbc(dev); - } - } - ret = intel_pipe_set_base(crtc, src->x1, src->y1, fb); - if (ret) + if (ret != 0) { + DRM_DEBUG_KMS("pin & fence failed\n"); return ret; - - if (!intel_crtc->primary_enabled) - intel_enable_primary_hw_plane(plane, crtc); + } } + crtc->primary->fb = fb; + crtc->x = src->x1; + crtc->y = src->y1; + intel_plane->crtc_x = state->orig_dst.x1; intel_plane->crtc_y = state->orig_dst.y1; intel_plane->crtc_w = drm_rect_width(&state->orig_dst); @@ -11888,6 +11862,59 @@ intel_commit_primary_plane(struct drm_plane *plane, intel_plane->src_h = drm_rect_height(&state->orig_src); intel_plane->obj = obj; + if (intel_crtc->active) { + /* + * FBC does not work on some platforms for rotated + * planes, so disable it when rotation is not 0 and + * update it when rotation is set back to 0. + * + * FIXME: This is redundant with the fbc update done in + * the primary plane enable function except that that + * one is done too late. We eventually need to unify + * this. + */ + if (intel_crtc->primary_enabled && + INTEL_INFO(dev)->gen <= 4 && !IS_G4X(dev) && + dev_priv->fbc.plane == intel_crtc->plane && + intel_plane->rotation != BIT(DRM_ROTATE_0)) { + intel_disable_fbc(dev); + } + + if (state->visible) { + /* FIXME: kill this fastboot hack */ + intel_update_pipe_size(intel_crtc); + + dev_priv->display.update_primary_plane(crtc, plane->fb, + crtc->x, crtc->y); + } else { + /* + * If clipping results in a non-visible primary plane, + * we'll disable the primary plane. Note that this is + * a bit different than what happens if userspace + * explicitly disables the plane by passing fb=0 + * because plane->fb still gets set and pinned. + */ + intel_disable_primary_hw_plane(plane, crtc); + } + + intel_frontbuffer_flip(dev, INTEL_FRONTBUFFER_PRIMARY(pipe)); + + mutex_lock(&dev->struct_mutex); + intel_update_fbc(dev); + mutex_unlock(&dev->struct_mutex); + } + + if (old_fb) { + if (intel_crtc->active && old_fb != fb) + intel_wait_for_vblank(dev, intel_crtc->pipe); + + if (old_fb != fb) { + mutex_lock(&dev->struct_mutex); + intel_unpin_fb_obj(old_obj); + mutex_unlock(&dev->struct_mutex); + } + } + return 0; } -- 1.9.3

2 9

[BUG] nouveau regression: ext monitor dead after resume
by Ortwin Glück 22 Sep '14

22 Sep '14

Hi, Since 3.16 an external monitor stays dark after resume from sleep. I didn't manage to activate it again with xrand. According to xrandr it is "connected" and configured with a mode, but I get no signal. Happens since 3.16 and is still broken with 3.17-rc5. Hardware: HP EliteBook 8540w 01:00.0 VGA compatible controller: NVIDIA Corporation GT215GLM [Quadro FX 1800M] (rev a2) 0 External Monitor connected via DVI on the docking station. XRandR before amd after suspend looks the same: $ xrandr Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 LVDS-1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 345mm x 194mm 1920x1080 59.9*+ 60.0 1680x1050 60.0 1400x1050 60.0 1280x1024 59.9 1280x960 59.9 1152x864 60.0 1024x768 59.9 800x600 59.9 640x480 59.4 720x400 59.6 640x400 60.0 640x350 59.8 DP-1 disconnected (normal left inverted right x axis y axis) DP-2 disconnected (normal left inverted right x axis y axis) eDP-1 disconnected (normal left inverted right x axis y axis) DP-3 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 598mm x 336mm 1920x1080 60.0*+ 1680x1050 59.9 1280x1024 75.0 60.0 1440x900 75.0 59.9 1024x768 75.1 60.0 800x600 75.0 60.3 640x480 75.0 72.8 66.7 60.0 720x400 70.1 VGA-1 disconnected (normal left inverted right x axis y axis) dmesg output of a suspend/resume cycle attached.

2 8

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

dri-devel September 2014