From: Daniel Vetter <daniel@ffwll.ch>
To: Lyude <cpaul@redhat.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
Jani Nikula <jani.nikula@linux.intel.com>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
linux-kernel@vger.kernel.org, David Airlie <airlied@redhat.com>,
Rob Clark <rclark@redhat.com>, Adam Jackson <ajax@redhat.com>
Subject: Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/skl: Don't skip mst encoders in skl_ddi_pll_select()
Date: Tue, 9 Feb 2016 10:35:37 +0100 [thread overview]
Message-ID: <20160209093537.GG11240@phenom.ffwll.local> (raw)
In-Reply-To: <1454428183-994-1-git-send-email-cpaul@redhat.com>
On Tue, Feb 02, 2016 at 10:49:43AM -0500, Lyude wrote:
> We don't actually check for INTEL_OUTPUT_DP_MST at all in here, as a
> result we skip assigning a DPLL to any DP MST ports, which makes link
> training fail:
>
> [ 1442.933896] [drm:intel_power_well_enable] enabling DDI D power well
> [ 1442.933905] [drm:skl_set_power_well] Enabling DDI D power well
> [ 1442.933957] [drm:intel_mst_pre_enable_dp] 0
> [ 1442.935474] [drm:intel_dp_set_signal_levels] Using signal levels 00000000
> [ 1442.935477] [drm:intel_dp_set_signal_levels] Using vswing level 0
> [ 1442.935480] [drm:intel_dp_set_signal_levels] Using pre-emphasis level 0
> [ 1442.936190] [drm:intel_dp_set_signal_levels] Using signal levels 05000000
> [ 1442.936193] [drm:intel_dp_set_signal_levels] Using vswing level 1
> [ 1442.936195] [drm:intel_dp_set_signal_levels] Using pre-emphasis level 1
> [ 1442.936858] [drm:intel_dp_set_signal_levels] Using signal levels 08000000
> [ 1442.936862] [drm:intel_dp_set_signal_levels] Using vswing level 2
> …
> [ 1442.998253] [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
> [ 1442.998512] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to train DP, aborting
>
> After which the pipe state goes completely out of sync:
>
> [ 70.075596] [drm:check_crtc_state] [CRTC:25]
> [ 70.075696] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in ddi_pll_sel (expected 0x00000000, found 0x00000001)
> [ 70.075747] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in shared_dpll (expected -1, found 0)
> [ 70.075798] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.ctrl1 (expected 0x00000000, found 0x00000021)
> [ 70.075840] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr1 (expected 0x00000000, found 0x80400173)
> [ 70.075884] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr2 (expected 0x00000000, found 0x000003a5)
> [ 70.075954] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in base.adjusted_mode.crtc_clock (expected 262750, found 72256)
> [ 70.075999] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in port_clock (expected 540000, found 148500)
>
> And if you're especially lucky, it keeps going downhill:
>
> [ 83.309256] Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler
> [ 83.309265]
> [ 83.309265] =================================
> [ 83.309266] [ INFO: inconsistent lock state ]
> [ 83.309267] 4.5.0-rc1Lyude-Test #265 Not tainted
> [ 83.309267] ---------------------------------
> [ 83.309268] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
> [ 83.309270] Xorg/1194 [HC0[1]:SC0[0]:HE1:SE1] takes:
> [ 83.309293] (&(&dev_priv->uncore.lock)->rlock){?.-...}, at: [<ffffffffa02a6073>] gen9_write32+0x63/0x400 [i915]
> [ 83.309293] {IN-HARDIRQ-W} state was registered at:
> [ 83.309297] [<ffffffff810e84f4>] __lock_acquire+0x9c4/0x1d00
> [ 83.309299] [<ffffffff810ea1be>] lock_acquire+0xce/0x1c0
> [ 83.309302] [<ffffffff8177d936>] _raw_spin_lock_irqsave+0x56/0x90
> [ 83.309321] [<ffffffffa02a5492>] gen9_read32+0x52/0x3d0 [i915]
> [ 83.309332] [<ffffffffa024beea>] gen8_irq_handler+0x27a/0x6a0 [i915]
> [ 83.309337] [<ffffffff810fdbc1>] handle_irq_event_percpu+0x41/0x300
> [ 83.309339] [<ffffffff810fdeb9>] handle_irq_event+0x39/0x60
> [ 83.309341] [<ffffffff811010b4>] handle_edge_irq+0x74/0x130
> [ 83.309344] [<ffffffff81009073>] handle_irq+0x73/0x120
> [ 83.309346] [<ffffffff817805f1>] do_IRQ+0x61/0x120
> [ 83.309348] [<ffffffff8177e6d6>] ret_from_intr+0x0/0x20
> [ 83.309351] [<ffffffff815f5105>] cpuidle_enter_state+0x105/0x330
> [ 83.309353] [<ffffffff815f5367>] cpuidle_enter+0x17/0x20
> [ 83.309356] [<ffffffff810dbe1a>] call_cpuidle+0x2a/0x50
> [ 83.309358] [<ffffffff810dc1dd>] cpu_startup_entry+0x26d/0x3a0
> [ 83.309360] [<ffffffff817701da>] rest_init+0x13a/0x140
> [ 83.309363] [<ffffffff81f2af8e>] start_kernel+0x475/0x482
> [ 83.309365] [<ffffffff81f2a315>] x86_64_start_reservations+0x2a/0x2c
> [ 83.309367] [<ffffffff81f2a452>] x86_64_start_kernel+0x13b/0x14a
>
> Fixes: 82d354370189 ("drm/i915/skl: Implementation of SKL DPLL programming")
> Signed-off-by: Lyude <cpaul@redhat.com>
Somehow CI is ignoring your patch, but then we don't have any dp mst skl
machines in CI anyway yet (would be obvious we'd have noticed this too).
So applied both, with cc: stable for patch 1.
Thanks, Daniel
> ---
> Changes
> * Add "Fixes" line with link to commit that introduced this problem
> * Add some stack traces to aid in future debugging and fixes
>
> drivers/gpu/drm/i915/intel_ddi.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
> index e6408e5..54a165b 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1589,7 +1589,8 @@ skl_ddi_pll_select(struct intel_crtc *intel_crtc,
> DPLL_CFGCR2_KDIV(wrpll_params.kdiv) |
> DPLL_CFGCR2_PDIV(wrpll_params.pdiv) |
> wrpll_params.central_freq;
> - } else if (intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT) {
> + } else if (intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT ||
> + intel_encoder->type == INTEL_OUTPUT_DP_MST) {
> switch (crtc_state->port_clock / 2) {
> case 81000:
> ctrl1 |= DPLL_CTRL1_LINK_RATE(DPLL_CTRL1_LINK_RATE_810, 0);
> --
> 2.5.0
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
prev parent reply other threads:[~2016-02-09 9:35 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-02 14:35 [PATCH " Lyude
2016-02-02 14:35 ` [PATCH 2/2] drm/i915/skl: Explicitly check for eDP " Lyude
2016-02-02 15:15 ` [PATCH 1/2] drm/i915/skl: Don't skip mst encoders " Jani Nikula
2016-02-02 15:49 ` [PATCH v2 " Lyude
2016-02-09 9:35 ` Daniel Vetter [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160209093537.GG11240@phenom.ffwll.local \
--to=daniel@ffwll.ch \
--cc=airlied@redhat.com \
--cc=ajax@redhat.com \
--cc=cpaul@redhat.com \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rclark@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome