[PATCH v2 00/10] ICL support and other enhancements for PMC Core

[PATCH v2 00/10] ICL support and other enhancements for PMC Core

[Rajneesh Bhardwaj]

This patch series provides Icelake support for PMC Core driver and while
doing so it introduces the Icelake Mobile to intel-family.h as per the
CPUID from below Coreboot link
https://github.com/coreboot/coreboot/blob/5ebcea3aaaa3cd358bc5bccaa156b13a6ef25df6/src/soc/intel/common/block/include/intelblocks/mp_init.h
and provides some fixes and enhancements to the driver.

Changes in v2:
 * Addressed review comments from Thomas
 * Added tags revieved
 * Folded in SHA1 suggestions from Stephen Rothwell, though Andy might want to
   fix it via rebasing
 * Rebased and tested with Linux v5.0.0-rc6

This series:
 - Adds ICL U/Y CPUID to intel-family.h
 - Enables PMC driver for ICL 
 - Introduces a new "package cstate show" feature
 - Fixes a customer issue related to S0ix on latest HP laptops
 - Fixes some minor bugs  

Rajneesh Bhardwaj (10):
  platform/x86: intel_pmc_core: Handle CFL regmap properly
  platform/x86: intel_pmc_core: Fix PCH IP sts reading
  platform/x86: intel_pmc_core: Fix PCH IP name
  platform/x86: intel_pmc_core: Fix file permissions for ltr_show
  platform/x86: intel_pmc_core: Include Reserved IP for LTR
  x86/cpu: Add Icelake to Intel family
  platform/x86: intel_pmc_core: Convert to INTEL_CPU_FAM6 macro
  platform/x86: intel_pmc_core: Add ICL platform support
  platform/x86: intel_pmc_core: Add Package cstates residency info
  platform/x86: intel_pmc_core: Quirk to ignore XTAL shutdown

 arch/x86/include/asm/intel-family.h   |   2 +
 drivers/platform/x86/intel_pmc_core.c | 155 +++++++++++++++++++++-----
 drivers/platform/x86/intel_pmc_core.h |  14 ++-
 3 files changed, 145 insertions(+), 26 deletions(-)

-- 
2.17.1

[PATCH v2 01/10] platform/x86: intel_pmc_core: Handle CFL regmap properly

[Rajneesh Bhardwaj]

Only Coffeelake should use Cannonlake regmap other than Cannonlake
platform. This allows Coffeelake special handling only when there is no
matching PCI device and default reg map selected as per CPUID is for
Sunrisepoint PCH. This change is needed to enable support for newer SoCs
such as Icelake.

Cc: "David E. Box" <david.e.box@intel.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Fixes: 661405bd817b ("platform/x86: intel_pmc_core: Special case for Coffeelake")
Acked-by: "David E. Box" <david.e.box@linux.intel.com>
Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
---
 drivers/platform/x86/intel_pmc_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/intel_pmc_core.c b/drivers/platform/x86/intel_pmc_core.c
index 22dbf115782e..37f605da9333 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -768,7 +768,7 @@ static int __init pmc_core_probe(void)
 	 * Sunrisepoint PCH regmap can't be used. Use Cannonlake PCH regmap
 	 * in this case.
 	 */
-	if (!pci_dev_present(pmc_pci_ids))
+	if (pmcdev->map == &spt_reg_map && !pci_dev_present(pmc_pci_ids))
 		pmcdev->map = &cnp_reg_map;
 
 	if (lpit_read_residency_count_address(&slp_s0_addr))
-- 
2.17.1

[PATCH v2 02/10] platform/x86: intel_pmc_core: Fix PCH IP sts reading

[Rajneesh Bhardwaj]

A previous commit "platform/x86: intel_pmc_core: Make the driver PCH
family agnostic <c977b98bbef5898ed3d30b08ea67622e9e82082a>" provided
better abstraction to this driver but has some fundamental issues.

e.g. the following condition

for (index = 0; index < pmcdev->map->ppfear_buckets &&
	index < PPFEAR_MAX_NUM_ENTRIES; index++, iter++)

is wrong because for CNL, PPFEAR_MAX_NUM_ENTRIES is hardcoded as 5 which
is _wrong_ and even though ppfear_buckets is 8, the loop fails to read
all eight registers needed for CNL PCH i.e. PPFEAR0 and PPFEAR1. This
patch refactors the pfear show logic to correctly read PCH IP power
gating status for Cannonlake and beyond.

Cc: "David E. Box" <david.e.box@intel.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Fixes: c977b98bbef5 ("platform/x86: intel_pmc_core: Make the driver PCH family agnostic")
Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
---
 drivers/platform/x86/intel_pmc_core.c | 3 ++-
 drivers/platform/x86/intel_pmc_core.h | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/platform/x86/intel_pmc_core.c b/drivers/platform/x86/intel_pmc_core.c
index 37f605da9333..9f143cdbea05 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -380,7 +380,8 @@ static int pmc_core_ppfear_show(struct seq_file *s, void *unused)
 	     index < PPFEAR_MAX_NUM_ENTRIES; index++, iter++)
 		pf_regs[index] = pmc_core_reg_read_byte(pmcdev, iter);
 
-	for (index = 0; map[index].name; index++)
+	for (index = 0; map[index].name &&
+	     index < pmcdev->map->ppfear_buckets * 8; index++)
 		pmc_core_display_map(s, index, pf_regs[index / 8], map);
 
 	return 0;
diff --git a/drivers/platform/x86/intel_pmc_core.h b/drivers/platform/x86/intel_pmc_core.h
index 89554cba5758..1a0104d2cbf0 100644
--- a/drivers/platform/x86/intel_pmc_core.h
+++ b/drivers/platform/x86/intel_pmc_core.h
@@ -32,7 +32,7 @@
 #define SPT_PMC_SLP_S0_RES_COUNTER_STEP		0x64
 #define PMC_BASE_ADDR_MASK			~(SPT_PMC_MMIO_REG_LEN - 1)
 #define MTPMC_MASK				0xffff0000
-#define PPFEAR_MAX_NUM_ENTRIES			5
+#define PPFEAR_MAX_NUM_ENTRIES			12
 #define SPT_PPFEAR_NUM_ENTRIES			5
 #define SPT_PMC_READ_DISABLE_BIT		0x16
 #define SPT_PMC_MSG_FULL_STS_BIT		0x18
-- 
2.17.1

[PATCH v2 03/10] platform/x86: intel_pmc_core: Fix PCH IP name

[Rajneesh Bhardwaj]

For Cannonlake and Icelake, the IP name for Res_6 should be SPF i.e.
South Port F. No functional change is intended other than just renaming
the IP appropriately.

Cc: "David E. Box" <david.e.box@intel.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Fixes: 291101f6a735 ("platform/x86: intel_pmc_core: Add CannonLake PCH support")
Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
---
 drivers/platform/x86/intel_pmc_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/intel_pmc_core.c b/drivers/platform/x86/intel_pmc_core.c
index 9f143cdbea05..80936e6bdc61 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -203,7 +203,7 @@ static const struct pmc_bit_map cnp_pfear_map[] = {
 	{"CNVI",                BIT(3)},
 	{"UFS0",                BIT(4)},
 	{"EMMC",                BIT(5)},
-	{"Res_6",               BIT(6)},
+	{"SPF",			BIT(6)},
 	{"SBR6",                BIT(7)},
 
 	{"SBR7",                BIT(0)},
-- 
2.17.1

[PATCH v2 04/10] platform/x86: intel_pmc_core: Fix file permissions for ltr_show

[Rajneesh Bhardwaj]

File permissions for ltr_show attribute should be similar to other
debugfs attributes created by this driver. '0644' should be used only
when there is a write operation desired such as for ltr_ignore.

Cc: "David E. Box" <david.e.box@intel.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
[rajneesh: folded in correct SHA1 as reported by Stephen Rothwell]
Fixes: 2eb150558bb7 ("platform/x86: intel_pmc_core: Show Latency Tolerance info")
Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
---
 drivers/platform/x86/intel_pmc_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/intel_pmc_core.c b/drivers/platform/x86/intel_pmc_core.c
index 80936e6bdc61..125461ca2927 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -702,7 +702,7 @@ static int pmc_core_dbgfs_register(struct pmc_dev *pmcdev)
 	debugfs_create_file("ltr_ignore", 0644, dir, pmcdev,
 			    &pmc_core_ltr_ignore_ops);
 
-	debugfs_create_file("ltr_show", 0644, dir, pmcdev, &pmc_core_ltr_fops);
+	debugfs_create_file("ltr_show", 0444, dir, pmcdev, &pmc_core_ltr_fops);
 
 	if (pmcdev->map->pll_sts)
 		debugfs_create_file("pll_status", 0444, dir, pmcdev,
-- 
2.17.1

[PATCH v2 05/10] platform/x86: intel_pmc_core: Include Reserved IP for LTR

[Rajneesh Bhardwaj]

Recently introduced commit "platform/x86: intel_pmc_core: Show Latency
Tolerance info <51337cd94d18184601ac0fb4cf1a02b8bbabc3d7> skipped the
LTR from a reserved IP. Though this doesn't cause any functional issue
but it is needed for the consumers of "ltr_ignore" as the index printing
for "ltr_show" is missing. For example, w/o this change, a user that wants
to ignore LTR from ME would do something like

echo 5 > ltr_ignore

but the index for ME is 6. Printing a reserved IP helps to properly
calculate LTR ignore offsets.

Cc: "David E. Box" <david.e.box@intel.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
---
 drivers/platform/x86/intel_pmc_core.c | 2 ++
 drivers/platform/x86/intel_pmc_core.h | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/drivers/platform/x86/intel_pmc_core.c b/drivers/platform/x86/intel_pmc_core.c
index 125461ca2927..835ed6d333bf 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -108,6 +108,7 @@ static const struct pmc_bit_map spt_ltr_show_map[] = {
 	{"SATA",		SPT_PMC_LTR_SATA},
 	{"GIGABIT_ETHERNET",	SPT_PMC_LTR_GBE},
 	{"XHCI",		SPT_PMC_LTR_XHCI},
+	{"Reserved",		SPT_PMC_LTR_RESERVED},
 	{"ME",			SPT_PMC_LTR_ME},
 	/* EVA is Enterprise Value Add, doesn't really exist on PCH */
 	{"EVA",			SPT_PMC_LTR_EVA},
@@ -276,6 +277,7 @@ static const struct pmc_bit_map cnp_ltr_show_map[] = {
 	{"SATA",		CNP_PMC_LTR_SATA},
 	{"GIGABIT_ETHERNET",	CNP_PMC_LTR_GBE},
 	{"XHCI",		CNP_PMC_LTR_XHCI},
+	{"Reserved",		CNP_PMC_LTR_RESERVED},
 	{"ME",			CNP_PMC_LTR_ME},
 	/* EVA is Enterprise Value Add, doesn't really exist on PCH */
 	{"EVA",			CNP_PMC_LTR_EVA},
diff --git a/drivers/platform/x86/intel_pmc_core.h b/drivers/platform/x86/intel_pmc_core.h
index 1a0104d2cbf0..0680ca397b57 100644
--- a/drivers/platform/x86/intel_pmc_core.h
+++ b/drivers/platform/x86/intel_pmc_core.h
@@ -46,6 +46,7 @@
 #define SPT_PMC_LTR_SATA			0x368
 #define SPT_PMC_LTR_GBE				0x36C
 #define SPT_PMC_LTR_XHCI			0x370
+#define SPT_PMC_LTR_RESERVED			0x374
 #define SPT_PMC_LTR_ME				0x378
 #define SPT_PMC_LTR_EVA				0x37C
 #define SPT_PMC_LTR_SPC				0x380
@@ -156,6 +157,7 @@ enum ppfear_regs {
 #define CNP_PMC_LTR_SATA			0x1B68
 #define CNP_PMC_LTR_GBE				0x1B6C
 #define CNP_PMC_LTR_XHCI			0x1B70
+#define CNP_PMC_LTR_RESERVED			0x1B74
 #define CNP_PMC_LTR_ME				0x1B78
 #define CNP_PMC_LTR_EVA				0x1B7C
 #define CNP_PMC_LTR_SPC				0x1B80
-- 
2.17.1

[PATCH v2 06/10] x86/cpu: Add Icelake to Intel family

[Rajneesh Bhardwaj]

Add CPUID of Icelake (ICL) mobile processors to Intel family list. The
information related to ICL CPUID is referenced from below Coreboot
project link.

https://github.com/coreboot/coreboot/blob/5ebcea3aaaa3cd358bc5bccaa156b13a6ef25df6/src/soc/intel/common/block/include/intelblocks/mp_init.h

Cc: x86@kernel.org
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "David E. Box" <david.e.box@intel.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
---
 arch/x86/include/asm/intel-family.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/include/asm/intel-family.h b/arch/x86/include/asm/intel-family.h
index d9a9993af882..9f15384c504a 100644
--- a/arch/x86/include/asm/intel-family.h
+++ b/arch/x86/include/asm/intel-family.h
@@ -52,6 +52,8 @@
 
 #define INTEL_FAM6_CANNONLAKE_MOBILE	0x66
 
+#define INTEL_FAM6_ICELAKE_MOBILE	0x7E
+
 /* "Small Core" Processors (Atom) */
 
 #define INTEL_FAM6_ATOM_BONNELL		0x1C /* Diamondville, Pineview */
-- 
2.17.1

Re: [PATCH v2 06/10] x86/cpu: Add Icelake to Intel family

[Borislav Petkov]

On Wed, Feb 13, 2019 at 08:38:06PM +0530, Rajneesh Bhardwaj wrote:
> Add CPUID of Icelake (ICL) mobile processors to Intel family list. The
> information related to ICL CPUID is referenced from below Coreboot
> project link.
> 
> https://github.com/coreboot/coreboot/blob/5ebcea3aaaa3cd358bc5bccaa156b13a6ef25df6/src/soc/intel/common/block/include/intelblocks/mp_init.h
> 

I believe tglx was suggesting you should drop this link. If you can't
reference an official document, then you don't need any reference.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v2 06/10] x86/cpu: Add Icelake to Intel family

[Bhardwaj, Rajneesh]

On 13-Feb-19 8:53 PM, Borislav Petkov wrote:
> On Wed, Feb 13, 2019 at 08:38:06PM +0530, Rajneesh Bhardwaj wrote:
>> Add CPUID of Icelake (ICL) mobile processors to Intel family list. The
>> information related to ICL CPUID is referenced from below Coreboot
>> project link.
>>
>> https://github.com/coreboot/coreboot/blob/5ebcea3aaaa3cd358bc5bccaa156b13a6ef25df6/src/soc/intel/common/block/include/intelblocks/mp_init.h
>>
> I believe tglx was suggesting you should drop this link. If you can't
> reference an official document, then you don't need any reference.

Icelake related information is  available here 
https://www.intel.in/content/www/in/en/design/products-and-solutions/processors-and-chipsets/ice-lake/overview.html 
but it may require a login either with Intel or a Partner ID.

The CPUID mentioned in this document is 0x706E0 which is same as per 
this coreboot link.


>

Re: [PATCH v2 06/10] x86/cpu: Add Icelake to Intel family

[Borislav Petkov]

On Wed, Feb 13, 2019 at 09:13:01PM +0530, Bhardwaj, Rajneesh wrote:
> Icelake related information is  available here https://www.intel.in/content/www/in/en/design/products-and-solutions/processors-and-chipsets/ice-lake/overview.html
> but it may require a login either with Intel or a Partner ID.
> 
> The CPUID mentioned in this document is 0x706E0 which is same as per this
> coreboot link.

You did not read what I wrote.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH v2 06/10] x86/cpu: Add Icelake to Intel family

[Bhardwaj, Rajneesh]

I sure did, perhaps it wasn't clear in my response. I can remove 
coreboot link in next version but please clarify whether i should keep 
other link that i mentioned or just keep the commit without any link?

On 13-Feb-19 9:34 PM, Borislav Petkov wrote:
> On Wed, Feb 13, 2019 at 09:13:01PM +0530, Bhardwaj, Rajneesh wrote:
>> Icelake related information is  available here https://www.intel.in/content/www/in/en/design/products-and-solutions/processors-and-chipsets/ice-lake/overview.html
>> but it may require a login either with Intel or a Partner ID.
>>
>> The CPUID mentioned in this document is 0x706E0 which is same as per this
>> coreboot link.
> You did not read what I wrote.
>

Re: [PATCH v2 06/10] x86/cpu: Add Icelake to Intel family

[Dave Hansen]

On 2/13/19 8:35 AM, Bhardwaj, Rajneesh wrote:
> I sure did, perhaps it wasn't clear in my response. I can remove
> coreboot link in next version but please clarify whether i should keep
> other link that i mentioned or just keep the commit without any link?

I think we're hearing loud and clear from the maintainers that they
prefer *public*, official documentation from Intel to back up our patches.

Barring that, they'd rather have no link than a link to some other
random project.

Re: [PATCH v2 06/10] x86/cpu: Add Icelake to Intel family

[Bhardwaj, Rajneesh]

On 13-Feb-19 10:10 PM, Dave Hansen wrote:
> On 2/13/19 8:35 AM, Bhardwaj, Rajneesh wrote:
>> I sure did, perhaps it wasn't clear in my response. I can remove
>> coreboot link in next version but please clarify whether i should keep
>> other link that i mentioned or just keep the commit without any link?
> I think we're hearing loud and clear from the maintainers that they
> prefer *public*, official documentation from Intel to back up our patches.
>
> Barring that, they'd rather have no link than a link to some other
> random project.

Thank you Dave for the clarification.

Hi Borislav, I realize that the link i mentioned is not public. 
Apologies for creating confusion around that and for the previous top 
posting.  I will drop references to the coreboot link too in the next 
version.

>

Re: [PATCH v2 06/10] x86/cpu: Add Icelake to Intel family

[Borislav Petkov]

On Wed, Feb 13, 2019 at 10:43:30PM +0530, Bhardwaj, Rajneesh wrote:
> Hi Borislav, I realize that the link i mentioned is not public. Apologies
> for creating confusion around that and for the previous top posting.  I will
> drop references to the coreboot link too in the next version.

As we talked on IRC with Dave, those patches don't need to point to an
official document.

If the model number is wrong, we'll learn very soon about it. :-)

If it is a patchset enabling a feature or an erratum, then this becomes
a whole different story.

Thx.

-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[PATCH v2 07/10] platform/x86: intel_pmc_core: Convert to INTEL_CPU_FAM6 macro

[Rajneesh Bhardwaj]

INTEL_CPU_FAM6() macro provides better abstraction and reduces code size so use
it instead of custom grown ICPU().

Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
---
 drivers/platform/x86/intel_pmc_core.c | 13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/drivers/platform/x86/intel_pmc_core.c b/drivers/platform/x86/intel_pmc_core.c
index 835ed6d333bf..d3752d75075b 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -25,9 +25,6 @@
 
 #include "intel_pmc_core.h"
 
-#define ICPU(model, data) \
-	{ X86_VENDOR_INTEL, 6, model, X86_FEATURE_MWAIT, (kernel_ulong_t)data }
-
 static struct pmc_dev pmc;
 
 static const struct pmc_bit_map spt_pll_map[] = {
@@ -738,11 +735,11 @@ static inline void pmc_core_dbgfs_unregister(struct pmc_dev *pmcdev)
 #endif /* CONFIG_DEBUG_FS */
 
 static const struct x86_cpu_id intel_pmc_core_ids[] = {
-	ICPU(INTEL_FAM6_SKYLAKE_MOBILE, &spt_reg_map),
-	ICPU(INTEL_FAM6_SKYLAKE_DESKTOP, &spt_reg_map),
-	ICPU(INTEL_FAM6_KABYLAKE_MOBILE, &spt_reg_map),
-	ICPU(INTEL_FAM6_KABYLAKE_DESKTOP, &spt_reg_map),
-	ICPU(INTEL_FAM6_CANNONLAKE_MOBILE, &cnp_reg_map),
+	INTEL_CPU_FAM6(SKYLAKE_MOBILE, spt_reg_map),
+	INTEL_CPU_FAM6(SKYLAKE_DESKTOP, spt_reg_map),
+	INTEL_CPU_FAM6(KABYLAKE_MOBILE, spt_reg_map),
+	INTEL_CPU_FAM6(KABYLAKE_DESKTOP, spt_reg_map),
+	INTEL_CPU_FAM6(CANNONLAKE_MOBILE, cnp_reg_map),
 	{}
 };
 
-- 
2.17.1

[PATCH v2 08/10] platform/x86: intel_pmc_core: Add ICL platform support

[Rajneesh Bhardwaj]

Icelake can resue most of the CNL PCH IPs as they are mostly similar.
This patch enables the PMC Core driver for ICL family.

It also addresses few other minor issues like upper case conversions and
some tab alignments.

Cc: "David E. Box" <david.e.box@intel.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-and-tested-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
---
 drivers/platform/x86/intel_pmc_core.c | 59 +++++++++++++++++++++------
 drivers/platform/x86/intel_pmc_core.h |  4 ++
 2 files changed, 50 insertions(+), 13 deletions(-)

diff --git a/drivers/platform/x86/intel_pmc_core.c b/drivers/platform/x86/intel_pmc_core.c
index d3752d75075b..400946b7a3b5 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -166,25 +166,26 @@ static const struct pmc_bit_map cnp_pfear_map[] = {
 	{"SDX",                 BIT(4)},
 	{"SPE",                 BIT(5)},
 	{"Fuse",                BIT(6)},
-	{"Res_23",              BIT(7)},
+	/* Reserved for Cannonlake but valid for Icelake */
+	{"SBR8",		BIT(7)},
 
 	{"CSME_FSC",            BIT(0)},
 	{"USB3_OTG",            BIT(1)},
 	{"EXI",                 BIT(2)},
 	{"CSE",                 BIT(3)},
-	{"csme_kvm",            BIT(4)},
-	{"csme_pmt",            BIT(5)},
-	{"csme_clink",          BIT(6)},
-	{"csme_ptio",           BIT(7)},
-
-	{"csme_usbr",           BIT(0)},
-	{"csme_susram",         BIT(1)},
-	{"csme_smt1",           BIT(2)},
+	{"CSME_KVM",            BIT(4)},
+	{"CSME_PMT",            BIT(5)},
+	{"CSME_CLINK",          BIT(6)},
+	{"CSME_PTIO",           BIT(7)},
+
+	{"CSME_USBR",           BIT(0)},
+	{"CSME_SUSRAM",         BIT(1)},
+	{"CSME_SMT1",           BIT(2)},
 	{"CSME_SMT4",           BIT(3)},
-	{"csme_sms2",           BIT(4)},
-	{"csme_sms1",           BIT(5)},
-	{"csme_rtc",            BIT(6)},
-	{"csme_psf",            BIT(7)},
+	{"CSME_SMS2",           BIT(4)},
+	{"CSME_SMS1",           BIT(5)},
+	{"CSME_RTC",            BIT(6)},
+	{"CSME_PSF",            BIT(7)},
 
 	{"SBR0",                BIT(0)},
 	{"SBR1",                BIT(1)},
@@ -209,6 +210,20 @@ static const struct pmc_bit_map cnp_pfear_map[] = {
 	{"HDA_PGD4",            BIT(2)},
 	{"HDA_PGD5",            BIT(3)},
 	{"HDA_PGD6",            BIT(4)},
+	/* Reserved for Cannonlake but valid for Icelake */
+	{"PSF6",		BIT(5)},
+	{"PSF7",		BIT(6)},
+	{"PSF8",		BIT(7)},
+
+	/* Icelake generation onwards only */
+	{"RES_65",		BIT(0)},
+	{"RES_66",		BIT(1)},
+	{"RES_67",		BIT(2)},
+	{"TAM",			BIT(3)},
+	{"GBETSN",		BIT(4)},
+	{"TBTLSX",		BIT(5)},
+	{"RES_71",		BIT(6)},
+	{"RES_72",		BIT(7)},
 	{}
 };
 
@@ -290,6 +305,8 @@ static const struct pmc_bit_map cnp_ltr_show_map[] = {
 	{"ISH",			CNP_PMC_LTR_ISH},
 	{"UFSX2",		CNP_PMC_LTR_UFSX2},
 	{"EMMC",		CNP_PMC_LTR_EMMC},
+	/* Reserved for Cannonlake but valid for Icelake */
+	{"WIGIG",		ICL_PMC_LTR_WIGIG},
 	/* Below two cannot be used for LTR_IGNORE */
 	{"CURRENT_PLATFORM",	CNP_PMC_LTR_CUR_PLT},
 	{"AGGREGATED_SYSTEM",	CNP_PMC_LTR_CUR_ASLT},
@@ -311,6 +328,21 @@ static const struct pmc_reg_map cnp_reg_map = {
 	.ltr_ignore_max = CNP_NUM_IP_IGN_ALLOWED,
 };
 
+static const struct pmc_reg_map icl_reg_map = {
+	.pfear_sts = cnp_pfear_map,
+	.slp_s0_offset = CNP_PMC_SLP_S0_RES_COUNTER_OFFSET,
+	.slps0_dbg_maps = cnp_slps0_dbg_maps,
+	.ltr_show_sts = cnp_ltr_show_map,
+	.slps0_dbg_offset = CNP_PMC_SLPS0_DBG_OFFSET,
+	.ltr_ignore_offset = CNP_PMC_LTR_IGNORE_OFFSET,
+	.regmap_length = CNP_PMC_MMIO_REG_LEN,
+	.ppfear0_offset = CNP_PMC_HOST_PPFEAR0A,
+	.ppfear_buckets = ICL_PPFEAR_NUM_ENTRIES,
+	.pm_cfg_offset = CNP_PMC_PM_CFG_OFFSET,
+	.pm_read_disable_bit = CNP_PMC_READ_DISABLE_BIT,
+	.ltr_ignore_max = ICL_NUM_IP_IGN_ALLOWED,
+};
+
 static inline u8 pmc_core_reg_read_byte(struct pmc_dev *pmcdev, int offset)
 {
 	return readb(pmcdev->regbase + offset);
@@ -740,6 +772,7 @@ static const struct x86_cpu_id intel_pmc_core_ids[] = {
 	INTEL_CPU_FAM6(KABYLAKE_MOBILE, spt_reg_map),
 	INTEL_CPU_FAM6(KABYLAKE_DESKTOP, spt_reg_map),
 	INTEL_CPU_FAM6(CANNONLAKE_MOBILE, cnp_reg_map),
+	INTEL_CPU_FAM6(ICELAKE_MOBILE, icl_reg_map),
 	{}
 };
 
diff --git a/drivers/platform/x86/intel_pmc_core.h b/drivers/platform/x86/intel_pmc_core.h
index 0680ca397b57..78dd4229489d 100644
--- a/drivers/platform/x86/intel_pmc_core.h
+++ b/drivers/platform/x86/intel_pmc_core.h
@@ -178,6 +178,10 @@ enum ppfear_regs {
 #define LTR_REQ_SNOOP				BIT(15)
 #define LTR_REQ_NONSNOOP			BIT(31)
 
+#define ICL_PPFEAR_NUM_ENTRIES			9
+#define ICL_NUM_IP_IGN_ALLOWED			20
+#define ICL_PMC_LTR_WIGIG			0x1BFC
+
 struct pmc_bit_map {
 	const char *name;
 	u32 bit_mask;
-- 
2.17.1

[PATCH v2 09/10] platform/x86: intel_pmc_core: Add Package cstates residency info

[Rajneesh Bhardwaj]

This patch introduces a new debugfs entry to read current Package
cstate residency counters. A similar variant of this patch was discussed
earlier "https://patchwork.kernel.org/patch/9908563/" but didn't make it
into mainline for various reasons. Current version only adds debugfs
entry which is quite useful for S0ix debug but excludes the exported API
that was there in initial version. Though there are tools like turbostat
and socwatch which can also show this info but sometimes its more
practical to have it here as it's hard to switch between various tools for
S0ix debug when pmc_core driver is the primary debug tool. Internal and
external customers have requested for this patch to be included in the
PMC driver on many occasions and Google Chrome OS team has already included
it in their builds. This becomes handy when requesting logs from external
customers who may not always have above mentioned tools in their integrated
kernel builds.

Package cstate residency MSRs provide useful debug information about
system idle states. In idle states system must enter deeper Package
cstates. Package cstates depend not only on Core cstates but also on
various IP block's power gating status and LTR values.

For Intel Core SoCs Package C10 entry is a must for deeper sleep states
such as S0ix. "Suspend-to-idle"  should ideally take this path:
PC0 -> PC10 -> S0ix. For S0ix debug, its logical to check for
Package C10 residency first if for some reason system fails to enter S0ix.

Please refer to this link for MSR details:
https://software.intel.com/sites/default/files/managed/22/0d/335592-sdm-vol-4.pdf

Usage:
cat /sys/kernel/debug/pmc_core/package_cstate_show
Package C2       : 0xec2e21735f
Package C3       : 0xc30113ba4
Package C6       : 0x9ef4be15c5
Package C7       : 0x1e011904
Package C8       : 0x3c5653cfe5a
Package C9       : 0x0
Package C10      : 0x16fff4289

Cc: Arjan van de Ven <arjan@linux.intel.com>
Cc: "David E. Box" <david.e.box@intel.com>
Cc: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Acked-and-tested-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
---
 drivers/platform/x86/intel_pmc_core.c | 38 +++++++++++++++++++++++++++
 drivers/platform/x86/intel_pmc_core.h |  1 +
 2 files changed, 39 insertions(+)

diff --git a/drivers/platform/x86/intel_pmc_core.c b/drivers/platform/x86/intel_pmc_core.c
index 400946b7a3b5..4e7aa1711148 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -22,11 +22,24 @@
 
 #include <asm/cpu_device_id.h>
 #include <asm/intel-family.h>
+#include <asm/msr.h>
 
 #include "intel_pmc_core.h"
 
 static struct pmc_dev pmc;
 
+/* PKGC MSRs are common across Intel Core SoCs */
+static const struct pmc_bit_map msr_map[] = {
+	{"Package C2",                  MSR_PKG_C2_RESIDENCY},
+	{"Package C3",                  MSR_PKG_C3_RESIDENCY},
+	{"Package C6",                  MSR_PKG_C6_RESIDENCY},
+	{"Package C7",                  MSR_PKG_C7_RESIDENCY},
+	{"Package C8",                  MSR_PKG_C8_RESIDENCY},
+	{"Package C9",                  MSR_PKG_C9_RESIDENCY},
+	{"Package C10",                 MSR_PKG_C10_RESIDENCY},
+	{}
+};
+
 static const struct pmc_bit_map spt_pll_map[] = {
 	{"MIPI PLL",			SPT_PMC_BIT_MPHY_CMN_LANE0},
 	{"GEN2 USB2PCIE2 PLL",		SPT_PMC_BIT_MPHY_CMN_LANE1},
@@ -129,6 +142,7 @@ static const struct pmc_reg_map spt_reg_map = {
 	.mphy_sts = spt_mphy_map,
 	.pll_sts = spt_pll_map,
 	.ltr_show_sts = spt_ltr_show_map,
+	.msr_sts = msr_map,
 	.slp_s0_offset = SPT_PMC_SLP_S0_RES_COUNTER_OFFSET,
 	.ltr_ignore_offset = SPT_PMC_LTR_IGNORE_OFFSET,
 	.regmap_length = SPT_PMC_MMIO_REG_LEN,
@@ -318,6 +332,7 @@ static const struct pmc_reg_map cnp_reg_map = {
 	.slp_s0_offset = CNP_PMC_SLP_S0_RES_COUNTER_OFFSET,
 	.slps0_dbg_maps = cnp_slps0_dbg_maps,
 	.ltr_show_sts = cnp_ltr_show_map,
+	.msr_sts = msr_map,
 	.slps0_dbg_offset = CNP_PMC_SLPS0_DBG_OFFSET,
 	.ltr_ignore_offset = CNP_PMC_LTR_IGNORE_OFFSET,
 	.regmap_length = CNP_PMC_MMIO_REG_LEN,
@@ -333,6 +348,7 @@ static const struct pmc_reg_map icl_reg_map = {
 	.slp_s0_offset = CNP_PMC_SLP_S0_RES_COUNTER_OFFSET,
 	.slps0_dbg_maps = cnp_slps0_dbg_maps,
 	.ltr_show_sts = cnp_ltr_show_map,
+	.msr_sts = msr_map,
 	.slps0_dbg_offset = CNP_PMC_SLPS0_DBG_OFFSET,
 	.ltr_ignore_offset = CNP_PMC_LTR_IGNORE_OFFSET,
 	.regmap_length = CNP_PMC_MMIO_REG_LEN,
@@ -709,6 +725,25 @@ static int pmc_core_ltr_show(struct seq_file *s, void *unused)
 }
 DEFINE_SHOW_ATTRIBUTE(pmc_core_ltr);
 
+static int pmc_core_pkgc_show(struct seq_file *s, void *unused)
+{
+	struct pmc_dev *pmcdev = s->private;
+	const struct pmc_bit_map *map = pmcdev->map->msr_sts;
+	u64 pcstate_count;
+	int index;
+
+	for (index = 0; map[index].name ; index++) {
+		if (rdmsrl_safe(map[index].bit_mask, &pcstate_count))
+			continue;
+
+		seq_printf(s, "%-8s : 0x%llx\n", map[index].name,
+			   pcstate_count);
+	}
+
+	return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(pmc_core_pkgc);
+
 static void pmc_core_dbgfs_unregister(struct pmc_dev *pmcdev)
 {
 	debugfs_remove_recursive(pmcdev->dbgfs_dir);
@@ -735,6 +770,9 @@ static int pmc_core_dbgfs_register(struct pmc_dev *pmcdev)
 
 	debugfs_create_file("ltr_show", 0444, dir, pmcdev, &pmc_core_ltr_fops);
 
+	debugfs_create_file("package_cstate_show", 0444, dir, pmcdev,
+			    &pmc_core_pkgc_fops);
+
 	if (pmcdev->map->pll_sts)
 		debugfs_create_file("pll_status", 0444, dir, pmcdev,
 				    &pmc_core_pll_fops);
diff --git a/drivers/platform/x86/intel_pmc_core.h b/drivers/platform/x86/intel_pmc_core.h
index 78dd4229489d..6f1b64808075 100644
--- a/drivers/platform/x86/intel_pmc_core.h
+++ b/drivers/platform/x86/intel_pmc_core.h
@@ -214,6 +214,7 @@ struct pmc_reg_map {
 	const struct pmc_bit_map *pll_sts;
 	const struct pmc_bit_map **slps0_dbg_maps;
 	const struct pmc_bit_map *ltr_show_sts;
+	const struct pmc_bit_map *msr_sts;
 	const u32 slp_s0_offset;
 	const u32 ltr_ignore_offset;
 	const int regmap_length;
-- 
2.17.1

[PATCH v2 10/10] platform/x86: intel_pmc_core: Quirk to ignore XTAL shutdown

[Rajneesh Bhardwaj]

On some platforms such as HP Elite-x2-1013-g3, the platform BIOS
enforces XTAL to remain off before S0ix state can be achieved. This may
not be optimum when we want to enable use cases like Low Power Audio,
Wake on Voice etc which always need 24mhz clock.

This introduces a new quirk to allow S0ix entry when all other
conditions except for XTAL clock are good on a given platform. The extra
power consumed by XTAL clock is about 2mw but it saves much more
platform power compared to the system that remains in just PC10.

Link: https://bit.ly/2UmnrFf
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201579
Tested-by: "David E. Box" <david.e.box@linux.intel.com>
Reported-and-tested-by: russianneuromancer <russianneuromancer@ya.ru>
Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
---
 drivers/platform/x86/intel_pmc_core.c | 34 +++++++++++++++++++++++++++
 drivers/platform/x86/intel_pmc_core.h |  5 ++++
 2 files changed, 39 insertions(+)

diff --git a/drivers/platform/x86/intel_pmc_core.c b/drivers/platform/x86/intel_pmc_core.c
index 4e7aa1711148..a27574e3e868 100644
--- a/drivers/platform/x86/intel_pmc_core.c
+++ b/drivers/platform/x86/intel_pmc_core.c
@@ -15,6 +15,7 @@
 #include <linux/bitfield.h>
 #include <linux/debugfs.h>
 #include <linux/delay.h>
+#include <linux/dmi.h>
 #include <linux/io.h>
 #include <linux/module.h>
 #include <linux/pci.h>
@@ -151,6 +152,7 @@ static const struct pmc_reg_map spt_reg_map = {
 	.pm_cfg_offset = SPT_PMC_PM_CFG_OFFSET,
 	.pm_read_disable_bit = SPT_PMC_READ_DISABLE_BIT,
 	.ltr_ignore_max = SPT_NUM_IP_IGN_ALLOWED,
+	.pm_vric1_offset = SPT_PMC_VRIC1_OFFSET,
 };
 
 /* Cannonlake: PGD PFET Enable Ack Status Register(s) bitmap */
@@ -821,6 +823,37 @@ static const struct pci_device_id pmc_pci_ids[] = {
 	{ 0, },
 };
 
+/*
+ * This quirk can be used on those platforms where
+ * the platform BIOS enforces 24Mhx Crystal to shutdown
+ * before PMC can assert SLP_S0#.
+ */
+int quirk_xtal_ignore(const struct dmi_system_id *id)
+{
+	struct pmc_dev *pmcdev = &pmc;
+	u32 value;
+
+	value = pmc_core_reg_read(pmcdev, pmcdev->map->pm_vric1_offset);
+	/* 24MHz Crystal Shutdown Qualification Disable */
+	value |= SPT_PMC_VRIC1_XTALSDQDIS;
+	/* Low Voltage Mode Enable */
+	value &= ~SPT_PMC_VRIC1_SLPS0LVEN;
+	pmc_core_reg_write(pmcdev, pmcdev->map->pm_vric1_offset, value);
+	return 0;
+}
+
+static const struct dmi_system_id pmc_core_dmi_table[]  = {
+	{
+	.callback = quirk_xtal_ignore,
+	.ident = "HP Elite x2 1013 G3",
+	.matches = {
+		DMI_MATCH(DMI_SYS_VENDOR, "HP"),
+		DMI_MATCH(DMI_PRODUCT_NAME, "HP Elite x2 1013 G3"),
+		},
+	},
+	{}
+};
+
 static int __init pmc_core_probe(void)
 {
 	struct pmc_dev *pmcdev = &pmc;
@@ -862,6 +895,7 @@ static int __init pmc_core_probe(void)
 		return err;
 	}
 
+	dmi_check_system(pmc_core_dmi_table);
 	pr_info(" initialized\n");
 	return 0;
 }
diff --git a/drivers/platform/x86/intel_pmc_core.h b/drivers/platform/x86/intel_pmc_core.h
index 6f1b64808075..88d9c0653a5f 100644
--- a/drivers/platform/x86/intel_pmc_core.h
+++ b/drivers/platform/x86/intel_pmc_core.h
@@ -25,6 +25,7 @@
 #define SPT_PMC_MTPMC_OFFSET			0x20
 #define SPT_PMC_MFPMC_OFFSET			0x38
 #define SPT_PMC_LTR_IGNORE_OFFSET		0x30C
+#define SPT_PMC_VRIC1_OFFSET			0x31c
 #define SPT_PMC_MPHY_CORE_STS_0			0x1143
 #define SPT_PMC_MPHY_CORE_STS_1			0x1142
 #define SPT_PMC_MPHY_COM_STS_0			0x1155
@@ -136,6 +137,9 @@ enum ppfear_regs {
 #define SPT_PMC_BIT_MPHY_CMN_LANE2		BIT(2)
 #define SPT_PMC_BIT_MPHY_CMN_LANE3		BIT(3)
 
+#define SPT_PMC_VRIC1_SLPS0LVEN			BIT(13)
+#define SPT_PMC_VRIC1_XTALSDQDIS		BIT(22)
+
 /* Cannonlake Power Management Controller register offsets */
 #define CNP_PMC_SLPS0_DBG_OFFSET		0x10B4
 #define CNP_PMC_PM_CFG_OFFSET			0x1818
@@ -224,6 +228,7 @@ struct pmc_reg_map {
 	const int pm_read_disable_bit;
 	const u32 slps0_dbg_offset;
 	const u32 ltr_ignore_max;
+	const u32 pm_vric1_offset;
 };
 
 /**
-- 
2.17.1

RE: [PATCH v2 10/10] platform/x86: intel_pmc_core: Quirk to ignore XTAL shutdown

[Mario.Limonciello]

> -----Original Message-----
> From: platform-driver-x86-owner@vger.kernel.org <platform-driver-x86-
> owner@vger.kernel.org> On Behalf Of Rajneesh Bhardwaj
> Sent: Wednesday, February 13, 2019 9:08 AM
> To: platform-driver-x86@vger.kernel.org
> Cc: dvhart@infradead.org; andy@infradead.org; linux-kernel@vger.kernel.org;
> Rajneesh Bhardwaj
> Subject: [PATCH v2 10/10] platform/x86: intel_pmc_core: Quirk to ignore XTAL
> shutdown
> 
> 
> [EXTERNAL EMAIL]
> 
> On some platforms such as HP Elite-x2-1013-g3, the platform BIOS
> enforces XTAL to remain off before S0ix state can be achieved. This may
> not be optimum when we want to enable use cases like Low Power Audio,
> Wake on Voice etc which always need 24mhz clock.
> 
> This introduces a new quirk to allow S0ix entry when all other
> conditions except for XTAL clock are good on a given platform. The extra
> power consumed by XTAL clock is about 2mw but it saves much more
> platform power compared to the system that remains in just PC10.
> 

I wonder are there really any use cases for 24 mhz clock "needing" to stay
enabled on Linux over a S0ix cycle and factor into the S0ix state decision?

Is it perhaps better to set this as default behavior and quirk situations that it
may not be needed.

> Link: https://bit.ly/2UmnrFf
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201579
> Tested-by: "David E. Box" <david.e.box@linux.intel.com>
> Reported-and-tested-by: russianneuromancer <russianneuromancer@ya.ru>
> Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
> ---
>  drivers/platform/x86/intel_pmc_core.c | 34 +++++++++++++++++++++++++++
>  drivers/platform/x86/intel_pmc_core.h |  5 ++++
>  2 files changed, 39 insertions(+)
> 
> diff --git a/drivers/platform/x86/intel_pmc_core.c
> b/drivers/platform/x86/intel_pmc_core.c
> index 4e7aa1711148..a27574e3e868 100644
> --- a/drivers/platform/x86/intel_pmc_core.c
> +++ b/drivers/platform/x86/intel_pmc_core.c
> @@ -15,6 +15,7 @@
>  #include <linux/bitfield.h>
>  #include <linux/debugfs.h>
>  #include <linux/delay.h>
> +#include <linux/dmi.h>
>  #include <linux/io.h>
>  #include <linux/module.h>
>  #include <linux/pci.h>
> @@ -151,6 +152,7 @@ static const struct pmc_reg_map spt_reg_map = {
>  	.pm_cfg_offset = SPT_PMC_PM_CFG_OFFSET,
>  	.pm_read_disable_bit = SPT_PMC_READ_DISABLE_BIT,
>  	.ltr_ignore_max = SPT_NUM_IP_IGN_ALLOWED,
> +	.pm_vric1_offset = SPT_PMC_VRIC1_OFFSET,
>  };
> 
>  /* Cannonlake: PGD PFET Enable Ack Status Register(s) bitmap */
> @@ -821,6 +823,37 @@ static const struct pci_device_id pmc_pci_ids[] = {
>  	{ 0, },
>  };
> 
> +/*
> + * This quirk can be used on those platforms where
> + * the platform BIOS enforces 24Mhx Crystal to shutdown
> + * before PMC can assert SLP_S0#.
> + */
> +int quirk_xtal_ignore(const struct dmi_system_id *id)
> +{
> +	struct pmc_dev *pmcdev = &pmc;
> +	u32 value;
> +
> +	value = pmc_core_reg_read(pmcdev, pmcdev->map->pm_vric1_offset);
> +	/* 24MHz Crystal Shutdown Qualification Disable */
> +	value |= SPT_PMC_VRIC1_XTALSDQDIS;
> +	/* Low Voltage Mode Enable */
> +	value &= ~SPT_PMC_VRIC1_SLPS0LVEN;
> +	pmc_core_reg_write(pmcdev, pmcdev->map->pm_vric1_offset, value);
> +	return 0;
> +}
> +
> +static const struct dmi_system_id pmc_core_dmi_table[]  = {
> +	{
> +	.callback = quirk_xtal_ignore,
> +	.ident = "HP Elite x2 1013 G3",
> +	.matches = {
> +		DMI_MATCH(DMI_SYS_VENDOR, "HP"),
> +		DMI_MATCH(DMI_PRODUCT_NAME, "HP Elite x2 1013 G3"),
> +		},
> +	},
> +	{}
> +};
> +
>  static int __init pmc_core_probe(void)
>  {
>  	struct pmc_dev *pmcdev = &pmc;
> @@ -862,6 +895,7 @@ static int __init pmc_core_probe(void)
>  		return err;
>  	}
> 
> +	dmi_check_system(pmc_core_dmi_table);
>  	pr_info(" initialized\n");
>  	return 0;
>  }
> diff --git a/drivers/platform/x86/intel_pmc_core.h
> b/drivers/platform/x86/intel_pmc_core.h
> index 6f1b64808075..88d9c0653a5f 100644
> --- a/drivers/platform/x86/intel_pmc_core.h
> +++ b/drivers/platform/x86/intel_pmc_core.h
> @@ -25,6 +25,7 @@
>  #define SPT_PMC_MTPMC_OFFSET			0x20
>  #define SPT_PMC_MFPMC_OFFSET			0x38
>  #define SPT_PMC_LTR_IGNORE_OFFSET		0x30C
> +#define SPT_PMC_VRIC1_OFFSET			0x31c
>  #define SPT_PMC_MPHY_CORE_STS_0			0x1143
>  #define SPT_PMC_MPHY_CORE_STS_1			0x1142
>  #define SPT_PMC_MPHY_COM_STS_0			0x1155
> @@ -136,6 +137,9 @@ enum ppfear_regs {
>  #define SPT_PMC_BIT_MPHY_CMN_LANE2		BIT(2)
>  #define SPT_PMC_BIT_MPHY_CMN_LANE3		BIT(3)
> 
> +#define SPT_PMC_VRIC1_SLPS0LVEN			BIT(13)
> +#define SPT_PMC_VRIC1_XTALSDQDIS		BIT(22)
> +
>  /* Cannonlake Power Management Controller register offsets */
>  #define CNP_PMC_SLPS0_DBG_OFFSET		0x10B4
>  #define CNP_PMC_PM_CFG_OFFSET			0x1818
> @@ -224,6 +228,7 @@ struct pmc_reg_map {
>  	const int pm_read_disable_bit;
>  	const u32 slps0_dbg_offset;
>  	const u32 ltr_ignore_max;
> +	const u32 pm_vric1_offset;
>  };
> 
>  /**
> --
> 2.17.1

Re: [PATCH v2 10/10] platform/x86: intel_pmc_core: Quirk to ignore XTAL shutdown

[Bhardwaj, Rajneesh]

On 13-Feb-19 8:51 PM, Mario.Limonciello@dell.com wrote:
>
>> -----Original Message-----
>> From: platform-driver-x86-owner@vger.kernel.org <platform-driver-x86-
>> owner@vger.kernel.org> On Behalf Of Rajneesh Bhardwaj
>> Sent: Wednesday, February 13, 2019 9:08 AM
>> To: platform-driver-x86@vger.kernel.org
>> Cc: dvhart@infradead.org; andy@infradead.org; linux-kernel@vger.kernel.org;
>> Rajneesh Bhardwaj
>> Subject: [PATCH v2 10/10] platform/x86: intel_pmc_core: Quirk to ignore XTAL
>> shutdown
>>
>>
>> [EXTERNAL EMAIL]
>>
>> On some platforms such as HP Elite-x2-1013-g3, the platform BIOS
>> enforces XTAL to remain off before S0ix state can be achieved. This may
>> not be optimum when we want to enable use cases like Low Power Audio,
>> Wake on Voice etc which always need 24mhz clock.
>>
>> This introduces a new quirk to allow S0ix entry when all other
>> conditions except for XTAL clock are good on a given platform. The extra
>> power consumed by XTAL clock is about 2mw but it saves much more
>> platform power compared to the system that remains in just PC10.
>>
> I wonder are there really any use cases for 24 mhz clock "needing" to stay
> enabled on Linux over a S0ix cycle and factor into the S0ix state decision?
>
> Is it perhaps better to set this as default behavior and quirk situations that it
> may not be needed.

Hi Mario,

I agree but the PMC default settings are determined by the platform 
BIOS. Some vendors may want to support WakeOnVoice and other use cases 
where a dependent clock from XTAL may be required while others might 
just not care. For this particular machine, the BIOS runs some special 
asl code that handles these settings for Windows and this is a deviation 
from normal. Thus we prefer a quirk for this and will monitor similar 
reports from other vendors too on other SoCs as well before we make this 
default in driver.


>
>> Link: https://bit.ly/2UmnrFf
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=201579
>> Tested-by: "David E. Box" <david.e.box@linux.intel.com>
>> Reported-and-tested-by: russianneuromancer <russianneuromancer@ya.ru>
>> Signed-off-by: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
>> ---
>>   drivers/platform/x86/intel_pmc_core.c | 34 +++++++++++++++++++++++++++
>>   drivers/platform/x86/intel_pmc_core.h |  5 ++++
>>   2 files changed, 39 insertions(+)
>>
>> diff --git a/drivers/platform/x86/intel_pmc_core.c
>> b/drivers/platform/x86/intel_pmc_core.c
>> index 4e7aa1711148..a27574e3e868 100644
>> --- a/drivers/platform/x86/intel_pmc_core.c
>> +++ b/drivers/platform/x86/intel_pmc_core.c
>> @@ -15,6 +15,7 @@
>>   #include <linux/bitfield.h>
>>   #include <linux/debugfs.h>
>>   #include <linux/delay.h>
>> +#include <linux/dmi.h>
>>   #include <linux/io.h>
>>   #include <linux/module.h>
>>   #include <linux/pci.h>
>> @@ -151,6 +152,7 @@ static const struct pmc_reg_map spt_reg_map = {
>>   	.pm_cfg_offset = SPT_PMC_PM_CFG_OFFSET,
>>   	.pm_read_disable_bit = SPT_PMC_READ_DISABLE_BIT,
>>   	.ltr_ignore_max = SPT_NUM_IP_IGN_ALLOWED,
>> +	.pm_vric1_offset = SPT_PMC_VRIC1_OFFSET,
>>   };
>>
>>   /* Cannonlake: PGD PFET Enable Ack Status Register(s) bitmap */
>> @@ -821,6 +823,37 @@ static const struct pci_device_id pmc_pci_ids[] = {
>>   	{ 0, },
>>   };
>>
>> +/*
>> + * This quirk can be used on those platforms where
>> + * the platform BIOS enforces 24Mhx Crystal to shutdown
>> + * before PMC can assert SLP_S0#.
>> + */
>> +int quirk_xtal_ignore(const struct dmi_system_id *id)
>> +{
>> +	struct pmc_dev *pmcdev = &pmc;
>> +	u32 value;
>> +
>> +	value = pmc_core_reg_read(pmcdev, pmcdev->map->pm_vric1_offset);
>> +	/* 24MHz Crystal Shutdown Qualification Disable */
>> +	value |= SPT_PMC_VRIC1_XTALSDQDIS;
>> +	/* Low Voltage Mode Enable */
>> +	value &= ~SPT_PMC_VRIC1_SLPS0LVEN;
>> +	pmc_core_reg_write(pmcdev, pmcdev->map->pm_vric1_offset, value);
>> +	return 0;
>> +}
>> +
>> +static const struct dmi_system_id pmc_core_dmi_table[]  = {
>> +	{
>> +	.callback = quirk_xtal_ignore,
>> +	.ident = "HP Elite x2 1013 G3",
>> +	.matches = {
>> +		DMI_MATCH(DMI_SYS_VENDOR, "HP"),
>> +		DMI_MATCH(DMI_PRODUCT_NAME, "HP Elite x2 1013 G3"),
>> +		},
>> +	},
>> +	{}
>> +};
>> +
>>   static int __init pmc_core_probe(void)
>>   {
>>   	struct pmc_dev *pmcdev = &pmc;
>> @@ -862,6 +895,7 @@ static int __init pmc_core_probe(void)
>>   		return err;
>>   	}
>>
>> +	dmi_check_system(pmc_core_dmi_table);
>>   	pr_info(" initialized\n");
>>   	return 0;
>>   }
>> diff --git a/drivers/platform/x86/intel_pmc_core.h
>> b/drivers/platform/x86/intel_pmc_core.h
>> index 6f1b64808075..88d9c0653a5f 100644
>> --- a/drivers/platform/x86/intel_pmc_core.h
>> +++ b/drivers/platform/x86/intel_pmc_core.h
>> @@ -25,6 +25,7 @@
>>   #define SPT_PMC_MTPMC_OFFSET			0x20
>>   #define SPT_PMC_MFPMC_OFFSET			0x38
>>   #define SPT_PMC_LTR_IGNORE_OFFSET		0x30C
>> +#define SPT_PMC_VRIC1_OFFSET			0x31c
>>   #define SPT_PMC_MPHY_CORE_STS_0			0x1143
>>   #define SPT_PMC_MPHY_CORE_STS_1			0x1142
>>   #define SPT_PMC_MPHY_COM_STS_0			0x1155
>> @@ -136,6 +137,9 @@ enum ppfear_regs {
>>   #define SPT_PMC_BIT_MPHY_CMN_LANE2		BIT(2)
>>   #define SPT_PMC_BIT_MPHY_CMN_LANE3		BIT(3)
>>
>> +#define SPT_PMC_VRIC1_SLPS0LVEN			BIT(13)
>> +#define SPT_PMC_VRIC1_XTALSDQDIS		BIT(22)
>> +
>>   /* Cannonlake Power Management Controller register offsets */
>>   #define CNP_PMC_SLPS0_DBG_OFFSET		0x10B4
>>   #define CNP_PMC_PM_CFG_OFFSET			0x1818
>> @@ -224,6 +228,7 @@ struct pmc_reg_map {
>>   	const int pm_read_disable_bit;
>>   	const u32 slps0_dbg_offset;
>>   	const u32 ltr_ignore_max;
>> +	const u32 pm_vric1_offset;
>>   };
>>
>>   /**
>> --
>> 2.17.1

Re: [PATCH v2 00/10] ICL support and other enhancements for PMC Core

[Andy Shevchenko]

On Wed, Feb 13, 2019 at 5:08 PM Rajneesh Bhardwaj
<rajneesh.bhardwaj@linux.intel.com> wrote:
>
> This patch series provides Icelake support for PMC Core driver and while
> doing so it introduces the Icelake Mobile to intel-family.h as per the
> CPUID from below Coreboot link
> https://github.com/coreboot/coreboot/blob/5ebcea3aaaa3cd358bc5bccaa156b13a6ef25df6/src/soc/intel/common/block/include/intelblocks/mp_init.h
> and provides some fixes and enhancements to the driver.

It's not applicable to my tree.

> Changes in v2:
>  * Addressed review comments from Thomas
>  * Added tags revieved
>  * Folded in SHA1 suggestions from Stephen Rothwell, though Andy might want to
>    fix it via rebasing
>  * Rebased and tested with Linux v5.0.0-rc6
>
> This series:
>  - Adds ICL U/Y CPUID to intel-family.h
>  - Enables PMC driver for ICL
>  - Introduces a new "package cstate show" feature
>  - Fixes a customer issue related to S0ix on latest HP laptops
>  - Fixes some minor bugs
>
> Rajneesh Bhardwaj (10):
>   platform/x86: intel_pmc_core: Handle CFL regmap properly
>   platform/x86: intel_pmc_core: Fix PCH IP sts reading
>   platform/x86: intel_pmc_core: Fix PCH IP name
>   platform/x86: intel_pmc_core: Fix file permissions for ltr_show
>   platform/x86: intel_pmc_core: Include Reserved IP for LTR
>   x86/cpu: Add Icelake to Intel family
>   platform/x86: intel_pmc_core: Convert to INTEL_CPU_FAM6 macro
>   platform/x86: intel_pmc_core: Add ICL platform support
>   platform/x86: intel_pmc_core: Add Package cstates residency info
>   platform/x86: intel_pmc_core: Quirk to ignore XTAL shutdown
>
>  arch/x86/include/asm/intel-family.h   |   2 +
>  drivers/platform/x86/intel_pmc_core.c | 155 +++++++++++++++++++++-----
>  drivers/platform/x86/intel_pmc_core.h |  14 ++-
>  3 files changed, 145 insertions(+), 26 deletions(-)
>
> --
> 2.17.1
>


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 00/10] ICL support and other enhancements for PMC Core

[Bhardwaj, Rajneesh]

On 13-Feb-19 9:03 PM, Andy Shevchenko wrote:
> On Wed, Feb 13, 2019 at 5:08 PM Rajneesh Bhardwaj
> <rajneesh.bhardwaj@linux.intel.com> wrote:
>> This patch series provides Icelake support for PMC Core driver and while
>> doing so it introduces the Icelake Mobile to intel-family.h as per the
>> CPUID from below Coreboot link
>> https://github.com/coreboot/coreboot/blob/5ebcea3aaaa3cd358bc5bccaa156b13a6ef25df6/src/soc/intel/common/block/include/intelblocks/mp_init.h
>> and provides some fixes and enhancements to the driver.
> It's not applicable to my tree.

Hi Andy,  I could apply and test in on latest upstream so i think its 
probably because you have applied 5 patches from v1 on your tree. 
https://github.com/dvhart/linux-pdx86/commits/for-next

I sent the whole series again since 
https://patchwork.kernel.org/patch/10791893 referred to a wrong commit 
for Fixes:. If you want to address that by rebasing then can you please 
just consider patches 6-10.

Please let me know if there is any other issue?

>> Changes in v2:
>>   * Addressed review comments from Thomas
>>   * Added tags revieved
>>   * Folded in SHA1 suggestions from Stephen Rothwell, though Andy might want to
>>     fix it via rebasing
>>   * Rebased and tested with Linux v5.0.0-rc6
>>
>> This series:
>>   - Adds ICL U/Y CPUID to intel-family.h
>>   - Enables PMC driver for ICL
>>   - Introduces a new "package cstate show" feature
>>   - Fixes a customer issue related to S0ix on latest HP laptops
>>   - Fixes some minor bugs
>>
>> Rajneesh Bhardwaj (10):
>>    platform/x86: intel_pmc_core: Handle CFL regmap properly
>>    platform/x86: intel_pmc_core: Fix PCH IP sts reading
>>    platform/x86: intel_pmc_core: Fix PCH IP name
>>    platform/x86: intel_pmc_core: Fix file permissions for ltr_show
>>    platform/x86: intel_pmc_core: Include Reserved IP for LTR
>>    x86/cpu: Add Icelake to Intel family
>>    platform/x86: intel_pmc_core: Convert to INTEL_CPU_FAM6 macro
>>    platform/x86: intel_pmc_core: Add ICL platform support
>>    platform/x86: intel_pmc_core: Add Package cstates residency info
>>    platform/x86: intel_pmc_core: Quirk to ignore XTAL shutdown
>>
>>   arch/x86/include/asm/intel-family.h   |   2 +
>>   drivers/platform/x86/intel_pmc_core.c | 155 +++++++++++++++++++++-----
>>   drivers/platform/x86/intel_pmc_core.h |  14 ++-
>>   3 files changed, 145 insertions(+), 26 deletions(-)
>>
>> --
>> 2.17.1
>>
>

Re: [PATCH v2 00/10] ICL support and other enhancements for PMC Core

[Andy Shevchenko]

On Wed, Feb 13, 2019 at 5:50 PM Bhardwaj, Rajneesh
<rajneesh.bhardwaj@linux.intel.com> wrote:
> On 13-Feb-19 9:03 PM, Andy Shevchenko wrote:
> > On Wed, Feb 13, 2019 at 5:08 PM Rajneesh Bhardwaj
> > <rajneesh.bhardwaj@linux.intel.com> wrote:
> >> This patch series provides Icelake support for PMC Core driver and while
> >> doing so it introduces the Icelake Mobile to intel-family.h as per the
> >> CPUID from below Coreboot link
> >> https://github.com/coreboot/coreboot/blob/5ebcea3aaaa3cd358bc5bccaa156b13a6ef25df6/src/soc/intel/common/block/include/intelblocks/mp_init.h
> >> and provides some fixes and enhancements to the driver.
> > It's not applicable to my tree.
>
> Hi Andy,  I could apply and test in on latest upstream so i think its
> probably because you have applied 5 patches from v1 on your tree.
> https://github.com/dvhart/linux-pdx86/commits/for-next

You need to use latest tip of the subsystem tree always.

> I sent the whole series again since
> https://patchwork.kernel.org/patch/10791893 referred to a wrong commit
> for Fixes:. If you want to address that by rebasing then can you please
> just consider patches 6-10.

We don't do rebasing for published changes. Only in rear cases when
otherwise would be worse.
Darren didn't respond to my question what he thinks about this case,
but at least it's not related to the code itself which, in my opinion,
decreases a severity.

> Please let me know if there is any other issue?


-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 00/10] ICL support and other enhancements for PMC Core

[Bhardwaj, Rajneesh]

On 13-Feb-19 10:58 PM, Andy Shevchenko wrote:
> On Wed, Feb 13, 2019 at 5:50 PM Bhardwaj, Rajneesh
> <rajneesh.bhardwaj@linux.intel.com> wrote:
>> On 13-Feb-19 9:03 PM, Andy Shevchenko wrote:
>>> On Wed, Feb 13, 2019 at 5:08 PM Rajneesh Bhardwaj
>>> <rajneesh.bhardwaj@linux.intel.com> wrote:
>>>> This patch series provides Icelake support for PMC Core driver and while
>>>> doing so it introduces the Icelake Mobile to intel-family.h as per the
>>>> CPUID from below Coreboot link
>>>> https://github.com/coreboot/coreboot/blob/5ebcea3aaaa3cd358bc5bccaa156b13a6ef25df6/src/soc/intel/common/block/include/intelblocks/mp_init.h
>>>> and provides some fixes and enhancements to the driver.
>>> It's not applicable to my tree.
>> Hi Andy,  I could apply and test in on latest upstream so i think its
>> probably because you have applied 5 patches from v1 on your tree.
>> https://github.com/dvhart/linux-pdx86/commits/for-next
> You need to use latest tip of the subsystem tree always.

Ok.

>
>> I sent the whole series again since
>> https://patchwork.kernel.org/patch/10791893 referred to a wrong commit
>> for Fixes:. If you want to address that by rebasing then can you please
>> just consider patches 6-10.
> We don't do rebasing for published changes. Only in rear cases when
> otherwise would be worse.
> Darren didn't respond to my question what he thinks about this case,
> but at least it's not related to the code itself which, in my opinion,
> decreases a severity.

Thanks Andy. So if i understand correctly, you are suggesting that i 
should ignore those patches that made to "for-next" branch already?

So should i just send a v3 comprising of remaining 5 patches and of 
course,  addressing recent review comments?

>> Please let me know if there is any other issue?
>

Re: [PATCH v2 00/10] ICL support and other enhancements for PMC Core

[Andy Shevchenko]

On Wed, Feb 13, 2019 at 8:02 PM Bhardwaj, Rajneesh
<rajneesh.bhardwaj@linux.intel.com> wrote:
> On 13-Feb-19 10:58 PM, Andy Shevchenko wrote:
> > On Wed, Feb 13, 2019 at 5:50 PM Bhardwaj, Rajneesh
> > <rajneesh.bhardwaj@linux.intel.com> wrote:
> >> On 13-Feb-19 9:03 PM, Andy Shevchenko wrote:

> > We don't do rebasing for published changes. Only in rear cases when
> > otherwise would be worse.
> > Darren didn't respond to my question what he thinks about this case,
> > but at least it's not related to the code itself which, in my opinion,
> > decreases a severity.
>
> Thanks Andy. So if i understand correctly, you are suggesting that i
> should ignore those patches that made to "for-next" branch already?

I suggest you to rebase your local branch against latest subsystem tip
branch, resolve conflicts if any, test, and only after that send a new
version.

> So should i just send a v3 comprising of remaining 5 patches and of
> course,  addressing recent review comments?

I dunno how many patches you will get after rebasing. It might be 5,
might be more, might be less. You decide what will be in next version.
Just carefully describe the changes in the log.

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v2 00/10] ICL support and other enhancements for PMC Core

[Andy Shevchenko]

On Wed, Feb 13, 2019 at 8:13 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Wed, Feb 13, 2019 at 8:02 PM Bhardwaj, Rajneesh
> <rajneesh.bhardwaj@linux.intel.com> wrote:
> > On 13-Feb-19 10:58 PM, Andy Shevchenko wrote:
> > > On Wed, Feb 13, 2019 at 5:50 PM Bhardwaj, Rajneesh
> > > <rajneesh.bhardwaj@linux.intel.com> wrote:
> > >> On 13-Feb-19 9:03 PM, Andy Shevchenko wrote:
>
> > > We don't do rebasing for published changes. Only in rear cases when
> > > otherwise would be worse.
> > > Darren didn't respond to my question what he thinks about this case,
> > > but at least it's not related to the code itself which, in my opinion,
> > > decreases a severity.
> >
> > Thanks Andy. So if i understand correctly, you are suggesting that i
> > should ignore those patches that made to "for-next" branch already?
>
> I suggest you to rebase your local branch against latest subsystem tip
> branch, resolve conflicts if any, test, and only after that send a new
> version.

To clarify: "subsystem tip branch" in our case means for-next. The
above is a generic process which would work with Linux kernel
development.

-- 
With Best Regards,
Andy Shevchenko