On Mon, Aug 08, 2016 at 03:52:41PM +0300, Ville Syrjälä wrote: > On Fri, Aug 05, 2016 at 03:45:19PM -0700, Clint Taylor wrote: > > On 08/03/2016 06:36 AM, ville.syrjala@xxxxxxxxxxxxxxx wrote: > > > From: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> > > > > > > Dell UP2414Q doesn't like it when we're driving it in MST mode, and then > > > reboot the machine. After reboot, the monitor is somehow confused and > > > refuses to do the payload allocation: > > > [drm:drm_dp_mst_allocate_vcpi] initing vcpi for 282 8 > > > [drm:drm_dp_dpcd_write_payload] status not set after read payload table status 0 > > > and thus we're left with a black screen until the monitor power is > > > toggled. > > > > > > It seems that if we shut down things gracefully prior to rebooting, the > > > monitor doesn't get confused like this. So let's try to shut down all > > > the displays gracefully on reboot. The downside is that we will > > > introduce the reboot notifier to all the modesetl locks. So if there's > > > a locking bug around, we might not be able to reboot the machine > > > gracefully. sysrq reboot will still work though, as it will not > > > call the notifiers. > > > > > > While we do this, we can eliminate the eDP reboot notifier, which is > > > there to shut down the panel power and make sure the firmware won't > > > violate the panel power cycle delay post-reboot. Since we're now > > > shutting eDP down properly, we can mostly just rip out the eDP notifier. > > > We still need to do the panel power cycle wait though, as that would > > > normally get postponed until the next modeset. So let's move that part > > > into intel_panel so that other display types will get the same treatment > > > as a bonus. > > > > > > The Dell UP2414Q can often get even more confused, and sometimes what > > > you have to do is: switch to another input on the monitor, toggle the > > > monitor power, switch the input back to the original setting. And > > > sometimes it seems you just have to yank the power cable entirely. I'm > > > not sure if this reboot notifier might avoid some of these other > > > failure modes as well, but I'm pretty sure it can't hurt at least. > > > > > > > While testing this change on SKL if 2 crtc's are enabled resume from > > suspend is 500ms longer than a single crtc resume. Are we calling the > > T12 msleep(500) for non eDP panels? > > Seems unlikely, unless we misdetect DP as eDP. 500ms sure sounds a lot > for non-eDP though. You can try this patch to get easy access to the timings to see if they seem reasonable: commit 7e88e096931065efebd43d844fe3bf106932a9fa Author: David Weinehall <david.weinehall@xxxxxxxxxxxxxxx> Date: Thu Jul 21 13:36:49 2016 +0300 drm/i915/debugfs: Add panel delays for eDP The eDP backlight and panel enable/disable delays are quite useful to know when measuring time consumed by suspend/resume, and while the information are printed to the kernel log as debug messages, having this information in debugfs makes things easier. Signed-off-by: David Weinehall <david.weinehall@xxxxxxxxxxxxxxx> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index e726b02bdb5a..282d6716d012 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -5544,6 +5544,40 @@ static const struct file_operations i915_dpcd_fops = { .release = single_release, }; +static int i915_panel_show(struct seq_file *m, void *data) +{ + struct drm_connector *connector = m->private; + struct intel_dp *intel_dp = + enc_to_intel_dp(&intel_attached_encoder(connector)->base); + + if (connector->status != connector_status_connected) + return -ENODEV; + + seq_printf(m, "Panel power up delay: %d\n", + intel_dp->panel_power_up_delay); + seq_printf(m, "Panel power down delay: %d\n", + intel_dp->panel_power_down_delay); + seq_printf(m, "Backlight on delay: %d\n", + intel_dp->backlight_on_delay); + seq_printf(m, "Backlight off delay: %d\n", + intel_dp->backlight_off_delay); + + return 0; +} + +static int i915_panel_open(struct inode *inode, struct file *file) +{ + return single_open(file, i915_panel_show, inode->i_private); +} + +static const struct file_operations i915_panel_fops = { + .owner = THIS_MODULE, + .open = i915_panel_open, + .read = seq_read, + .llseek = seq_lseek, + .release = single_release, +}; + /** * i915_debugfs_connector_add - add i915 specific connector debugfs files * @connector: pointer to a registered drm_connector @@ -5563,8 +5597,12 @@ int i915_debugfs_connector_add(struct drm_connector *connector) if (connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort || connector->connector_type == DRM_MODE_CONNECTOR_eDP) - debugfs_create_file("i915_dpcd", S_IRUGO, root, connector, - &i915_dpcd_fops); + debugfs_create_file("i915_dpcd", S_IRUGO, root, + connector, &i915_dpcd_fops); + + if (connector->connector_type == DRM_MODE_CONNECTOR_eDP) + debugfs_create_file("i915_panel_timings", S_IRUGO, root, + connector, &i915_panel_fops); return 0; } _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx