On Wed, 25 Aug 2021, Jani Nikula jani.nikula@intel.com wrote:
On Thu, 19 Aug 2021, Ville Syrjälä ville.syrjala@linux.intel.com wrote:
On Fri, Aug 13, 2021 at 01:43:20PM +0300, Jani Nikula wrote:
Extend the use of extended receiver cap at 0x2200 to cover MAIN_LINK_CHANNEL_CODING_CAP in 0x2206, in case an implementation hides the DP 2.0 128b/132b channel encoding cap.
Cc: Manasi Navare manasi.d.navare@intel.com Signed-off-by: Jani Nikula jani.nikula@intel.com
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 9b2a2961fca8..9389f92cb944 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -608,7 +608,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_MAIN_LINK_CHANNEL_CODING + 1];
Why are we even reading less of this than the normal receiver caps?
Good question. I forget my reasoning to only extend to what might affect this use case. Should we extend to the size of the usual receiver caps?
Ah, there was a previous discussion [1] with Lyude (Cc'd).
BR, Jani.
[1] https://patchwork.freedesktop.org/patch/msgid/20200901123226.4177-1-jani.nik...
BR, Jani.
int ret;
/*
2.20.1