Bug 72210

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.