On Mon, 29 Jun 2015, Daniel Vetter daniel@ffwll.ch wrote:
On Mon, Jun 29, 2015 at 05:50:09PM +0300, Jani Nikula wrote:
On Mon, 29 Jun 2015, Ander Conselvan De Oliveira conselvan2@gmail.com wrote:
On Fri, 2015-06-26 at 14:43 -0700, Linus Torvalds wrote:
On Thu, Jun 25, 2015 at 6:00 PM, Dave Airlie airlied@linux.ie 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 ander.conselvan.de.oliveira@intel.com 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 <ander.conselvan.de.oliveira@intel.com> 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 <ander.conselvan.de.oliveira@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Reported-and-tested-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>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 ander.conselvan.de.oliveira@intel.com 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 ander.conselvan.de.oliveira@intel.com Reviewed-by: Maarten Lankhorst maarten.lankhorst@linux.intel.com Signed-off-by: Daniel Vetter daniel.vetter@ffwll.ch
BR, Jani.
-Daniel
Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch