Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752814AbbF3M6I (ORCPT ); Tue, 30 Jun 2015 08:58:08 -0400 Received: from mga14.intel.com ([192.55.52.115]:56046 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753141AbbF3M5v (ORCPT ); Tue, 30 Jun 2015 08:57:51 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,377,1432623600"; d="scan'208";a="753245916" From: Jani Nikula To: Daniel Vetter Cc: Ander Conselvan De Oliveira , Linus Torvalds , Dave Airlie , Daniel Vetter , intel-gfx , Linux Kernel Mailing List , DRI mailing list Subject: Re: [Intel-gfx] [git pull] drm tree for 4.2 In-Reply-To: <20150629153511.GW30960@phenom.ffwll.local> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo References: <1435581800.3453.27.camel@gmail.com> <87381ay3fi.fsf@intel.com> <20150629153511.GW30960@phenom.ffwll.local> User-Agent: Notmuch/0.19+112~g77230b0 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Tue, 30 Jun 2015 16:00:12 +0300 Message-ID: <878ub1wdur.fsf@intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5604 Lines: 130 On Mon, 29 Jun 2015, Daniel Vetter wrote: > On Mon, Jun 29, 2015 at 05:50:09PM +0300, Jani Nikula wrote: >> On Mon, 29 Jun 2015, Ander Conselvan De Oliveira wrote: >> > On Fri, 2015-06-26 at 14:43 -0700, Linus Torvalds wrote: >> >> On Thu, Jun 25, 2015 at 6:00 PM, Dave Airlie wrote: >> >> > >> >> > This is the main drm pull request for v4.2. >> >> >> >> It seems to work ok for me, but it causes quite a few new warnings on >> >> my Sony VAIO Pro laptop. It's (once more) a regular i5-4200U CPU (aka >> >> Haswell, aka 4th gen Intel Core i5) >> >> >> >> Most of them are in check_crtc_state(), and I currently have 18 of >> >> these in my log: >> >> >> >> [drm:check_crtc_state [i915]] *ERROR* mismatch in >> >> dpll_hw_state.wrpll (expected 0x90280202, found 0x00000000) >> >> WARNING: CPU: 0 PID: 115 at >> >> drivers/gpu/drm/i915/intel_display.c:12319 >> >> check_crtc_state+0x8be/0xf60 [i915]() >> >> pipe state doesn't match! >> >> >> >> but there's a few others too: >> >> >> >> WARNING: CPU: 3 PID: 1871 at >> >> drivers/gpu/drm/i915/intel_display.c:1362 hsw_disable_ips+0x34/0x160 >> >> [i915]() >> >> plane A assertion failure (expected on, current off) >> >> >> >> WARNING: CPU: 3 PID: 1871 at drivers/gpu/drm/drm_irq.c:1162 >> >> drm_wait_one_vblank+0x148/0x1a0 [drm]() >> >> vblank not available on crtc 0, ret=-22 >> >> >> >> and the backtraces aren't all that interesting, but I'm attaching the >> >> cleaned-up dmesg, duplicate callchains and all. >> > >> > Please provide a full dmesg with drm.debug=0x1f in the kernel command >> > line. >> >> Ander, I think I was able to reproduce this on the BDW NUC here. Bisect >> points at... >> >> commit dd3cd74acf12723045a64f1f2c6298ac7b34a5d5 >> Author: Ander Conselvan de Oliveira >> Date: Fri May 15 13:34:29 2015 +0300 >> >> drm/i915: Don't overwrite (e)DP PLL selection on SKL >> >> In the following commit, the place where the contents of dpll_hw_state >> in crtc_state where zeroed was changed. Prior to that commit, it >> happened when the new state was allocated, but now that happens just >> before the call the .crtc_compute_clock() hook. The DP code for SKL, >> however, sets up the (private) PLL in the encoder compute config >> function that has already run by the time that memset() is reached, >> causing the previous value to be lost. >> >> This patch fixes the issue by moving the memset() down the call chain, >> so that it is only called if the values in dpll_hw_state are going to be >> updated. >> >> commit 4978cc93d9ac240b435ce60431aef24239b4c270 >> Author: Ander Conselvan de Oliveira >> Date: Tue Apr 21 17:13:21 2015 +0300 >> >> drm/i915: Preserve shared DPLL information in new pipe_config >> >> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=90462 >> Signed-off-by: Ander Conselvan de Oliveira >> Reviewed-by: Damien Lespiau >> Reported-and-tested-by: Tvrtko Ursulin >> Signed-off-by: Daniel Vetter >> >> This doesn't revert cleanly on Linus' master, and I didn't have the time >> to look deeper right now. However I confirmed that this commit fails and >> its parent doesn't. > > Note that there seems to be two bugs here: Firs one is display state > checker getting annoyed, which is probably the one Jani bisected to here > (please confirm). Right, the above bisect is for the "[drm:check_crtc_state [i915]] *ERROR* mismatch in dpll_hw_state.wrpll (expected 0x90280202, found 0x00000000)" warning. > The other is the two backtraces complaining that the pipe is off (both the > drm_irq.c and the one in hsw_display_ips amount to that) because we seem > to call disable_planes on a disable pipe, which is bullocks (with runtime > pm the hw is dead and will just drop the writes). The "vblank not available on crtc 0, ret=-22" warning bisects to commit 8c7b5ccb729870e606321b3703e2c2e698c49a95 Author: Ander Conselvan de Oliveira Date: Tue Apr 21 17:13:19 2015 +0300 drm/i915: Use atomic helpers for computing changed flags Replace the drivers own logic for computing mode_changed, active_changed and planes_changed flags with the check_modeset() atomic helper. Since that function needs to compare the crtc's new mode with the current, this patch also moves the set up of crtc_state->mode earlier in the call chain. Note that for the call to check_plane() to work properly, we need to check new plane state against new crtc state. But since we still use the plane update helper, which doesn't have a full atomic state, we need to hack around that in intel_plane_atomic_check(). Signed-off-by: Ander Conselvan de Oliveira Reviewed-by: Maarten Lankhorst Signed-off-by: Daniel Vetter BR, Jani. > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch -- Jani Nikula, Intel Open Source Technology Center -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/