From: Viresh Kumar <viresh.kumar@linaro.org>
To: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: rjw@rjwysocki.net, linux-pm@vger.kernel.org
Subject: Re: [PATCH] cpufreq: acpi_cpufreq: base frequency attribute support
Date: Tue, 1 Mar 2016 07:58:30 +0530 [thread overview]
Message-ID: <20160301022830.GX2791@vireshk-i7> (raw)
In-Reply-To: <1456778205-19197-1-git-send-email-srinivas.pandruvada@linux.intel.com>
On 29-02-16, 12:36, Srinivas Pandruvada wrote:
> Currently scaling_available_frequencies displays list of available
> frequencies which can be used to set max/min or current scaling frequency.
>
> >cat scaling_available_frequencies
> 2301000 2300000 2200000 2000000 1900000 1800000 1700000 1500000 1400000
> 1300000 1100000 1000000 900000 800000 600000 500000
>
> Here traditionally it is assumed that only 2301000 is a turbo frequency,
> which is purely opportunistic, anything else user can request and may
> get it.
> But because of configurable thermal design power implementation in several
> Intel CPUs, the opportunistic frequency start can be any frequency in this
> range. For example it can be 2300000 or any lower value.
> This change adds an optional new attribute called "base_frequency",
> which displays the max non-turbo frequency (base frequency). For example:
> >cat base_frequency
> 2200000
> This will allow user to choose a certain frequency which is not
> opportunistic.
>
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
> ---
You missed adding a version log and V2 in subject :(
> drivers/cpufreq/acpi-cpufreq.c | 36 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 36 insertions(+)
>
> diff --git a/drivers/cpufreq/acpi-cpufreq.c b/drivers/cpufreq/acpi-cpufreq.c
> index 51eef87..76edd28 100644
> --- a/drivers/cpufreq/acpi-cpufreq.c
> +++ b/drivers/cpufreq/acpi-cpufreq.c
> @@ -646,6 +646,21 @@ static int acpi_cpufreq_blacklist(struct cpuinfo_x86 *c)
> }
> #endif
>
> +static ssize_t show_base_frequency(struct cpufreq_policy *policy, char *buf)
> +{
> + u64 tar;
> + int err;
> +
> + err = rdmsrl_safe_on_cpu(policy->cpu, MSR_TURBO_ACTIVATION_RATIO, &tar);
> + if (!err)
So, this will automatically take care of checking if a CPU has support
for it or not, right ?
> + /* Refer to IA64, IA32 SDM table 35-20, unit = 100 MHz */
> + return sprintf(buf, "%llu\n", tar * 100000);
> +
> + return err;
> +}
> +
> +cpufreq_freq_attr_ro(base_frequency);
> +
> static int acpi_cpufreq_cpu_init(struct cpufreq_policy *policy)
> {
> unsigned int i;
> @@ -889,6 +904,7 @@ static struct freq_attr *acpi_cpufreq_attr[] = {
> &cpb,
> #endif
> NULL,
> + NULL,
Its not straight forward, so please add a comment (like cpufreq-dt),
that what the first NULL is going to be used for.
> };
>
> static struct cpufreq_driver acpi_cpufreq_driver = {
> @@ -971,6 +987,26 @@ static int __init acpi_cpufreq_init(void)
> }
> }
> #endif
> +
> + if (boot_cpu_has(X86_FEATURE_IDA)) {
> + u64 plat_info, tar;
> + int err;
> +
> + err = rdmsrl_safe_on_cpu(0, MSR_PLATFORM_INFO, &plat_info);
> + /* Check number of config TDP levels > 0 */
> + if (!err && ((plat_info >> 33) & 0x03) > 0) {
> + err = rdmsrl_safe_on_cpu(0, MSR_TURBO_ACTIVATION_RATIO,
> + &tar);
> + if (!err) {
Maybe just:
if (!rdmsrl_safe_on_cpu(0, MSR_TURBO_ACTIVATION_RATIO, &tar)) {
...
}
> + struct freq_attr **attr;
> +
> + for (attr = acpi_cpufreq_attr; *attr; attr++)
> + ;
> + *attr = &base_frequency;
What about:
acpi_cpufreq_attr[ARRAY_SIZE(acpi_cpufreq_attr) - 2] = &base_frequency;
and a comment to describe that ?
> + }
> + }
> + }
> +
> acpi_cpufreq_boost_init();
>
> ret = cpufreq_register_driver(&acpi_cpufreq_driver);
> --
> 2.4.3
--
viresh
next prev parent reply other threads:[~2016-03-01 2:28 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-29 20:36 [PATCH] cpufreq: acpi_cpufreq: base frequency attribute support Srinivas Pandruvada
2016-03-01 2:28 ` Viresh Kumar [this message]
2016-03-01 18:10 ` Srinivas Pandruvada
2016-03-02 2:38 ` Viresh Kumar
-- strict thread matches above, loose matches on Subject: below --
2015-10-01 22:25 Srinivas Pandruvada
2015-10-07 17:23 ` Viresh Kumar
2015-10-09 15:34 ` Srinivas Pandruvada
2015-10-15 22:45 ` Rafael J. Wysocki
2015-10-16 5:42 ` Viresh Kumar
2016-02-24 20:00 ` Srinivas Pandruvada
2016-02-24 20:05 ` Rafael J. Wysocki
2016-02-24 23:37 ` Srinivas Pandruvada
2016-02-25 3:27 ` Viresh Kumar
2016-02-25 18:07 ` Srinivas Pandruvada
2016-02-26 1:10 ` Pandruvada, Srinivas
2016-02-26 1:57 ` Viresh Kumar
2016-02-26 20:21 ` Srinivas Pandruvada
2016-02-29 3:16 ` Viresh Kumar
2016-02-29 17:11 ` Srinivas Pandruvada
2016-03-01 2:16 ` Viresh Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160301022830.GX2791@vireshk-i7 \
--to=viresh.kumar@linaro.org \
--cc=linux-pm@vger.kernel.org \
--cc=rjw@rjwysocki.net \
--cc=srinivas.pandruvada@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox