linux-kernel - Re: [PATCH v4 4/5] arm64: dts: sdm845: Add OPP tables and power-domains for venus

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: <159596607146.1360974.8446772748472044390@swboyd.mtv.corp.google.com>
Date:   Tue, 28 Jul 2020 12:54:31 -0700
From:   Stephen Boyd <sboyd@...nel.org>
To:     Rajendra Nayak <rnayak@...eaurora.org>,
        Viresh Kumar <viresh.kumar@...aro.org>
Cc:     Stanimir Varbanov <stanimir.varbanov@...aro.org>,
        robh+dt@...nel.org, agross@...nel.org, bjorn.andersson@...aro.org,
        linux-arm-msm@...r.kernel.org, linux-media@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
        mka@...omium.org, Taniya Das <tdas@...eaurora.org>
Subject: Re: [PATCH v4 4/5] arm64: dts: sdm845: Add OPP tables and power-domains for venus

Quoting Rajendra Nayak (2020-07-27 21:17:28)
> 
> On 7/28/2020 6:22 AM, Stephen Boyd wrote:
> > Quoting Viresh Kumar (2020-07-27 08:38:06)
> >> On 27-07-20, 17:38, Rajendra Nayak wrote:
> >>> On 7/27/2020 11:23 AM, Rajendra Nayak wrote:
> >>>> On 7/24/2020 7:39 PM, Stanimir Varbanov wrote:
> >>>>>>> +
> >>>>>>> +                opp-533000000 {
> >>>>>>> +                    opp-hz = /bits/ 64 <533000000>;
> >>
> >> Is this the highest OPP in table ?
> >>
> >>>>> Actually it comes from videocc, where ftbl_video_cc_venus_clk_src
> >>>>> defines 533000000 but the real calculated freq is 533000097.
> >>>>
> >>>> I still don't quite understand why the videocc driver returns this
> >>>> frequency despite this not being in the freq table.
> >>>
> >>> Ok, so I see the same issue on sc7180 also. clk_round_rate() does seem to
> >>> return whats in the freq table, but clk_set_rate() goes ahead and sets it
> > 
> > I'm happy to see clk_round_rate() return the actual rate that would be
> > achieved and not just the rate that is in the frequency tables. Would
> > that fix the problem? 
> 
> It would, but only if I also update the OPP table to have 533000097
> instead of 533000000 (which I guess is needed anyway)
> If this is the actual frequency that's achievable, then perhaps even the clock
> freq table should have this? 533000097 and not 533000000?
> That way clk_round_rate() would return the actual rate that's achieved and
> we don't need any extra math. Isn't that the reason these freq tables exist
> anyway.

Yes the freq tables are there in the clk driver so we don't have to do a
bunch of math. Fixing them to be accurate has been deemed "hard" from
what I recall because the tables are generated from some math function
that truncates the lower Hertz values.