Bug 66952

Summary: [IVB Regression: Apple MacBook Pro] shared pll warning, reusing active PLL (eDP + two any pipes will cause call trace in dmesg)
Product: DRI Reporter: shui yangwei <yangweix.shui>
Component: DRM/IntelAssignee: Daniel Vetter <daniel>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: major    
Priority: medium    
Version: unspecified   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg: eDP + two any cause call trace
none
dmesg: eDP + two any cause call trace
none
sanitize shared dpll state
none
dmesg: test with patch in comment #4 on -next-queued latest none

Description shui yangwei 2013-07-16 08:46:41 UTC 
Created attachment 82471 [details]
dmesg: eDP + two any cause call  trace

Environment:
--------------------
Kernel: (drm-intel-next-queued)50b44a449ff1a19712ebc36ffccf9ac0a68033bf
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Jun 5 13:34:33 2013 +0200

    drm/i915: clear DPLL reg when disabling i9xx dplls

Good commit: 328d8e829b9a05814af4722c1091d62c5533c4f8


lspci:
--------------------
00:02.0 VGA compatible controller: Intel Corporation Device 0162 (rev 09)

Description:
--------------------
With eDP and two any pipes plugged in, there's "call trace" in dmesg when machine resumed from booting. If I plugged each pipe only, there's not this issue. Our Apple MacBook Pro support: HDMI , mini-DP-to-HDMI, mini-DP-to-VGA, mini-DP-to-DVI and mini-DP-to-DP.

Bisect is on the way, we will update the bug ASAP. This machine is not support kexec currently, we need take much more time by manual. If you have any idea about this regression, please comment. THX.

Reproduce step:
--------------------
1. plugged two any pipes in
2. reboot
3. check the dmesg when machine boot up
Comment 1 Chris Wilson 2013-07-16 09:18:44 UTC 
The complete call traces are required - just attach the full dmesg.
Comment 2 shui yangwei 2013-07-16 10:06:30 UTC 
Created attachment 82473 [details]
dmesg: eDP + two any cause call  trace

Sorry, I forget to move the filter condition when append the dmesg, now it's OK.
Comment 3 Daniel Vetter 2013-07-16 10:37:16 UTC 
Very funny, somehow pll->on is true and the dpll is even running, but no one is using it. And both the modeset state check before that modeset and at the end of that modeset seem to be completely happy with the state of affairs.

And according to the hw state readout at boot we also have no users at of those plls.

/me is completely stumped
Comment 4 Daniel Vetter 2013-07-16 10:52:54 UTC 
Created attachment 82476 [details] [review]
sanitize shared dpll state

Please test with this patch and grab a new debug dmesg. It's just a hunch that this is the bug, so the patch also contains some additional debug output in case I'm wrong.
Comment 5 shui yangwei 2013-07-17 01:34:01 UTC 
Created attachment 82516 [details]
dmesg: test with patch in comment #4 on -next-queued latest

(In reply to comment #4)
> Created attachment 82476 [details] [review] [review]
> sanitize shared dpll state
> 
> Please test with this patch and grab a new debug dmesg. It's just a hunch
> that this is the bug, so the patch also contains some additional debug
> output in case I'm wrong.

I apply this patch on latest -next-queued kernel, and this issue doesn't appear. I append the dmesg here.
Comment 6 Chris Wilson 2013-07-17 11:24:54 UTC 
commit 35c95375f69ceec721fea67a0532bc17ceb5cf64
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Wed Jul 17 06:55:04 2013 +0200

    drm/i915: Sanitize shared dpll state
Comment 7 Elizabeth 2017-10-06 14:45:03 UTC 
Closing old verified.

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.