On 6/24/2022 4:12 PM, Stephen Boyd wrote:
Quoting Kuogee Hsieh (2022-06-24 15:53:45)
MSM_DP_CONTROLLER_1 need to match to the index = 1 of sc7280_dp_cfg[] <== This is correct
The problem is sc7280_dp_cfg[] have two entries since eDP place at index
of MSM_DP_CONTROLLER_1.
but .num_desc = 1 <== this said only have one entry at sc7280_dp_cfg[]
table. Therefore eDP will never be found at for loop at
_dpu_kms_initialize_displayport().
Yes, but what else does the MSM_DP_CONTROLLER_1 need to match? Because
the intention of the previous commit was to make it so the order of
sc7280_dp_cfg couldn't be messed up and not match the
MSM_DP_CONTROLLER_1 value that lives in sc7280_intf[].
at _dpu_kms_initialize_displayport()
- info.h_tile_instance[0] = i; <== assign i to become dp controller id, "i" is index of scxxxx_dp_cfg[]
This what I mean MSM_DP_CONTROLLER_1 need to match to index = 1 of
scxxxx_dp_cfg[].
it it is not match, then MSM_DP_CONTROLLER_1 with match to different INTF.
Sorry, my mistake. it is not in drm_bridge_add.
It should be in dpu_encoder_init() of _dpu_kms_initialize_displayport().
can you make below changes (patch) to _dpu_kms_initialize_displayport().
Yes, I've made that change to try to understand the problem. I still
don't understand, sadly. Does flipping the order of iteration through
'priv->dp' somehow mean that the crtc that is assigned to the eDP
connector is left unchanged? Whereas without registering the eDP encoder
first means we have to change the crtc for the eDP encoder and that
can't be done atomically?
