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:   Thu, 3 Sep 2020 15:37:02 +0300
From:   Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
To:     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>,
        Jonathan Marek <jonathan@...ek.ca>,
        Rob Clark <robdclark@...omium.org>
Subject: Re: [PATCH v1 6/9] phy: qcom-qmp: Add support for DP in USB3+DP combo
 phy

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



-- 
With best wishes
Dmitry

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ