linux-kernel - Re: [PATCHv3 6/6] drivers/cpufreq: Add a CPUFreq driver for AMD processors (Fam17h and later)

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: <3199bd27-68d6-3cda-7c03-fca6eeda96b9@amd.com>
Date:   Fri, 12 Jul 2019 16:44:25 +0000
From:   Janakarajan Natarajan <jnataraj@....com>
To:     Viresh Kumar <viresh.kumar@...aro.org>
CC:     "Natarajan, Janakarajan" <Janakarajan.Natarajan@....com>,
        "linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
        "devel@...ica.org" <devel@...ica.org>,
        "Rafael J . Wysocki" <rjw@...ysocki.net>,
        Len Brown <lenb@...nel.org>,
        Robert Moore <robert.moore@...el.com>,
        Erik Schmauss <erik.schmauss@...el.com>,
        "Ghannam, Yazen" <Yazen.Ghannam@....com>
Subject: Re: [PATCHv3 6/6] drivers/cpufreq: Add a CPUFreq driver for AMD
 processors (Fam17h and later)

On 7/11/2019 10:10 PM, Viresh Kumar wrote:
> On 11-07-19, 16:58, Janakarajan Natarajan wrote:
>> On 7/11/2019 1:12 AM, Viresh Kumar wrote:
>>> On 10-07-19, 18:37, Natarajan, Janakarajan wrote:
>>>> +static int amd_cpufreq_cpu_init(struct cpufreq_policy *policy)
>>>> +{
>>>> +	return 0;
>>>> +}
>>>> +
>>>> +static int amd_cpufreq_cpu_exit(struct cpufreq_policy *policy)
>>>> +{
>>>> +	return 0;
>>>> +}
>>>> +
>>>> +static int amd_cpufreq_cpu_verify(struct cpufreq_policy *policy)
>>>> +{
>>>> +	return 0;
>>>> +}
>>>> +
>>>> +static int amd_cpufreq_cpu_target_index(struct cpufreq_policy *policy,
>>>> +					unsigned int index)
>>>> +{
>>>> +	return 0;
>>>> +}
>>> All empty helpers ? There is nothing you need to do ?
>>
>> When we posted v2 of this patchset, Rafael let us know that he was
>> uncomfortable
>>
>> going behind the (acpi-cpufreq) drivers back by letting the user
>> communicate directly
>>
>> with the platform. That's the reason we have an empty driver whose
>> primary purpose
>>
>> is to expose sysfs entries for the user.
> I read his comments now and what he suggested is:
>
> "What about handling this like the others do, through a proper cpufreq
> driver?"
>
> I am not sure if he meant something like that you have here. Only one
> cpufreq driver can be registered at any point of time with the kernel,
> and so if this one is there then acpi-cpufreq or intel-pstate can't be
> there. Who will do DVFS ?


By default, the driver is disabled and cpufreq falls back to using 
acpi-cpufreq. To enable the driver,

a parameter i.e. amd_cpufreq.cppc_enable=1 needs to be used. Then the 
user will gain access to

/sys/devices/system/cpu/cpu<num>/amd_cpufreq/{enable, max_perf, 
min_perf, desired_perf, auto_sel_enable}.


max_perf, min_perf allows the user to indicate to the platform the 
performance they expect

in an abstract scale [min_perf to max_perf] inclusive. desired_perf is 
the performance the user

would like to ideally achieve. desired_perf will fall withing max and 
min perf. Based on the value of these

registers, the platform will adjust a number of variables, voltage and 
frequency being one of them.


If the user would rather have the system handle all power/performance 
adjustments by

itself, then they can set the auto_sel_enable register.


Thanks,

Janakarajan