From: "Thulasimani, Sivakumar" <sivakumar.thulasimani@intel.com>
To: Lyude <cpaul@redhat.com>, intel-gfx@lists.freedesktop.org
Cc: David Airlie <airlied@linux.ie>,
Daniel Vetter <daniel.vetter@intel.com>,
"open list:INTEL DRM DRIVERS excluding Poulsbo, Moorestow...,
linux-kernel@vger.kernel.org open list"
<dri-devel@lists.freedesktop.org>,
stable@vger.kernel.org
Subject: Re: [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting
Date: Wed, 24 Feb 2016 08:03:04 +0530 [thread overview]
Message-ID: <56CD1660.2030203@intel.com> (raw)
In-Reply-To: <1456265512-15670-1-git-send-email-cpaul@redhat.com>
On 2/24/2016 3:41 AM, Lyude wrote:
> As it turns out, resuming DP MST is racey since we don't make sure MST
> is ready before we start modesetting, it just usually happens to be
> ready in time. This isn't the case on all systems, particularly a
> ThinkPad T560 with displays connected through the dock. On these
> systems, resuming the laptop while connected to the dock usually results
> in blank monitors. Making sure MST is ready before doing any kind of
> modesetting fixes this issue.
basic question since i haven't worked on MST much. MST should work like any
other digital panel on resume. i.e detect followed by modeset. in the
modified
commit mentioned below is it failing to detect the panel or failing at
the modeset ?
if we are depending on the intel_display_resume, how about moving the
intel_dp_mst_resume just above intel_display_resume?
Generic question to others in mail list on i915_drm_resume
we are doing a modeset and then doing the detect/hpd init.
shouldn't this be the other way round ? almost all displays
will pass a modeset even if display is not connected so we
are spending time on modeset even for displays that were
removed during the suspend state. if this is to simply
drm_state being saved and restored,
> We originally changed the resume order in
>
> commit e7d6f7d70829 ("drm/i915: resume MST after reading back hw state")
>
> to fix a ton of WARN_ON's after resume, but this doesn't seem to be an
> issue now anyhow.
>
> CC: stable@vger.kernel.org
> Signed-off-by: Lyude <cpaul@redhat.com>
> ---
> drivers/gpu/drm/i915/i915_drv.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index f357058..4dcf3dd 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -733,6 +733,14 @@ static int i915_drm_resume(struct drm_device *dev)
> intel_opregion_setup(dev);
>
> intel_init_pch_refclk(dev);
> +
> + /*
> + * We need to make sure that we resume MST before doing anything
> + * display related, otherwise we risk trying to bring up a display on
> + * MST before the hub is actually ready
> + */
> + intel_dp_mst_resume(dev);
> +
This does not look proper. if the CD clock is turned off during suspend
our dpcd read itself might fail till we enable CD Clock.
regards,
Sivakumar
> drm_mode_config_reset(dev);
>
> /*
> @@ -765,8 +773,6 @@ static int i915_drm_resume(struct drm_device *dev)
> intel_display_resume(dev);
> drm_modeset_unlock_all(dev);
>
> - intel_dp_mst_resume(dev);
> -
> /*
> * ... but also need to make sure that hotplug processing
> * doesn't cause havoc. Like in the driver load code we don't
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-02-24 2:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-23 22:11 [PATCH] drm/i915: Resume DP MST before doing any kind of modesetting Lyude
2016-02-24 2:33 ` Thulasimani, Sivakumar [this message]
2016-02-25 15:09 ` [Intel-gfx] " Lyude Paul
2016-02-25 21:05 ` Rob Clark
2016-02-29 16:12 ` Daniel Vetter
2016-02-29 21:33 ` [Intel-gfx] " Dave Airlie
2016-03-02 9:27 ` Daniel Vetter
2016-02-29 23:33 ` Rob Clark
2016-03-01 0:47 ` Thulasimani, Sivakumar
2016-03-01 1:38 ` Rob Clark
2016-03-02 9:31 ` Daniel Vetter
2016-03-02 9:29 ` Daniel Vetter
2016-03-02 15:28 ` Rob Clark
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56CD1660.2030203@intel.com \
--to=sivakumar.thulasimani@intel.com \
--cc=airlied@linux.ie \
--cc=cpaul@redhat.com \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).