linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael@kernel.org>
To: "Pan, Harry" <harry.pan@intel.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>, Harry Pan <gs0622@gmail.com>,
	Jacob Pan <jacob.jun.pan@linux.intel.com>,
	Len Brown <lenb@kernel.org>, Linux PM <linux-pm@vger.kernel.org>
Subject: Re: [PATCH v3] intel_idle: Add Comet Lake support
Date: Tue, 10 Mar 2020 09:37:14 +0100	[thread overview]
Message-ID: <CAJZ5v0g6fAPZxX3MKGomjTWfWVMV-A+8yUC=ydOg5YwD-moDvQ@mail.gmail.com> (raw)
In-Reply-To: <6089B7674E6F464F847AB76B599E0EAA78AB6A98@PGSMSX102.gar.corp.intel.com>

On Mon, Mar 9, 2020 at 10:07 AM Pan, Harry <harry.pan@intel.com> wrote:
>
> 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.

Not exactly.

The rules are as follows:
 * If there is a built-in table for the given processor in the driver,
it will be used, but the C-states that are not exposed in _CST will be
disabled by default (the state parameters come from the built-in table
for all C-states).
 * Otherwise (i.e. the driver does not recognized the given
processor), C-state definitions will be based on the _CST data.

See https://www.kernel.org/doc/html/latest/admin-guide/pm/intel_idle.html
for details.

>  - Any pros and cons of using the tables of _CST in firmware and embedded one in the kernel?

Both can be used at the same time (see above).

The built-in table in the kernel must be suitable for all of the
platforms shipped with the given processor (SoC).

Obviously, the _CST table allows intel_idle to work if the processor
included in the platform is not recognized by it.

Generally, our planned strategy is to provide built-in C-state tables
for all new "mainstream" processors with the use_acpi flag set to
avoid enabling C-states that may have not been validated on a given
platform by default.

>  - Can the table in _CST archive more optimal idle states management?

Possibly, but not likely.

> If there is already any reference, documents I missed, kindly enlighten me then I would like to read it first before refining the questions.

See above. :-)

Thanks!


___________________________________
> 從: Rafael J. Wysocki [rafael@kernel.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@intel.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@kernel.org> wrote:
> > >
> > > On Tue, Mar 3, 2020 at 10:10 AM Harry Pan <harry.pan@intel.com> wrote:
> > >>
> > >> Add a general C-state table in order to support Comet Lake.
> > >>
> > >> Signed-off-by: Harry Pan <harry.pan@intel.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
> > >>

  reply	other threads:[~2020-03-10  8:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-26 17:34 [PATCH] intel_idle: Add Comet Lake support Harry Pan
2020-02-26 21:47 ` Rafael J. Wysocki
2020-02-27 10:56   ` Rafael J. Wysocki
2020-03-03  9:09 ` [PATCH v3] " Harry Pan
2020-03-04  9:53   ` Rafael J. Wysocki
2020-03-04 11:57     ` Pan, Harry
2020-03-04 21:14       ` Rafael J. Wysocki
2020-03-09  9:02         ` Pan, Harry
2020-03-10  8:37           ` Rafael J. Wysocki [this message]
2020-03-04 11:43   ` [PATCH v4] " Harry Pan
2020-03-12  9:25     ` [PATCH v5] " Harry Pan

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='CAJZ5v0g6fAPZxX3MKGomjTWfWVMV-A+8yUC=ydOg5YwD-moDvQ@mail.gmail.com' \
    --to=rafael@kernel.org \
    --cc=gs0622@gmail.com \
    --cc=harry.pan@intel.com \
    --cc=jacob.jun.pan@linux.intel.com \
    --cc=lenb@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).