[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6089B7674E6F464F847AB76B599E0EAA78AB6A98@PGSMSX102.gar.corp.intel.com>
Date: Mon, 9 Mar 2020 09:02:57 +0000
From: "Pan, Harry" <harry.pan@...el.com>
To: "Rafael J. Wysocki" <rafael@...nel.org>
CC: LKML <linux-kernel@...r.kernel.org>, Harry Pan <gs0622@...il.com>,
"Jacob Pan" <jacob.jun.pan@...ux.intel.com>,
Len Brown <lenb@...nel.org>,
Linux PM <linux-pm@...r.kernel.org>
Subject: RE: [PATCH v3] intel_idle: Add Comet Lake support
Hi Rafael,
Thanks for the comments.
I have some questions, I am wondering if you can share upstream thought w.r.t the future development of intel_idle.
- It looks to me since v5.6 intel_idle will prefer _CST of ACPI rather than the general table embedded in this driver.
- Any pros and cons of using the tables of _CST in firmware and embedded one in the kernel?
- Can the table in _CST archive more optimal idle states management?
If there is already any reference, documents I missed, kindly enlighten me then I would like to read it first before refining the questions.
Thanks and take care,
Harry
________________________________________
從: Rafael J. Wysocki [rafael@...nel.org]
寄件日期: 2020年3月5日 上午 05:14
至: Pan, Harry
副本: Rafael J. Wysocki; LKML; Harry Pan; Jacob Pan; Len Brown; Linux PM
主旨: Re: [PATCH v3] intel_idle: Add Comet Lake support
On Wed, Mar 4, 2020 at 12:57 PM Pan, Harry <harry.pan@...el.com> wrote:
>
> Hi Rafael,
>
> Yes, I skipped it considering to align CML-U V0 and A0 stepping w/ the same table; I sent v4 for your review.
Skipping that flag is risky, because it may cause some C-states to be
enabled on systems where they have not been validated (e.g. systems
shipping with other OSes which only use _CST C-states). There were
problems related to that in the past which is one of the reasons for
adding _CST support to intel_idle. use_acpi should be set for all new
platforms going forward as a rule.
> In the other hand, I am proposing using _CST as long term plan in CrOS dev teams.
That I obviously agree with. :-)
> > On Mar 4, 2020, at 17:53, Rafael J. Wysocki <rafael@...nel.org> wrote:
> >
> > On Tue, Mar 3, 2020 at 10:10 AM Harry Pan <harry.pan@...el.com> wrote:
> >>
> >> Add a general C-state table in order to support Comet Lake.
> >>
> >> Signed-off-by: Harry Pan <harry.pan@...el.com>
> >>
> >> ---
> >>
> >> drivers/idle/intel_idle.c | 7 +++++++
> >> 1 file changed, 7 insertions(+)
> >>
> >> diff --git a/drivers/idle/intel_idle.c b/drivers/idle/intel_idle.c
> >> index d55606608ac8..05bce595fafe 100644
> >> --- a/drivers/idle/intel_idle.c
> >> +++ b/drivers/idle/intel_idle.c
> >> @@ -1067,6 +1067,11 @@ static const struct idle_cpu idle_cpu_dnv = {
> >> .use_acpi = true,
> >> };
> >>
> >> +static const struct idle_cpu idle_cpu_cml = {
> >> + .state_table = skl_cstates,
> >> + .disable_promotion_to_c1e = true,
> >
> > .use_acpi = true,
> >
> > missing? Otherwise you can just use idle_cpu_skl as is, can't you?
> >
> >> +};
> >> +
> >> static const struct x86_cpu_id intel_idle_ids[] __initconst = {
> >> INTEL_CPU_FAM6(NEHALEM_EP, idle_cpu_nhx),
> >> INTEL_CPU_FAM6(NEHALEM, idle_cpu_nehalem),
> >> @@ -1105,6 +1110,8 @@ static const struct x86_cpu_id intel_idle_ids[] __initconst = {
> >> INTEL_CPU_FAM6(ATOM_GOLDMONT_PLUS, idle_cpu_bxt),
> >> INTEL_CPU_FAM6(ATOM_GOLDMONT_D, idle_cpu_dnv),
> >> INTEL_CPU_FAM6(ATOM_TREMONT_D, idle_cpu_dnv),
> >> + INTEL_CPU_FAM6(COMETLAKE_L, idle_cpu_cml),
> >> + INTEL_CPU_FAM6(COMETLAKE, idle_cpu_cml),
> >> {}
> >> };
> >>
> >> --
> >> 2.24.1
> >>
Powered by blists - more mailing lists