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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.