linux-kernel - Re: [PATCH v4 09/10] clk: qcom: dispcc: Update DP clk ops for phy design

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]

Message-ID: <160080070307.310579.1550032345045011322@swboyd.mtv.corp.google.com>
Date:   Tue, 22 Sep 2020 11:51:43 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     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 <swboyd@...omium.org>,
        Jonathan Marek <jonathan@...ek.ca>,
        Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
        Rob Clark <robdclark@...omium.org>
Subject: Re: [PATCH v4 09/10] clk: qcom: dispcc: Update DP clk ops for phy design

Quoting Stephen Boyd (2020-09-16 16:12:01)
> The clk_rcg2_dp_determine_rate() function is used for the DP pixel clk.
> This function should return the rate that can be achieved by the pixel
> clk in 'struct clk_rate_request::rate' and match the logic similar to
> what is seen in clk_rcg2_dp_set_rate(). But that isn't the case. Instead
> the code merely bubbles the rate request up to the parent of the pixel
> clk and doesn't try to do a rational approximation of the rate that
> would be achieved by picking some m/n value for the RCG.
> 
> Let's change this logic so that we can assume the parent clk frequency
> is fixed (it is because it's the VCO of the DP PLL that is configured
> based on the link rate) and so that we can calculate what the m/n value
> will be and adjust the req->rate appropriately.
> 
> Cc: Jeykumar Sankaran <jsanka@...eaurora.org>
> Cc: Chandan Uddaraju <chandanu@...eaurora.org>
> Cc: Vara Reddy <varar@...eaurora.org>
> Cc: Tanmay Shah <tanmay@...eaurora.org>
> Cc: Bjorn Andersson <bjorn.andersson@...aro.org>
> Cc: Manu Gautam <mgautam@...eaurora.org>
> Cc: Sandeep Maheswaram <sanm@...eaurora.org>
> Cc: Douglas Anderson <dianders@...omium.org>
> Cc: Sean Paul <seanpaul@...omium.org>
> Cc: Stephen Boyd <sboyd@...nel.org>
> Cc: Jonathan Marek <jonathan@...ek.ca>
> Cc: Dmitry Baryshkov <dmitry.baryshkov@...aro.org>
> Cc: Rob Clark <robdclark@...omium.org>
> Signed-off-by: Stephen Boyd <swboyd@...omium.org>
> ---

Applied to clk-next