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 80A76C282DD for ; Thu, 9 Jan 2020 17:57:29 +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 507D420678 for ; Thu, 9 Jan 2020 17:57:29 +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="DRG8lZq+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 507D420678 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 748DB6E935; Thu, 9 Jan 2020 17:57:28 +0000 (UTC) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) by gabe.freedesktop.org (Postfix) with ESMTPS id 79E826E935; Thu, 9 Jan 2020 17:57:27 +0000 (UTC) Received: by mail-wr1-x442.google.com with SMTP id b6so8433095wrq.0; Thu, 09 Jan 2020 09:57:27 -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=8MPSzvCE9W7r+xvCSEaTEpM9zgf3lmCs20BXaX/kn3Q=; b=DRG8lZq+jF6r87ZjGggk0qknCYgdkgQGPt9lT1gRb1natDyYBX6zHBtfA8TCZY4CHd Chqfpkb98yj0+9BXen3yEUrliMQezZYYK5QABU4oXTdZ1P2fIxIGapXqQkXBdphCrqa/ w6oomod2zbo6jms/rNr6LQ5wYaWhfpmsaac82tCZ7iZ/YZNmaUaxb8Gfkwgb2MKNUspu Ujjo/A9TnCyWF8737veeoXAx6yPhw1cP6yNUaT2ERDAlHb4h17OnGgkGmazV1cWKayKy 0vRJ9yZ8RtoULQ1R0cjkY+6VOzYPqPrD+jlSpKfAv+qxW5huKtpqDlvaxmTUzL/3pQNZ Z0+g== 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=8MPSzvCE9W7r+xvCSEaTEpM9zgf3lmCs20BXaX/kn3Q=; b=nqFBhKHfkyU7Auz1sEi6yiQ004Y6XqNL37K9rKu1wS5QOIOf841jL9L+fs0N+ErxPj uq9n+m01p3cVc6k6QyKpAeUh4sRp7KvcpeqphlwqQYVv6f3S+f1mSFLXU+0RV0qN4MW3 U+MGBpBtqa32kGILVXR7lf1W1xwYSXjYOjEAQkWrj/ZY4mdfPoG5uGSkUAnlhe1MvT5k iCFTXX1/5NUcsRi2H6L7/oYWmTDrCUl+XmGxLr+t636ZKRmG+U7Loc5juwfe/mPv1wFJ KErq/fxDswq5xgw6yz4dsB0jwek47KiGBBOY4GcWiCfqNDhBcdnVKmULFfsxQA3epBPQ NAtg== X-Gm-Message-State: APjAAAWGRovYu+1FXN+kdBkq45IoQDIEvx5Uk+S9OlYeVACaZbqPyjkB RwWXJrPRVC/Ka2EY+kWwTkuRNyGH9MLwFErTC4xBinMvcCE= X-Google-Smtp-Source: APXvYqyS9UybDNZ8YM6bvLTf/mTKllpvscV83Hj4QgSqKPbyntgwgSX6yKcr+JJrMjBuyvZV5TVqQMVFsKARlgvg8dE= X-Received: by 2002:a5d:6144:: with SMTP id y4mr12408208wrt.367.1578592646050; Thu, 09 Jan 2020 09:57:26 -0800 (PST) MIME-Version: 1.0 References: <20200109150752.28098-1-mario.kleiner.de@gmail.com> <20200109152656.GP1208@intel.com> <20200109153815.GQ1208@intel.com> <20200109164715.GD13686@intel.com> In-Reply-To: <20200109164715.GD13686@intel.com> From: Mario Kleiner Date: Thu, 9 Jan 2020 18:57:14 +0100 Message-ID: Subject: Re: [PATCH] drm/i915/dp: Add current maximum eDP link rate to sink_rate array. To: =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= 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, intel-gfx , dri-devel , Daniel Vetter Content-Type: multipart/mixed; boundary="===============1185132122==" Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" --===============1185132122== Content-Type: multipart/alternative; boundary="000000000000e9b823059bb8bd72" --000000000000e9b823059bb8bd72 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 9, 2020 at 5:47 PM Ville Syrj=C3=A4l=C3=A4 wrote: > On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote: > > On Thu, Jan 9, 2020 at 4:38 PM Ville Syrj=C3=A4l=C3=A4 < > ville.syrjala@linux.intel.com> > > wrote: > > > > > On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrj=C3=A4l=C3=A4 wro= te: > > > > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote: > > > > > The panel reports 10 bpc color depth in its EDID, and the UEFI > > > > > firmware chooses link settings at boot which support enough > > > > > bandwidth for 10 bpc (324000 kbit/sec to be precise), but the > > > > > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible, > > > > > > Does it actually or do we just ignore the fact that it reports > 3.24Gbps? > > > > > > If it really reports 3.24 then we should be able to just add that to > > > dp_rates[] in intel_dp_set_sink_rates() and be done with it. > > > > > > Although we'd likely want to skip 3.24 unless it really is reported > > > as the max so as to not use that non-standard rate on other displays. > > > So would require a bit fancier logic for that. > > > > > > > > Was also my initial thought, but the DP_MAX_LINK_RATE reg reports 2.7 > Gbps > > as maximum. > > So dpcd[0x1] =3D=3D 0xa ? > > Yes. [*] > What about the magic second version of DP_MAX_LINK_RATE at 0x2201 ? > Hmm. I guess we should already be reading that via > intel_dp_extended_receiver_capabilities(). > Yes, you do. [*] Well, i have to recheck on the machine. I started this work on the AMD side and checked what AMD DC gave me, haven't rechecked stuff under i915 that i already knew from AMD. Comparing the implementations, there's some peculiar differences that may matter: intel_dp_extended_receiver_capabilities() is more "paranoid" than AMD DC's retrieve_link_cap() function in deciding if the extended receiver caps are valid. Intels implementation copies only the first 6 Bytes of extended receiver caps into the dpcd[] arrays, whereas AMD copies 16 Bytes. Not sure about the differences, but one of you may wanna check why this is, and if it matters somehow. Btw. your proposed /* blah */ if (max_rate > ...) wouldn't work if dpcd[0x1] =3D=3D 0xa, which it likely is [*]. AMD DC identified it as DP 1.1, eDP 1.3, and these extended caps seem to be only part of DP 1.3+ if i understand the comments in intel_dp_extended_receiver_capabilities() correctly. -mario > > -- > Ville Syrj=C3=A4l=C3=A4 > Intel > --000000000000e9b823059bb8bd72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 9, 2020 at 5:47 PM Ville = Syrj=C3=A4l=C3=A4 <vill= e.syrjala@linux.intel.com> wrote:
On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kl= einer wrote:
> On Thu, Jan 9, 2020 at 4:38 PM Ville Syrj=C3=A4l=C3=A4 <ville.syrjala@linux= .intel.com>
> wrote:
>
> > On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrj=C3=A4l=C3=A4= wrote:
> > > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrot= e:
> > > > The panel reports 10 bpc color depth in its EDID, and t= he UEFI
> > > > firmware chooses link settings at boot which support en= ough
> > > > bandwidth for 10 bpc (324000 kbit/sec to be precise), b= ut the
> > > > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as= possible,
> >
> > Does it actually or do we just ignore the fact that it reports 3.= 24Gbps?
> >
> > If it really reports 3.24 then we should be able to just add that= to
> > dp_rates[] in intel_dp_set_sink_rates() and be done with it.
> >
> > Although we'd likely want to skip 3.24 unless it really is re= ported
> > as the max so as to not use that non-standard rate on other displ= ays.
> > So would require a bit fancier logic for that.
> >
> >
> Was also my initial thought, but the DP_MAX_LINK_RATE reg reports 2.7 = Gbps
> as maximum.

So dpcd[0x1] =3D=3D 0xa ?


Yes. [*]
=C2=A0
What about the magic second version of DP_MAX_LINK_RATE at 0x2201 ?
Hmm. I guess we should already be reading that via
intel_dp_extended_receiver_capabilities().

<= div>Yes, you do.

[*] Well, i have to recheck on th= e machine. I started this work on the AMD side and checked what AMD DC gave= me, haven't rechecked stuff under i915 that i already knew from AMD. C= omparing the implementations, there's some peculiar differences that ma= y matter:

intel_dp_extended_receiver_capabilities(= ) is more "paranoid" than AMD DC's retrieve_link_cap() functi= on in deciding if the extended receiver caps are valid. Intels implementati= on copies only the first 6 Bytes of extended receiver caps into the dpcd[] = arrays, whereas AMD copies 16 Bytes. Not sure about the differences, but on= e of you may wanna check why this is, and if it matters somehow.
=
Btw. your proposed

/* blah */=
if (max_rate > ...)

wouldn't wor= k if dpcd[0x1] =3D=3D 0xa, which it likely is [*]. AMD DC identified it as = DP 1.1, eDP 1.3, and these extended caps seem to be only part of DP 1.3+ if= i understand the comments in intel_dp_extended_receiver_capabilities() cor= rectly.

-mario

=C2=A0

--
Ville Syrj=C3=A4l=C3=A4
Intel
--000000000000e9b823059bb8bd72-- --===============1185132122== 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 --===============1185132122==-- 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 B53DEC282DD for ; Thu, 9 Jan 2020 17:57:33 +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 8AFC620678 for ; Thu, 9 Jan 2020 17:57:33 +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="DRG8lZq+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8AFC620678 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 791CD6E937; Thu, 9 Jan 2020 17:57:29 +0000 (UTC) Received: from mail-wr1-x442.google.com (mail-wr1-x442.google.com [IPv6:2a00:1450:4864:20::442]) by gabe.freedesktop.org (Postfix) with ESMTPS id 79E826E935; Thu, 9 Jan 2020 17:57:27 +0000 (UTC) Received: by mail-wr1-x442.google.com with SMTP id b6so8433095wrq.0; Thu, 09 Jan 2020 09:57:27 -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=8MPSzvCE9W7r+xvCSEaTEpM9zgf3lmCs20BXaX/kn3Q=; b=DRG8lZq+jF6r87ZjGggk0qknCYgdkgQGPt9lT1gRb1natDyYBX6zHBtfA8TCZY4CHd Chqfpkb98yj0+9BXen3yEUrliMQezZYYK5QABU4oXTdZ1P2fIxIGapXqQkXBdphCrqa/ w6oomod2zbo6jms/rNr6LQ5wYaWhfpmsaac82tCZ7iZ/YZNmaUaxb8Gfkwgb2MKNUspu Ujjo/A9TnCyWF8737veeoXAx6yPhw1cP6yNUaT2ERDAlHb4h17OnGgkGmazV1cWKayKy 0vRJ9yZ8RtoULQ1R0cjkY+6VOzYPqPrD+jlSpKfAv+qxW5huKtpqDlvaxmTUzL/3pQNZ Z0+g== 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=8MPSzvCE9W7r+xvCSEaTEpM9zgf3lmCs20BXaX/kn3Q=; b=nqFBhKHfkyU7Auz1sEi6yiQ004Y6XqNL37K9rKu1wS5QOIOf841jL9L+fs0N+ErxPj uq9n+m01p3cVc6k6QyKpAeUh4sRp7KvcpeqphlwqQYVv6f3S+f1mSFLXU+0RV0qN4MW3 U+MGBpBtqa32kGILVXR7lf1W1xwYSXjYOjEAQkWrj/ZY4mdfPoG5uGSkUAnlhe1MvT5k iCFTXX1/5NUcsRi2H6L7/oYWmTDrCUl+XmGxLr+t636ZKRmG+U7Loc5juwfe/mPv1wFJ KErq/fxDswq5xgw6yz4dsB0jwek47KiGBBOY4GcWiCfqNDhBcdnVKmULFfsxQA3epBPQ NAtg== X-Gm-Message-State: APjAAAWGRovYu+1FXN+kdBkq45IoQDIEvx5Uk+S9OlYeVACaZbqPyjkB RwWXJrPRVC/Ka2EY+kWwTkuRNyGH9MLwFErTC4xBinMvcCE= X-Google-Smtp-Source: APXvYqyS9UybDNZ8YM6bvLTf/mTKllpvscV83Hj4QgSqKPbyntgwgSX6yKcr+JJrMjBuyvZV5TVqQMVFsKARlgvg8dE= X-Received: by 2002:a5d:6144:: with SMTP id y4mr12408208wrt.367.1578592646050; Thu, 09 Jan 2020 09:57:26 -0800 (PST) MIME-Version: 1.0 References: <20200109150752.28098-1-mario.kleiner.de@gmail.com> <20200109152656.GP1208@intel.com> <20200109153815.GQ1208@intel.com> <20200109164715.GD13686@intel.com> In-Reply-To: <20200109164715.GD13686@intel.com> From: Mario Kleiner Date: Thu, 9 Jan 2020 18:57:14 +0100 Message-ID: To: =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= 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, intel-gfx , dri-devel , Daniel Vetter Content-Type: multipart/mixed; boundary="===============1615741302==" Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" --===============1615741302== Content-Type: multipart/alternative; boundary="000000000000e9b823059bb8bd72" --000000000000e9b823059bb8bd72 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 9, 2020 at 5:47 PM Ville Syrj=C3=A4l=C3=A4 wrote: > On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kleiner wrote: > > On Thu, Jan 9, 2020 at 4:38 PM Ville Syrj=C3=A4l=C3=A4 < > ville.syrjala@linux.intel.com> > > wrote: > > > > > On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrj=C3=A4l=C3=A4 wro= te: > > > > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrote: > > > > > The panel reports 10 bpc color depth in its EDID, and the UEFI > > > > > firmware chooses link settings at boot which support enough > > > > > bandwidth for 10 bpc (324000 kbit/sec to be precise), but the > > > > > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as possible, > > > > > > Does it actually or do we just ignore the fact that it reports > 3.24Gbps? > > > > > > If it really reports 3.24 then we should be able to just add that to > > > dp_rates[] in intel_dp_set_sink_rates() and be done with it. > > > > > > Although we'd likely want to skip 3.24 unless it really is reported > > > as the max so as to not use that non-standard rate on other displays. > > > So would require a bit fancier logic for that. > > > > > > > > Was also my initial thought, but the DP_MAX_LINK_RATE reg reports 2.7 > Gbps > > as maximum. > > So dpcd[0x1] =3D=3D 0xa ? > > Yes. [*] > What about the magic second version of DP_MAX_LINK_RATE at 0x2201 ? > Hmm. I guess we should already be reading that via > intel_dp_extended_receiver_capabilities(). > Yes, you do. [*] Well, i have to recheck on the machine. I started this work on the AMD side and checked what AMD DC gave me, haven't rechecked stuff under i915 that i already knew from AMD. Comparing the implementations, there's some peculiar differences that may matter: intel_dp_extended_receiver_capabilities() is more "paranoid" than AMD DC's retrieve_link_cap() function in deciding if the extended receiver caps are valid. Intels implementation copies only the first 6 Bytes of extended receiver caps into the dpcd[] arrays, whereas AMD copies 16 Bytes. Not sure about the differences, but one of you may wanna check why this is, and if it matters somehow. Btw. your proposed /* blah */ if (max_rate > ...) wouldn't work if dpcd[0x1] =3D=3D 0xa, which it likely is [*]. AMD DC identified it as DP 1.1, eDP 1.3, and these extended caps seem to be only part of DP 1.3+ if i understand the comments in intel_dp_extended_receiver_capabilities() correctly. -mario > > -- > Ville Syrj=C3=A4l=C3=A4 > Intel > --000000000000e9b823059bb8bd72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 9, 2020 at 5:47 PM Ville = Syrj=C3=A4l=C3=A4 <vill= e.syrjala@linux.intel.com> wrote:
On Thu, Jan 09, 2020 at 05:30:05PM +0100, Mario Kl= einer wrote:
> On Thu, Jan 9, 2020 at 4:38 PM Ville Syrj=C3=A4l=C3=A4 <ville.syrjala@linux= .intel.com>
> wrote:
>
> > On Thu, Jan 09, 2020 at 05:26:57PM +0200, Ville Syrj=C3=A4l=C3=A4= wrote:
> > > On Thu, Jan 09, 2020 at 04:07:52PM +0100, Mario Kleiner wrot= e:
> > > > The panel reports 10 bpc color depth in its EDID, and t= he UEFI
> > > > firmware chooses link settings at boot which support en= ough
> > > > bandwidth for 10 bpc (324000 kbit/sec to be precise), b= ut the
> > > > DP_MAX_LINK_RATE dpcd register only reports 2.7 Gbps as= possible,
> >
> > Does it actually or do we just ignore the fact that it reports 3.= 24Gbps?
> >
> > If it really reports 3.24 then we should be able to just add that= to
> > dp_rates[] in intel_dp_set_sink_rates() and be done with it.
> >
> > Although we'd likely want to skip 3.24 unless it really is re= ported
> > as the max so as to not use that non-standard rate on other displ= ays.
> > So would require a bit fancier logic for that.
> >
> >
> Was also my initial thought, but the DP_MAX_LINK_RATE reg reports 2.7 = Gbps
> as maximum.

So dpcd[0x1] =3D=3D 0xa ?


Yes. [*]
=C2=A0
What about the magic second version of DP_MAX_LINK_RATE at 0x2201 ?
Hmm. I guess we should already be reading that via
intel_dp_extended_receiver_capabilities().

<= div>Yes, you do.

[*] Well, i have to recheck on th= e machine. I started this work on the AMD side and checked what AMD DC gave= me, haven't rechecked stuff under i915 that i already knew from AMD. C= omparing the implementations, there's some peculiar differences that ma= y matter:

intel_dp_extended_receiver_capabilities(= ) is more "paranoid" than AMD DC's retrieve_link_cap() functi= on in deciding if the extended receiver caps are valid. Intels implementati= on copies only the first 6 Bytes of extended receiver caps into the dpcd[] = arrays, whereas AMD copies 16 Bytes. Not sure about the differences, but on= e of you may wanna check why this is, and if it matters somehow.
=
Btw. your proposed

/* blah */=
if (max_rate > ...)

wouldn't wor= k if dpcd[0x1] =3D=3D 0xa, which it likely is [*]. AMD DC identified it as = DP 1.1, eDP 1.3, and these extended caps seem to be only part of DP 1.3+ if= i understand the comments in intel_dp_extended_receiver_capabilities() cor= rectly.

-mario

=C2=A0

--
Ville Syrj=C3=A4l=C3=A4
Intel
--000000000000e9b823059bb8bd72-- --===============1615741302== 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 --===============1615741302==--