All of lore.kernel.org
 help / color / mirror / Atom feed
From: Palmer Dabbelt <palmer@dabbelt.com>
To: ville.syrjala@linux.intel.com
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: Fix DisplayPort Hotplug
Date: Tue, 14 Feb 2017 10:48:10 -0800 (PST)	[thread overview]
Message-ID: <mhng-efba2280-6124-4195-9d85-da1291442f20@palmer-mbp2014> (raw)
In-Reply-To: <20170214150154.GK31595@intel.com>

On Tue, 14 Feb 2017 07:01:54 PST (-0800), ville.syrjala@linux.intel.com wrote:
> On Fri, Feb 10, 2017 at 02:44:20PM -0800, Palmer Dabbelt wrote:
>> DisplayPort no longer hotplugs on my machine (a 2014 MacBook Pro
>> attached to an ASUS PB287Q).  I believe the problem is that long pulses
>> are no longer triggering intel_dp_check_link_status.
>
> That shouldn't itsefl cause problems with hotplugs. It could cause
> problems if you hotplug displays without a proper randr client running
> in which case the link is left running when you unplug the displays and
> then gets retrained when you plug a display back in.

Maybe it's a problem with my setup, as I don't think I have any randr client
running: I just run xrandr via my xinitrc and via some scripts linked from udev
for DRM hotplug events for when I move the laptop around.  Is it required that
I have more stuff running in order to make DPMS events work?  IIRC my setup has
looked like this for years now, but if it's broken because it's wacky then I
can change it.

Regardless, I think something is still broken here.  I don't need to actaully
unplug anything for this to break, if I just run "xset dpms force off" to turn
the screen off and then wake it back up my eDP laptop display comes back fine
but my DP monitor doesn't.  I'd expect eDP and DP to behave the same here.
IIRC the link doesn't come back up even if I twiddle some xrandr stuff, but I
might getting this confused with the previous similar bug.  If you want I can
boot back into the broken kernel and run some experiments, but it'd be great if
you could suggest some for me.

> That doesn't explain why intel_dp_check_link_status() wouldn't get
> called though. It should be called via intel_dp_detect() ->
> intel_dp_long_pulse().

Sorry, I don't actually know anything about DRM so I'm not sure what's going
on.  I just generated this patch by looking at the bug from last time my DP
monitor stopped working, looking at the last few things that touched that
function, and then adding back in the thing that looks like it would make link
detection work again :).

The last time I did this I got it wrong as well -- looking at
<https://bugs.freedesktop.org/show_bug.cgi?id=89453> I see that I suggested

  diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
  index d714a4b5711e..274bd293d9e9 100644
  --- a/drivers/gpu/drm/i915/intel_dp.c
  +++ b/drivers/gpu/drm/i915/intel_dp.c
  @@ -4625,7 +4625,9 @@ static const struct drm_encoder_funcs intel_dp_enc_funcs = {
   void
   intel_dp_hot_plug(struct intel_encoder *intel_encoder)
   {
  -	return;
  +       struct intel_dp *intel_dp = enc_to_intel_dp(&intel_encoder->base);
  +
  +       intel_dp_check_link_status(intel_dp);
   }

 enum irqreturn

but the correct solution (d14e7b6d1 "drm/i915: Check DP link status on long hpd
too") was very different

  diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
  index 3781cd3..94686cb 100644
  --- a/drivers/gpu/drm/i915/intel_dp.c
  +++ b/drivers/gpu/drm/i915/intel_dp.c
  @@ -4961,9 +4961,12 @@ intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)

                  intel_dp_probe_oui(intel_dp);

  -               if (!intel_dp_probe_mst(intel_dp))
  +               if (!intel_dp_probe_mst(intel_dp)) {
  +                       drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
  +                       intel_dp_check_link_status(intel_dp);
  +                       drm_modeset_unlock(&dev->mode_config.connection_mutex);
                          goto mst_fail;
  -
  +               }

my fix for this new bug (which might just be another workaround) was copied
from the correct fix from last time.

>
>> I bisected the
>> problem down to (7d23e3c37 "drm/i915: Cleaning up intel_dp_hpd_pulse")
>> and it appears the only material change there was to remove one of those
>> calls.
>>
>> This commit adds the check_link_status call back in, which causes hotplug to
>> work again for me.  I test this via a "xset dpms force off".  Note that this is
>> very similar to <https://bugs.freedesktop.org/show_bug.cgi?id=89453>, but it's
>> back again.
>>
>> I've tested this against 4.9, and it applies against the current head.
>>
>> See <https://bugs.freedesktop.org/show_bug.cgi?id=99766>.
>>
>> Here's the commit that triggered the regression:
>>
>> commit 7d23e3c37bb3fc6952dc84007ee60cb533fd2d5c
>> Author: Shubhangi Shrivastava <shubhangi.shrivastava@intel.com>
>> Date:   Wed Mar 30 18:05:23 2016 +0530
>>
>>     drm/i915: Cleaning up intel_dp_hpd_pulse
>>
>>     Current DP detection has DPCD operations split across
>>     intel_dp_hpd_pulse and intel_dp_detect which contains
>>     duplicates as well. Also intel_dp_detect is called
>>     during modes enumeration as well which will result
>>     in multiple dpcd operations. So this patch tries
>>     to solve both these by bringing all DPCD operations
>>     in one single function and make intel_dp_detect
>>     use existing values instead of repeating same steps.
>>
>> Signed-off-by: Palmer Dabbelt <palmer@dabbelt.com>
>> ---
>>  drivers/gpu/drm/i915/intel_dp.c | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
>> index 0b8e8eb..32ca4be 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -4831,6 +4831,10 @@ intel_dp_hpd_pulse(struct intel_digital_port *intel_dig_port, bool long_hpd)
>>  		      long_hpd ? "long" : "short");
>>
>>  	if (long_hpd) {
>> +		drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
>> +		intel_dp_check_link_status(intel_dp);
>> +		drm_modeset_unlock(&dev->mode_config.connection_mutex);
>> +
>>  		intel_dp->detect_done = false;
>>  		return IRQ_NONE;
>>  	}
>> --
>> 2.10.2
>>
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-02-14 18:48 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-10 22:44 [PATCH] drm/i915: Fix DisplayPort Hotplug Palmer Dabbelt
2017-02-14  8:22 ` ✗ Fi.CI.BAT: warning for " Patchwork
2017-02-14  8:54   ` Saarinen, Jani
2017-02-14 15:01 ` [PATCH] " Ville Syrjälä
2017-02-14 18:48   ` Palmer Dabbelt [this message]
2017-02-14 19:00     ` Ville Syrjälä
2017-02-16  2:58       ` Palmer Dabbelt
2017-02-16 15:26         ` Ville Syrjälä
2017-02-16 15:30           ` [PATCH] drm/i915: Perform link quality check unconditionally during long pulse ville.syrjala
2017-02-16 15:30             ` ville.syrjala
2017-02-16 15:39             ` Palmer Dabbelt
2017-02-16 15:39               ` Palmer Dabbelt
2017-02-16 15:49               ` Ville Syrjälä
2017-02-16 15:49                 ` Ville Syrjälä
2017-02-16 17:07             ` [Intel-gfx] " Manasi Navare
2017-02-16 17:07               ` Manasi Navare
2017-02-16 17:18               ` Ville Syrjälä
2017-02-16 17:18                 ` Ville Syrjälä
2017-02-16 17:24                 ` [Intel-gfx] " Manasi Navare
2017-02-16 17:24                   ` Manasi Navare
2017-02-16 17:46                   ` [Intel-gfx] " Ville Syrjälä
2017-02-16 17:46                     ` Ville Syrjälä
2017-02-23  4:00                     ` [Intel-gfx] " Palmer Dabbelt
2017-02-23  4:00                       ` Palmer Dabbelt
2017-02-23  9:22                       ` [Intel-gfx] " Ville Syrjälä
2017-02-23  9:22                         ` Ville Syrjälä
2017-03-13 20:53             ` [PATCH v2] " ville.syrjala
2017-03-13 20:53               ` ville.syrjala
2017-03-13 21:20               ` [Intel-gfx] " Chris Wilson
2017-03-13 21:20                 ` Chris Wilson
2017-03-13 23:09               ` Manasi Navare
2017-03-13 23:09                 ` Manasi Navare
2017-03-14 10:15                 ` Ville Syrjälä
2017-03-14 10:15                   ` Ville Syrjälä
2017-04-12 19:30             ` [PATCH v3] " ville.syrjala
2017-04-12 19:30               ` ville.syrjala
2017-04-13 12:27               ` Ville Syrjälä
2017-04-13 12:27                 ` Ville Syrjälä
2017-02-16 19:52 ` ✓ Fi.CI.BAT: success for drm/i915: Fix DisplayPort Hotplug (rev2) Patchwork
2017-03-13 21:47 ` ✓ Fi.CI.BAT: success for drm/i915: Fix DisplayPort Hotplug (rev3) Patchwork
2017-04-12 19:47 ` ✓ Fi.CI.BAT: success for drm/i915: Fix DisplayPort Hotplug (rev4) Patchwork

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=mhng-efba2280-6124-4195-9d85-da1291442f20@palmer-mbp2014 \
    --to=palmer@dabbelt.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@linux.intel.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.