linux-kernel - Re: [TEGRA194_CPUFREQ Patch 2/3] cpufreq: Add Tegra194 cpufreq driver

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: <aa9fb180-6a23-e27b-51f6-f6b5685d65be@nvidia.com>
Date:   Thu, 26 Mar 2020 05:29:58 +0530
From:   sumitg <sumitg@...dia.com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
CC:     <rjw@...ysocki.net>, <catalin.marinas@....com>, <will@...nel.org>,
        <thierry.reding@...il.com>, <jonathanh@...dia.com>,
        <talho@...dia.com>, <linux-pm@...r.kernel.org>,
        <linux-tegra@...r.kernel.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>, <bbasu@...dia.com>,
        <mperttunen@...dia.com>, <sumitg@...dia.com>
Subject: Re: [TEGRA194_CPUFREQ Patch 2/3] cpufreq: Add Tegra194 cpufreq driver

Hi Viresh,

Sorry for the late reply.

On 04/12/19 4:57 PM, Viresh Kumar wrote:
> On 04-12-19, 16:25, sumitg wrote:
>> In T194, CCPLEX doesn't have access to set clocks and the
>>
>> clk_{get|set}_rate() functions set clocks by hook to BPMP R5.
>>
>> CPU freq can be directly set by CCPLEX using MSR(NVFREQ_REQ_EL1).
>>
>> As DVFS run's on BPMP, another MSR (NVFREQ_FEEDBACK_EL1) is
>>
>> used to read the counters and calculate "actual" cpu freq at CCPLEX.
>>
>> So, "cpuinfo_cur_freq" node gives the actual cpu frequency and not
>>
>> given by node "scaling_cur_freq".
> Right, but why can't this be hidden in the CPU's clk driver instead,
> so cpufreq driver can just do clk_get_rate() and clk_set_rate() ?
>
>>> - populating cpufreq table, you can probably add OPPs instead using
>>>     the same mechanism
>> We are reading available frequencies from BPMP to populate
>>
>> cpufreq table and not using static opp table.
> Right and lot of other platforms read it from firmware (I believe BBMP
> is a firmware here), and create OPPs at runtime. Look at this for
> example:
>
> drivers/cpufreq/qcom-cpufreq-hw.c
>
> and search for dev_pm_opp_add().
>
- I think we don't need separate CPU clock driver & to reuse

   cpufreq-dt driver as we will still have to replicate same logic

   from cpufreq driver to that dummy clock driver for calculating

   actual cpufreq from MSR value. So, it won't add much value.

     - "qcom-cpufreq-hw.c" is using clk_get_rate() during init, but

       the frequency ops "get/target_index" write to register directly

       and not using clk api's. Also, the clock driver from gcc-msm*.c

       seem to handle all clocks in CCPLEX.

       Tegra SOC's which didn't have BPMP had the clock handling

       done by CCPLEX. They were using clk_{get|set}_rate() api's

       as you mentioned. But in Tegra194, all clock handling is done

       within BPMP R5 core except CPU clock(which is through MSR).

- Adding OPP's with dev_pm_opp_add() is also not required as:

    1) We don't have any consumer like energy model or EAS in

        Tegra194 which it seems was valid with "qcom-cpufreq-hw.c".

        So, i think it won't be useful for T194.

    2) Also, there is no way to map ndiv to voltage in kernel. Kernel

        driver passes ndiv value to BPMP(R5) which converts to vhint.

Please share your inputs.