Messages in this thread Patch in this message | | | From | "Pan, Harry" <> | Subject | RE: [PATCH v3] intel_idle: Add Comet Lake support | Date | Mon, 9 Mar 2020 09:02:57 +0000 |
| |
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@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 > >>
| |