[PATCH] drm/dp: start using more of the extended receiver caps

[PATCH] drm/dp: start using more of the extended receiver caps

[Jani Nikula]

In the future, we'll be needing more of the extended receiver capability
field starting at DPCD address 0x2200. (Specifically, we'll need main
link channel coding cap for DP 2.0.) Start using it now to not miss out
later on.

Cc: Lyude Paul <lyude@redhat.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

---

I guess this can be merged after the topic branch to drm-misc-next or
so, but I'd prefer to have this fairly early on to catch any potential
issues.
---
 drivers/gpu/drm/drm_dp_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 1e7c638873c8..3a3c238452df 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -436,7 +436,7 @@ static u8 drm_dp_downstream_port_count(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
 static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
 					  u8 dpcd[DP_RECEIVER_CAP_SIZE])
 {
-	u8 dpcd_ext[6];
+	u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];
 	int ret;
 
 	/*
-- 
2.20.1

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Intel-gfx] [PATCH] drm/dp: start using more of the extended receiver caps

[Jani Nikula]

In the future, we'll be needing more of the extended receiver capability
field starting at DPCD address 0x2200. (Specifically, we'll need main
link channel coding cap for DP 2.0.) Start using it now to not miss out
later on.

Cc: Lyude Paul <lyude@redhat.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

---

I guess this can be merged after the topic branch to drm-misc-next or
so, but I'd prefer to have this fairly early on to catch any potential
issues.
---
 drivers/gpu/drm/drm_dp_helper.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 1e7c638873c8..3a3c238452df 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -436,7 +436,7 @@ static u8 drm_dp_downstream_port_count(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
 static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
 					  u8 dpcd[DP_RECEIVER_CAP_SIZE])
 {
-	u8 dpcd_ext[6];
+	u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];
 	int ret;
 
 	/*
-- 
2.20.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/dp: start using more of the extended receiver caps

[Patchwork]

[-- Attachment #1.1: Type: text/plain, Size: 4506 bytes --]

== Series Details ==

Series: drm/dp: start using more of the extended receiver caps
URL   : https://patchwork.freedesktop.org/series/81223/
State : failure

== Summary ==

CI Bug Log - changes from CI_DRM_8951 -> Patchwork_18428
====================================================

Summary
-------

  **FAILURE**

  Serious unknown changes coming with Patchwork_18428 absolutely need to be
  verified manually.
  
  If you think the reported changes have nothing to do with the changes
  introduced in Patchwork_18428, please notify your bug team to allow them
  to document this new failure mode, which will reduce false positives in CI.

  External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18428/index.html

Possible new issues
-------------------

  Here are the unknown changes that may have been introduced in Patchwork_18428:

### IGT changes ###

#### Possible regressions ####

  * igt@i915_selftest@live@gem_contexts:
    - fi-cfl-8109u:       [PASS][1] -> [INCOMPLETE][2]
   [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-cfl-8109u/igt@i915_selftest@live@gem_contexts.html
   [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18428/fi-cfl-8109u/igt@i915_selftest@live@gem_contexts.html

  
Known issues
------------

  Here are the changes found in Patchwork_18428 that come from known issues:

### IGT changes ###

#### Issues hit ####

  * igt@i915_pm_rpm@basic-pci-d3-state:
    - fi-bsw-kefka:       [PASS][3] -> [DMESG-WARN][4] ([i915#1982])
   [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-bsw-kefka/igt@i915_pm_rpm@basic-pci-d3-state.html
   [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18428/fi-bsw-kefka/igt@i915_pm_rpm@basic-pci-d3-state.html

  * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
    - fi-byt-j1900:       [PASS][5] -> [DMESG-WARN][6] ([i915#1982])
   [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-byt-j1900/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
   [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18428/fi-byt-j1900/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
    - fi-icl-u2:          [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
   [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-icl-u2/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html
   [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18428/fi-icl-u2/igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic.html

  
#### Possible fixes ####

  * igt@i915_selftest@live@execlists:
    - fi-icl-y:           [INCOMPLETE][9] ([i915#2276]) -> [PASS][10]
   [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-icl-y/igt@i915_selftest@live@execlists.html
   [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18428/fi-icl-y/igt@i915_selftest@live@execlists.html

  * igt@i915_selftest@live@gem_contexts:
    - fi-cml-s:           [INCOMPLETE][11] -> [PASS][12]
   [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-cml-s/igt@i915_selftest@live@gem_contexts.html
   [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18428/fi-cml-s/igt@i915_selftest@live@gem_contexts.html

  
#### Warnings ####

  * igt@i915_pm_rpm@module-reload:
    - fi-kbl-guc:         [DMESG-WARN][13] ([i915#2203]) -> [DMESG-FAIL][14] ([i915#2203])
   [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8951/fi-kbl-guc/igt@i915_pm_rpm@module-reload.html
   [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18428/fi-kbl-guc/igt@i915_pm_rpm@module-reload.html

  
  [i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
  [i915#2203]: https://gitlab.freedesktop.org/drm/intel/issues/2203
  [i915#2276]: https://gitlab.freedesktop.org/drm/intel/issues/2276


Participating hosts (38 -> 33)
------------------------------

  Missing    (5): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-byt-clapper 


Build changes
-------------

  * Linux: CI_DRM_8951 -> Patchwork_18428

  CI-20190529: 20190529
  CI_DRM_8951: 5f8c53e35ef01a1d5e97db6005d3c308d3734bac @ git://anongit.freedesktop.org/gfx-ci/linux
  IGT_5775: 58cb0aea18fa471af43c11ee9f587554721a7815 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
  Patchwork_18428: 62d31449302e19443041547501eb72010c72d679 @ git://anongit.freedesktop.org/gfx-ci/linux


== Linux commits ==

62d31449302e drm/dp: start using more of the extended receiver caps

== Logs ==

For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_18428/index.html

[-- Attachment #1.2: Type: text/html, Size: 5484 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/dp: start using more of the extended receiver caps

[Lyude Paul]

On Tue, 2020-09-01 at 15:32 +0300, Jani Nikula wrote:
> In the future, we'll be needing more of the extended receiver capability
> field starting at DPCD address 0x2200. (Specifically, we'll need main
> link channel coding cap for DP 2.0.) Start using it now to not miss out
> later on.
> 
> Cc: Lyude Paul <lyude@redhat.com>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> 
> ---
> 
> I guess this can be merged after the topic branch to drm-misc-next or
> so, but I'd prefer to have this fairly early on to catch any potential
> issues.
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 1e7c638873c8..3a3c238452df 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -436,7 +436,7 @@ static u8 drm_dp_downstream_port_count(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
>  static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
>  					  u8 dpcd[DP_RECEIVER_CAP_SIZE])
>  {
> -	u8 dpcd_ext[6];
> +	u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];

Not 100% sure this is right? It's not clear at first glance of the 2.0 spec, but
my assumption would be that on < DP2.0 devices that everything but those first 6
bytes are zeroed out in the extended DPRX field. Since we memcpy() dpcd_ext
using sizeof(dpcd_ext), we'd potentially end up zeroing out all of the DPCD caps
that comes after those 6 bytes.

>  	int ret;
>  
>  	/*
-- 
Sincerely,
      Lyude Paul (she/her)
      Software Engineer at Red Hat

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/dp: start using more of the extended receiver caps

[Lyude Paul]

On Tue, 2020-09-01 at 15:32 +0300, Jani Nikula wrote:
> In the future, we'll be needing more of the extended receiver capability
> field starting at DPCD address 0x2200. (Specifically, we'll need main
> link channel coding cap for DP 2.0.) Start using it now to not miss out
> later on.
> 
> Cc: Lyude Paul <lyude@redhat.com>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> 
> ---
> 
> I guess this can be merged after the topic branch to drm-misc-next or
> so, but I'd prefer to have this fairly early on to catch any potential
> issues.
> ---
>  drivers/gpu/drm/drm_dp_helper.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 1e7c638873c8..3a3c238452df 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -436,7 +436,7 @@ static u8 drm_dp_downstream_port_count(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
>  static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
>  					  u8 dpcd[DP_RECEIVER_CAP_SIZE])
>  {
> -	u8 dpcd_ext[6];
> +	u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];

Not 100% sure this is right? It's not clear at first glance of the 2.0 spec, but
my assumption would be that on < DP2.0 devices that everything but those first 6
bytes are zeroed out in the extended DPRX field. Since we memcpy() dpcd_ext
using sizeof(dpcd_ext), we'd potentially end up zeroing out all of the DPCD caps
that comes after those 6 bytes.

>  	int ret;
>  
>  	/*
-- 
Sincerely,
      Lyude Paul (she/her)
      Software Engineer at Red Hat

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/dp: start using more of the extended receiver caps

[Jani Nikula]

On Tue, 01 Sep 2020, Lyude Paul <lyude@redhat.com> wrote:
> On Tue, 2020-09-01 at 15:32 +0300, Jani Nikula wrote:
>> In the future, we'll be needing more of the extended receiver capability
>> field starting at DPCD address 0x2200. (Specifically, we'll need main
>> link channel coding cap for DP 2.0.) Start using it now to not miss out
>> later on.
>> 
>> Cc: Lyude Paul <lyude@redhat.com>
>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>> 
>> ---
>> 
>> I guess this can be merged after the topic branch to drm-misc-next or
>> so, but I'd prefer to have this fairly early on to catch any potential
>> issues.
>> ---
>>  drivers/gpu/drm/drm_dp_helper.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
>> index 1e7c638873c8..3a3c238452df 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>> @@ -436,7 +436,7 @@ static u8 drm_dp_downstream_port_count(const u8
>> dpcd[DP_RECEIVER_CAP_SIZE])
>>  static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
>>  					  u8 dpcd[DP_RECEIVER_CAP_SIZE])
>>  {
>> -	u8 dpcd_ext[6];
>> +	u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];
>
> Not 100% sure this is right? It's not clear at first glance of the 2.0 spec, but
> my assumption would be that on < DP2.0 devices that everything but those first 6
> bytes are zeroed out in the extended DPRX field. Since we memcpy() dpcd_ext
> using sizeof(dpcd_ext), we'd potentially end up zeroing out all of the DPCD caps
> that comes after those 6 bytes.

Re-reading stuff... AFAICT everything in 0x2200..0x220F should be
valid. They should match what's in 0x0000..0x000F except for 0x0000,
0x0001, and 0x0005, for backwards compatibility.

Apparently there are no such backwards compatibility concerns with the
other receiver cap fields then.

But it gives me an uneasy feeling that many places in the spec refer to
0x2200+ even though they should per spec be the same in 0x0000+.

I guess we can try without the change, and fix later if we hit issues.


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

Re: [Intel-gfx] [PATCH] drm/dp: start using more of the extended receiver caps

[Jani Nikula]

On Tue, 01 Sep 2020, Lyude Paul <lyude@redhat.com> wrote:
> On Tue, 2020-09-01 at 15:32 +0300, Jani Nikula wrote:
>> In the future, we'll be needing more of the extended receiver capability
>> field starting at DPCD address 0x2200. (Specifically, we'll need main
>> link channel coding cap for DP 2.0.) Start using it now to not miss out
>> later on.
>> 
>> Cc: Lyude Paul <lyude@redhat.com>
>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>> 
>> ---
>> 
>> I guess this can be merged after the topic branch to drm-misc-next or
>> so, but I'd prefer to have this fairly early on to catch any potential
>> issues.
>> ---
>>  drivers/gpu/drm/drm_dp_helper.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
>> index 1e7c638873c8..3a3c238452df 100644
>> --- a/drivers/gpu/drm/drm_dp_helper.c
>> +++ b/drivers/gpu/drm/drm_dp_helper.c
>> @@ -436,7 +436,7 @@ static u8 drm_dp_downstream_port_count(const u8
>> dpcd[DP_RECEIVER_CAP_SIZE])
>>  static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
>>  					  u8 dpcd[DP_RECEIVER_CAP_SIZE])
>>  {
>> -	u8 dpcd_ext[6];
>> +	u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];
>
> Not 100% sure this is right? It's not clear at first glance of the 2.0 spec, but
> my assumption would be that on < DP2.0 devices that everything but those first 6
> bytes are zeroed out in the extended DPRX field. Since we memcpy() dpcd_ext
> using sizeof(dpcd_ext), we'd potentially end up zeroing out all of the DPCD caps
> that comes after those 6 bytes.

Re-reading stuff... AFAICT everything in 0x2200..0x220F should be
valid. They should match what's in 0x0000..0x000F except for 0x0000,
0x0001, and 0x0005, for backwards compatibility.

Apparently there are no such backwards compatibility concerns with the
other receiver cap fields then.

But it gives me an uneasy feeling that many places in the spec refer to
0x2200+ even though they should per spec be the same in 0x0000+.

I guess we can try without the change, and fix later if we hit issues.


BR,
Jani.

-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/dp: start using more of the extended receiver caps

[Lyude Paul]

On Tue, 2020-09-01 at 21:01 +0300, Jani Nikula wrote:
> On Tue, 01 Sep 2020, Lyude Paul <lyude@redhat.com> wrote:
> > On Tue, 2020-09-01 at 15:32 +0300, Jani Nikula wrote:
> > > In the future, we'll be needing more of the extended receiver capability
> > > field starting at DPCD address 0x2200. (Specifically, we'll need main
> > > link channel coding cap for DP 2.0.) Start using it now to not miss out
> > > later on.
> > > 
> > > Cc: Lyude Paul <lyude@redhat.com>
> > > Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> > > 
> > > ---
> > > 
> > > I guess this can be merged after the topic branch to drm-misc-next or
> > > so, but I'd prefer to have this fairly early on to catch any potential
> > > issues.
> > > ---
> > >  drivers/gpu/drm/drm_dp_helper.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > b/drivers/gpu/drm/drm_dp_helper.c
> > > index 1e7c638873c8..3a3c238452df 100644
> > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > @@ -436,7 +436,7 @@ static u8 drm_dp_downstream_port_count(const u8
> > > dpcd[DP_RECEIVER_CAP_SIZE])
> > >  static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
> > >  					  u8 dpcd[DP_RECEIVER_CAP_SIZE])
> > >  {
> > > -	u8 dpcd_ext[6];
> > > +	u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];
> > 
> > Not 100% sure this is right? It's not clear at first glance of the 2.0
> > spec, but
> > my assumption would be that on < DP2.0 devices that everything but those
> > first 6
> > bytes are zeroed out in the extended DPRX field. Since we memcpy()
> > dpcd_ext
> > using sizeof(dpcd_ext), we'd potentially end up zeroing out all of the
> > DPCD caps
> > that comes after those 6 bytes.
> 
> Re-reading stuff... AFAICT everything in 0x2200..0x220F should be
> valid. They should match what's in 0x0000..0x000F except for 0x0000,
> 0x0001, and 0x0005, for backwards compatibility.
> 
> Apparently there are no such backwards compatibility concerns with the
> other receiver cap fields then.
> 
> But it gives me an uneasy feeling that many places in the spec refer to
> 0x2200+ even though they should per spec be the same in 0x0000+.
> 
> I guess we can try without the change, and fix later if we hit issues.

I'm fine with the change if it doesn't break things btw - just as long as
we're making sure that we don't zero things out by accident
> 
> 
> BR,
> Jani.
> 
-- 
Cheers,
	Lyude Paul (she/her)
	Software Engineer at Red Hat

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH] drm/dp: start using more of the extended receiver caps

[Lyude Paul]

On Tue, 2020-09-01 at 21:01 +0300, Jani Nikula wrote:
> On Tue, 01 Sep 2020, Lyude Paul <lyude@redhat.com> wrote:
> > On Tue, 2020-09-01 at 15:32 +0300, Jani Nikula wrote:
> > > In the future, we'll be needing more of the extended receiver capability
> > > field starting at DPCD address 0x2200. (Specifically, we'll need main
> > > link channel coding cap for DP 2.0.) Start using it now to not miss out
> > > later on.
> > > 
> > > Cc: Lyude Paul <lyude@redhat.com>
> > > Signed-off-by: Jani Nikula <jani.nikula@intel.com>
> > > 
> > > ---
> > > 
> > > I guess this can be merged after the topic branch to drm-misc-next or
> > > so, but I'd prefer to have this fairly early on to catch any potential
> > > issues.
> > > ---
> > >  drivers/gpu/drm/drm_dp_helper.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/drm_dp_helper.c
> > > b/drivers/gpu/drm/drm_dp_helper.c
> > > index 1e7c638873c8..3a3c238452df 100644
> > > --- a/drivers/gpu/drm/drm_dp_helper.c
> > > +++ b/drivers/gpu/drm/drm_dp_helper.c
> > > @@ -436,7 +436,7 @@ static u8 drm_dp_downstream_port_count(const u8
> > > dpcd[DP_RECEIVER_CAP_SIZE])
> > >  static int drm_dp_read_extended_dpcd_caps(struct drm_dp_aux *aux,
> > >  					  u8 dpcd[DP_RECEIVER_CAP_SIZE])
> > >  {
> > > -	u8 dpcd_ext[6];
> > > +	u8 dpcd_ext[DP_RECEIVER_CAP_SIZE];
> > 
> > Not 100% sure this is right? It's not clear at first glance of the 2.0
> > spec, but
> > my assumption would be that on < DP2.0 devices that everything but those
> > first 6
> > bytes are zeroed out in the extended DPRX field. Since we memcpy()
> > dpcd_ext
> > using sizeof(dpcd_ext), we'd potentially end up zeroing out all of the
> > DPCD caps
> > that comes after those 6 bytes.
> 
> Re-reading stuff... AFAICT everything in 0x2200..0x220F should be
> valid. They should match what's in 0x0000..0x000F except for 0x0000,
> 0x0001, and 0x0005, for backwards compatibility.
> 
> Apparently there are no such backwards compatibility concerns with the
> other receiver cap fields then.
> 
> But it gives me an uneasy feeling that many places in the spec refer to
> 0x2200+ even though they should per spec be the same in 0x0000+.
> 
> I guess we can try without the change, and fix later if we hit issues.

I'm fine with the change if it doesn't break things btw - just as long as
we're making sure that we don't zero things out by accident
> 
> 
> BR,
> Jani.
> 
-- 
Cheers,
	Lyude Paul (she/her)
	Software Engineer at Red Hat

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [PATCH] drm/dp: start using more of the extended receiver caps

[Jani Nikula]

On Mon, 21 Sep 2020, Lyude Paul <lyude@redhat.com> wrote:
> On Tue, 2020-09-01 at 21:01 +0300, Jani Nikula wrote:
>> I guess we can try without the change, and fix later if we hit issues.
>
> I'm fine with the change if it doesn't break things btw - just as long as
> we're making sure that we don't zero things out by accident

My conclusion was to go without, it's a trivial change to add
afterwards as needed.

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

Re: [Intel-gfx] [PATCH] drm/dp: start using more of the extended receiver caps

[Jani Nikula]

On Mon, 21 Sep 2020, Lyude Paul <lyude@redhat.com> wrote:
> On Tue, 2020-09-01 at 21:01 +0300, Jani Nikula wrote:
>> I guess we can try without the change, and fix later if we hit issues.
>
> I'm fine with the change if it doesn't break things btw - just as long as
> we're making sure that we don't zero things out by accident

My conclusion was to go without, it's a trivial change to add
afterwards as needed.

BR,
Jani.




-- 
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx