[Intel-gfx] [PATCH] drm/i915: Fix DisplayPort Hotplug

Thu Feb 16 15:26:59 UTC 2017

On Wed, Feb 15, 2017 at 06:58:13PM -0800, Palmer Dabbelt wrote:
> On Tue, Feb 14, 2017 at 11:00 AM, Ville Syrjälä
> <ville.syrjala at linux.intel.com> wrote:
> > On Tue, Feb 14, 2017 at 10:48:10AM -0800, Palmer Dabbelt wrote:
> >> On Tue, 14 Feb 2017 07:01:54 PST (-0800), ville.syrjala at 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.
> >
> > That should more or less work. Well, depends on what you do in your
> > udev scripts. But that's pretty much what your typical xrandr clients
> > do, except the udev event gets first converted into a randr event by the
> > X server.
> >
> >> Is it required that
> >> I have more stuff running in order to make DPMS events work?
> >
> > Not sure what you mean by DPMS events. "xset dpms" just turns things
> > on/off, there are no events involved really.
> 
> I guess my "dpms event" I meant "the monitor going on and off".
> 
> >> 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.
> >
> > That is definitely a bug somewhere. Can you boot your machine with
> > drm.debug=0xe passed to the kernel, then reproduce this dpms problem,
> > and then post the full dmesg. Maybe the log will show something
> > interesting.
> 
> Attached.  There's two copies: one from after I boot and start X, and
> the second from after I do a DPMS cycle:
> 
>   $ xset dpms force off
>   $ sleep 10s # wait for the monitor to go to sleep
>   # press ctrl to wake the monitor back up
> 
> One item of interest: when I ran this on my work monitor (a newer Dell
> DisplayPort monitor) I didn't have any DPMS problems, but when I ran
> it on my ASUS PB287Q the monitor doesn't come back from sleep.

[   94.812227] [drm:intel_enable_pipe] enabling pipe B
[   94.812237] [drm:intel_audio_codec_enable] ELD on [CONNECTOR:45:DP-1], [ENCODER:44:DDI B]
[   94.812240] [drm:hsw_audio_codec_enable] Enable audio codec on pipe B, 36 bytes ELD
[   94.856356] [drm:verify_connector_state] [CONNECTOR:45:DP-1]
[   94.856365] [drm:intel_atomic_commit_tail] [CRTC:30:pipe B]
[   94.856377] [drm:verify_single_dpll_state.isra.113] LCPLL 2700
[   95.343061] [drm:intel_get_hpd_pins] hotplug event received, stat 0x00200000, dig 0x00101012, pins 0x00000020
[   95.343067] [drm:intel_hpd_irq_handler] digital hpd port B - long
[   95.343069] [drm:intel_hpd_irq_handler] Received HPD interrupt on PIN 5 - cnt: 0
[   95.343102] [drm:intel_dp_hpd_pulse] got hpd irq on port B - long
[   95.343108] [drm:i915_hotplug_work_func] running encoder hotplug functions
[   95.343112] [drm:i915_hotplug_work_func] Connector DP-1 (pin 5) received hotplug event.
[   95.343114] [drm:intel_dp_detect] [CONNECTOR:45:DP-1]
[   95.343130] [drm:i915_hotplug_work_func] [CONNECTOR:45:DP-1] status updated from connected to disconnected

OK so here turned on the pipe, and soon after the sink decided
to drop HPD for some reason.

[   96.545016] [drm:intel_get_hpd_pins] hotplug event received, stat 0x00200000, dig 0x00101012, pins 0x00000020
[   96.545023] [drm:intel_hpd_irq_handler] digital hpd port B - long
[   96.545026] [drm:intel_hpd_irq_handler] Received HPD interrupt on PIN 5 - cnt: 0
[   96.545059] [drm:intel_dp_hpd_pulse] got hpd irq on port B - long
[   96.545067] [drm:i915_hotplug_work_func] running encoder hotplug functions
[   96.545070] [drm:i915_hotplug_work_func] Connector DP-1 (pin 5) received hotplug event.
[   96.545076] [drm:intel_dp_detect] [CONNECTOR:45:DP-1]
[   96.546859] [drm:intel_dp_read_dpcd] DPCD: 12 14 c4 01 01 00 01 00 02 02 06 00 00 00 01
[   96.547619] [drm:intel_dp_detect] Display Port TPS3 support: source yes, sink yes
[   96.547622] [drm:intel_dp_print_rates] source rates: 162000, 270000, 540000
[   96.547624] [drm:intel_dp_print_rates] sink rates: 162000, 270000, 540000
[   96.547625] [drm:intel_dp_print_rates] common rates: 162000, 270000, 540000
[   96.549257] [drm:intel_dp_detect] Sink is not MST capable
[   96.552242] [drm:drm_dp_i2c_do_msg] native defer
[   96.553547] [drm:drm_dp_i2c_do_msg] native defer
[   96.554873] [drm:drm_dp_i2c_do_msg] native defer
[   96.556255] [drm:drm_dp_i2c_do_msg] native defer
[   96.557561] [drm:drm_dp_i2c_do_msg] native defer
[   96.558885] [drm:drm_dp_i2c_do_msg] native defer
[   96.560269] [drm:drm_dp_i2c_do_msg] native defer
[   96.561574] [drm:drm_dp_i2c_do_msg] native defer
[   96.564260] [drm:drm_dp_i2c_do_msg] native defer
[   96.565580] [drm:drm_dp_i2c_do_msg] native defer
[   96.566931] [drm:drm_dp_i2c_do_msg] native defer
[   96.568309] [drm:drm_dp_i2c_do_msg] native defer
[   96.569617] [drm:drm_dp_i2c_do_msg] native defer
[   96.570941] [drm:drm_dp_i2c_do_msg] native defer
[   96.572321] [drm:drm_dp_i2c_do_msg] native defer
[   96.573629] [drm:drm_dp_i2c_do_msg] native defer
[   96.574943] [drm:drm_detect_monitor_audio] Monitor has basic audio support
[   96.575694] [drm:i915_hotplug_work_func] [CONNECTOR:45:DP-1] status updated from disconnected to connected

And soon after it decided to reassert HPD again. I have no idea why
it's doing that. In theory your userspace scripts should have noticed
this and turned things off as soon as the HPD dropped, and then
reenabled things again. Not sure why that didn't happend, but in any
case we should still try to make sure you get a picture on your
screen even without any udev/xrandr magic. So what we need to do is
ignore the previous connector status when determining if we should
retrain the link. Patch is on the way...

I do wonder slighlty how this HPD ping pong would go over with userspace
that would actually react to the HPD dips. Would we end up in some
infinite on<->off loop or something? Hard to say.

PS. please don't drop people/ml from cc. This can be important information
    in case someone later has to revisit this code, so we want to have it
    all on record somewhere. I bounced your mail to the list now.

-- 
Ville Syrjälä
Intel OTC