Re: [Intel-gfx] [git pull] drm tree for 4.2
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 0x) >> >> 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 0x)" 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
Re: [Intel-gfx] [git pull] drm tree for 4.2
On Mon, 29 Jun 2015, Daniel Vetter dan...@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 conselv...@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 airl...@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 0x) 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.olive...@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.olive...@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.olive...@intel.com Reviewed-by: Damien Lespiau damien.lesp...@intel.com Reported-and-tested-by: Tvrtko Ursulin tvrtko.ursu...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@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 0x) 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.olive...@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.olive...@intel.com Reviewed-by: Maarten Lankhorst maarten.lankho...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@ffwll.ch BR, Jani. -Daniel -- Daniel Vetter
Re: [Intel-gfx] [git pull] drm tree for 4.2
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 0x) > >> 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). 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). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] drm tree for 4.2
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 0x) >> 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. BR, Jani. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] drm tree for 4.2
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 0x) > 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. Thanks, Ander -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] drm tree for 4.2
On Fri, 2015-06-26 at 14:43 -0700, Linus Torvalds wrote: On Thu, Jun 25, 2015 at 6:00 PM, Dave Airlie airl...@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 0x) 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. Thanks, Ander -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] drm tree for 4.2
On Mon, 29 Jun 2015, Ander Conselvan De Oliveira conselv...@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 airl...@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 0x) 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.olive...@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.olive...@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.olive...@intel.com Reviewed-by: Damien Lespiau damien.lesp...@intel.com Reported-and-tested-by: Tvrtko Ursulin tvrtko.ursu...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@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. BR, Jani. -- 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Intel-gfx] [git pull] drm tree for 4.2
On Mon, Jun 29, 2015 at 05:50:09PM +0300, Jani Nikula wrote: On Mon, 29 Jun 2015, Ander Conselvan De Oliveira conselv...@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 airl...@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 0x) 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.olive...@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.olive...@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.olive...@intel.com Reviewed-by: Damien Lespiau damien.lesp...@intel.com Reported-and-tested-by: Tvrtko Ursulin tvrtko.ursu...@linux.intel.com Signed-off-by: Daniel Vetter daniel.vet...@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). 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). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] drm tree for 4.2
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 0x) 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. Linus out Description: Binary data
Re: [git pull] drm tree for 4.2
On Fri, Jun 26, 2015 at 1:37 PM, Dave Airlie wrote: > > No generally Linus likes to do his own merges with hints from us. > > unless it's really tricky. Yup. And this time all the merges were trivial. My merge ended up differing from Dave's simply because of an ordering of statements that could be done in either direction, and the "natural" direction ended up depending mainly on which way the merge was done (ie me pulling Dave's tree, or Dave pulling mine). I'm running it on my machine now, just waiting for the allmodconfig build to also finish before pushing it out. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] drm tree for 4.2
On 26 June 2015 at 18:05, Christian König wrote: > Hey Dave, > > I'm not 100% sure, but didn't you wanted to send this pull request out for > drm-next-merged instead of drm-next? > > Cause I'm still getting merge conflicts when I try to merge 4.1 into > drm-next. No generally Linus likes to do his own merges with hints from us. unless it's really tricky. Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] drm tree for 4.2
On Fri, Jun 26, 2015 at 1:37 PM, Dave Airlie airl...@gmail.com wrote: No generally Linus likes to do his own merges with hints from us. unless it's really tricky. Yup. And this time all the merges were trivial. My merge ended up differing from Dave's simply because of an ordering of statements that could be done in either direction, and the natural direction ended up depending mainly on which way the merge was done (ie me pulling Dave's tree, or Dave pulling mine). I'm running it on my machine now, just waiting for the allmodconfig build to also finish before pushing it out. Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] drm tree for 4.2
On 26 June 2015 at 18:05, Christian König deathsim...@vodafone.de wrote: Hey Dave, I'm not 100% sure, but didn't you wanted to send this pull request out for drm-next-merged instead of drm-next? Cause I'm still getting merge conflicts when I try to merge 4.1 into drm-next. No generally Linus likes to do his own merges with hints from us. unless it's really tricky. Dave. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [git pull] drm tree for 4.2
On Thu, Jun 25, 2015 at 6:00 PM, Dave Airlie airl...@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 0x) 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. Linus out Description: Binary data
[git pull] drm tree for 4.2
Hi Linus, This is the main drm pull request for v4.2. I've one other new driver from freescale on my radar, it's been posted and reviewed, I'd just like to get someone to give it a last look, so maybe I'll send it or maybe I'll leave it. There is no major nouveau changes in here, Ben was working on something big, and we agreed it was a bit late, there wasn't anything else he considered urgent to merge. There might be another msm pull for some bits that are waiting on arm-soc, I'll see how we time it. I'm on holidays from middle of next week for a week, I'm sure everyone can survive without me. This touches some "of" stuff, acks are in place except for the fixes to the build in various configs,t hat I just applied. This also contains a couple of merge conflicts in radeon and i915, I've pushed a drm-next-merged branch to the same tree with them fixed up, the radeon one affects userspace API so please make sure you use the correct ordering for the two values, UNMAP is 0x25, RESET 0x26. Thanks, Dave. new drivers: virtio-gpu: KMS only pieces of driver for virtio-gpu in qemu. This is just the first part of this driver, enough to run unaccelerated userspace on. As qemu merges more we'll start adding the 3D features for the virgl 3d work. amdgpu: a new driver from AMD to driver their newer GPUs. (VI+) It contains a new cleaner userspace API, and is a clean break from radeon moving forward, that AMD are going to concentrate on. It also contains a set of register headers auto generated from AMD internal database. core: atomic modesetting API completed, enabled by default now. Add support for mode_id blob to atomic ioctl to complete interface. bunch of Displayport MST fixes lots of misc fixes. panel: new simple panels, fix some long-standing build issues with bridge drivers radeon: VCE1 support add a GPU reset counter for userspace lots of fixes. amdkfd: H/W debugger support module static user-mode queues support killing all the waves when a process terminates use standard DECLARE_BITMAP i915: Add Broxton support S3, rotation support for Skylake RPS booting tuning CPT modeset sequence fixes ns2501 dither support enable cmd parser on haswell cdclk handling fixes gen8 dynamic pte allocation lots of atomic conversion work exynos: Add atomic modesetting support Add iommu support Consolidate drm driver initialization and MIC, DECON and MIPI-DSI support for exynos5433 omapdrm: atomic modesetting support (fixes lots of things in rewrite) tegra: DP aux transaction fixes iommu support fix msm: adreno a306 support various dsi bits various 64-bit fixes NV12MT support rcar-du: atomic and misc fixes sti: fix HDMI timing complaince tilcdc: use drm component API to access tda998x driver fix module unloading qxl: stability fixes. The following changes since commit c65b99f046843d2455aa231747b5a07a999a9f3d: Linux 4.1-rc6 (2015-05-31 19:01:07 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-next for you to fetch changes up to c5fd936e992dd2829167d2adc63e151675ca6898: drm/nouveau: Pause between setting gpu to D3hot and cutting the power (2015-06-26 10:26:37 +1000) A.Sunil Kamath (3): drm/i915/bxt: Implement enable/disable for Display C9 state drm/i915/skl: Implement enable/disable for Display C5 state. Implement enable/disable for Display C6 state Alex Deucher (70): drm/radeon: implement tn_set_vce_clocks drm/radeon/dpm: add vce dpm support for TN drm/radeon/dpm: add vce support for SI drm/radeon: add support for vce 1.0 clock gating drm/radeon/tn/si: enable/disable vce cg when encoding v2 drm/radeon: make dpcd parameters const drm/radeon: take the mode_config mutex when dealing with hpds (v2) drm/radeon: clean up radeon_audio_enable drm/amdgpu: add BIF 4.1 register headers drm/amdgpu: add BIF 5.0 register headers drm/amdgpu: add BIF 5.1 register headers drm/amdgpu: add DCE 8.0 register headers drm/amdgpu: add DCE 10.0 register headers drm/amdgpu: add DCE 11.0 register headers drm/amdgpu: add GCA 7.0 register headers drm/amdgpu: add GCA 7.2 register headers drm/amdgpu: add GCA 8.0 register headers drm/amdgpu: add GMC 7.0 register headers drm/amdgpu: add GMC 7.1 register headers drm/amdgpu: add GMC 8.1 register headers drm/amdgpu: add GMC 8.2 register headers drm/amdgpu: add OSS 2.0
[git pull] drm tree for 4.2
Hi Linus, This is the main drm pull request for v4.2. I've one other new driver from freescale on my radar, it's been posted and reviewed, I'd just like to get someone to give it a last look, so maybe I'll send it or maybe I'll leave it. There is no major nouveau changes in here, Ben was working on something big, and we agreed it was a bit late, there wasn't anything else he considered urgent to merge. There might be another msm pull for some bits that are waiting on arm-soc, I'll see how we time it. I'm on holidays from middle of next week for a week, I'm sure everyone can survive without me. This touches some of stuff, acks are in place except for the fixes to the build in various configs,t hat I just applied. This also contains a couple of merge conflicts in radeon and i915, I've pushed a drm-next-merged branch to the same tree with them fixed up, the radeon one affects userspace API so please make sure you use the correct ordering for the two values, UNMAP is 0x25, RESET 0x26. Thanks, Dave. new drivers: virtio-gpu: KMS only pieces of driver for virtio-gpu in qemu. This is just the first part of this driver, enough to run unaccelerated userspace on. As qemu merges more we'll start adding the 3D features for the virgl 3d work. amdgpu: a new driver from AMD to driver their newer GPUs. (VI+) It contains a new cleaner userspace API, and is a clean break from radeon moving forward, that AMD are going to concentrate on. It also contains a set of register headers auto generated from AMD internal database. core: atomic modesetting API completed, enabled by default now. Add support for mode_id blob to atomic ioctl to complete interface. bunch of Displayport MST fixes lots of misc fixes. panel: new simple panels, fix some long-standing build issues with bridge drivers radeon: VCE1 support add a GPU reset counter for userspace lots of fixes. amdkfd: H/W debugger support module static user-mode queues support killing all the waves when a process terminates use standard DECLARE_BITMAP i915: Add Broxton support S3, rotation support for Skylake RPS booting tuning CPT modeset sequence fixes ns2501 dither support enable cmd parser on haswell cdclk handling fixes gen8 dynamic pte allocation lots of atomic conversion work exynos: Add atomic modesetting support Add iommu support Consolidate drm driver initialization and MIC, DECON and MIPI-DSI support for exynos5433 omapdrm: atomic modesetting support (fixes lots of things in rewrite) tegra: DP aux transaction fixes iommu support fix msm: adreno a306 support various dsi bits various 64-bit fixes NV12MT support rcar-du: atomic and misc fixes sti: fix HDMI timing complaince tilcdc: use drm component API to access tda998x driver fix module unloading qxl: stability fixes. The following changes since commit c65b99f046843d2455aa231747b5a07a999a9f3d: Linux 4.1-rc6 (2015-05-31 19:01:07 -0700) are available in the git repository at: git://people.freedesktop.org/~airlied/linux drm-next for you to fetch changes up to c5fd936e992dd2829167d2adc63e151675ca6898: drm/nouveau: Pause between setting gpu to D3hot and cutting the power (2015-06-26 10:26:37 +1000) A.Sunil Kamath (3): drm/i915/bxt: Implement enable/disable for Display C9 state drm/i915/skl: Implement enable/disable for Display C5 state. Implement enable/disable for Display C6 state Alex Deucher (70): drm/radeon: implement tn_set_vce_clocks drm/radeon/dpm: add vce dpm support for TN drm/radeon/dpm: add vce support for SI drm/radeon: add support for vce 1.0 clock gating drm/radeon/tn/si: enable/disable vce cg when encoding v2 drm/radeon: make dpcd parameters const drm/radeon: take the mode_config mutex when dealing with hpds (v2) drm/radeon: clean up radeon_audio_enable drm/amdgpu: add BIF 4.1 register headers drm/amdgpu: add BIF 5.0 register headers drm/amdgpu: add BIF 5.1 register headers drm/amdgpu: add DCE 8.0 register headers drm/amdgpu: add DCE 10.0 register headers drm/amdgpu: add DCE 11.0 register headers drm/amdgpu: add GCA 7.0 register headers drm/amdgpu: add GCA 7.2 register headers drm/amdgpu: add GCA 8.0 register headers drm/amdgpu: add GMC 7.0 register headers drm/amdgpu: add GMC 7.1 register headers drm/amdgpu: add GMC 8.1 register headers drm/amdgpu: add GMC 8.2 register headers drm/amdgpu: add OSS 2.0
