From: Jani Nikula <jani.nikula@linux.intel.com>
To: "Ville Syrjälä" <ville.syrjala@linux.intel.com>,
"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: Wed, 15 Jan 2020 14:34:02 +0200 [thread overview]
Message-ID: <87o8v4kif9.fsf@intel.com> (raw)
In-Reply-To: <20200110180944.GL13686@intel.com>
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.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2020-01-15 12:34 UTC|newest]
Thread overview: 21+ 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:26 ` Ville Syrjälä
2020-01-09 15:38 ` Ville Syrjälä
2020-01-09 16:30 ` Mario Kleiner
2020-01-09 16:47 ` Ville Syrjälä
2020-01-09 17:57 ` Mario Kleiner
2020-01-09 18:24 ` Ville Syrjälä
2020-01-09 20:19 ` Mario Kleiner
2020-01-10 13:32 ` Ville Syrjälä
2020-01-10 15:50 ` Mario Kleiner
2020-01-09 16:31 ` Ville Syrjälä
2020-01-09 16:27 ` Mario Kleiner
2020-01-09 15:39 ` Alex Deucher
2020-01-09 16:46 ` Mario Kleiner
2020-01-09 19:49 ` Alex Deucher
2020-01-09 21:04 ` Mario Kleiner
2020-01-09 21:26 ` Harry Wentland
2020-01-10 16:02 ` Mario Kleiner
2020-01-10 18:09 ` [Intel-gfx] " Ville Syrjälä
2020-01-15 12:34 ` Jani Nikula [this message]
2020-01-15 14:17 ` Ville Syrjälä
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=87o8v4kif9.fsf@intel.com \
--to=jani.nikula@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 \
--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 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).