Created attachment 90070 [details] dmesg after a round of s3 Environment: -------------------- Kernel: (drm-intel-nightly)013133c43b2595ad72d1c66c7afa31dca82132d4 Some additional commit info: Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Fri Nov 29 15:52:10 2013 +0100 drm-intel-nightly: 2013y-11m-29d-15h-52m-00s integration manifest Description: -------------------- On Baytrail, 3 response time of i915 init,suspend and resume are quite larger than before. It's a regression. I attach the dmesg in the attachment. The previous response time we get:(we can check it in comment 7 of bug 69250 ): Acquire initcall time: 1386 msecs Acquire suspend time: 825 msecs Acquire resume time: 767 msecs The response time I get this time is as follows: Acquire initcall time: 3084msecs Acquire suspend time: 944 msecs Acquire resume time: 1100 msecs Reproduce Steps: -------------------- 1. Rebuild kernel with option CONFIG_PM_TRACE. 2. Boot system with kernel command: initcall_debug drm.debug=0xe 3. perform a suspend-resume cycle by executing 'echo mem > /sys/power/state' 4. The dump the dmesg with the following command: dmesg | grep -i -e "i915_init\|PM:.*complete\|00:02.0+"
Just to make it clear that the BYT machine was connected with eDP monitor when I get the response time. :)
Can you please try to bisect where this regression has been introduced?
Created attachment 90341 [details] dmesg after a round of s3 with the bisected first bad commit kernel I bisected it and it say: 4aeebd7443e36b0a40032e518a9338f48bd27efc is the first bad commit commit 4aeebd7443e36b0a40032e518a9338f48bd27efc Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Oct 31 09:53:36 2013 +0100 drm/i915: dp aux irq support for g4x/vlv Now we have this everywhere. Next up would be to wire up the DP hotplug pin to speed up panel power sequencing for eDP panels ... I've decided to leave the has_aux_irq logic in the code, it should come handy for hw bringup. For testing/fail-safety the dp aux code already has a timeout when waiting for interrupts to signal completion and screams rather loud if they don't arrive in time. Given that we need a real piece of hw to talk to anyway this is probably as good as it gets. v2: Don't check the dp aux channel bits on i965 machines, they have a different meaning there. Yay for reusing bits at will! Spotted by Jani. Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> The response time of kernel builded by this commit : Initcall time: 3035 msecs Suspend time: 933 msecs Resume time: 1101 msecs
Please notice that the improvements posted on bug #72211 should also affect BYT init/suspend/resume times, but they won't fix the specific regression you reported.
Created attachment 91017 [details] dmesg of eDP responsetime I tested the BYT eDP with the tree you give in Bug 72211 Comment 7. The result is as shown below: Initcall time: 2889.186 msecs Suspend time: 376.812 msecs Resume time: 938.967 msecs
It looks like Paulo's tree improves much for eDP. What's the plan to merge?
Iirc, xrandr can be used as a test of whether the irq paths are quicker. Can you please paste the results of "time xrandr" for 4aeebd7443e36b0a40032e518a9338f48bd27efc^ 4aeebd7443e36b0a40032e518a9338f48bd27efc drm-intel-nightly on your byt. Maybe it will need a DP attached for this method to detect a difference between commits.
(In reply to comment #7) > Iirc, xrandr can be used as a test of whether the irq paths are quicker. > .... > on your byt. Maybe it will need a DP attached for this method to detect a > difference between commits.
(In reply to comment #7) When you say "between commits", do you mean between the commit 4aeebd7443e36b0a40032e518a9338f48bd27efc and the latest commit on drm-intel-nightly ? And there exits two bugs on BYT DP port(Bug 72896 and Bug 72897), the screen will become black after load I915 driver. So I want to know whether it's OK to test with eDP attached?
(In reply to comment #9) > (In reply to comment #7) > When you say "between commits", do you mean between the commit > 4aeebd7443e36b0a40032e518a9338f48bd27efc and the latest commit on > drm-intel-nightly ? Roughly. I just wanted to measure 4aeebd7443e36b0a40032e518a9338f48bd27efc and its parent (so that we can correlate how the change in xrandr corresponds to the initcall times) and then confirm the problem still exists unadulterated on drm-intel-nightly. > And there exits two bugs on BYT DP port(Bug 72896 and Bug 72897), the screen > will become black after load I915 driver. So I want to know whether it's OK > to test with eDP attached? The issue is that eDP caches its EDID upon initialisation so we cannot use xrandr to time how long it takes to read the EDID over the aux channel, and therefore we cannot use this method to measure the impact of the IRQ paths. To use eDP for this testing, you would need to also apply: diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index 885d271942b3..ab339cc63640 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -3586,6 +3586,7 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp, /* We now know it's not a ghost, init power sequence regs. */ intel_dp_init_panel_power_sequencer_registers(dev, intel_dp, power_seq); +#if 0 edid = drm_get_edid(connector, &intel_dp->adapter); if (edid) { if (drm_add_edid_modes(connector, edid)) { @@ -3599,6 +3600,9 @@ static bool intel_edp_init_connector(struct intel_dp *intel_dp, } else { edid = ERR_PTR(-ENOENT); } +#else + edid = ERR_PTR(-ENOENT); +#endif intel_connector->edid = edid; /* prefer fixed mode from EDID if available */
(In reply to comment #10) I applied you patch at the commit 4aeebd and its parents c09cd6, and got the results of "time xrandr" as follows. But the screen displayed incorrectly after boot up the patched kernels. You can check the dmesg and image of the screen in the attachment. The "time xrandr" results get at commit 4aeebd: Screen 0: minimum 320 x 200, current 1024 x 768, maximum 32767 x 32767 eDP1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x768 60.0*+ 800x600 60.3 56.2 640x480 59.9 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) real 0m0.049s user 0m0.003s sys 0m0.009s The "time xrandr" results at its parents commit c09cd6: Screen 0: minimum 320 x 200, current 1024 x 768, maximum 32767 x 32767 eDP1 connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm 1024x768 60.0*+ 800x600 60.3 56.2 640x480 59.9 VGA1 disconnected (normal left inverted right x axis y axis) HDMI1 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) VIRTUAL1 disconnected (normal left inverted right x axis y axis) real 0m0.024s user 0m0.002s sys 0m0.006s
Created attachment 92567 [details] This is the image of the incorrectly displayed screen with patched kernel
Created attachment 92568 [details] This is the dmesg got at commit 4aeebd7443e36b0a40032e518a9338f48bd27efc with patch applied
Created attachment 92569 [details] This is the dmesg got at its parent commit c09cd6e9691ec6fce8cb90b65929cad389d39c84 with patch applied
This should be fixed with commit bfbdb420f51457935784759ae5ef36b2257666a1 Author: Imre Deak <imre.deak@intel.com> Date: Thu Jan 16 19:56:53 2014 +0200 drm/i915: g4x/vlv: fix dp aux interrupt mask
Verified! I tested with latest drm-intel-nightly kernel(8f5284d0165252f41609a97acc2755234b22cf15). The response time it shows: Initcall time: 1157.943 msecs Suspend time: 383.248 msecs Resume time: 517.891 msecs
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.