linux-kernel - Re: [PATCH v1 2/3] drm/msm/dp: decoupling dp->id out of dp controller_id at scxxxx_dp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 24 Jun 2022 14:17:50 -0700
From:   Kuogee Hsieh <quic_khsieh@...cinc.com>
To:     Stephen Boyd <swboyd@...omium.org>, <agross@...nel.org>,
        <airlied@...ux.ie>, <bjorn.andersson@...aro.org>,
        <daniel@...ll.ch>, <dianders@...omium.org>,
        <dmitry.baryshkov@...aro.org>, <dri-devel@...ts.freedesktop.org>,
        <robdclark@...il.com>, <sean@...rly.run>, <vkoul@...nel.org>
CC:     <quic_abhinavk@...cinc.com>, <quic_aravindh@...cinc.com>,
        <quic_sbillaka@...cinc.com>, <freedreno@...ts.freedesktop.org>,
        <linux-arm-msm@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1 2/3] drm/msm/dp: decoupling dp->id out of dp
 controller_id at scxxxx_dp_cfg table


On 6/24/2022 1:00 PM, Stephen Boyd wrote:
> Quoting Kuogee Hsieh (2022-06-24 10:15:11)
>> Current the index (dp->id) of DP descriptor table (scxxxx_dp_cfg[]) are tightly
>> coupled with DP controller_id. This means DP use controller id 0 must be placed
>> at first entry of DP descriptor table (scxxxx_dp_cfg[]). Otherwise the internal
>> INTF will mismatch controller_id. This will cause controller kickoff wrong
>> interface timing engine and cause dpu_encoder_phys_vid_wait_for_commit_done
>> vblank timeout error.
>>
>> This patch add controller_id field into struct msm_dp_desc to break the tightly
>> coupled relationship between index (dp->id) of DP descriptor table with DP
>> controller_id.
> Please no. This reverts the intention of commit bb3de286d992
> ("drm/msm/dp: Support up to 3 DP controllers")
>
>      A new enum is introduced to document the connection between the
>      instances referenced in the dpu_intf_cfg array and the controllers in
>      the DP driver and sc7180 is updated.
>
> It sounds like the intent of that commit failed to make a strong enough
> connection. Now it needs to match the INTF number as well? I can't
> really figure out what is actually wrong, because this patch undoes that
> intentional tight coupling. Is the next patch the important part that
> flips the order of the two interfaces?

The commit bb3de286d992have two problems,

1)  The below sc7280_dp_cfg will not work, if eDP use 
MSM_DP_CONTROLLER_2 instead of  MSM_DP_CONTROLLER_1

since it have num_descs =2 but eDP is at index 2 (CONTROLLER_2) which 
never be reached.

static const struct msm_dp_config sc7280_dp_cfg = {
         .descs = (const struct msm_dp_desc[]) {
                 [MSM_DP_CONTROLLER_2] = { .io_start = 0x0aea0000, 
.connector_type = DRM_MODE_CONNECTOR_eDP, .wide_bus_en = true },
                 [MSM_DP_CONTROLLER_0] = { .io_start = 0x0ae90000, 
.connector_type = DRM_MODE_CONNECTOR_DisplayPort, .wide_bus_en = true },
         },
         .num_descs = 2,
};

2)  DP always has index of 0 (dp->id = 0) and the first one to call 
msm_dp_modeset_init(). This make DP always place at head of bridge chain.

At next patch eDP must be placed at head of bridge chain to fix eDP 
corruption issue. This is the purpose of this patch. I will revise the 
commit text.