All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@linux.intel.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>,
	Harry Wentland <hwentlan@amd.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.
Date: Wed, 15 Jan 2020 16:17:50 +0200	[thread overview]
Message-ID: <20200115141750.GX13686@intel.com> (raw)
In-Reply-To: <87o8v4kif9.fsf@intel.com>

On Wed, Jan 15, 2020 at 02:34:02PM +0200, Jani Nikula wrote:
> On Fri, 10 Jan 2020, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > 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.
> 
> Everything about this panel is ugly.
> 
> The panel does not claim to support extended receiver caps. (I have not
> seen whether there is non-zero data at 0x2200. Mario, please provide a
> dump of that DPCD region.)
> 
> The panel does use DPCD_DISPLAY_CONTROL_CAPABLE and reports eDP 1.3 in
> EDP_DPCD_REV.
> 
> eDP 1.3 says only four values are supported in LINK_BW_SET (0x06, 0x0a,
> 0x14, and 0x1e). The same for MAX_LINK_RATE for all DP, and even in the
> extended receiver cap.
> 
> You could perhaps make the case for the interpretation in commit
> 57a1b0893782 ("drm: Make the bw/link rate calculations more forgiving")
> that in eDP 1.4+ you can use arbitrary values in LINK_BW_SET. But I
> think that's a stretch, really. And anyway the panel reports eDP 1.3.
> 
> The panel is consistent in that it does not claim to support link rate
> selection nor does it have anything in SUPPORTED_LINK_RATES which are
> eDP 1.4+ features.
> 
> However, the panel reports 0x0a as the max link rate in MAX_LINK_RATE,
> which exceeds the value 0x0c set in LINK_BW_SET by the firmware.
> 
> Bottom line is, *if* we're going to support this proprietary crap of a
> panel, it *must* be an isolated quirk. I certainly won't take a patch
> generalizing this to any panel out there. But you're going to have to be
> pretty clever to isolate this crap. I'm not sure if quirking a homebrew
> extended receiver cap is going to be enough.

drm_dp_read_receiver_caps()
{
	dpcd_read(dpcd);
	if (quirk) {
		DRM_DEBUG_KMS("blah");
		dpcd[MAX_BW] = 0xc;
	}
}

intel_dp_sink_rates()
{
	...
	if (max_bw > rates[i-1])
		rates[i++] = max_bw;
}

Would seem more or less OK to me. And doing it this way would also
cover the MyDP 6.75 case automagically.

-- 
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
From: "Ville Syrjälä" <ville.syrjala@linux.intel.com>
To: Jani Nikula <jani.nikula@linux.intel.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>,
	Harry Wentland <Harry.Wentland@amd.com>,
	Alex Deucher <alexdeucher@gmail.com>,
	Harry Wentland <hwentlan@amd.com>
Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.
Date: Wed, 15 Jan 2020 16:17:50 +0200	[thread overview]
Message-ID: <20200115141750.GX13686@intel.com> (raw)
In-Reply-To: <87o8v4kif9.fsf@intel.com>

On Wed, Jan 15, 2020 at 02:34:02PM +0200, Jani Nikula wrote:
> On Fri, 10 Jan 2020, Ville Syrjälä <ville.syrjala@linux.intel.com> wrote:
> > 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.
> 
> Everything about this panel is ugly.
> 
> The panel does not claim to support extended receiver caps. (I have not
> seen whether there is non-zero data at 0x2200. Mario, please provide a
> dump of that DPCD region.)
> 
> The panel does use DPCD_DISPLAY_CONTROL_CAPABLE and reports eDP 1.3 in
> EDP_DPCD_REV.
> 
> eDP 1.3 says only four values are supported in LINK_BW_SET (0x06, 0x0a,
> 0x14, and 0x1e). The same for MAX_LINK_RATE for all DP, and even in the
> extended receiver cap.
> 
> You could perhaps make the case for the interpretation in commit
> 57a1b0893782 ("drm: Make the bw/link rate calculations more forgiving")
> that in eDP 1.4+ you can use arbitrary values in LINK_BW_SET. But I
> think that's a stretch, really. And anyway the panel reports eDP 1.3.
> 
> The panel is consistent in that it does not claim to support link rate
> selection nor does it have anything in SUPPORTED_LINK_RATES which are
> eDP 1.4+ features.
> 
> However, the panel reports 0x0a as the max link rate in MAX_LINK_RATE,
> which exceeds the value 0x0c set in LINK_BW_SET by the firmware.
> 
> Bottom line is, *if* we're going to support this proprietary crap of a
> panel, it *must* be an isolated quirk. I certainly won't take a patch
> generalizing this to any panel out there. But you're going to have to be
> pretty clever to isolate this crap. I'm not sure if quirking a homebrew
> extended receiver cap is going to be enough.

drm_dp_read_receiver_caps()
{
	dpcd_read(dpcd);
	if (quirk) {
		DRM_DEBUG_KMS("blah");
		dpcd[MAX_BW] = 0xc;
	}
}

intel_dp_sink_rates()
{
	...
	if (max_bw > rates[i-1])
		rates[i++] = max_bw;
}

Would seem more or less OK to me. And doing it this way would also
cover the MyDP 6.75 case automagically.

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

  reply	other threads:[~2020-01-15 14:17 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-09 15:07 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ä
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ä [this message]
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=20200115141750.GX13686@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=jani.nikula@linux.intel.com \
    --cc=mario.kleiner.de@gmail.de \
    --subject='Re: [Intel-gfx] [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array.' \
    /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

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.