From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B9D46C33CB2 for ; Wed, 15 Jan 2020 14:17:58 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9865B24679 for ; Wed, 15 Jan 2020 14:17:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9865B24679 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=dri-devel-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id A9CFA6EA07; Wed, 15 Jan 2020 14:17:56 +0000 (UTC) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by gabe.freedesktop.org (Postfix) with ESMTPS id 643B96EA02; Wed, 15 Jan 2020 14:17:55 +0000 (UTC) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2020 06:17:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,322,1574150400"; d="scan'208";a="213715688" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by orsmga007.jf.intel.com with SMTP; 15 Jan 2020 06:17:51 -0800 Received: by stinkbox (sSMTP sendmail emulation); Wed, 15 Jan 2020 16:17:50 +0200 Date: Wed, 15 Jan 2020 16:17:50 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Jani Nikula Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array. Message-ID: <20200115141750.GX13686@intel.com> References: <20200109150752.28098-1-mario.kleiner.de@gmail.com> <20200110180944.GL13686@intel.com> <87o8v4kif9.fsf@intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87o8v4kif9.fsf@intel.com> X-Patchwork-Hint: comment User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mario.kleiner.de@gmail.de, Daniel Vetter , Intel Graphics Development , Maling list - DRI developers , Harry Wentland Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" On Wed, Jan 15, 2020 at 02:34:02PM +0200, Jani Nikula wrote: > On Fri, 10 Jan 2020, Ville Syrj=E4l=E4 wr= ote: > > 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 >> > > wrote: > >> > > >> > On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner > >> > > > >> > wrote: > >> > > > >> > > On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher > >> > > wrote: > >> > >> > >> > >> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner > >> > >> >> > > wrote: > >> > >> > > >> > As Harry mentioned in the other thread, won't this only work if = the > >> > display was brought up by the vbios?=A0 In the suspend/resume ca= se, > >> > 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 =3D=3D SIGNAL_TYPE_LVDS || > >> > link->connector_signal =3D=3D 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] =3D 0xc; } } intel_dp_sink_rates() { ... if (max_bw > rates[i-1]) rates[i++] =3D 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=E4l=E4 Intel _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 57D06C33CB1 for ; Wed, 15 Jan 2020 14:17:57 +0000 (UTC) Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 32DC524679 for ; Wed, 15 Jan 2020 14:17:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 32DC524679 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.intel.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=intel-gfx-bounces@lists.freedesktop.org Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 958ED6EA02; Wed, 15 Jan 2020 14:17:56 +0000 (UTC) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by gabe.freedesktop.org (Postfix) with ESMTPS id 643B96EA02; Wed, 15 Jan 2020 14:17:55 +0000 (UTC) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Jan 2020 06:17:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.70,322,1574150400"; d="scan'208";a="213715688" Received: from stinkbox.fi.intel.com (HELO stinkbox) ([10.237.72.174]) by orsmga007.jf.intel.com with SMTP; 15 Jan 2020 06:17:51 -0800 Received: by stinkbox (sSMTP sendmail emulation); Wed, 15 Jan 2020 16:17:50 +0200 Date: Wed, 15 Jan 2020 16:17:50 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Jani Nikula Message-ID: <20200115141750.GX13686@intel.com> References: <20200109150752.28098-1-mario.kleiner.de@gmail.com> <20200110180944.GL13686@intel.com> <87o8v4kif9.fsf@intel.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <87o8v4kif9.fsf@intel.com> X-Patchwork-Hint: comment User-Agent: Mutt/1.10.1 (2018-07-13) Subject: Re: [Intel-gfx] [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array. X-BeenThere: intel-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Intel graphics driver community testing & development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: mario.kleiner.de@gmail.de, Daniel Vetter , Intel Graphics Development , Maling list - DRI developers , Harry Wentland , Alex Deucher , Harry Wentland Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" On Wed, Jan 15, 2020 at 02:34:02PM +0200, Jani Nikula wrote: > On Fri, 10 Jan 2020, Ville Syrj=E4l=E4 wr= ote: > > 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 >> > > wrote: > >> > > >> > On Thu, Jan 9, 2020 at 11:47 AM Mario Kleiner > >> > > > >> > wrote: > >> > > > >> > > On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher > >> > > wrote: > >> > >> > >> > >> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner > >> > >> >> > > wrote: > >> > >> > > >> > As Harry mentioned in the other thread, won't this only work if = the > >> > display was brought up by the vbios?=A0 In the suspend/resume ca= se, > >> > 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 =3D=3D SIGNAL_TYPE_LVDS || > >> > link->connector_signal =3D=3D 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] =3D 0xc; } } intel_dp_sink_rates() { ... if (max_bw > rates[i-1]) rates[i++] =3D 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=E4l=E4 Intel _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx