From: "Jan Beulich" <JBeulich@suse.com>
To: Wei W Wang <wei.w.wang@intel.com>
Cc: Julien Grall <julien.grall@citrix.com>,
"andrew.cooper3@citrix.com" <andrew.cooper3@citrix.com>,
"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>
Subject: Re: [PATCH v3 06/11] x86/intel_pstate: the main boby of the intel_pstate driver
Date: Mon, 15 Jun 2015 10:11:53 +0100 [thread overview]
Message-ID: <557EB2F90200007800084B0C@mail.emea.novell.com> (raw)
In-Reply-To: <286AC319A985734F985F78AFA26841F798E477@shsmsx102.ccr.corp.intel.com>
>>> On 15.06.15 at 02:30, <wei.w.wang@intel.com> wrote:
> On 12/06/2015 19:30, Julien Grall wrote:
>> On 11/06/2015 21:41, Wang, Wei W wrote:
>> > On 11/06/2015 22:02, Julien Grall wrote:
>> >> On 11/06/2015 04:27, Wei Wang wrote:
>> >>> diff --git a/xen/include/acpi/cpufreq/cpufreq.h
>> >> b/xen/include/acpi/cpufreq/cpufreq.h
>> >>> index d10e4c7..71bb45c 100644
>> >>> --- a/xen/include/acpi/cpufreq/cpufreq.h
>> >>> +++ b/xen/include/acpi/cpufreq/cpufreq.h
>> >>> @@ -34,6 +34,12 @@ struct acpi_cpufreq_data {
>> >>>
>> >>> extern struct acpi_cpufreq_data *cpufreq_drv_data[NR_CPUS];
>> >>>
>> >>> +/*
>> >>> + * Maximum transition latency is in nanoseconds - if it's unknown,
>> >>> + * CPUFREQ_ETERNAL shall be used.
>> >>> + */
>> >>> +#define CPUFREQ_ETERNAL (-1)
>> >>> +
>> >>> struct cpufreq_cpuinfo {
>> >>> unsigned int max_freq;
>> >>> unsigned int second_max_freq; /* P1 if Turbo Mode is on */
>> >>> @@ -77,6 +83,8 @@ struct cpufreq_policy {
>> >>> };
>> >>> DECLARE_PER_CPU(struct cpufreq_policy *, cpufreq_cpu_policy);
>> >>>
>> >>> +extern int intel_pstate_init(void);
>> >>> +
>> >>
>> >> As said on a previous version [1], intel_pstate_init is x86 specific.
>> >> Although xen/include/acpi contains common headers.
>> >
>> > Please see our latest discussion here (the bottom of the link):
>> > http://lists.xen.org/archives/html/xen-devel/2015-06/msg00047.html
>>
>> Well we are planning to move cpufreq.h out of acpi in order to use for
> device
>> tree based platform. Most of these declaration is common.
>>
>> Although any x86 specific function would have to go out in a separate
> header.
>>
>> Please avoid to add new one when it's possible. I don't see why a new asm-
>> x86/cpufreq.h can't be added...
>
> I don't have an objection to creating a new header like that.
> Jan, what's your opinion?
If there's no suitable header to put what you need, creating one like
Julien suggested seems okay to me.
Jan
next prev parent reply other threads:[~2015-06-15 9:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-11 8:27 [PATCH v3 06/11] x86/intel_pstate: the main boby of the intel_pstate driver Wei Wang
2015-06-11 14:00 ` Julien Grall
2015-06-12 1:41 ` Wang, Wei W
2015-06-12 11:29 ` Julien Grall
2015-06-15 0:30 ` Wang, Wei W
2015-06-15 9:11 ` Jan Beulich [this message]
2015-06-18 15:03 ` Jan Beulich
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=557EB2F90200007800084B0C@mail.emea.novell.com \
--to=jbeulich@suse.com \
--cc=andrew.cooper3@citrix.com \
--cc=julien.grall@citrix.com \
--cc=wei.w.wang@intel.com \
--cc=xen-devel@lists.xen.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.