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=-0.3 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 A2FDDC33CA3 for ; Fri, 10 Jan 2020 16:02:41 +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 792692082E for ; Fri, 10 Jan 2020 16:02:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="NVBEGPNh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 792692082E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.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 E17996EA44; Fri, 10 Jan 2020 16:02:38 +0000 (UTC) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) by gabe.freedesktop.org (Postfix) with ESMTPS id 5377E89A6D; Fri, 10 Jan 2020 16:02:37 +0000 (UTC) Received: by mail-wr1-x444.google.com with SMTP id q6so2287179wro.9; Fri, 10 Jan 2020 08:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fk4l7uGygizrgCjzbf0QE8J+XpL6US2LefSlzMowOTc=; b=NVBEGPNhnL488QezvjtNkfrWuBvTvtvebb7vpa5vAIAzNYqHBkRnWjdh23TVsRXWoJ SGc1PNlntHtywOBWO5FLUIGtvKNRNqPO3MTWauCfLU2FeHK6c2fhU3ekETcXy0ljjmWh ThoCdxx9AsZEzDavVUyJ2AaT1jmiISBMMtjqEUG2e8NNELZXDBi7lv1XcX13LH7YMvBY SaQcri0rruc8hFSAjTfxaMt4XN7Obxt9y0xVasNJ1sMGKrJS/b9A+VUEi24zdJ1QPjoj /3i1cwp2VAV3m/g8zGQ0bpTGlSxESX/FHPObeYD376/Piv1gv7dpjDpPPEkCWnh5V12F cq5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Fk4l7uGygizrgCjzbf0QE8J+XpL6US2LefSlzMowOTc=; b=OCwzslIWbpn9u1i4nEKJpx+CAmkH/MzueQ8TX20+kxtVRm2tVedVczjbOZtfn/RVwA rwbqRoHQgrb1JwrG/h92gPdvlFjC480nARszO2r/i9xcNxlXJdGcECuEPfeYKVl8gm3J Sq4pTD/mJkVGRDYRjIHBphgv3jyqET/KfsGqqE9d7TxKvxr1z4pMZs7JfZV9VhNuhdWI F63cdyHrH6I04TGGsy2Qv2bFsXENDLHJgIdmEtsn8JxFFLT6WL6F70QOj1gFD9c81PJ2 2D8EOuv+tZz7eKoGMt88CTuq2MSTSPAyIHcDRDV4HJqDqhciO8rvzSVWKB0hvkQL6h80 gZPA== X-Gm-Message-State: APjAAAWG2YCYrmJVIkkXLtaNKqYH1LakduKacSWpSviyQjrhk8TFQDTz eHeZNHIm8dmJU4JN5kFsFjs4ZPLh7Y8XARGi0Vw= X-Google-Smtp-Source: APXvYqxS9x4bESFullmo5dI3Te4aTGskQMwp2UyMm++IhPSTsPffIPhudMsris3wraNVGWHqIVVD1vnWbhunXcAx7Jc= X-Received: by 2002:adf:f5cb:: with SMTP id k11mr4151805wrp.71.1578672155990; Fri, 10 Jan 2020 08:02:35 -0800 (PST) MIME-Version: 1.0 References: <20200109150752.28098-1-mario.kleiner.de@gmail.com> In-Reply-To: From: Mario Kleiner Date: Fri, 10 Jan 2020 17:02:24 +0100 Message-ID: Subject: Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array. To: Harry Wentland 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 Content-Type: multipart/mixed; boundary="===============1246791235==" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --===============1246791235== Content-Type: multipart/alternative; boundary="000000000000132222059bcb416a" --000000000000132222059bcb416a Content-Type: text/plain; charset="UTF-8" On Thu, Jan 9, 2020 at 10:26 PM 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? 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. > > Harry > > Ok, as you wish. How do i do that? Is there already some DP related official mechanism, or do i just add some if-statement to detect_edp_sink_caps () that matches on a new EDID quirk to be defined for that panel in drm_edid etc., and then if (edit quirk for that panel) dpcd[DP_MAX_LINK_RATE ] = 0xc; The other question would be if we should do it for this panel on AMD DC at all? I see my original patch more as something to fix other odd (Apple?) panels, than for this specific one. As mentioned above, photometer testing on AMD DC with a Polaris on the MBP 2017 suggests that the deault 2.7 Gbps 8 bit mode + AMD's spatial dithering provides higher quality results for >= 10 bpc framebuffers than actually running the panel at 10 bit without dithering. As a little side-note, for squeezing out more precision than the 10 bpc framebuffers we officially have in Mesa/OpenGL, my software Psychtoolbox has some special hacks, playing funny tricks with resizing X-Screens, applying bit-twiddling shaders to images and MMIO programming the gpu "behind the back" of the driver, to get the gpu into RGBA16161616 linear scanout mode. That gives up to 12 bpc precision on that panel according to photometer measurements. While AMD's dithering with the panel in 8 bit + 4 bit spatial dithering gives pretty good results, panel at 10 bit + 2 bit spatial dithering has some artifacts. And even at a normal 10 bit framebuffer, the 8 bit panel + 2 bit dithering seems to give better results than 10 bit panel mode. -mario --000000000000132222059bcb416a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 9, 2020 at 10:26 PM Harry= Wentland <hwentlan@amd.com> = wrote:
=20


On 2020-01-09 4:04 p.m., Mario Kleiner wrote:
=20
On Thu, Jan 9, 2020 at 8:49 PM Alex Deucher <alexdeucher@gmail.= com> wrote:
On Thu, Jan 9, = 2020 at 11:47 AM Mario Kleiner
<mario.kleiner.de@gmail.com> wrote:
>
> On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher <alexdeucher@gmail.com&= gt; wrote:
>>
>> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
>> <mario.kleiner.de@gmail.com> wrote:
>> >
As Harry mentioned in the other thread, won't this only wor= k if the
display was brought up by the vbios?=C2=A0 In the suspend/resum= e 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 =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 w= e 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.

Harry


Ok, as you wish. How do i do= that? Is there already some DP related official mechanism, or do i just ad= d some if-statement to 
detect_edp_s=
ink_caps() that matches on a new EDID qu=
irk to be defined for that panel in drm_edid etc., and then

if (edit=
 quirk for that panel)
    dpcd[DP_MAX_LINK_R=
ATE] =3D 0xc;

The other question= would be if we should do it for this panel on AMD DC at all? I see my orig= inal patch more as something to fix other odd (Apple?) panels, than for thi= s specific one. As mentioned above, photometer testing on AMD DC with a Pol= aris on the MBP 2017 suggests that the deault 2.7 Gbps 8 bit mode + AMD'= ;s spatial dithering provides higher quality results for >=3D 10 bpc fra= mebuffers than actually running the panel at 10 bit without dithering.
<= /div>

As a little side-note, for squeezing out more prec= ision than the 10 bpc framebuffers we officially have in Mesa/OpenGL, my so= ftware Psychtoolbox has some special hacks, playing funny tricks with resiz= ing X-Screens, applying bit-twiddling shaders to images and MMIO programmin= g the gpu "behind the back" of the driver, to get the gpu into RG= BA16161616 linear scanout mode. That gives up to 12 bpc precision on that p= anel according to photometer measurements. While AMD's dithering with t= he panel in 8 bit + 4 bit spatial dithering gives pretty good results, pane= l at 10 bit + 2 bit spatial dithering has some artifacts. And even at a nor= mal 10 bit framebuffer, the 8 bit panel + 2 bit dithering seems to give bet= ter results than 10 bit panel mode.

-mario

=C2=A0
--000000000000132222059bcb416a-- --===============1246791235== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel --===============1246791235==-- 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=-0.3 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 73E73C282DD for ; Fri, 10 Jan 2020 16:02:39 +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 43A012082E for ; Fri, 10 Jan 2020 16:02:39 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="NVBEGPNh" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 43A012082E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.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 9F0F06EA43; Fri, 10 Jan 2020 16:02:38 +0000 (UTC) Received: from mail-wr1-x444.google.com (mail-wr1-x444.google.com [IPv6:2a00:1450:4864:20::444]) by gabe.freedesktop.org (Postfix) with ESMTPS id 5377E89A6D; Fri, 10 Jan 2020 16:02:37 +0000 (UTC) Received: by mail-wr1-x444.google.com with SMTP id q6so2287179wro.9; Fri, 10 Jan 2020 08:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Fk4l7uGygizrgCjzbf0QE8J+XpL6US2LefSlzMowOTc=; b=NVBEGPNhnL488QezvjtNkfrWuBvTvtvebb7vpa5vAIAzNYqHBkRnWjdh23TVsRXWoJ SGc1PNlntHtywOBWO5FLUIGtvKNRNqPO3MTWauCfLU2FeHK6c2fhU3ekETcXy0ljjmWh ThoCdxx9AsZEzDavVUyJ2AaT1jmiISBMMtjqEUG2e8NNELZXDBi7lv1XcX13LH7YMvBY SaQcri0rruc8hFSAjTfxaMt4XN7Obxt9y0xVasNJ1sMGKrJS/b9A+VUEi24zdJ1QPjoj /3i1cwp2VAV3m/g8zGQ0bpTGlSxESX/FHPObeYD376/Piv1gv7dpjDpPPEkCWnh5V12F cq5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Fk4l7uGygizrgCjzbf0QE8J+XpL6US2LefSlzMowOTc=; b=OCwzslIWbpn9u1i4nEKJpx+CAmkH/MzueQ8TX20+kxtVRm2tVedVczjbOZtfn/RVwA rwbqRoHQgrb1JwrG/h92gPdvlFjC480nARszO2r/i9xcNxlXJdGcECuEPfeYKVl8gm3J Sq4pTD/mJkVGRDYRjIHBphgv3jyqET/KfsGqqE9d7TxKvxr1z4pMZs7JfZV9VhNuhdWI F63cdyHrH6I04TGGsy2Qv2bFsXENDLHJgIdmEtsn8JxFFLT6WL6F70QOj1gFD9c81PJ2 2D8EOuv+tZz7eKoGMt88CTuq2MSTSPAyIHcDRDV4HJqDqhciO8rvzSVWKB0hvkQL6h80 gZPA== X-Gm-Message-State: APjAAAWG2YCYrmJVIkkXLtaNKqYH1LakduKacSWpSviyQjrhk8TFQDTz eHeZNHIm8dmJU4JN5kFsFjs4ZPLh7Y8XARGi0Vw= X-Google-Smtp-Source: APXvYqxS9x4bESFullmo5dI3Te4aTGskQMwp2UyMm++IhPSTsPffIPhudMsris3wraNVGWHqIVVD1vnWbhunXcAx7Jc= X-Received: by 2002:adf:f5cb:: with SMTP id k11mr4151805wrp.71.1578672155990; Fri, 10 Jan 2020 08:02:35 -0800 (PST) MIME-Version: 1.0 References: <20200109150752.28098-1-mario.kleiner.de@gmail.com> In-Reply-To: From: Mario Kleiner Date: Fri, 10 Jan 2020 17:02:24 +0100 Message-ID: To: Harry Wentland 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 , Alex Deucher , Harry Wentland Content-Type: multipart/mixed; boundary="===============0117735300==" Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" --===============0117735300== Content-Type: multipart/alternative; boundary="000000000000132222059bcb416a" --000000000000132222059bcb416a Content-Type: text/plain; charset="UTF-8" On Thu, Jan 9, 2020 at 10:26 PM 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? 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. > > Harry > > Ok, as you wish. How do i do that? Is there already some DP related official mechanism, or do i just add some if-statement to detect_edp_sink_caps () that matches on a new EDID quirk to be defined for that panel in drm_edid etc., and then if (edit quirk for that panel) dpcd[DP_MAX_LINK_RATE ] = 0xc; The other question would be if we should do it for this panel on AMD DC at all? I see my original patch more as something to fix other odd (Apple?) panels, than for this specific one. As mentioned above, photometer testing on AMD DC with a Polaris on the MBP 2017 suggests that the deault 2.7 Gbps 8 bit mode + AMD's spatial dithering provides higher quality results for >= 10 bpc framebuffers than actually running the panel at 10 bit without dithering. As a little side-note, for squeezing out more precision than the 10 bpc framebuffers we officially have in Mesa/OpenGL, my software Psychtoolbox has some special hacks, playing funny tricks with resizing X-Screens, applying bit-twiddling shaders to images and MMIO programming the gpu "behind the back" of the driver, to get the gpu into RGBA16161616 linear scanout mode. That gives up to 12 bpc precision on that panel according to photometer measurements. While AMD's dithering with the panel in 8 bit + 4 bit spatial dithering gives pretty good results, panel at 10 bit + 2 bit spatial dithering has some artifacts. And even at a normal 10 bit framebuffer, the 8 bit panel + 2 bit dithering seems to give better results than 10 bit panel mode. -mario --000000000000132222059bcb416a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 9, 2020 at 10:26 PM Harry= Wentland <hwentlan@amd.com> = wrote:
=20


On 2020-01-09 4:04 p.m., Mario Kleiner wrote:
=20
On Thu, Jan 9, 2020 at 8:49 PM Alex Deucher <alexdeucher@gmail.= com> wrote:
On Thu, Jan 9, = 2020 at 11:47 AM Mario Kleiner
<mario.kleiner.de@gmail.com> wrote:
>
> On Thu, Jan 9, 2020 at 4:40 PM Alex Deucher <alexdeucher@gmail.com&= gt; wrote:
>>
>> On Thu, Jan 9, 2020 at 10:08 AM Mario Kleiner
>> <mario.kleiner.de@gmail.com> wrote:
>> >
As Harry mentioned in the other thread, won't this only wor= k if the
display was brought up by the vbios?=C2=A0 In the suspend/resum= e 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 =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 w= e 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.

Harry


Ok, as you wish. How do i do= that? Is there already some DP related official mechanism, or do i just ad= d some if-statement to 
detect_edp_s=
ink_caps() that matches on a new EDID qu=
irk to be defined for that panel in drm_edid etc., and then

if (edit=
 quirk for that panel)
    dpcd[DP_MAX_LINK_R=
ATE] =3D 0xc;

The other question= would be if we should do it for this panel on AMD DC at all? I see my orig= inal patch more as something to fix other odd (Apple?) panels, than for thi= s specific one. As mentioned above, photometer testing on AMD DC with a Pol= aris on the MBP 2017 suggests that the deault 2.7 Gbps 8 bit mode + AMD'= ;s spatial dithering provides higher quality results for >=3D 10 bpc fra= mebuffers than actually running the panel at 10 bit without dithering.
<= /div>

As a little side-note, for squeezing out more prec= ision than the 10 bpc framebuffers we officially have in Mesa/OpenGL, my so= ftware Psychtoolbox has some special hacks, playing funny tricks with resiz= ing X-Screens, applying bit-twiddling shaders to images and MMIO programmin= g the gpu "behind the back" of the driver, to get the gpu into RG= BA16161616 linear scanout mode. That gives up to 12 bpc precision on that p= anel according to photometer measurements. While AMD's dithering with t= he panel in 8 bit + 4 bit spatial dithering gives pretty good results, pane= l at 10 bit + 2 bit spatial dithering has some artifacts. And even at a nor= mal 10 bit framebuffer, the 8 bit panel + 2 bit dithering seems to give bet= ter results than 10 bit panel mode.

-mario

=C2=A0
--000000000000132222059bcb416a-- --===============0117735300== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx --===============0117735300==--