linux-kernel - Re: [PATCH RESEND 0/5] cpufreq: ti-cpufreq: Enable AM625 CPUFreq

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] [day] [month] [year] [list]

Date:   Mon, 7 Nov 2022 15:32:04 +0530
From:   Viresh Kumar <viresh.kumar@...aro.org>
To:     Vibhore Vardhan <vibhore@...com>
Cc:     nm@...com, vigneshr@...com, kristo@...nel.org, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, rafael@...nel.org,
        linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org
Subject: Re: [PATCH RESEND 0/5] cpufreq: ti-cpufreq: Enable AM625 CPUFreq

On 01-11-22, 13:09, Vibhore Vardhan wrote:
> Apologies, resending because I botched the label in previous series.
> Please reply to this series rather than the one sent previously.
> 
> Hi,
> This series enables CPUFreq for AM625. This version is a fixup and
> rebase of the patch series by Dave Gerlach on v6.1-rc3 [1].
> 
> It updates the ti-cpufreq driver to support parsing of the speed grade
> value out of the JTAG_USER_ID register and adds necessary support code
> to use cpufreq-dt.
> 
> The operating-points table that gets added support 200,400,600,800 for
> all variants and then 1GHz for the S Speed grade only and 1.25 for the T
> Speed grade only. 1.4GHz has been added in board specific dts file as it
> requires VDD_CORE to be at 0.85V.
> 
> The latency between pre and post frequency transition was measured in
> CPUFreq driver for all combinations of OPP changes. The average value
> was selected as overall clock-latency.
> 
> Tested on am62-sk board using manual frequency changes and then reading
> back frequency with k3conf, and this shows matching frequency to what
> was set.
> 
> This should not impact existing K3 platforms that do not have operating
> points table defined.

Applied. Thanks.

-- 
viresh