| Summary: | [byt bisected] WARN_ON(!power_domains->domain_use_count[domain]) | ||
|---|---|---|---|
| Product: | DRI | Reporter: | Matwey V. Kornilov <matwey.kornilov> |
| Component: | DRM/Intel | Assignee: | Matwey V. Kornilov <matwey.kornilov> |
| Status: | CLOSED FIXED | QA Contact: | Intel GFX Bugs mailing list <intel-gfx-bugs> |
| Severity: | blocker | ||
| Priority: | highest | CC: | intel-gfx-bugs, patrik.r.jakobsson, tiwai, ville.syrjala |
| Version: | unspecified | Keywords: | bisected, regression |
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| See Also: |
https://bugzilla.novell.com/show_bug.cgi?id=1009674 https://bugzilla.redhat.com/show_bug.cgi?id=1335655 |
||
| Whiteboard: | |||
| i915 platform: | BYT | i915 features: | display/DP |
| Attachments: | |||
|
Description
Matwey V. Kornilov
2016-11-12 13:17:42 UTC
Created attachment 127931 [details]
hwinfo
Created attachment 127932 [details]
.config
commit a781ce79d51fc4952870c998937980a042927e84 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri Nov 27 18:55:25 2015 +0200 drm/i915: Clean up AUX power domain handling Introduce intel_display_port_aux_power_domain() which simply returns the appropriate AUX power domain for a specific port, and then replace the intel_display_port_power_domain() with calls to the new function in the DP code. As long as we're not actually enabling the port we don't need the lane power domains, and those are handled now purely from modeset_update_crtc_power_domains(). My initial motivation for this was to see if I could keep the DPIO power wells powered down while doing AUX on CHV, but turns out I can't so this doesn't change anything for CHV at least. But I think it's still a worthwile change. (In reply to Chris Wilson from comment #3) > commit a781ce79d51fc4952870c998937980a042927e84 > Author: Ville Syrjälä <ville.syrjala@linux.intel.com> > Date: Fri Nov 27 18:55:25 2015 +0200 > > drm/i915: Clean up AUX power domain handling > > Introduce intel_display_port_aux_power_domain() which simply returns > the appropriate AUX power domain for a specific port, and then replace > the intel_display_port_power_domain() with calls to the new function > in the DP code. As long as we're not actually enabling the port we don't > need the lane power domains, and those are handled now purely from > modeset_update_crtc_power_domains(). > > My initial motivation for this was to see if I could keep the DPIO power > wells powered down while doing AUX on CHV, but turns out I can't so this > doesn't change anything for CHV at least. But I think it's still a > worthwile change. Matwey, please re-test with latest drm-intel-nightly (https://cgit.freedesktop.org/drm-intel/) and confirm that is now fixed also on your side. a781ce79d51f ("drm/i915: Clean up AUX power domain handling") is the *bad* commit, not a fix.
(In reply to yann from comment #4) > (In reply to Chris Wilson from comment #3) > > commit a781ce79d51fc4952870c998937980a042927e84 > > Author: Ville Syrjälä <ville.syrjala@linux.intel.com> > > Date: Fri Nov 27 18:55:25 2015 +0200 > > > > drm/i915: Clean up AUX power domain handling > > > > Introduce intel_display_port_aux_power_domain() which simply returns > > the appropriate AUX power domain for a specific port, and then replace > > the intel_display_port_power_domain() with calls to the new function > > in the DP code. As long as we're not actually enabling the port we don't > > need the lane power domains, and those are handled now purely from > > modeset_update_crtc_power_domains(). > > > > My initial motivation for this was to see if I could keep the DPIO power > > wells powered down while doing AUX on CHV, but turns out I can't so this > > doesn't change anything for CHV at least. But I think it's still a > > worthwile change. > > Matwey, please re-test with latest drm-intel-nightly > (https://cgit.freedesktop.org/drm-intel/) and confirm that is now fixed also > on your side. Ok, I will do. Should I pay extra attention to the specific commit which you believe fix the issue. (In reply to Matwey V. Kornilov from comment #6) > (In reply to yann from comment #4) > > (In reply to Chris Wilson from comment #3) > > > commit a781ce79d51fc4952870c998937980a042927e84 > > > Author: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > Date: Fri Nov 27 18:55:25 2015 +0200 > > > > > > drm/i915: Clean up AUX power domain handling > > > > > > Introduce intel_display_port_aux_power_domain() which simply returns > > > the appropriate AUX power domain for a specific port, and then replace > > > the intel_display_port_power_domain() with calls to the new function > > > in the DP code. As long as we're not actually enabling the port we don't > > > need the lane power domains, and those are handled now purely from > > > modeset_update_crtc_power_domains(). > > > > > > My initial motivation for this was to see if I could keep the DPIO power > > > wells powered down while doing AUX on CHV, but turns out I can't so this > > > doesn't change anything for CHV at least. But I think it's still a > > > worthwile change. > > > > Matwey, please re-test with latest drm-intel-nightly > > (https://cgit.freedesktop.org/drm-intel/) and confirm that is now fixed also > > on your side. > > Ok, I will do. Should I pay extra attention to the specific commit which you > believe fix the issue. The goal is to have a version where that commit is merged. If you take latest drm-intel-nightly, for instance, you should be safe because it already merged in that branch (In reply to yann from comment #7) > (In reply to Matwey V. Kornilov from comment #6) > > (In reply to yann from comment #4) > > > (In reply to Chris Wilson from comment #3) > > > > commit a781ce79d51fc4952870c998937980a042927e84 > > > > Author: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > Date: Fri Nov 27 18:55:25 2015 +0200 > > > > > > > > drm/i915: Clean up AUX power domain handling > > > > > > > > Introduce intel_display_port_aux_power_domain() which simply returns > > > > the appropriate AUX power domain for a specific port, and then replace > > > > the intel_display_port_power_domain() with calls to the new function > > > > in the DP code. As long as we're not actually enabling the port we don't > > > > need the lane power domains, and those are handled now purely from > > > > modeset_update_crtc_power_domains(). > > > > > > > > My initial motivation for this was to see if I could keep the DPIO power > > > > wells powered down while doing AUX on CHV, but turns out I can't so this > > > > doesn't change anything for CHV at least. But I think it's still a > > > > worthwile change. > > > > > > Matwey, please re-test with latest drm-intel-nightly > > > (https://cgit.freedesktop.org/drm-intel/) and confirm that is now fixed also > > > on your side. > > > > Ok, I will do. Should I pay extra attention to the specific commit which you > > believe fix the issue. > > The goal is to have a version where that commit is merged. If you take > latest drm-intel-nightly, for instance, you should be safe because it > already merged in that branch Matwev, seeing Jani's comment #5, don't re-test since this is the commit that introduced regression (sorry my bad here). Highest+Blocker as being regression w/o workaround Does this happen with latest nightly? commit cda2d70a4395323bcf064c81ee0f89d2de015544 still does NOT work (In reply to Matwey V. Kornilov from comment #11) > commit cda2d70a4395323bcf064c81ee0f89d2de015544 still does NOT work No idea what tha commit is since I don't have it. You shouldn't refer to commits purely by their sha1 when dealing with rebasing trees. Also what does "does NOT work" mean exactly? The warning is still printed? Can you grab a full dmesg all the way from boot with drm.debug=0xe passed to the kernel, and attach it here? Created attachment 128561 [details] dmesg with drm.debug=0xe and latest drm-intel nightly https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-nightly&id=cda2d70a4395323bcf064c81ee0f89d2de015544 cda2d70a4395 ("drm-tip: 2016y-12m-19d-13h-00m-10s UTC integration manifestdrm-intel-nightly") Requested dmesg is attached. Created attachment 128568 [details]
dmesg with drm.debug=0xe and latest drm-intel nightly
I've updated dmesg. I've managed to obtain verbose version.
Created attachment 128576 [details] [review] [PATCH] drm/i915: Force VDD off on the new power seqeuencer before starting to use it The only explanation I can derive from the log is that the VDD force bit is left on by the BIOS for the other power sequencer as well. This patch should make sure our state tracking will be synced properly with that reality. Please test. (In reply to Ville Syrjala from comment #15) > Created attachment 128576 [details] [review] [review] > [PATCH] drm/i915: Force VDD off on the new power seqeuencer before starting > to use it > > The only explanation I can derive from the log is that the VDD force bit is > left on by the BIOS for the other power sequencer as well. > > This patch should make sure our state tracking will be synced properly with > that reality. Please test. Oh and I'd like to see the dmesg w/ drm.debug=0xe with that patch whether or not it fixes the problem. Created attachment 128593 [details]
dmesg for patch
The warning doesn't appear with the patch.
Attached here is dmesg.
(In reply to Matwey V. Kornilov from comment #17) > Created attachment 128593 [details] > dmesg for patch > > The warning doesn't appear with the patch. > Attached here is dmesg. [ 9.445473] [drm:vlv_detach_power_sequencer [i915]] detaching pipe B power sequencer from port C [ 9.445530] [drm:intel_enable_dp [i915]] initializing pipe A power sequencer for port C [ 9.445586] [drm:intel_dp_init_panel_power_sequencer_registers [i915]] VDD already on, disabling first [ 9.445645] [drm:intel_dp_init_panel_power_sequencer_registers [i915]] panel power sequencer register settings: PP_ON 0x87d00001, PP_OFF 0x1f40001, PP_DIV 0x270f06 Yep. So my theory was correct. Thank for testing. Fixed with commit 5d5ab2d26f32bdaa5872b938658e0bf8d341bc4c Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Tue Dec 20 18:51:17 2016 +0200 drm/i915: Force VDD off on the new power seqeuencer before starting to use it |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.