From: Manasi Navare <manasi.d.navare@intel.com>
To: "Pandiyan, Dhinakaran" <dhinakaran.pandiyan@intel.com>
Cc: "Vetter, Daniel" <daniel.vetter@intel.com>,
"intel-gfx@lists.freedesktop.org"
<intel-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP
Date: Thu, 17 Aug 2017 14:16:22 -0700 [thread overview]
Message-ID: <20170817211622.GA27365@intel.com> (raw)
In-Reply-To: <20170817210105.GF26293@intel.com>
On Thu, Aug 17, 2017 at 02:01:05PM -0700, Manasi Navare wrote:
> On Thu, Aug 17, 2017 at 01:11:00PM -0700, Pandiyan, Dhinakaran wrote:
> > On Thu, 2017-08-17 at 12:46 -0700, Manasi Navare wrote:
> > > On Thu, Aug 17, 2017 at 07:01:05AM +0000, Rodrigo Vivi wrote:
> > > > On Wed, Aug 16, 2017 at 11:51 PM Manasi Navare
> > > > <[1]manasi.d.navare@intel.com> wrote:
> > > >
> > > > In case of eDP because the panel has a fixed mode we cannot
> > > > link train fallback and prune modes since this results in
> > > > no modes available for eDP connector.
> > > >
> > > > What about downclock modes?!
> > >
> > > What are the downclock modes? We have seen an issue with pruning modes
> > > in case of eDP panel where we end up pruning the mode due to link train
> > > fallback and then we get an error saying "No modes available for the
> > > connector"
> > >
> >
> > fwiw I've got two laptops with eDP's having more than ten modes.
> >
Hmm, I have always dealt with laptops with eDPs with a fixed mode
and so are the systems in CI which are giving this "no mode
left on the connector error".
Manasi
>
> Yes but link training is not supposed to fail for eDP since its a
> fixed connection and so after discussing with Daniel and Jani, this is
> the consensus that we shouldnt be falling back and retraining in case
> of eDP since most eDP panels are going to have 1 or 2 modes.
>
> Manasi
>
> > > >
> > > > Also since its a panel, link training should not fail dynamically
> > > > based on cable conditions like in case of DP.
> > > >
> > > > Is there any bug associated with this patch?
> > >
> > > Yes this is the bug:
> > > https://bugs.freedesktop.org/show_bug.cgi?id=101518
> > > But the reason I didnt have this in the Fixes tab is because
> > > this patch will not fix the bug, it will just isolate to it being
> > > a bug with AUX Timeouts warning.
> > >
> > > Regards
> > > Manasi
> > >
> > > >
> > > > Cc: Jani Nikula <[2]jani.nikula@linux.intel.com>
> > > > Cc: Jim Bride <[3]jim.bride@linux.intel.com>
> > > > Cc: Ville Syrjälä <[4]ville.syrjala@linux.intel.com>
> > > > Cc: Daniel Vetter <[5]daniel.vetter@intel.com>
> > > > Signed-off-by: Manasi Navare <[6]manasi.d.navare@intel.com>
> > > > ---
> > > > drivers/gpu/drm/i915/intel_dp.c | 2 +-
> > > > drivers/gpu/drm/i915/intel_dp_link_training.c | 3 ++-
> > > > drivers/gpu/drm/i915/intel_drv.h | 1 +
> > > > 3 files changed, 4 insertions(+), 2 deletions(-)
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > index 4fd4853..edac0c8 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > @@ -109,7 +109,7 @@ static const int default_rates[] = { 162000,
> > > > 270000, 540000 };
> > > > * If a CPU or PCH DP output is attached to an eDP panel, this
> > > > function
> > > > * will return true, and false otherwise.
> > > > */
> > > > -static bool is_edp(struct intel_dp *intel_dp)
> > > > +bool is_edp(struct intel_dp *intel_dp)
> > > > {
> > > > struct intel_digital_port *intel_dig_port =
> > > > dp_to_dig_port(intel_dp);
> > > > diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > index 05907fa..18ec61f 100644
> > > > --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> > > > @@ -332,7 +332,8 @@ intel_dp_start_link_train(struct intel_dp
> > > > *intel_dp)
> > > > intel_connector->[7]base.base.id,
> > > > intel_connector->[8]base.name,
> > > > intel_dp->link_rate, intel_dp->lane_count);
> > > > - if (!intel_dp_get_link_train_fallback_values(intel_dp,
> > > > + /* Dont fallback and prune modes if its eDP */
> > > > + if (!is_edp(intel_dp) &&
> > > > !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 */
> > > > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > > > b/drivers/gpu/drm/i915/intel_drv.h
> > > > index fa47285..9800a15 100644
> > > > --- a/drivers/gpu/drm/i915/intel_drv.h
> > > > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > > > @@ -1548,6 +1548,7 @@ static inline unsigned int
> > > > intel_dp_unused_lane_mask(int lane_count)
> > > > }
> > > > bool intel_dp_read_dpcd(struct intel_dp *intel_dp);
> > > > +bool is_edp(struct intel_dp *intel_dp);
> > > > int intel_dp_link_required(int pixel_clock, int bpp);
> > > > int intel_dp_max_data_rate(int max_link_clock, int max_lanes);
> > > > bool intel_digital_port_connected(struct drm_i915_private
> > > > *dev_priv,
> > > > --
> > > > 2.1.4
> > > > _______________________________________________
> > > > Intel-gfx mailing list
> > > > [9]Intel-gfx@lists.freedesktop.org
> > > > [10]https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > >
> > > > References
> > > >
> > > > 1. mailto:manasi.d.navare@intel.com
> > > > 2. mailto:jani.nikula@linux.intel.com
> > > > 3. mailto:jim.bride@linux.intel.com
> > > > 4. mailto:ville.syrjala@linux.intel.com
> > > > 5. mailto:daniel.vetter@intel.com
> > > > 6. mailto:manasi.d.navare@intel.com
> > > > 7. http://base.base.id/
> > > > 8. http://base.name/
> > > > 9. mailto:Intel-gfx@lists.freedesktop.org
> > > > 10. https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> > > _______________________________________________
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
next prev parent reply other threads:[~2017-08-17 21:08 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-17 6:58 [PATCH] drm/i915: Do not do link training fallback or prune modes for eDP Manasi Navare
2017-08-17 7:01 ` Rodrigo Vivi
2017-08-17 19:46 ` Manasi Navare
2017-08-17 20:11 ` Pandiyan, Dhinakaran
2017-08-17 20:44 ` Rodrigo Vivi
2017-08-17 22:10 ` Manasi Navare
2017-08-18 4:00 ` Dhinakaran Pandiyan
2017-08-17 21:01 ` Manasi Navare
2017-08-17 21:16 ` Manasi Navare [this message]
2017-08-18 8:08 ` Daniel Vetter
2017-08-17 7:21 ` ✓ Fi.CI.BAT: success for " Patchwork
2017-08-17 9:51 ` [PATCH] " Jani Nikula
2017-08-17 19:29 ` Manasi Navare
2017-08-17 19:28 ` Pandiyan, Dhinakaran
2017-08-17 19:42 ` Manasi Navare
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=20170817211622.GA27365@intel.com \
--to=manasi.d.navare@intel.com \
--cc=daniel.vetter@intel.com \
--cc=dhinakaran.pandiyan@intel.com \
--cc=intel-gfx@lists.freedesktop.org \
/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;
as well as URLs for NNTP newsgroup(s).