On Fri, 10 Jan 2020, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> 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@xxxxxxxxx >> > <mailto:alexdeucher@xxxxxxxxx>> wrote: >> > >> > On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner >> > <mario.kleiner.de@xxxxxxxxx <mailto:mario.kleiner.de@xxxxxxxxx>> >> > wrote: >> > > >> > > On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher >> > <alexdeucher@xxxxxxxxx <mailto:alexdeucher@xxxxxxxxx>> wrote: >> > >> >> > >> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner >> > >> <mario.kleiner.de@xxxxxxxxx >> > <mailto:mario.kleiner.de@xxxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
