From: Manasi Navare <manasi.d.navare@intel.com>
To: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>,
intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 3/4] drm/i915: Find fallback link rate/lane count
Date: Thu, 8 Dec 2016 14:05:57 -0800 [thread overview]
Message-ID: <20161208220556.GC26051@intel.com> (raw)
In-Reply-To: <871sxigkmd.fsf@intel.com>
On Thu, Dec 08, 2016 at 11:46:02PM +0200, Jani Nikula wrote:
> On Tue, 06 Dec 2016, Manasi Navare <manasi.d.navare@intel.com> wrote:
> > If link training fails, then we need to fallback to lower
> > link rate first and if link training fails at RBR, then
> > fallback to lower lane count.
> > This function finds the next lower link rate/lane count
> > value after link training failure and limits the max
> > link_rate and lane_count values to these fallback values.
> >
> > v6:
> > * Cap the max link rate and lane count to the max
> > values obtained during fallback link training (Daniel Vetter)
> > v5:
> > * Start the fallback at the lane count value passed not
> > the max lane count (Jani Nikula)
> > v4:
> > * Remove the redundant variable link_train_failed
> > v3:
> > * Remove fallback_link_rate_index variable, just obtain
> > that using the helper intel_dp_link_rate_index (Jani Nikula)
> > v2:
> > Squash the patch that returns the link rate index (Jani Nikula)
> >
> > Acked-by: Tony Cheng <tony.cheng@amd.com>
> > Acked-by: Harry Wentland <harry.wentland@amd.com>
> > Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Daniel Vetter <daniel.vetter@intel.com>
> > Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 40 ++++++++++++++++++++++++++++++++++++++++
> > drivers/gpu/drm/i915/intel_drv.h | 2 ++
> > 2 files changed, 42 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> > index 434dc7d..b5c7526f 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -278,6 +278,46 @@ static int intel_dp_common_rates(struct intel_dp *intel_dp,
> > common_rates);
> > }
> >
> > +static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
> > + int *common_rates, int link_rate)
> > +{
> > + int common_len;
> > + int index;
> > +
> > + common_len = intel_dp_common_rates(intel_dp, common_rates);
> > + for (index = 0; index < common_len; index++) {
> > + if (link_rate == common_rates[common_len - index - 1])
> > + return common_len - index - 1;
>
> Probably somewhere in the history of the patch series there was a time
> when it was necessary to search for the rates in reverse order. What
> possible benefit could that offer at this point?
>
The advantage here is that the link rate is more likely to match quicker
if we search in reverse order.
> > + }
> > +
> > + return -1;
> > +}
> > +
> > +int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> > + int link_rate, uint8_t lane_count)
> > +{
> > + int common_rates[DP_MAX_SUPPORTED_RATES] = {};
>
> No need to initialize because you initialize it a couple of lines later.
>
Agreed
> > + int common_len;
> > + int link_rate_index = -1;
>
> No need to initialize because you initialize it a couple of lines later.
>
> > +
> > + common_len = intel_dp_common_rates(intel_dp, common_rates);
> > + link_rate_index = intel_dp_link_rate_index(intel_dp,
> > + common_rates,
> > + link_rate);
>
> Please stop and think, and don't rush each new iteration of the patches.
>
> What's wrong with the above lines? Please think about it. Answer at the
> end of the mail (*).
>
> > + if (link_rate_index > 0) {
> > + intel_dp->max_sink_link_bw = drm_dp_link_rate_to_bw_code(common_rates[link_rate_index - 1]);
> > + intel_dp->max_sink_lane_count = lane_count;
> > + } else if (lane_count > 1) {
> > + intel_dp->max_sink_link_bw = intel_dp_max_link_bw(intel_dp);
> > + intel_dp->max_sink_lane_count = lane_count >> 1;
> > + } else {
> > + DRM_ERROR("Link Training Unsuccessful\n");
> > + return -1;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > static enum drm_mode_status
> > intel_dp_mode_valid(struct drm_connector *connector,
> > struct drm_display_mode *mode)
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> > index b6526ad..47e3671 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1400,6 +1400,8 @@ bool intel_dp_init_connector(struct intel_digital_port *intel_dig_port,
> > void intel_dp_set_link_params(struct intel_dp *intel_dp,
> > int link_rate, uint8_t lane_count,
> > bool link_mst);
> > +int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> > + int link_rate, uint8_t lane_count);
> > void intel_dp_start_link_train(struct intel_dp *intel_dp);
> > void intel_dp_stop_link_train(struct intel_dp *intel_dp);
> > void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
>
>
> (*) You do intel_dp_common_rates(intel_dp, common_rates) twice, for no
> reason at all.
>
Actually the first call was to obtain the common_len which was needed earlier but
we no longer need it because of the simplified fallback logic modifying the
max sink link rate directly.
So yes I will remove the first call to intel_dp_common_rate()
Good catch! Thanks Jani.
Regards
Manasi
> --
> Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2016-12-08 22:05 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-06 0:27 [PATCH 0/4] Link Training failure handling by sending Hotplug Uevent Manasi Navare
2016-12-06 0:27 ` [PATCH 1/4] drm: Add a new connector atomic property for link status Manasi Navare
2016-12-06 7:23 ` [Intel-gfx] " Daniel Vetter
2016-12-06 15:56 ` Manasi Navare
2016-12-06 16:07 ` [PATCH v4 " Manasi Navare
2016-12-08 15:05 ` Jani Nikula
2016-12-08 15:28 ` [Intel-gfx] " Daniel Vetter
2016-12-08 19:04 ` [PATCH v5 " Manasi Navare
2016-12-08 19:36 ` Sean Paul
2016-12-08 19:48 ` Manasi Navare
2016-12-08 19:47 ` [PATCH v6 " Manasi Navare
2016-12-06 0:27 ` [PATCH 2/4] drm/i915: Compute sink's max lane count/link BW at Hotplug Manasi Navare
2016-12-08 18:15 ` Manasi Navare
2016-12-08 21:23 ` Jani Nikula
2016-12-08 21:39 ` Manasi Navare
2016-12-08 21:48 ` Manasi Navare
2016-12-13 14:28 ` Jani Nikula
2016-12-06 0:27 ` [PATCH 3/4] drm/i915: Find fallback link rate/lane count Manasi Navare
2016-12-08 18:19 ` Manasi Navare
2016-12-08 21:46 ` Jani Nikula
2016-12-08 22:05 ` Manasi Navare [this message]
2016-12-09 3:05 ` [PATCH v7 " Manasi Navare
2016-12-09 9:54 ` Jani Nikula
2016-12-13 14:36 ` Jani Nikula
2016-12-06 0:27 ` [PATCH 4/4] drm/i915: Implement Link Rate fallback on Link training failure Manasi Navare
2016-12-08 18:23 ` Manasi Navare
2016-12-08 21:51 ` Jani Nikula
2016-12-08 22:09 ` Manasi Navare
2016-12-06 0:53 ` ✗ Fi.CI.BAT: failure for Link Training failure handling by sending Hotplug Uevent Patchwork
2016-12-06 16:53 ` ✗ Fi.CI.BAT: failure for Link Training failure handling by sending Hotplug Uevent (rev2) Patchwork
2016-12-08 19:53 ` ✗ Fi.CI.BAT: failure for Link Training failure handling by sending Hotplug Uevent (rev3) Patchwork
2016-12-08 20:23 ` ✗ Fi.CI.BAT: failure for Link Training failure handling by sending Hotplug Uevent (rev4) Patchwork
2016-12-09 4:23 ` ✗ Fi.CI.BAT: failure for Link Training failure handling by sending Hotplug Uevent (rev5) Patchwork
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=20161208220556.GC26051@intel.com \
--to=manasi.d.navare@intel.com \
--cc=daniel.vetter@intel.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=intel-gfx@lists.freedesktop.org \
--cc=jani.nikula@linux.intel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.