All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Harry Wentland <hwentlan@amd.com>
Cc: mario.kleiner.de@gmail.de, Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Maling list - DRI developers <dri-devel@lists.freedesktop.org>
Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.
Date: Fri, 10 Jan 2020 20:09:44 +0200	[thread overview]
Message-ID: <20200110180944.GL13686@intel.com> (raw)
In-Reply-To: <bae132f3-73e6-5004-c9a9-adb632338268@amd.com>

On Thu, Jan 09, 2020 at 04:26:19PM -0500, Harry Wentland wrote:
> 
> 
> On 2020-01-09 4:04 p.m., Mario Kleiner wrote:
> > On Thu, Jan 9, 2020 at 8:49 PM Alex Deucher <alexdeucher@gmail.com
> > <mailto:alexdeucher@gmail.com>> wrote:
> >
> >     On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner
> >     <mario.kleiner.de@gmail.com <mailto:mario.kleiner.de@gmail.com>>
> >     wrote:
> >     >
> >     > On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher
> >     <alexdeucher@gmail.com <mailto:alexdeucher@gmail.com>> wrote:
> >     >>
> >     >> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
> >     >> <mario.kleiner.de@gmail.com
> >     <mailto:mario.kleiner.de@gmail.com>> wrote:
> >     >> >
> >     As Harry mentioned in the other thread, won't this only work if the
> >     display was brought up by the vbios?  In the suspend/resume case,
> >     won't we just fall back to 2.7Gbps?
> >
> >     Alex
> >
> >
> > Adding Harry to cc...
> >
> > The code is only executed for eDP. On the Intel side, it seems that
> > intel_edp_init_dpcd() gets only called during driver load /
> > modesetting init, so not on resume.
> >
> > On the AMD DC side, dc_link_detect_helper() has this early no-op
> > return at the beginning:
> >
> > if ((link->connector_signal == SIGNAL_TYPE_LVDS ||
> > 			link->connector_signal == SIGNAL_TYPE_EDP) &&
> > 			link->local_sink)
> > 		return true;
> >
> > So i guess if link->local_sink doesn't get NULL'ed during a
> > suspend/resume cycle, then we never reach the setup code that would
> > overwrite with non vbios settings?
> >
> > Sounds reasonable to me, given that eDP panels are usually fixed
> > internal panels, nothing that gets hot(un-)plugged?
> >
> > I can't test, because suspend/resume with the Polaris gpu on the MBP
> > 2017 is totally broken atm., just as vgaswitcheroo can't do its job.
> > Looks like powering down the gpu works, but powering up doesn't. And
> > also modesetting at vgaswitcheroo switch time is no-go, because the
> > DDC/AUX lines apparently can't be switched on that Apple gmux, and
> > handover of that data seems to be not implemented in current
> > vgaswitcheroo. At the moment switching between AMD only or Intel+AMD
> > Prime setup is quite a pita...
> >
> 
> I haven't followed the entire discussion on the i915 thread but for the
> amdgpu dc patch I would prefer a DPCD quirk to override the reported
> link settings with the correct link rate.

We could consider adding a standard function for reading the receiver
caps and applying the quirk there. I have a feeling that putting it
into drm_dp_dpcd_read() would be a bit too low level since it would
prevent reading the non-quirked raw data easily.

-- 
Ville Syrjälä
Intel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

WARNING: multiple messages have this Message-ID (diff)
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Harry Wentland <hwentlan@amd.com>
Cc: mario.kleiner.de@gmail.de, Daniel Vetter <daniel.vetter@ffwll.ch>,
	Intel Graphics Development <intel-gfx@lists.freedesktop.org>,
	Maling list - DRI developers <dri-devel@lists.freedesktop.org>,
	Alex Deucher <alexdeucher@gmail.com>,
	Harry Wentland <Harry.Wentland@amd.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.
Date: Fri, 10 Jan 2020 20:09:44 +0200	[thread overview]
Message-ID: <20200110180944.GL13686@intel.com> (raw)
In-Reply-To: <bae132f3-73e6-5004-c9a9-adb632338268@amd.com>

On Thu, Jan 09, 2020 at 04:26:19PM -0500, Harry Wentland wrote:
> 
> 
> On 2020-01-09 4:04 p.m., Mario Kleiner wrote:
> > On Thu, Jan 9, 2020 at 8:49 PM Alex Deucher <alexdeucher@gmail.com
> > <mailto:alexdeucher@gmail.com>> wrote:
> >
> >     On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner
> >     <mario.kleiner.de@gmail.com <mailto:mario.kleiner.de@gmail.com>>
> >     wrote:
> >     >
> >     > On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher
> >     <alexdeucher@gmail.com <mailto:alexdeucher@gmail.com>> wrote:
> >     >>
> >     >> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
> >     >> <mario.kleiner.de@gmail.com
> >     <mailto:mario.kleiner.de@gmail.com>> wrote:
> >     >> >
> >     As Harry mentioned in the other thread, won't this only work if the
> >     display was brought up by the vbios?  In the suspend/resume case,
> >     won't we just fall back to 2.7Gbps?
> >
> >     Alex
> >
> >
> > Adding Harry to cc...
> >
> > The code is only executed for eDP. On the Intel side, it seems that
> > intel_edp_init_dpcd() gets only called during driver load /
> > modesetting init, so not on resume.
> >
> > On the AMD DC side, dc_link_detect_helper() has this early no-op
> > return at the beginning:
> >
> > if ((link->connector_signal == SIGNAL_TYPE_LVDS ||
> > 			link->connector_signal == SIGNAL_TYPE_EDP) &&
> > 			link->local_sink)
> > 		return true;
> >
> > So i guess if link->local_sink doesn't get NULL'ed during a
> > suspend/resume cycle, then we never reach the setup code that would
> > overwrite with non vbios settings?
> >
> > Sounds reasonable to me, given that eDP panels are usually fixed
> > internal panels, nothing that gets hot(un-)plugged?
> >
> > I can't test, because suspend/resume with the Polaris gpu on the MBP
> > 2017 is totally broken atm., just as vgaswitcheroo can't do its job.
> > Looks like powering down the gpu works, but powering up doesn't. And
> > also modesetting at vgaswitcheroo switch time is no-go, because the
> > DDC/AUX lines apparently can't be switched on that Apple gmux, and
> > handover of that data seems to be not implemented in current
> > vgaswitcheroo. At the moment switching between AMD only or Intel+AMD
> > Prime setup is quite a pita...
> >
> 
> I haven't followed the entire discussion on the i915 thread but for the
> amdgpu dc patch I would prefer a DPCD quirk to override the reported
> link settings with the correct link rate.

We could consider adding a standard function for reading the receiver
caps and applying the quirk there. I have a feeling that putting it
into drm_dp_dpcd_read() would be a bit too low level since it would
prevent reading the non-quirked raw data easily.

-- 
Ville Syrjälä
Intel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2020-01-10 18:09 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-09 15:07 [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array Mario Kleiner
2020-01-09 15:07 ` [Intel-gfx] " Mario Kleiner
2020-01-09 15:26 ` Ville Syrjälä
2020-01-09 15:26   ` [Intel-gfx] " Ville Syrjälä
2020-01-09 15:38   ` Ville Syrjälä
2020-01-09 15:38     ` [Intel-gfx] " Ville Syrjälä
2020-01-09 16:30     ` Mario Kleiner
2020-01-09 16:30       ` [Intel-gfx] " Mario Kleiner
2020-01-09 16:47       ` Ville Syrjälä
2020-01-09 16:47         ` [Intel-gfx] " Ville Syrjälä
2020-01-09 17:57         ` Mario Kleiner
2020-01-09 17:57           ` [Intel-gfx] " Mario Kleiner
2020-01-09 18:24           ` Ville Syrjälä
2020-01-09 18:24             ` [Intel-gfx] " Ville Syrjälä
2020-01-09 20:19             ` Mario Kleiner
2020-01-09 20:19               ` [Intel-gfx] " Mario Kleiner
2020-01-10 13:32               ` Ville Syrjälä
2020-01-10 13:32                 ` [Intel-gfx] " Ville Syrjälä
2020-01-10 15:50                 ` Mario Kleiner
2020-01-10 15:50                   ` [Intel-gfx] " Mario Kleiner
2020-01-09 16:31     ` Ville Syrjälä
2020-01-09 16:31       ` [Intel-gfx] " Ville Syrjälä
2020-01-09 16:27   ` Mario Kleiner
2020-01-09 16:27     ` [Intel-gfx] " Mario Kleiner
2020-01-09 15:39 ` Alex Deucher
2020-01-09 15:39   ` [Intel-gfx] " Alex Deucher
2020-01-09 16:46   ` Mario Kleiner
2020-01-09 16:46     ` [Intel-gfx] " Mario Kleiner
2020-01-09 19:49     ` Alex Deucher
2020-01-09 19:49       ` [Intel-gfx] " Alex Deucher
2020-01-09 21:04       ` Mario Kleiner
2020-01-09 21:04         ` [Intel-gfx] " Mario Kleiner
2020-01-09 21:26         ` Harry Wentland
2020-01-09 21:26           ` [Intel-gfx] " Harry Wentland
2020-01-10 16:02           ` Mario Kleiner
2020-01-10 16:02             ` [Intel-gfx] " Mario Kleiner
2020-01-10 18:09           ` Ville Syrjälä [this message]
2020-01-10 18:09             ` Ville Syrjälä
2020-01-15 12:34             ` Jani Nikula
2020-01-15 12:34               ` Jani Nikula
2020-01-15 14:17               ` Ville Syrjälä
2020-01-15 14:17                 ` Ville Syrjälä
2020-01-09 23:52 ` [Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/dp: Add current maximum eDP link rate to sink_rate array. (rev2) 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=20200110180944.GL13686@intel.com \
    --to=ville.syrjala@linux.intel.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=hwentlan@amd.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=mario.kleiner.de@gmail.de \
    /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.