All of lore.kernel.org
 help / color / mirror / Atom feed
From: Manasi Navare <manasi.d.navare@intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	intel-gfx@lists.freedesktop.org, Dave Airlie <airlied@redhat.com>
Subject: Re: [PATCH] drm/i915/edp: Do not do link training fallback or prune modes on EDP
Date: Thu, 12 Oct 2017 12:05:45 -0700	[thread overview]
Message-ID: <20171012190545.GB2421@intel.com> (raw)
In-Reply-To: <20171012173710.GR10981@intel.com>

On Thu, Oct 12, 2017 at 08:37:10PM +0300, Ville Syrjälä wrote:
> On Wed, Oct 11, 2017 at 04:19:45PM -0700, Manasi Navare wrote:
> > In case of eDP because the panel has a fixed mode, the link rate
> > and lane count at which it is trained corresponds to the link BW
> > required to support the native resolution of the panel. In case of
> > panles with lower resolutions where fewer lanes are hooked up internally,
> > that number is reflected in the MAX_LANE_COUNT DPCD register of the panel.
> > So it is pointless to fallback to lower link rate/lane count in case
> > of link training failure on eDP connector since the lower link BW
> > will not support the native resolution of the panel and we cannot
> > prune the preferred mode on the eDP connector.
> > 
> > In case of Link training failure on the eDP panel, something is wrong
> > in the HW internally and hence driver errors out with a loud
> > and clear DRM_ERROR message.
> > 
> > Cc: Clinton Taylor <clinton.a.taylor@intel.com>
> > Cc: Jim Bride <jim.bride@linux.intel.com>
> > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
> > Cc: Dave Airlie <airlied@redhat.com>
> > Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
> > Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
> > ---
> >  drivers/gpu/drm/i915/intel_dp_link_training.c | 25 ++++++++++++++++---------
> >  1 file changed, 16 insertions(+), 9 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > index 05907fa..bcccef1 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > @@ -328,14 +328,21 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
> >  	return;
> >  
> >   failure_handling:
> > -	DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
> > -		      intel_connector->base.base.id,
> > -		      intel_connector->base.name,
> > -		      intel_dp->link_rate, intel_dp->lane_count);
> > -	if (!intel_dp_get_link_train_fallback_values(intel_dp,
> > -						     intel_dp->link_rate,
> > -						     intel_dp->lane_count))
> > -		/* Schedule a Hotplug Uevent to userspace to start modeset */
> > -		schedule_work(&intel_connector->modeset_retry_work);
> > +	/* Dont fallback and prune modes if its eDP */
> > +	if (!intel_dp_is_edp(intel_dp)) {
> > +		DRM_DEBUG_KMS("[CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
> > +			      intel_connector->base.base.id,
> > +			      intel_connector->base.name,
> > +			      intel_dp->link_rate, intel_dp->lane_count);
> > +		if (!intel_dp_get_link_train_fallback_values(intel_dp,
> > +							     intel_dp->link_rate,
> > +							     intel_dp->lane_count))
> > +			/* Schedule a Hotplug Uevent to userspace to start modeset */
> > +			schedule_work(&intel_connector->modeset_retry_work);
> > +	} else
> 
> {} missing around the else. The conventio is to put {} around every
> branch if at least one branch needs them.
> 
> > +		DRM_ERROR("eDP [CONNECTOR:%d:%s] Link Training failed at link rate = %d, lane count = %d",
>                            ^^^
> That's redundant since the connector name will alrady say "eDP-<something>"
> 
> Apart from that this seems better than blindly pruning the panel's
> native mode. If we ever hit this on real hardware we may have to think
> about your other idea of trying to reduce the link params in a way
> that doesn't result the loss of the native mode.
>

Yes I agree. I started coding that logic at first but it becomes a little
bit of a stretch considering the fact that we should never run into that
situation.
So I agree that unless we actually see this on a real HW we should just avoid lowering
link rate/lane count.
 
> With the redundant stuff in the error message dropped and {} added this is
> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
>

Thanks for the review comments. Yes i will fix the debug message and add the necessary {}.

Manasi
 
> > +			  intel_connector->base.base.id,
> > +			  intel_connector->base.name,
> > +			  intel_dp->link_rate, intel_dp->lane_count);
> >  	return;
> >  }
> > -- 
> > 2.1.4
> 
> -- 
> Ville Syrjälä
> Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  reply	other threads:[~2017-10-12 19:01 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-10-11 23:19 [PATCH] drm/i915/edp: Do not do link training fallback or prune modes on EDP Manasi Navare
2017-10-11 23:51 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-10-12  6:15 ` ✗ Fi.CI.IGT: failure " Patchwork
2017-10-12 17:37 ` [PATCH] " Ville Syrjälä
2017-10-12 19:05   ` Manasi Navare [this message]
2017-10-12 19:13 ` [PATCH v2] " Manasi Navare
2018-01-19 15:45   ` Imre Deak
2018-01-22 16:07     ` Imre Deak
2018-01-23  9:48       ` Jani Nikula
2018-01-23 12:57         ` Imre Deak
2018-01-23 22:34           ` Manasi Navare
2018-01-30  7:38           ` Jani Nikula
2018-04-12  8:11             ` Timo Aaltonen
2018-04-12  9:10               ` Jani Nikula
2017-10-12 19:37 ` ✓ Fi.CI.BAT: success for drm/i915/edp: Do not do link training fallback or prune modes on EDP (rev2) Patchwork
2017-10-13  2:38 ` ✗ Fi.CI.IGT: failure " 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=20171012190545.GB2421@intel.com \
    --to=manasi.d.navare@intel.com \
    --cc=airlied@redhat.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=ville.syrjala@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.