From: Thomas Renninger <trenn@suse.de>
To: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Len Brown <lenb@kernel.org>,
Philippe Longepe <philippe.longepe@linux.intel.com>,
linux-pm@vger.kernel.org, rafael.j.wysocki@intel.com,
Prarit Bhargava <prarit@redhat.com>,
viresh.kumar@linaro.org
Subject: Re: [PATCH V6 1/3] cpufreq: intel_pstate: configurable algorithm to get target pstate
Date: Tue, 15 Dec 2015 15:24:53 +0100 [thread overview]
Message-ID: <6686771.YYmmLREfhx@skinner> (raw)
In-Reply-To: <1450117227.2912.17.camel@spandruv-desk3.jf.intel.com>
On Monday, December 14, 2015 10:20:27 AM Srinivas Pandruvada wrote:
> On Mon, 2015-12-14 at 16:13 +0100, Thomas Renninger wrote:
> > On Thursday, December 10, 2015 09:28:40 AM Srinivas Pandruvada wrote:
> > > On Thu, 2015-12-10 at 14:04 +0100, Thomas Renninger wrote:
> > > > On Wednesday, December 09, 2015 12:21:53 PM Srinivas Pandruvada wrote:
> > > > > On Wed, 2015-12-09 at 15:34 +0100, Thomas Renninger wrote:
...
> > And here:
> > https://en.wikipedia.org/wiki/Silvermont
> >
> > I get:
> > List of Silvermont processors:
> > Desktop processors (Bay Trail-D)
> > Server processors (Avoton)
> > Communications processors (Rangeley)
> > Embedded/automotive processors (Bay Trail-I)
> > Mobile processors (Bay Trail-M)
> > Tablet processors (Bay Trail-T)
> > Smartphone processors (Merrifield and Moorefield)
> >
> > List of Airmont processors
> > Mobile processors (Braswell)
> > Smartphone and Tablet processors (Cherry Trail)
> >
> > Not sure what specific functions you mean...
> > Can you name them?
>
> You have them above for two micro-architectures.
> But they have different cpu id when the use case calls for totally
> different use case. For example server processor (Avaton above in your
> list) has a cpuid of 0x4D, which we don't support for Intel Pstate.
Thanks.
Does this means Avaton will fall back to acpi-cpufreq?
Would it make sense to initalize with intel_pstate and then switch to
performance governor per default?
This may need some fiddling with our certifcation tool which expects
cpupfreq to work at least a bit.
Thomas
PS: Thanks for all the input. Summary (from my point of view):
Go for the airmont/silvermont specific algorithms. Especially as they seem to
be an important improvment. But at least write something to syslog.
The "ondemand" compatiblity patch(es) are not that important, right?
I would hold them off and evaluate whether it will make sense to get back
to governors. Even if not, I am not sure it is a good idea to introduce a
fake ondemand governor which is still doing things totally different than
the orignal one...
next prev parent reply other threads:[~2015-12-15 14:25 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-04 16:40 [PATCH V6 0/3] cpufreq: intel_pstate: account non C0 time Philippe Longepe
2015-12-04 16:40 ` Philippe Longepe
2015-12-04 16:40 ` [PATCH V6 1/3] cpufreq: intel_pstate: configurable algorithm to get target pstate Philippe Longepe
2015-12-08 15:27 ` Thomas Renninger
2015-12-08 18:02 ` Srinivas Pandruvada
2015-12-09 14:34 ` Thomas Renninger
2015-12-09 20:21 ` Srinivas Pandruvada
2015-12-10 13:04 ` Thomas Renninger
2015-12-10 17:28 ` Srinivas Pandruvada
2015-12-14 15:13 ` Thomas Renninger
2015-12-14 18:20 ` Srinivas Pandruvada
2015-12-15 14:24 ` Thomas Renninger [this message]
2015-12-15 17:59 ` Len Brown
2015-12-16 10:25 ` Thomas Renninger
2015-12-15 18:10 ` Srinivas Pandruvada
2015-12-10 22:01 ` Rafael J. Wysocki
2015-12-14 16:14 ` Stephane Gasparini
2015-12-14 16:36 ` Stephane Gasparini
2015-12-14 22:13 ` Doug Smythies
2015-12-15 10:30 ` Philippe Longepe
2015-12-15 13:06 ` Stephane Gasparini
2015-12-15 23:34 ` Doug Smythies
2015-12-16 9:49 ` Stephane Gasparini
2015-12-14 16:22 ` Thomas Renninger
2015-12-14 16:38 ` Stephane Gasparini
2015-12-14 22:06 ` Rafael J. Wysocki
2015-12-15 14:13 ` Thomas Renninger
2015-12-04 16:40 ` [PATCH " Philippe Longepe
2015-12-04 17:35 ` Srinivas Pandruvada
2015-12-10 0:45 ` Rafael J. Wysocki
2015-12-10 0:19 ` Srinivas Pandruvada
2015-12-10 0:51 ` Rafael J. Wysocki
2015-12-04 16:40 ` [PATCH V6 2/3] cpufreq: intel_pstate: account for non C0 time Philippe Longepe
2015-12-04 16:40 ` [PATCH " Philippe Longepe
2015-12-04 16:40 ` [PATCH V6 3/3] cpufreq: intel_pstate: Account for IO wait time Philippe Longepe
2015-12-04 16:40 ` Philippe Longepe
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=6686771.YYmmLREfhx@skinner \
--to=trenn@suse.de \
--cc=lenb@kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=philippe.longepe@linux.intel.com \
--cc=prarit@redhat.com \
--cc=rafael.j.wysocki@intel.com \
--cc=srinivas.pandruvada@linux.intel.com \
--cc=viresh.kumar@linaro.org \
/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