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, 4 Sep 2020 00:35:38 +0300
From:   Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To:     Jonathan Marek <jonathan@...ek.ca>,
        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 03/09/2020 15:41, Jonathan Marek wrote:
> 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?

Firmware sources.


-- 
With best wishes
Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ