drm/dp_mst: Clear all payload id tables downstream when initializing
It seems that on certain MST hubs, namely the CableMatters USB-C 2x DP hub, using the DP_PAYLOAD_ALLOCATE_SET and DP_PAYLOAD_TABLE_UPDATE_STATUS register ranges to clear any pre-existing payload allocations on the hub isn't always enough to reset things if the source device has been reset unexpectedly. Or at least, that's the current running theory. The precise behavior appears to be that when the source device gets reset unexpectedly, the hub begins reporting an available_pbn value of 0 for all of its ports. This is a bit inconsistent with the our theory, since this seems to happen even if previously set PBN allocations should have resulted in a non-zero available_pbn value. So, it's possible that something else may be going on here. Strangely though, sending a CLEAR_PAYLOAD_ID_TABLE broadcast request when initializing the MST topology seems to bring things into working order and make available_pbn work again. Since this is a pretty safe solution, let's go ahead and implement it. Changes since v1: * Change indenting on drm_dp_send_clear_payload_id_table() prototype * Remove some braces in drm_dp_send_clear_payload_id_table() * Reorganize some variable declarations in drm_dp_send_clear_payload_id_table() * Don't forget to handle DP_CLEAR_PAYLOAD_ID_TABLE in drm_dp_sideband_parse_reply() * Move drm_dp_send_clear_payload_id_table() call into drm_dp_mst_link_probe_work(), since we can't send sideband messages while under lock in drm_dp_mst_topology_mgr_set_mst() * Change commit message Acked-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190829000944.20722-1-lyude@redhat.com
Showing
Please register or sign in to comment