The mysterious case of IRQs, failed DP aux ch transactions, and Skylake

The mysterious case of IRQs, failed DP aux ch transactions, and Skylake

[Lyude]

Hi! Daniel Vetter referred me to you since you're a hardware guy, and
also suggested I include the whole intel-gfx list on this.

So as of late I've been testing the mainline kernel on some new
production Skylake machines. While it worked perfectly on most of them,
I've been stumped with a weird issue that arose with a Lenovo ThinkPad
T560. If I place the laptop in a dock, suspend it, and then resume it,
monitors connected to the dock don't come back up on resume. It should
be noted that these docks use DP MST for all of the monitor connections
they have, so it's basically just an MST hub. As far as I can tell, it
looks like this only occurs while using the dock. Using normal MST
monitors doesn't show this issue.

After doing some investigation, I managed to find where the problem
starts. So, the main functions of concern in the driver when it comes
to resume are i915_drm_resume_early() and i915_drm_resume(). The
problem starts in the latter function, where we reenable interrupts for
the GPU by calling intel_runtime_pm_enable_interrupts(). If we go down
a little further, the exact line where the problem starts is
drivers/gpu/drm/i915/i915_irq.c:3756:

	I915_WRITE(GEN8_MASTER_IRQ, DE_MASTER_IRQ_CONTROL);
	POSTING_READ(GEN8_MASTER_IRQ);

Simple explanation: this writes to the master IRQ control register and
toggles bit 31 to on, the bit that enables/disables all interrupts on
the GPU. So this is where things get weird: if we start resuming DP MST
before doing this single register write (by calling
intel_dp_mst_resume()), everything works perfectly and the screen turns
back on. If we try resuming DP MST after this register write, all of
the DP aux transactions timeout according to the hardware:

[   23.928507] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[   23.938506] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[   23.948587] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
[   24.006942] [drm:drm_dp_check_act_status] failed to get ACT bit 1 after 30 retries

It looks like what happens is that after doing this register write, we
become unable to successfully do any DP aux transactions for about 15-
20 msec. After that time passes, everything goes back to normal and DP
aux works fine again. In fact, if we just wait for 15 msec before
trying to resume DP MST, the monitors come on perfectly as a result.
While I'd love to just have a fix as simple as that, unfortunately we'd
like to know what's actually causing this to happen. What's strange is
that it doesn't seem like we actually get any interrupts from the GPU
during that 15-20 msec duration where DP aux stops working, since I
don't see our IRQ handler for i915 getting called at all during that
time. Daniel Vetter has suggested it might be the DMC firmware doing
aux transactions using the PSR block, resulting in the bus being busy,
but preventing the firmware for the DMC from being loaded at all
doesn't seem to make a difference.

Hopefully as a hardware guy you might be able to give us some insight
as to what's going on. If anyone notices I've missed any important
details about this, feel free to reply and mention them. Thanks ahead
of time for the help.


-- 
Cheers,
	Lyude

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: The mysterious case of IRQs, failed DP aux ch transactions, and Skylake

[Runyan, Arthur J]

Hi Lyude,
I like mysteries, but DP and docks usually ends up as a sob story.

The master interrupt control doesn't have any hardware connection to DP aux.  I don't know how much confidence you have in the IRQ check, but it seems likely that an interrupt, probably hotplug, triggered programming to mess up aux.

PSR is a concern, but even that would only block 1 transaction on eDP aux, and here you must be using a non-eDP port. 

During the 15msec, check the PWR_WELL_CTL Misc IO Power Request.  That needs to be enabled to supply power to DP aux. 

Also your DDI_AUX_CTL value, 0x7d40001f, looks wrong since the Fast Wake Sync Pulse Count is zeroed out.  Check what value it uses after 15msec when aux is working. 


>-----Original Message-----
>From: Lyude [mailto:cpaul@redhat.com]
>Sent: Tuesday, March 01, 2016 9:15 AM
>To: Runyan, Arthur J
>Cc: intel-gfx@lists.freedesktop.org; Vetter, Daniel; David Airlie; Rob Clark
>Subject: The mysterious case of IRQs, failed DP aux ch transactions, and Skylake
>
>Hi! Daniel Vetter referred me to you since you're a hardware guy, and
>also suggested I include the whole intel-gfx list on this.
>
>So as of late I've been testing the mainline kernel on some new
>production Skylake machines. While it worked perfectly on most of them,
>I've been stumped with a weird issue that arose with a Lenovo ThinkPad
>T560. If I place the laptop in a dock, suspend it, and then resume it,
>monitors connected to the dock don't come back up on resume. It should
>be noted that these docks use DP MST for all of the monitor connections
>they have, so it's basically just an MST hub. As far as I can tell, it
>looks like this only occurs while using the dock. Using normal MST
>monitors doesn't show this issue.
>
>After doing some investigation, I managed to find where the problem
>starts. So, the main functions of concern in the driver when it comes
>to resume are i915_drm_resume_early() and i915_drm_resume(). The
>problem starts in the latter function, where we reenable interrupts for
>the GPU by calling intel_runtime_pm_enable_interrupts(). If we go down
>a little further, the exact line where the problem starts is
>drivers/gpu/drm/i915/i915_irq.c:3756:
>
>	I915_WRITE(GEN8_MASTER_IRQ, DE_MASTER_IRQ_CONTROL);
>	POSTING_READ(GEN8_MASTER_IRQ);
>
>Simple explanation: this writes to the master IRQ control register and
>toggles bit 31 to on, the bit that enables/disables all interrupts on
>the GPU. So this is where things get weird: if we start resuming DP MST
>before doing this single register write (by calling
>intel_dp_mst_resume()), everything works perfectly and the screen turns
>back on. If we try resuming DP MST after this register write, all of
>the DP aux transactions timeout according to the hardware:
>
>[   23.928507] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
>[   23.938506] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
>[   23.948587] [drm:intel_dp_aux_ch] dp_aux_ch timeout status 0x7d40001f
>[   24.006942] [drm:drm_dp_check_act_status] failed to get ACT bit 1 after 30
>retries
>
>It looks like what happens is that after doing this register write, we
>become unable to successfully do any DP aux transactions for about 15-
>20 msec. After that time passes, everything goes back to normal and DP
>aux works fine again. In fact, if we just wait for 15 msec before
>trying to resume DP MST, the monitors come on perfectly as a result.
>While I'd love to just have a fix as simple as that, unfortunately we'd
>like to know what's actually causing this to happen. What's strange is
>that it doesn't seem like we actually get any interrupts from the GPU
>during that 15-20 msec duration where DP aux stops working, since I
>don't see our IRQ handler for i915 getting called at all during that
>time. Daniel Vetter has suggested it might be the DMC firmware doing
>aux transactions using the PSR block, resulting in the bus being busy,
>but preventing the firmware for the DMC from being loaded at all
>doesn't seem to make a difference.
>
>Hopefully as a hardware guy you might be able to give us some insight
>as to what's going on. If anyone notices I've missed any important
>details about this, feel free to reply and mention them. Thanks ahead
>of time for the help.
>
>
>--
>Cheers,
>	Lyude

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx