From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4CAD3C4363D for ; Tue, 22 Sep 2020 16:49:24 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0B66120738 for ; Tue, 22 Sep 2020 16:49:23 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0B66120738 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id C5B146E8DD; Tue, 22 Sep 2020 16:49:22 +0000 (UTC) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by gabe.freedesktop.org (Postfix) with ESMTPS id C1FEC6E8C3 for ; Tue, 22 Sep 2020 16:49:20 +0000 (UTC) IronPort-SDR: jbTW6WI0+QsF3ZWBgMACfT3GSOKfcOg2b8/uPblgOWqEFMnM7MEt2105LLh+J1ABK1AoD99t1s ok7xkJrfgoLw== X-IronPort-AV: E=McAfee;i="6000,8403,9752"; a="148409002" X-IronPort-AV: E=Sophos;i="5.77,291,1596524400"; d="scan'208";a="148409002" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Sep 2020 09:49:20 -0700 IronPort-SDR: fsIxjMW1yvqEGhDSeNOW+7OYLDc8lmJjEfR3BaPEjeFAbJAKXFUCNdLYoh61acaILJE9Xi/LtN xNFzH+RfcD8w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.77,291,1596524400"; d="scan'208";a="338344095" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by orsmga008.jf.intel.com with SMTP; 22 Sep 2020 09:49:17 -0700 Received: by stinkbox (sSMTP sendmail emulation); Tue, 22 Sep 2020 19:49:17 +0300 Date: Tue, 22 Sep 2020 19:49:17 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Imre Deak Message-ID: <20200922164917.GT6112@intel.com> References: <20200922125106.30540-1-imre.deak@intel.com> <20200922125106.30540-4-imre.deak@intel.com> <20200922132705.GS6112@intel.com> <20200922153035.GF23028@ideak-desk.fi.intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200922153035.GF23028@ideak-desk.fi.intel.com> X-Patchwork-Hint: comment User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [Intel-gfx] [PATCH 3/7] drm/i915: Simplify the link training functions X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: intel-gfx@lists.freedesktop.org Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Tue, Sep 22, 2020 at 06:30:35PM +0300, Imre Deak wrote: > On Tue, Sep 22, 2020 at 04:27:05PM +0300, Ville Syrj=E4l=E4 wrote: > > On Tue, Sep 22, 2020 at 03:51:02PM +0300, Imre Deak wrote: > > > Split the prepare, link training, fallback-handling steps into their = own > > > functions for clarity and as a preparation for the upcoming LTTPR cha= nges. > > > = > > > While at it also add some documentation to exported functions. > > > = > > > Signed-off-by: Imre Deak > > > --- > > > .../drm/i915/display/intel_dp_link_training.c | 80 ++++++++++++++---= -- > > > 1 file changed, 62 insertions(+), 18 deletions(-) > > > = > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/= drivers/gpu/drm/i915/display/intel_dp_link_training.c > > > index 6d13d00db5e6..0c3809891bd2 100644 > > > --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c > > > @@ -162,14 +162,13 @@ static bool intel_dp_link_max_vswing_reached(st= ruct intel_dp *intel_dp) > > > return true; > > > } > > > = > > > -/* Enable corresponding port and start training pattern 1 */ > > > -static bool > > > -intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp) > > > +/* > > > + * Prepare link training by configuring the link parameters and enab= ling the > > > + * corresponding port. > > > + */ > > > +static void intel_dp_prepare_link_train(struct intel_dp *intel_dp) > > > { > > > struct drm_i915_private *i915 =3D dp_to_i915(intel_dp); > > > - u8 voltage; > > > - int voltage_tries, cr_tries, max_cr_tries; > > > - bool max_vswing_reached =3D false; > > > u8 link_config[2]; > > > u8 link_bw, rate_select; > > > = > > > @@ -203,6 +202,16 @@ intel_dp_link_training_clock_recovery(struct int= el_dp *intel_dp) > > > drm_dp_dpcd_write(&intel_dp->aux, DP_DOWNSPREAD_CTRL, link_config, = 2); > > > = > > > intel_dp->DP |=3D DP_PORT_EN; > > = > > I guess we no longer actually enable the port here? The comment ^ still= says > > we do. > > = > > Hmm. Seems we do enable the port on ddi platforms, but not on older > > platforms. I guess the docs could still use a tweak to reflect > > reality a bit better. > = > Yes, missed the old platform part, will update the comment. > = > > = > > > +} > > > + > > > +/* Perform the link training clock recovery phase using training pat= tern 1. */ > > > +static bool > > > +intel_dp_link_training_clock_recovery(struct intel_dp *intel_dp) > > > +{ > > > + struct drm_i915_private *i915 =3D dp_to_i915(intel_dp); > > > + u8 voltage; > > > + int voltage_tries, cr_tries, max_cr_tries; > > > + bool max_vswing_reached =3D false; > > > = > > > /* clock recovery */ > > > if (!intel_dp_reset_link_train(intel_dp, > > > @@ -325,6 +334,10 @@ static u32 intel_dp_training_pattern(struct inte= l_dp *intel_dp) > > > return DP_TRAINING_PATTERN_2; > > > } > > > = > > > +/* > > > + * Perform the link training channel equalization phase using one of= training > > > + * pattern 2, 3 or 4 depending on the the source and sink capabiliti= es. > > > + */ > > > static bool > > > intel_dp_link_training_channel_equalization(struct intel_dp *intel_d= p) > > > { > > > @@ -395,6 +408,15 @@ intel_dp_link_training_channel_equalization(stru= ct intel_dp *intel_dp) > > > = > > > } > > > = > > > +/** > > > + * intel_dp_stop_link_train - stop link training > > > + * @intel_dp: DP struct > > > + * > > > + * Stop the link training of the @intel_dp port, programming the por= t to > > > + * output an idle pattern = > > = > > I don't think we use the idle pattern on all platforms. > = > Yes, just DDI, this also needs a doc update. > = > > BTW intel_dp_set_idle_link_train() looks pretty pointless. Could just > > inline it into its only caller, or at least move it into > > intel_dp_link_training.c. > = > Ok, can unexport/inline it. Btw, this part made me wonder what's the > exact reason for keeping the idle pattern output and corresponding DPCD > programming separate, that is why can't we disable the training pattern > in DPCD after intel_dp_set_idle_link_train()? That would make things > more uniform on all platforms. Hmm. I guess we're violating the DP spec a bit with the current sequence: "The Source device shall start sending the idle pattern after it has cleared the Training_Pattern byte in the DPCD" Currently we start sending the idle pattern way earlier. And even on platform where we don't send the idle pattern [1] we are disabling the training pattern before we do the corresponding DPCD write. So we may want to change the order to follow the spec. [1] I guess the hw must send a few idle patterns automagically since IIRC the spec requires it? -- = Ville Syrj=E4l=E4 Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx