linux-kernel - Re: [PATCH v1 6/9] phy: qcom-qmp: Add support for DP in USB3+DP combo phy

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 for Android: free password hash cracker in your pocket

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

Message-ID: <4165cdc6-dfa6-1ff2-f317-753292a068c2@marek.ca>
Date:   Thu, 3 Sep 2020 08:41:15 -0400
From:   Jonathan Marek <jonathan@...ek.ca>
To:     Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Kishon Vijay Abraham I <kishon@...com>,
        Vinod Koul <vkoul@...nel.org>
Cc:     linux-kernel@...r.kernel.org, linux-arm-msm@...r.kernel.org,
        Jeykumar Sankaran <jsanka@...eaurora.org>,
        Chandan Uddaraju <chandanu@...eaurora.org>,
        Vara Reddy <varar@...eaurora.org>,
        Tanmay Shah <tanmay@...eaurora.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        Manu Gautam <mgautam@...eaurora.org>,
        Sandeep Maheswaram <sanm@...eaurora.org>,
        Douglas Anderson <dianders@...omium.org>,
        Sean Paul <seanpaul@...omium.org>,
        Stephen Boyd <sboyd@...nel.org>,
        Rob Clark <robdclark@...omium.org>
Subject: Re: [PATCH v1 6/9] phy: qcom-qmp: Add support for DP in USB3+DP combo
 phy

On 9/3/20 8:37 AM, Dmitry Baryshkov wrote:
> On 02/09/2020 04:01, Stephen Boyd wrote:
>> Quoting Dmitry Baryshkov (2020-09-01 06:36:34)
>>> With these functions I'm struggling between introducing
>>> PHY_TYPE_DP_V3/V4 and introducing callbacks into qmp_phy_cfg. What would
>>> you prefer?
>>>
>>> What about the following struct?
>>>
>>> struct qmp_phy_dp_opts {
>>>          void (*dp_aux_init)(struct qmp_phy *qphy);
>>>          void (*dp_configure_tx)(struct qmp_phy *qphy);
>>>          void (*dp_configure_lanes)(struct qmp_phy *qphy);
>>> };
>>>
>>> I'm not sure about dp_calibrate().
>>>
>>
>> Is there v4 code somewhere that I can see? Another level of indirection
>> is always a solution, so it is probably fine. This driver is currently
>> written with many conditionals instead of function tables so I'm not
>> sure it fits in with the style of how things are done though. The
>> alternative is to use an enum and call different functions?
> 
> Downstream DP driver sources can be found here:
> https://source.codeaurora.org/quic/la/platform/vendor/opensource/display-drivers/tree/msm/dp/dp_catalog_v420.c?h=LA.UM.8.12.r1-13900-sm8250.0 
> 
> 
> https://source.codeaurora.org/quic/la/platform/vendor/opensource/display-drivers/tree/pll/dp_pll_7nm_util.c?h=LA.UM.8.12.r1-13900-sm8250.0 
> 
> 
>>
>> The calibrate call is there to "turn the crank" on the aux settings.  I
>> need to cycle through the different values for that aux register so that
>> aux can be tuned properly. The AUX channel really has another phy that
>> needs tuning so we're sort of combining the aux and DP link phy together
>> here by letting the calibrate call tune the AUX phy and the configure
>> call tune the DP phy. I don't see any sort of concept of an AUX phy
>> though so this seemed ok. Does v4 need to tune more registers?
> 
> 
> It looks like four values are written to AUX_CFG1:
> 0x20, 0x13, 0x23, 0x1d
> 

AFAICT, it only writes 0x13 to AUX_CFG1, in dp_pll_7nm_util.c, and the 
qcom,aux-cfg1-settings in dts only has 0x13. Same for all other 
AUX_CFGn, which only have one value written. Am I missing something?