There may be more to this issue. From the logs, it looks like the dock is an actual sink / active adapter, supporting 1.2 compliance, HBR2, etc. The monitor, when plugged into this port, is listed as a downstream branch device. The DPCD for the sink device in the dock is this:
[ 26.257557] [drm:intel_dp_get_dpcd], DPCD: 12 14 c4 01 00 15 01 83 02 00 00 00 00 00 04
And the DPCD from the monitor is this:
[ 26.397960] [drm:intel_dp_get_dpcd], DPCD: 11 0a 84 01 01 00 00 00 00 00 00 00 00 00 00
Clearly two different devices. The sink in the middle and the monitor being the branch device may explain why increasing the timeout value appears to alleviate this issue. I'm going to go look into how we handle branch devices and see what I can find in there. In the meantime, to implement the 500us workaround in a patch, I'll see if I can key off the DPCD value and only use 500us when a downstream port is present. That should prevent any issues when working with normal (non-branch) devices.
There may be more to this issue. From the logs, it looks like the dock is an actual sink / active adapter, supporting 1.2 compliance, HBR2, etc. The monitor, when plugged into this port, is listed as a downstream branch device. The DPCD for the sink device in the dock is this: dp_get_ dpcd], DPCD: 12 14 c4 01 00 15 01 83 02 00 00 00 00 00 04 dp_get_ dpcd], DPCD: 11 0a 84 01 01 00 00 00 00 00 00 00 00 00 00
[ 26.257557] [drm:intel_
And the DPCD from the monitor is this:
[ 26.397960] [drm:intel_
Clearly two different devices. The sink in the middle and the monitor being the branch device may explain why increasing the timeout value appears to alleviate this issue. I'm going to go look into how we handle branch devices and see what I can find in there. In the meantime, to implement the 500us workaround in a patch, I'll see if I can key off the DPCD value and only use 500us when a downstream port is present. That should prevent any issues when working with normal (non-branch) devices.
-T