Bug 72210

Summary: [Regression BYT] S3 response time large than before
Product: DRI Reporter: Qingshuai Tian <qingshuai.tian>
Component: DRM/IntelAssignee: Daniel Vetter <daniel>
Status: CLOSED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: normal    
Priority: high CC: intel-gfx-bugs, przanoni
Version: unspecified   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
dmesg after a round of s3
none
dmesg after a round of s3 with the bisected first bad commit kernel
none
dmesg of eDP responsetime
none
This is the image of the incorrectly displayed screen with patched kernel
none
This is the dmesg got at commit 4aeebd7443e36b0a40032e518a9338f48bd27efc with patch applied
none
This is the dmesg got at its parent commit c09cd6e9691ec6fce8cb90b65929cad389d39c84 with patch applied none

Description Qingshuai Tian 2013-12-02 02:48:36 UTC
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+"
Comment 1 Qingshuai Tian 2013-12-02 02:56:07 UTC
Just to make it clear that the BYT machine was connected with eDP monitor when I get the response time.  :)
Comment 2 Daniel Vetter 2013-12-03 17:28:00 UTC
Can you please try to bisect where this regression has been introduced?
Comment 3 Qingshuai Tian 2013-12-06 08:44:39 UTC
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
Comment 4 Paulo Zanoni 2013-12-17 14:00:07 UTC
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.
Comment 5 Qingshuai Tian 2013-12-20 03:06:14 UTC
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
Comment 6 Gordon Jin 2014-01-17 05:53:45 UTC
It looks like Paulo's tree improves much for eDP. What's the plan to merge?
Comment 7 Chris Wilson 2014-01-17 18:58:17 UTC
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.
Comment 8 Qingshuai Tian 2014-01-20 05:12:31 UTC
(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.
Comment 9 Qingshuai Tian 2014-01-20 05:30:33 UTC
(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?
Comment 10 Chris Wilson 2014-01-20 12:43:47 UTC
(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 */
Comment 11 Qingshuai Tian 2014-01-22 07:56:14 UTC
(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
Comment 12 Qingshuai Tian 2014-01-22 08:00:09 UTC
Created attachment 92567 [details]
This is the image of the incorrectly displayed screen with patched kernel
Comment 13 Qingshuai Tian 2014-01-22 08:05:32 UTC
Created attachment 92568 [details]
This is the dmesg got at commit 4aeebd7443e36b0a40032e518a9338f48bd27efc with patch applied
Comment 14 Qingshuai Tian 2014-01-22 08:07:09 UTC
Created attachment 92569 [details]
This is the dmesg got at its parent commit c09cd6e9691ec6fce8cb90b65929cad389d39c84 with patch applied
Comment 15 Daniel Vetter 2014-01-27 07:50:01 UTC
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
Comment 16 Qingshuai Tian 2014-02-10 07:32:28 UTC
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
Comment 17 Elizabeth 2017-10-06 14:41:44 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.