| Message ID | 1477057478-29328-1-git-send-email-ville.syrjala@linux.intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, Oct 21, 2016 at 04:44:38PM +0300, ville.syrjala@linux.intel.com wrote: > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > Once we've determined that the sink is MST capable we never end up > running through the full detect cycle again, despite getting HPDs. > Fix tht by ripping out the incorrect piece of code responsible. Ah, the missing magic is the call to intel_dp_configure_mst() right? With that understood, Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> -Chris
On Fri, Oct 21, 2016 at 04:46:38PM +0100, Chris Wilson wrote: > On Fri, Oct 21, 2016 at 04:44:38PM +0300, ville.syrjala@linux.intel.com wrote: > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > Once we've determined that the sink is MST capable we never end up > > running through the full detect cycle again, despite getting HPDs. > > Fix tht by ripping out the incorrect piece of code responsible. > > Ah, the missing magic is the call to intel_dp_configure_mst() right? Yeah, if the cable is still physically connected we do that. And if not we'll take the earlier way out to inform the topology manager that we're no longer doing MST. > > With that understood, > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre
On Fri, Oct 21, 2016 at 02:17:00PM -0000, Patchwork wrote: > == Series Details == > > Series: drm/i915: Refresh that status of MST capable connectors in ->detect() > URL : https://patchwork.freedesktop.org/series/14163/ > State : failure > > == Summary == > > Series 14163v1 drm/i915: Refresh that status of MST capable connectors in ->detect() > https://patchwork.freedesktop.org/api/1.0/series/14163/revisions/1/mbox/ > > Test drv_module_reload_basic: > pass -> DMESG-WARN (fi-skl-6700hq) > pass -> DMESG-WARN (fi-skl-6770hq) > Test gem_busy: > Subgroup basic-hang-default: > pass -> DMESG-FAIL (fi-hsw-4770r) [ 109.661910] INFO: rcu_preempt detected stalls on CPUs/tasks: [ 109.661934] 0-...: (4 GPs behind) idle=604/0/0 softirq=6034/6034 fqs=0 [ 109.661953] 1-...: (2 GPs behind) idle=796/0/0 softirq=6234/6234 fqs=0 [ 109.661971] 3-...: (9 GPs behind) idle=1e4/0/0 softirq=6061/6061 fqs=0 [ 109.661989] 5-...: (1 GPs behind) idle=14a/0/0 softirq=6301/6302 fqs=0 [ 109.662007] 7-...: (0 ticks this GP) idle=9cc/0/0 softirq=6015/6015 fqs=0 [ 109.662024] (detected by 2, t=65002 jiffies, g=2664, c=2663, q=271) [ 109.662047] 0000000000000020 ffffffff81e03e50 ffffffff8144d307 ffffffff81e03e80 [ 109.662049] ffffffff81815371 0000000000000004 ffffffff81ebbfe0 ffff88011ea22490 [ 109.662050] ffffffff81ebc178 ffffffff81e03ec8 ffffffff816af155 00000000000138c2 [ 109.662052] Call Trace: [ 109.662057] [<ffffffff8144d307>] ? debug_smp_processor_id+0x17/0x20 [ 109.662059] [<ffffffff81815371>] ? intel_idle+0x101/0x106 [ 109.662061] [<ffffffff816af155>] ? cpuidle_enter_state+0xf5/0x380 [ 109.662062] [<ffffffff816af402>] ? cpuidle_enter+0x12/0x20 [ 109.662064] [<ffffffff810cbd2e>] ? call_cpuidle+0x1e/0x40 [ 109.662065] [<ffffffff810cbf4b>] ? cpu_startup_entry+0x10b/0x1f0 [ 109.662067] [<ffffffff8180cc47>] ? rest_init+0x127/0x130 [ 109.662070] [<ffffffff81f77f08>] ? start_kernel+0x3f6/0x403 [ 109.662072] [<ffffffff81f7728f>] ? x86_64_start_reservations+0x2a/0x2c [ 109.662074] [<ffffffff81f77404>] ? x86_64_start_kernel+0x173/0x186 ... Not sure what that was about. I don't think HSW has been show to suffer from the "GPU hogs the bus when it hangs in a bad way" type of think we'd seen with SNB/IVB? > Test gem_exec_suspend: > Subgroup basic-s3: > dmesg-warn -> PASS (fi-skl-6700hq) > Test kms_flip: > Subgroup basic-flip-vs-dpms: > pass -> DMESG-WARN (fi-skl-6770hq) [ 316.343964] [drm:skl_set_cdclk [i915]] *ERROR* failed to inform PCU about cdclk change https://bugs.freedesktop.org/show_bug.cgi?id=97929 > Test kms_force_connector_basic: > Subgroup force-load-detect: > pass -> DMESG-WARN (fi-ivb-3770) [ 343.433798] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 181 https://bugs.freedesktop.org/show_bug.cgi?id=98228 > Test kms_pipe_crc_basic: > Subgroup suspend-read-crc-pipe-a: > dmesg-warn -> PASS (fi-skl-6700hq) > Subgroup suspend-read-crc-pipe-b: > dmesg-warn -> PASS (fi-skl-6700hq) > Subgroup suspend-read-crc-pipe-c: > dmesg-warn -> PASS (fi-skl-6700hq) > > fi-bdw-5557u total:246 pass:231 dwarn:0 dfail:0 fail:0 skip:15 > fi-bsw-n3050 total:246 pass:204 dwarn:0 dfail:0 fail:0 skip:42 > fi-bxt-t5700 total:246 pass:216 dwarn:0 dfail:0 fail:0 skip:30 > fi-byt-j1900 total:246 pass:215 dwarn:0 dfail:0 fail:0 skip:31 > fi-byt-n2820 total:246 pass:211 dwarn:0 dfail:0 fail:0 skip:35 > fi-hsw-4770 total:246 pass:224 dwarn:0 dfail:0 fail:0 skip:22 > fi-hsw-4770r total:246 pass:223 dwarn:0 dfail:1 fail:0 skip:22 > fi-ilk-650 total:246 pass:185 dwarn:0 dfail:0 fail:1 skip:60 > fi-ivb-3520m total:246 pass:221 dwarn:0 dfail:0 fail:0 skip:25 > fi-ivb-3770 total:246 pass:220 dwarn:1 dfail:0 fail:0 skip:25 > fi-kbl-7200u total:246 pass:222 dwarn:0 dfail:0 fail:0 skip:24 > fi-skl-6260u total:246 pass:232 dwarn:0 dfail:0 fail:0 skip:14 > fi-skl-6700hq total:246 pass:222 dwarn:1 dfail:0 fail:0 skip:23 > fi-skl-6700k total:246 pass:222 dwarn:1 dfail:0 fail:0 skip:23 > fi-skl-6770hq total:246 pass:229 dwarn:3 dfail:0 fail:0 skip:14 > fi-snb-2520m total:246 pass:210 dwarn:0 dfail:0 fail:0 skip:36 > fi-snb-2600 total:246 pass:209 dwarn:0 dfail:0 fail:0 skip:37 > > Results at /archive/results/CI_IGT_test/Patchwork_2787/ > > 0af2197c61d3de189a02e400fb9cb8a900361b18 drm-intel-nightly: 2016y-10m-21d-13h-15m-26s UTC integration manifest > 1008dc0 drm/i915: Refresh that status of MST capable connectors in ->detect()
On Fri, Oct 21, 2016 at 04:46:38PM +0100, Chris Wilson wrote: > On Fri, Oct 21, 2016 at 04:44:38PM +0300, ville.syrjala@linux.intel.com wrote: > > From: Ville Syrjälä <ville.syrjala@linux.intel.com> > > > > Once we've determined that the sink is MST capable we never end up > > running through the full detect cycle again, despite getting HPDs. > > Fix tht by ripping out the incorrect piece of code responsible. > > Ah, the missing magic is the call to intel_dp_configure_mst() right? > > With that understood, > Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Pushed to dinq. Thanks for the review. > -Chris > > -- > Chris Wilson, Intel Open Source Technology Centre
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c index f30db8f2425e..80db8a3ac38f 100644 --- a/drivers/gpu/drm/i915/intel_dp.c +++ b/drivers/gpu/drm/i915/intel_dp.c @@ -4492,21 +4492,11 @@ static enum drm_connector_status intel_dp_detect(struct drm_connector *connector, bool force) { struct intel_dp *intel_dp = intel_attached_dp(connector); - struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp); - struct intel_encoder *intel_encoder = &intel_dig_port->base; enum drm_connector_status status = connector->status; DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n", connector->base.id, connector->name); - if (intel_dp->is_mst) { - /* MST devices are disconnected from a monitor POV */ - intel_dp_unset_edid(intel_dp); - if (intel_encoder->type != INTEL_OUTPUT_EDP) - intel_encoder->type = INTEL_OUTPUT_DP; - return connector_status_disconnected; - } - /* If full detect is not performed yet, do a full detect */ if (!intel_dp->detect_done) status = intel_dp_long_pulse(intel_dp->attached_connector);