drm/mst: Refactor the flow for payload allocation/removement
[Why] Today, the allocation/deallocation steps and status is a bit unclear. For instance, payload->vc_start_slot = -1 stands for "the failure of updating DPCD payload ID table" and can also represent as "payload is not allocated yet". These two cases should be handled differently and hence better to distinguish them for better understanding. [How] Define enumeration - ALLOCATION_LOCAL, ALLOCATION_DFP and ALLOCATION_REMOTE to distinguish different allocation status. Adjust the code to handle different status accordingly for better understanding the sequence of payload allocation and payload removement. For payload creation, the procedure should look like this: DRM part 1: * step 1 - update sw mst mgr variables to add a new payload * step 2 - add payload at immediate DFP DPCD payload table Driver: * Add new payload in HW and sync up with DFP by sending ACT DRM Part 2: * Send ALLOCATE_PAYLOAD sideband message to allocate bandwidth along the virtual channel. And as for payload removement, the procedure should look like this: DRM part 1: * step 1 - Send ALLOCATE_PAYLOAD sideband message to release bandwidth along the virtual channel * step 2 - Clear payload allocation at immediate DFP DPCD payload table Driver: * Remove the payload in HW and sync up with DFP by sending ACT DRM part 2: * update sw mst mgr variables to remove the payload Note that it's fine to fail when communicate with the branch device connected at immediate downstrean-facing port, but updating variables of SW mst mgr and HW configuration should be conducted anyway. That's because it's under commit_tail and we need to complete the HW programming. Changes since v1: * Remove the set but not use variable 'old_payload' in function 'nv50_msto_prepare'. Catched by kernel test robot <lkp@intel.com> Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230807025639.1612361-3-Wayne.Lin@amd.com
Showing
This diff is collapsed.
Please register or sign in to comment