On Mon, 2011-07-25 at 23:36 -0700, Keith Packard wrote:
[PATCH 1/5] drm/i915: Use dp_detect_common in hotplug helper [PATCH 2/5] drm/i915: Rename i915_dp_detect_common to [PATCH 3/5] drm/i915: In intel_dp_init, replace read of DPCD with
These three are simple cleanups to centralize all places where the DPCD block was read from the device. Now everyone shares the same function, and that function retries the reads.
Reviewed-by: Adam Jackson ajax@redhat.com
[PATCH 4/5] drm/i915: Delay 250ms before running the hotplug code
I was experimenting with DP hotplugging -- moving the plug in and out of the jack very slowly and discovered that the hotplug interrupt occurred well before or after the link for the aux data channel was connected or disconnected. The result of this was that a sufficiently rapid cycle back through user mode could easily beat the motion of the plug and cause the hotplug detection to get the wrong status. Sticking a 250ms delay before doing anything gives the user sufficient time to actually get the plug connected or disconnected.
At the very least this should instead be queue_delayed_work(). But if we're going to delay, can we instead set up PCH_PORT_HOTPLUG to do a 100ms delay for us? I'll try this locally, at any rate.
[PATCH 5/5] drm/i915: DP_PIPE_ENABLED must check transcoder on CPT
<snip>
Turns out the bug wasn't that the mode setting code was doing it wrong and turning the DP2 output off intentionally as a part of the mode change. Instead, the intel driver was trying to adjust the PCH link for the LVDS1 output and thought it needed to turn the DP2 output off because it mistakenly believed the DP2 output was sharing the same pipe as the LVDS1 output. Just a matter of using the wrong mechanism to detect which pipe the DP2 output was connected to.
Reviewed-by: Adam Jackson ajax@redhat.com
- ajax