[PATCH 00/15] hwmon, fam15h_power: introduce an accumulated power reporting algorithm

[PATCH 00/15] hwmon, fam15h_power: introduce an accumulated power reporting algorithm

[Huang Rui]

Hi all,

This serial of patches introduces an accumulated power reporting
algorithm. It will calculate the average power consumption for the
processor. The cpu feature flag is CPUID.8000_0007H:EDX[12].

This algorithm is used to test the comparison of processor power
consumption with between MWAITX delay and TSC delay on AMD Carrizo
platforms.

Reference:
http://marc.info/?l=linux-kernel&m=143874573111310&w=2

Commit f96756 at tip ("x86/asm: Add MONITORX/MWAITX instruction support")
Commit b466bd at tip ("x86/asm/delay: Introduce an MWAITX-based delay with a configurable timer")

Thanks,
Rui

Huang Rui (15):
  hwmon, fam15h_power: add support for AMD Carrizo
  hwmon, fam15h_power: rename fam15h_power_is_internal_node0 function
  hwmon, fam15h_power: refactor attributes for dynamically added
  hwmon, fam15h_power: update running_avg_capture bit field to 28
  hwmon, fam15h_power: enable power1_input on AMD Carrizo
  hwmon, fam15h_power: add documentation for new processors support
  hwmon, fam15h_power: add ratio of Tsample to the PTSC period
  hwmon, fam15h_power: add max compute unit accumulated power
  x86, amd: add accessor for number of cores per compute unit
  hwmon, fam15h_power: add compute unit accumulated power
  hwmon, fam15h_power: add ptsc counter value for accumulated power
  hwmon, fam15h_power: introduce a cpu accumulated power reporting
    algorithm
  hwmon, fam15h_power: add documentation for previous TDP reporting
  hwmon, fam15h_power: add documentation for accumulated power algorithm
  MAINTAINERS: change the maintainer of fam15h_power driver

 Documentation/hwmon/fam15h_power |  63 +++++++++++-
 MAINTAINERS                      |   4 +-
 arch/x86/include/asm/msr-index.h |   1 +
 arch/x86/include/asm/processor.h |   1 +
 arch/x86/kernel/cpu/amd.c        |  19 +++-
 drivers/hwmon/fam15h_power.c     | 204 ++++++++++++++++++++++++++++++++++-----
 6 files changed, 258 insertions(+), 34 deletions(-)

-- 
1.9.1

[lm-sensors] [PATCH 00/15] hwmon, fam15h_power: introduce an accumulated power reporting algorithm

[Huang Rui]

Hi all,

This serial of patches introduces an accumulated power reporting
algorithm. It will calculate the average power consumption for the
processor. The cpu feature flag is CPUID.8000_0007H:EDX[12].

This algorithm is used to test the comparison of processor power
consumption with between MWAITX delay and TSC delay on AMD Carrizo
platforms.

Reference:
http://marc.info/?l=linux-kernel&m\x143874573111310&w=2

Commit f96756 at tip ("x86/asm: Add MONITORX/MWAITX instruction support")
Commit b466bd at tip ("x86/asm/delay: Introduce an MWAITX-based delay with a configurable timer")

Thanks,
Rui

Huang Rui (15):
  hwmon, fam15h_power: add support for AMD Carrizo
  hwmon, fam15h_power: rename fam15h_power_is_internal_node0 function
  hwmon, fam15h_power: refactor attributes for dynamically added
  hwmon, fam15h_power: update running_avg_capture bit field to 28
  hwmon, fam15h_power: enable power1_input on AMD Carrizo
  hwmon, fam15h_power: add documentation for new processors support
  hwmon, fam15h_power: add ratio of Tsample to the PTSC period
  hwmon, fam15h_power: add max compute unit accumulated power
  x86, amd: add accessor for number of cores per compute unit
  hwmon, fam15h_power: add compute unit accumulated power
  hwmon, fam15h_power: add ptsc counter value for accumulated power
  hwmon, fam15h_power: introduce a cpu accumulated power reporting
    algorithm
  hwmon, fam15h_power: add documentation for previous TDP reporting
  hwmon, fam15h_power: add documentation for accumulated power algorithm
  MAINTAINERS: change the maintainer of fam15h_power driver

 Documentation/hwmon/fam15h_power |  63 +++++++++++-
 MAINTAINERS                      |   4 +-
 arch/x86/include/asm/msr-index.h |   1 +
 arch/x86/include/asm/processor.h |   1 +
 arch/x86/kernel/cpu/amd.c        |  19 +++-
 drivers/hwmon/fam15h_power.c     | 204 ++++++++++++++++++++++++++++++++++-----
 6 files changed, 258 insertions(+), 34 deletions(-)

-- 
1.9.1


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[PATCH 01/15] hwmon, fam15h_power: add support for AMD Carrizo

[Huang Rui]

AMD Carrizo(Fam15h, M60h) processors can report power1_crit
(ProcessorPwrWatts) and power1_input (CurrPwrWatts) values.
And this patch adds support for CZ.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 drivers/hwmon/fam15h_power.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index 3057dfc..0753810 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -233,6 +233,7 @@ static int fam15h_power_probe(struct pci_dev *pdev,
 static const struct pci_device_id fam15h_power_id_table[] = {
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F4) },
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M30H_NB_F4) },
+	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M60H_NB_F4) },
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_NB_F4) },
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F4) },
 	{}
-- 
1.9.1

[lm-sensors] [PATCH 01/15] hwmon, fam15h_power: add support for AMD Carrizo

[Huang Rui]

AMD Carrizo(Fam15h, M60h) processors can report power1_crit
(ProcessorPwrWatts) and power1_input (CurrPwrWatts) values.
And this patch adds support for CZ.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 drivers/hwmon/fam15h_power.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index 3057dfc..0753810 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -233,6 +233,7 @@ static int fam15h_power_probe(struct pci_dev *pdev,
 static const struct pci_device_id fam15h_power_id_table[] = {
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_NB_F4) },
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M30H_NB_F4) },
+	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_15H_M60H_NB_F4) },
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_NB_F4) },
 	{ PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_16H_M30H_NB_F4) },
 	{}
-- 
1.9.1


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[PATCH 02/15] hwmon, fam15h_power: rename fam15h_power_is_internal_node0 function

[Huang Rui]

We rename fam15h_power_is_internal_node0() function to
should_load_on_this_node(), because it may not be node0 from KV and
on, and they are single-node processors.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 drivers/hwmon/fam15h_power.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index 0753810..820adf1 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -117,7 +117,7 @@ static const struct attribute_group fam15h_power_group = {
 };
 __ATTRIBUTE_GROUPS(fam15h_power);
 
-static bool fam15h_power_is_internal_node0(struct pci_dev *f4)
+static bool should_load_on_this_node(struct pci_dev *f4)
 {
 	u32 val;
 
@@ -214,7 +214,7 @@ static int fam15h_power_probe(struct pci_dev *pdev,
 	 */
 	tweak_runavg_range(pdev);
 
-	if (!fam15h_power_is_internal_node0(pdev))
+	if (!should_load_on_this_node(pdev))
 		return -ENODEV;
 
 	data = devm_kzalloc(dev, sizeof(struct fam15h_power_data), GFP_KERNEL);
-- 
1.9.1

[lm-sensors] [PATCH 02/15] hwmon, fam15h_power: rename fam15h_power_is_internal_node0 function

[Huang Rui]

We rename fam15h_power_is_internal_node0() function to
should_load_on_this_node(), because it may not be node0 from KV and
on, and they are single-node processors.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 drivers/hwmon/fam15h_power.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index 0753810..820adf1 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -117,7 +117,7 @@ static const struct attribute_group fam15h_power_group = {
 };
 __ATTRIBUTE_GROUPS(fam15h_power);
 
-static bool fam15h_power_is_internal_node0(struct pci_dev *f4)
+static bool should_load_on_this_node(struct pci_dev *f4)
 {
 	u32 val;
 
@@ -214,7 +214,7 @@ static int fam15h_power_probe(struct pci_dev *pdev,
 	 */
 	tweak_runavg_range(pdev);
 
-	if (!fam15h_power_is_internal_node0(pdev))
+	if (!should_load_on_this_node(pdev))
 		return -ENODEV;
 
 	data = devm_kzalloc(dev, sizeof(struct fam15h_power_data), GFP_KERNEL);
-- 
1.9.1


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[PATCH 03/15] hwmon, fam15h_power: refactor attributes for dynamically added

[Huang Rui]

Attributes depend on the CPU model the driver gets loaded on.
Therefore, add those attributes dynamically at init time. This is more
flexible to control the different attributes on different platforms.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 drivers/hwmon/fam15h_power.c | 49 +++++++++++++++++++++++++++-----------------
 1 file changed, 30 insertions(+), 19 deletions(-)

diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index 820adf1..65ffb06 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -41,6 +41,8 @@ MODULE_LICENSE("GPL");
 #define REG_TDP_RUNNING_AVERAGE		0xe0
 #define REG_TDP_LIMIT3			0xe8
 
+#define FAM15H_MIN_POWER_GROUPS		2
+
 struct fam15h_power_data {
 	struct pci_dev *pdev;
 	unsigned int tdp_to_watts;
@@ -93,29 +95,35 @@ static ssize_t show_power_crit(struct device *dev,
 }
 static DEVICE_ATTR(power1_crit, S_IRUGO, show_power_crit, NULL);
 
-static umode_t fam15h_power_is_visible(struct kobject *kobj,
-				       struct attribute *attr,
-				       int index)
+static struct attribute_group fam15h_power_group;
+__ATTRIBUTE_GROUPS(fam15h_power);
+
+static int fam15h_power_init_attrs(struct pci_dev *pdev)
 {
-	/* power1_input is only reported for Fam15h, Models 00h-0fh */
-	if (attr == &dev_attr_power1_input.attr &&
-	   (boot_cpu_data.x86 != 0x15 || boot_cpu_data.x86_model > 0xf))
-		return 0;
+	int n = FAM15H_MIN_POWER_GROUPS;
+	struct attribute **fam15h_power_attrs;
 
-	return attr->mode;
-}
+	if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model <= 0xf)
+		n += 1;
 
-static struct attribute *fam15h_power_attrs[] = {
-	&dev_attr_power1_input.attr,
-	&dev_attr_power1_crit.attr,
-	NULL
-};
+	fam15h_power_attrs = devm_kcalloc(&pdev->dev, n,
+					  sizeof(*fam15h_power_attrs),
+					  GFP_KERNEL);
 
-static const struct attribute_group fam15h_power_group = {
-	.attrs = fam15h_power_attrs,
-	.is_visible = fam15h_power_is_visible,
-};
-__ATTRIBUTE_GROUPS(fam15h_power);
+	if (!fam15h_power_attrs) {
+		dev_err(&pdev->dev, "failed to alloc fam15h_power_attrs\n");
+		return -ENOMEM;
+	}
+
+	n = 0;
+	fam15h_power_attrs[n++] = &dev_attr_power1_crit.attr;
+	if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model <= 0xf)
+		fam15h_power_attrs[n++] = &dev_attr_power1_input.attr;
+
+	fam15h_power_group.attrs = fam15h_power_attrs;
+
+	return 0;
+}
 
 static bool should_load_on_this_node(struct pci_dev *f4)
 {
@@ -221,6 +229,9 @@ static int fam15h_power_probe(struct pci_dev *pdev,
 	if (!data)
 		return -ENOMEM;
 
+	if (fam15h_power_init_attrs(pdev))
+		return -ENOMEM;
+
 	fam15h_power_init_data(pdev, data);
 	data->pdev = pdev;
 
-- 
1.9.1

[lm-sensors] [PATCH 03/15] hwmon, fam15h_power: refactor attributes for dynamically added

[Huang Rui]

Attributes depend on the CPU model the driver gets loaded on.
Therefore, add those attributes dynamically at init time. This is more
flexible to control the different attributes on different platforms.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 drivers/hwmon/fam15h_power.c | 49 +++++++++++++++++++++++++++-----------------
 1 file changed, 30 insertions(+), 19 deletions(-)

diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index 820adf1..65ffb06 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -41,6 +41,8 @@ MODULE_LICENSE("GPL");
 #define REG_TDP_RUNNING_AVERAGE		0xe0
 #define REG_TDP_LIMIT3			0xe8
 
+#define FAM15H_MIN_POWER_GROUPS		2
+
 struct fam15h_power_data {
 	struct pci_dev *pdev;
 	unsigned int tdp_to_watts;
@@ -93,29 +95,35 @@ static ssize_t show_power_crit(struct device *dev,
 }
 static DEVICE_ATTR(power1_crit, S_IRUGO, show_power_crit, NULL);
 
-static umode_t fam15h_power_is_visible(struct kobject *kobj,
-				       struct attribute *attr,
-				       int index)
+static struct attribute_group fam15h_power_group;
+__ATTRIBUTE_GROUPS(fam15h_power);
+
+static int fam15h_power_init_attrs(struct pci_dev *pdev)
 {
-	/* power1_input is only reported for Fam15h, Models 00h-0fh */
-	if (attr = &dev_attr_power1_input.attr &&
-	   (boot_cpu_data.x86 != 0x15 || boot_cpu_data.x86_model > 0xf))
-		return 0;
+	int n = FAM15H_MIN_POWER_GROUPS;
+	struct attribute **fam15h_power_attrs;
 
-	return attr->mode;
-}
+	if (boot_cpu_data.x86 = 0x15 && boot_cpu_data.x86_model <= 0xf)
+		n += 1;
 
-static struct attribute *fam15h_power_attrs[] = {
-	&dev_attr_power1_input.attr,
-	&dev_attr_power1_crit.attr,
-	NULL
-};
+	fam15h_power_attrs = devm_kcalloc(&pdev->dev, n,
+					  sizeof(*fam15h_power_attrs),
+					  GFP_KERNEL);
 
-static const struct attribute_group fam15h_power_group = {
-	.attrs = fam15h_power_attrs,
-	.is_visible = fam15h_power_is_visible,
-};
-__ATTRIBUTE_GROUPS(fam15h_power);
+	if (!fam15h_power_attrs) {
+		dev_err(&pdev->dev, "failed to alloc fam15h_power_attrs\n");
+		return -ENOMEM;
+	}
+
+	n = 0;
+	fam15h_power_attrs[n++] = &dev_attr_power1_crit.attr;
+	if (boot_cpu_data.x86 = 0x15 && boot_cpu_data.x86_model <= 0xf)
+		fam15h_power_attrs[n++] = &dev_attr_power1_input.attr;
+
+	fam15h_power_group.attrs = fam15h_power_attrs;
+
+	return 0;
+}
 
 static bool should_load_on_this_node(struct pci_dev *f4)
 {
@@ -221,6 +229,9 @@ static int fam15h_power_probe(struct pci_dev *pdev,
 	if (!data)
 		return -ENOMEM;
 
+	if (fam15h_power_init_attrs(pdev))
+		return -ENOMEM;
+
 	fam15h_power_init_data(pdev, data);
 	data->pdev = pdev;
 
-- 
1.9.1


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[PATCH 04/15] hwmon, fam15h_power: update running_avg_capture bit field to 28

[Huang Rui]

On Carrizo and later platforms, running_avg_capture bit field is
extended to 4:31 (28 bits) from 4:25.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 drivers/hwmon/fam15h_power.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index 65ffb06..3e9b3b9 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -61,8 +61,19 @@ static ssize_t show_power(struct device *dev,
 
 	pci_bus_read_config_dword(f4->bus, PCI_DEVFN(PCI_SLOT(f4->devfn), 5),
 				  REG_TDP_RUNNING_AVERAGE, &val);
-	running_avg_capture = (val >> 4) & 0x3fffff;
-	running_avg_capture = sign_extend32(running_avg_capture, 21);
+
+	/*
+	 * On Carrizo and later platforms, TdpRunAvgAccCap bit field
+	 * is extended to 4:31 from 4:25.
+	 */
+	if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model >= 0x60) {
+		running_avg_capture = val >> 4;
+		running_avg_capture = sign_extend32(running_avg_capture, 27);
+	} else {
+		running_avg_capture = (val >> 4) & 0x3fffff;
+		running_avg_capture = sign_extend32(running_avg_capture, 21);
+	}
+
 	running_avg_range = (val & 0xf) + 1;
 
 	pci_bus_read_config_dword(f4->bus, PCI_DEVFN(PCI_SLOT(f4->devfn), 5),
-- 
1.9.1

[lm-sensors] [PATCH 04/15] hwmon, fam15h_power: update running_avg_capture bit field to 28

[Huang Rui]

On Carrizo and later platforms, running_avg_capture bit field is
extended to 4:31 (28 bits) from 4:25.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 drivers/hwmon/fam15h_power.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index 65ffb06..3e9b3b9 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -61,8 +61,19 @@ static ssize_t show_power(struct device *dev,
 
 	pci_bus_read_config_dword(f4->bus, PCI_DEVFN(PCI_SLOT(f4->devfn), 5),
 				  REG_TDP_RUNNING_AVERAGE, &val);
-	running_avg_capture = (val >> 4) & 0x3fffff;
-	running_avg_capture = sign_extend32(running_avg_capture, 21);
+
+	/*
+	 * On Carrizo and later platforms, TdpRunAvgAccCap bit field
+	 * is extended to 4:31 from 4:25.
+	 */
+	if (boot_cpu_data.x86 = 0x15 && boot_cpu_data.x86_model >= 0x60) {
+		running_avg_capture = val >> 4;
+		running_avg_capture = sign_extend32(running_avg_capture, 27);
+	} else {
+		running_avg_capture = (val >> 4) & 0x3fffff;
+		running_avg_capture = sign_extend32(running_avg_capture, 21);
+	}
+
 	running_avg_range = (val & 0xf) + 1;
 
 	pci_bus_read_config_dword(f4->bus, PCI_DEVFN(PCI_SLOT(f4->devfn), 5),
-- 
1.9.1


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[PATCH 05/15] hwmon, fam15h_power: enable power1_input on AMD Carrizo

[Huang Rui]

This patch enables power1_input attribute for Carrizo platform.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 drivers/hwmon/fam15h_power.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index 3e9b3b9..55b25ef 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -113,8 +113,11 @@ static int fam15h_power_init_attrs(struct pci_dev *pdev)
 {
 	int n = FAM15H_MIN_POWER_GROUPS;
 	struct attribute **fam15h_power_attrs;
+	struct cpuinfo_x86 *c = &boot_cpu_data;
 
-	if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model <= 0xf)
+	if (c->x86 == 0x15 &&
+	    ((c->x86_model <= 0xf) ||
+	     (c->x86_model >= 0x60 && c->x86_model <= 0x6f)))
 		n += 1;
 
 	fam15h_power_attrs = devm_kcalloc(&pdev->dev, n,
@@ -128,7 +131,9 @@ static int fam15h_power_init_attrs(struct pci_dev *pdev)
 
 	n = 0;
 	fam15h_power_attrs[n++] = &dev_attr_power1_crit.attr;
-	if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model <= 0xf)
+	if (c->x86 == 0x15 &&
+	    ((c->x86_model <= 0xf) ||
+	     (c->x86_model >= 0x60 && c->x86_model <= 0x6f)))
 		fam15h_power_attrs[n++] = &dev_attr_power1_input.attr;
 
 	fam15h_power_group.attrs = fam15h_power_attrs;
-- 
1.9.1

[lm-sensors] [PATCH 05/15] hwmon, fam15h_power: enable power1_input on AMD Carrizo

[Huang Rui]

This patch enables power1_input attribute for Carrizo platform.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 drivers/hwmon/fam15h_power.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index 3e9b3b9..55b25ef 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -113,8 +113,11 @@ static int fam15h_power_init_attrs(struct pci_dev *pdev)
 {
 	int n = FAM15H_MIN_POWER_GROUPS;
 	struct attribute **fam15h_power_attrs;
+	struct cpuinfo_x86 *c = &boot_cpu_data;
 
-	if (boot_cpu_data.x86 = 0x15 && boot_cpu_data.x86_model <= 0xf)
+	if (c->x86 = 0x15 &&
+	    ((c->x86_model <= 0xf) ||
+	     (c->x86_model >= 0x60 && c->x86_model <= 0x6f)))
 		n += 1;
 
 	fam15h_power_attrs = devm_kcalloc(&pdev->dev, n,
@@ -128,7 +131,9 @@ static int fam15h_power_init_attrs(struct pci_dev *pdev)
 
 	n = 0;
 	fam15h_power_attrs[n++] = &dev_attr_power1_crit.attr;
-	if (boot_cpu_data.x86 = 0x15 && boot_cpu_data.x86_model <= 0xf)
+	if (c->x86 = 0x15 &&
+	    ((c->x86_model <= 0xf) ||
+	     (c->x86_model >= 0x60 && c->x86_model <= 0x6f)))
 		fam15h_power_attrs[n++] = &dev_attr_power1_input.attr;
 
 	fam15h_power_group.attrs = fam15h_power_attrs;
-- 
1.9.1


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[PATCH 06/15] hwmon, fam15h_power: add documentation for new processors support

[Huang Rui]

This patch updates description of fam15h_power driver, its scope is
extended to family 16h processsors.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 Documentation/hwmon/fam15h_power | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/Documentation/hwmon/fam15h_power b/Documentation/hwmon/fam15h_power
index 8065481..e2b1b69 100644
--- a/Documentation/hwmon/fam15h_power
+++ b/Documentation/hwmon/fam15h_power
@@ -3,12 +3,13 @@ Kernel driver fam15h_power
 
 Supported chips:
 * AMD Family 15h Processors
+* AMD Family 16h Processors
 
   Prefix: 'fam15h_power'
   Addresses scanned: PCI space
   Datasheets:
   BIOS and Kernel Developer's Guide (BKDG) For AMD Family 15h Processors
-    (not yet published)
+  BIOS and Kernel Developer's Guide (BKDG) For AMD Family 16h Processors
 
 Author: Andreas Herrmann <herrmann.der.user@googlemail.com>
 
@@ -16,10 +17,11 @@ Description
 -----------
 
 This driver permits reading of registers providing power information
-of AMD Family 15h processors.
+of AMD Family 15h and 16h processors.
 
-For AMD Family 15h processors the following power values can be
-calculated using different processor northbridge function registers:
+For AMD Family 15h and 16h processors the following power values can
+be calculated using different processor northbridge function
+registers:
 
 * BasePwrWatts: Specifies in watts the maximum amount of power
   consumed by the processor for NB and logic external to the core.
-- 
1.9.1

[lm-sensors] [PATCH 06/15] hwmon, fam15h_power: add documentation for new processors support

[Huang Rui]

This patch updates description of fam15h_power driver, its scope is
extended to family 16h processsors.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 Documentation/hwmon/fam15h_power | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/Documentation/hwmon/fam15h_power b/Documentation/hwmon/fam15h_power
index 8065481..e2b1b69 100644
--- a/Documentation/hwmon/fam15h_power
+++ b/Documentation/hwmon/fam15h_power
@@ -3,12 +3,13 @@ Kernel driver fam15h_power
 
 Supported chips:
 * AMD Family 15h Processors
+* AMD Family 16h Processors
 
   Prefix: 'fam15h_power'
   Addresses scanned: PCI space
   Datasheets:
   BIOS and Kernel Developer's Guide (BKDG) For AMD Family 15h Processors
-    (not yet published)
+  BIOS and Kernel Developer's Guide (BKDG) For AMD Family 16h Processors
 
 Author: Andreas Herrmann <herrmann.der.user@googlemail.com>
 
@@ -16,10 +17,11 @@ Description
 -----------
 
 This driver permits reading of registers providing power information
-of AMD Family 15h processors.
+of AMD Family 15h and 16h processors.
 
-For AMD Family 15h processors the following power values can be
-calculated using different processor northbridge function registers:
+For AMD Family 15h and 16h processors the following power values can
+be calculated using different processor northbridge function
+registers:
 
 * BasePwrWatts: Specifies in watts the maximum amount of power
   consumed by the processor for NB and logic external to the core.
-- 
1.9.1


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[PATCH 07/15] hwmon, fam15h_power: add ratio of Tsample to the PTSC period

[Huang Rui]

This patch adds a member (cpu_pwr_sample_ratio) of fam15h_power_data,
that represents the ratio of compute unit power accumulator sample
period to the PTSC counter period.

Tsample: compute unit power accumulator sample period
Tref: the performance timestamp counter period
PTSC: performance timestamp counter

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 drivers/hwmon/fam15h_power.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index 55b25ef..d6efcf6 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -48,6 +48,7 @@ struct fam15h_power_data {
 	unsigned int tdp_to_watts;
 	unsigned int base_tdp;
 	unsigned int processor_pwr_watts;
+	unsigned int cpu_pwr_sample_ratio;
 };
 
 static ssize_t show_power(struct device *dev,
@@ -201,7 +202,7 @@ static int fam15h_power_resume(struct pci_dev *pdev)
 static void fam15h_power_init_data(struct pci_dev *f4,
 					     struct fam15h_power_data *data)
 {
-	u32 val;
+	u32 val, eax, ebx, ecx, edx;
 	u64 tmp;
 
 	pci_read_config_dword(f4, REG_PROCESSOR_TDP, &val);
@@ -222,6 +223,19 @@ static void fam15h_power_init_data(struct pci_dev *f4,
 
 	/* convert to microWatt */
 	data->processor_pwr_watts = (tmp * 15625) >> 10;
+
+	cpuid(0x80000007, &eax, &ebx, &ecx, &edx);
+
+	/* CPUID Fn8000_0007:EDX[12] indicates to support accumulated power */
+	if (!(edx & BIT(12)))
+		return;
+
+	/*
+	 * detemine the ratio of the compute unit power accumulator
+	 * sample period to the PTSC counter period by executing CPUID
+	 * Fn8000_0007:ECX
+	 */
+	data->cpu_pwr_sample_ratio = ecx;
 }
 
 static int fam15h_power_probe(struct pci_dev *pdev,
-- 
1.9.1

[lm-sensors] [PATCH 07/15] hwmon, fam15h_power: add ratio of Tsample to the PTSC period

[Huang Rui]

This patch adds a member (cpu_pwr_sample_ratio) of fam15h_power_data,
that represents the ratio of compute unit power accumulator sample
period to the PTSC counter period.

Tsample: compute unit power accumulator sample period
Tref: the performance timestamp counter period
PTSC: performance timestamp counter

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 drivers/hwmon/fam15h_power.c | 16 +++++++++++++++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index 55b25ef..d6efcf6 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -48,6 +48,7 @@ struct fam15h_power_data {
 	unsigned int tdp_to_watts;
 	unsigned int base_tdp;
 	unsigned int processor_pwr_watts;
+	unsigned int cpu_pwr_sample_ratio;
 };
 
 static ssize_t show_power(struct device *dev,
@@ -201,7 +202,7 @@ static int fam15h_power_resume(struct pci_dev *pdev)
 static void fam15h_power_init_data(struct pci_dev *f4,
 					     struct fam15h_power_data *data)
 {
-	u32 val;
+	u32 val, eax, ebx, ecx, edx;
 	u64 tmp;
 
 	pci_read_config_dword(f4, REG_PROCESSOR_TDP, &val);
@@ -222,6 +223,19 @@ static void fam15h_power_init_data(struct pci_dev *f4,
 
 	/* convert to microWatt */
 	data->processor_pwr_watts = (tmp * 15625) >> 10;
+
+	cpuid(0x80000007, &eax, &ebx, &ecx, &edx);
+
+	/* CPUID Fn8000_0007:EDX[12] indicates to support accumulated power */
+	if (!(edx & BIT(12)))
+		return;
+
+	/*
+	 * detemine the ratio of the compute unit power accumulator
+	 * sample period to the PTSC counter period by executing CPUID
+	 * Fn8000_0007:ECX
+	 */
+	data->cpu_pwr_sample_ratio = ecx;
 }
 
 static int fam15h_power_probe(struct pci_dev *pdev,
-- 
1.9.1


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[PATCH 08/15] hwmon, fam15h_power: add max compute unit accumulated power

[Huang Rui]

This patch adds a member in fam15h_power_data which specifies the
maximum accumulated power in a compute unit.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 drivers/hwmon/fam15h_power.c | 24 ++++++++++++++++++++----
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index d6efcf6..fdfa18e 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -26,6 +26,7 @@
 #include <linux/pci.h>
 #include <linux/bitops.h>
 #include <asm/processor.h>
+#include <asm/msr.h>
 
 MODULE_DESCRIPTION("AMD Family 15h CPU processor power monitor");
 MODULE_AUTHOR("Andreas Herrmann <herrmann.der.user@googlemail.com>");
@@ -43,12 +44,16 @@ MODULE_LICENSE("GPL");
 
 #define FAM15H_MIN_POWER_GROUPS		2
 
+#define MSR_F15H_CU_MAX_PWR_ACCUMULATOR	0xc001007b
+
 struct fam15h_power_data {
 	struct pci_dev *pdev;
 	unsigned int tdp_to_watts;
 	unsigned int base_tdp;
 	unsigned int processor_pwr_watts;
 	unsigned int cpu_pwr_sample_ratio;
+	/* maximum accumulated power of a compute unit */
+	u64 max_cu_acc_power;
 };
 
 static ssize_t show_power(struct device *dev,
@@ -199,8 +204,8 @@ static int fam15h_power_resume(struct pci_dev *pdev)
 #define fam15h_power_resume NULL
 #endif
 
-static void fam15h_power_init_data(struct pci_dev *f4,
-					     struct fam15h_power_data *data)
+static int fam15h_power_init_data(struct pci_dev *f4,
+				  struct fam15h_power_data *data)
 {
 	u32 val, eax, ebx, ecx, edx;
 	u64 tmp;
@@ -228,7 +233,7 @@ static void fam15h_power_init_data(struct pci_dev *f4,
 
 	/* CPUID Fn8000_0007:EDX[12] indicates to support accumulated power */
 	if (!(edx & BIT(12)))
-		return;
+		return 0;
 
 	/*
 	 * detemine the ratio of the compute unit power accumulator
@@ -236,6 +241,15 @@ static void fam15h_power_init_data(struct pci_dev *f4,
 	 * Fn8000_0007:ECX
 	 */
 	data->cpu_pwr_sample_ratio = ecx;
+
+	if (rdmsrl_safe(MSR_F15H_CU_MAX_PWR_ACCUMULATOR, &tmp)) {
+		pr_err("Failed to read max compute unit power accumulator MSR\n");
+		return -ENODEV;
+	}
+
+	data->max_cu_acc_power = tmp;
+
+	return 0;
 }
 
 static int fam15h_power_probe(struct pci_dev *pdev,
@@ -262,7 +276,9 @@ static int fam15h_power_probe(struct pci_dev *pdev,
 	if (fam15h_power_init_attrs(pdev))
 		return -ENOMEM;
 
-	fam15h_power_init_data(pdev, data);
+	if (fam15h_power_init_data(pdev, data))
+		return -ENODEV;
+
 	data->pdev = pdev;
 
 	hwmon_dev = devm_hwmon_device_register_with_groups(dev, "fam15h_power",
-- 
1.9.1

[lm-sensors] [PATCH 08/15] hwmon, fam15h_power: add max compute unit accumulated power

[Huang Rui]

This patch adds a member in fam15h_power_data which specifies the
maximum accumulated power in a compute unit.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 drivers/hwmon/fam15h_power.c | 24 ++++++++++++++++++++----
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index d6efcf6..fdfa18e 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -26,6 +26,7 @@
 #include <linux/pci.h>
 #include <linux/bitops.h>
 #include <asm/processor.h>
+#include <asm/msr.h>
 
 MODULE_DESCRIPTION("AMD Family 15h CPU processor power monitor");
 MODULE_AUTHOR("Andreas Herrmann <herrmann.der.user@googlemail.com>");
@@ -43,12 +44,16 @@ MODULE_LICENSE("GPL");
 
 #define FAM15H_MIN_POWER_GROUPS		2
 
+#define MSR_F15H_CU_MAX_PWR_ACCUMULATOR	0xc001007b
+
 struct fam15h_power_data {
 	struct pci_dev *pdev;
 	unsigned int tdp_to_watts;
 	unsigned int base_tdp;
 	unsigned int processor_pwr_watts;
 	unsigned int cpu_pwr_sample_ratio;
+	/* maximum accumulated power of a compute unit */
+	u64 max_cu_acc_power;
 };
 
 static ssize_t show_power(struct device *dev,
@@ -199,8 +204,8 @@ static int fam15h_power_resume(struct pci_dev *pdev)
 #define fam15h_power_resume NULL
 #endif
 
-static void fam15h_power_init_data(struct pci_dev *f4,
-					     struct fam15h_power_data *data)
+static int fam15h_power_init_data(struct pci_dev *f4,
+				  struct fam15h_power_data *data)
 {
 	u32 val, eax, ebx, ecx, edx;
 	u64 tmp;
@@ -228,7 +233,7 @@ static void fam15h_power_init_data(struct pci_dev *f4,
 
 	/* CPUID Fn8000_0007:EDX[12] indicates to support accumulated power */
 	if (!(edx & BIT(12)))
-		return;
+		return 0;
 
 	/*
 	 * detemine the ratio of the compute unit power accumulator
@@ -236,6 +241,15 @@ static void fam15h_power_init_data(struct pci_dev *f4,
 	 * Fn8000_0007:ECX
 	 */
 	data->cpu_pwr_sample_ratio = ecx;
+
+	if (rdmsrl_safe(MSR_F15H_CU_MAX_PWR_ACCUMULATOR, &tmp)) {
+		pr_err("Failed to read max compute unit power accumulator MSR\n");
+		return -ENODEV;
+	}
+
+	data->max_cu_acc_power = tmp;
+
+	return 0;
 }
 
 static int fam15h_power_probe(struct pci_dev *pdev,
@@ -262,7 +276,9 @@ static int fam15h_power_probe(struct pci_dev *pdev,
 	if (fam15h_power_init_attrs(pdev))
 		return -ENOMEM;
 
-	fam15h_power_init_data(pdev, data);
+	if (fam15h_power_init_data(pdev, data))
+		return -ENODEV;
+
 	data->pdev = pdev;
 
 	hwmon_dev = devm_hwmon_device_register_with_groups(dev, "fam15h_power",
-- 
1.9.1


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Huang Rui]

Add an accessor function amd_get_cores_per_cu() which returns the
number of cores per compute unit.

In a subsequent patch, we will use this function in fam15h_power
driver.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 arch/x86/include/asm/processor.h |  1 +
 arch/x86/kernel/cpu/amd.c        | 19 +++++++++++++++++--
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 19577dd..831ad682 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -810,6 +810,7 @@ static inline int mpx_disable_management(void)
 
 extern u16 amd_get_nb_id(int cpu);
 extern u32 amd_get_nodes_per_socket(void);
+extern u32 amd_get_cores_per_cu(void);
 
 static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
 {
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 51ad2af..8ab939a 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -26,6 +26,9 @@
  */
 static u32 nodes_per_socket = 1;
 
+/* cores_per_cu: stores the number of cores per compute unit */
+static u32 cores_per_cu = 1;
+
 static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
 {
 	u32 gprs[8] = { 0 };
@@ -298,7 +301,6 @@ static int nearby_node(int apicid)
 #ifdef CONFIG_SMP
 static void amd_get_topology(struct cpuinfo_x86 *c)
 {
-	u32 cores_per_cu = 1;
 	u8 node_id;
 	int cpu = smp_processor_id();
 
@@ -313,7 +315,6 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
 		/* get compute unit information */
 		smp_num_siblings = ((ebx >> 8) & 3) + 1;
 		c->compute_unit_id = ebx & 0xff;
-		cores_per_cu += ((ebx >> 8) & 3);
 	} else if (cpu_has(c, X86_FEATURE_NODEID_MSR)) {
 		u64 value;
 
@@ -379,6 +380,13 @@ u32 amd_get_nodes_per_socket(void)
 }
 EXPORT_SYMBOL_GPL(amd_get_nodes_per_socket);
 
+/* this function returns the number of cores per compute unit */
+u32 amd_get_cores_per_cu(void)
+{
+	return cores_per_cu;
+}
+EXPORT_SYMBOL_GPL(amd_get_cores_per_cu);
+
 static void srat_detect_node(struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_NUMA
@@ -506,6 +514,13 @@ static void bsp_init_amd(struct cpuinfo_x86 *c)
 		/* A random value per boot for bit slice [12:upper_bit) */
 		va_align.bits = get_random_int() & va_align.mask;
 	}
+
+	if (cpu_has_topoext) {
+		u32 cpuid;
+
+		cpuid = cpuid_ebx(0x8000001e);
+		cores_per_cu += ((cpuid >> 8) & 3);
+	}
 }
 
 static void early_init_amd(struct cpuinfo_x86 *c)
-- 
1.9.1

[lm-sensors] [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Huang Rui]

Add an accessor function amd_get_cores_per_cu() which returns the
number of cores per compute unit.

In a subsequent patch, we will use this function in fam15h_power
driver.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 arch/x86/include/asm/processor.h |  1 +
 arch/x86/kernel/cpu/amd.c        | 19 +++++++++++++++++--
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 19577dd..831ad682 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -810,6 +810,7 @@ static inline int mpx_disable_management(void)
 
 extern u16 amd_get_nb_id(int cpu);
 extern u32 amd_get_nodes_per_socket(void);
+extern u32 amd_get_cores_per_cu(void);
 
 static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
 {
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 51ad2af..8ab939a 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -26,6 +26,9 @@
  */
 static u32 nodes_per_socket = 1;
 
+/* cores_per_cu: stores the number of cores per compute unit */
+static u32 cores_per_cu = 1;
+
 static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
 {
 	u32 gprs[8] = { 0 };
@@ -298,7 +301,6 @@ static int nearby_node(int apicid)
 #ifdef CONFIG_SMP
 static void amd_get_topology(struct cpuinfo_x86 *c)
 {
-	u32 cores_per_cu = 1;
 	u8 node_id;
 	int cpu = smp_processor_id();
 
@@ -313,7 +315,6 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
 		/* get compute unit information */
 		smp_num_siblings = ((ebx >> 8) & 3) + 1;
 		c->compute_unit_id = ebx & 0xff;
-		cores_per_cu += ((ebx >> 8) & 3);
 	} else if (cpu_has(c, X86_FEATURE_NODEID_MSR)) {
 		u64 value;
 
@@ -379,6 +380,13 @@ u32 amd_get_nodes_per_socket(void)
 }
 EXPORT_SYMBOL_GPL(amd_get_nodes_per_socket);
 
+/* this function returns the number of cores per compute unit */
+u32 amd_get_cores_per_cu(void)
+{
+	return cores_per_cu;
+}
+EXPORT_SYMBOL_GPL(amd_get_cores_per_cu);
+
 static void srat_detect_node(struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_NUMA
@@ -506,6 +514,13 @@ static void bsp_init_amd(struct cpuinfo_x86 *c)
 		/* A random value per boot for bit slice [12:upper_bit) */
 		va_align.bits = get_random_int() & va_align.mask;
 	}
+
+	if (cpu_has_topoext) {
+		u32 cpuid;
+
+		cpuid = cpuid_ebx(0x8000001e);
+		cores_per_cu += ((cpuid >> 8) & 3);
+	}
 }
 
 static void early_init_amd(struct cpuinfo_x86 *c)
-- 
1.9.1


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[PATCH 10/15] hwmon, fam15h_power: add compute unit accumulated power

[Huang Rui]

This patch adds a member in fam15h_power_data which specifies the
compute unit accumulated power.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 drivers/hwmon/fam15h_power.c | 31 +++++++++++++++++++++++++++----
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index fdfa18e..f5ff48f 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -43,7 +43,9 @@ MODULE_LICENSE("GPL");
 #define REG_TDP_LIMIT3			0xe8
 
 #define FAM15H_MIN_POWER_GROUPS		2
+#define MAX_CUS				8
 
+#define MSR_F15H_CU_PWR_ACCUMULATOR	0xc001007a
 #define MSR_F15H_CU_MAX_PWR_ACCUMULATOR	0xc001007b
 
 struct fam15h_power_data {
@@ -54,6 +56,8 @@ struct fam15h_power_data {
 	unsigned int cpu_pwr_sample_ratio;
 	/* maximum accumulated power of a compute unit */
 	u64 max_cu_acc_power;
+	/* accumulated power of the compute units */
+	u64 cu_acc_power[MAX_CUS];
 };
 
 static ssize_t show_power(struct device *dev,
@@ -207,6 +211,7 @@ static int fam15h_power_resume(struct pci_dev *pdev)
 static int fam15h_power_init_data(struct pci_dev *f4,
 				  struct fam15h_power_data *data)
 {
+	int cu_num, cores_per_cu, cpu, cu;
 	u32 val, eax, ebx, ecx, edx;
 	u64 tmp;
 
@@ -249,6 +254,21 @@ static int fam15h_power_init_data(struct pci_dev *f4,
 
 	data->max_cu_acc_power = tmp;
 
+	cores_per_cu = amd_get_cores_per_cu();
+	cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
+
+	WARN_ON_ONCE(cu_num > MAX_CUS);
+
+	for (cpu = 0; cpu < cu_num * cores_per_cu; cpu += cores_per_cu) {
+		cu = cpu / cores_per_cu;
+		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_CU_PWR_ACCUMULATOR,
+				       &data->cu_acc_power[cu])) {
+			pr_err("Failed to read compute unit power accumulator MSR on core%d\n",
+			       cpu);
+			return -ENODEV;
+		}
+	}
+
 	return 0;
 }
 
@@ -258,6 +278,7 @@ static int fam15h_power_probe(struct pci_dev *pdev,
 	struct fam15h_power_data *data;
 	struct device *dev = &pdev->dev;
 	struct device *hwmon_dev;
+	int ret;
 
 	/*
 	 * though we ignore every other northbridge, we still have to
@@ -273,11 +294,13 @@ static int fam15h_power_probe(struct pci_dev *pdev,
 	if (!data)
 		return -ENOMEM;
 
-	if (fam15h_power_init_attrs(pdev))
-		return -ENOMEM;
+	ret = fam15h_power_init_attrs(pdev);
+	if (ret)
+		return ret;
 
-	if (fam15h_power_init_data(pdev, data))
-		return -ENODEV;
+	ret = fam15h_power_init_data(pdev, data);
+	if (ret)
+		return ret;
 
 	data->pdev = pdev;
 
-- 
1.9.1

[lm-sensors] [PATCH 10/15] hwmon, fam15h_power: add compute unit accumulated power

[Huang Rui]

This patch adds a member in fam15h_power_data which specifies the
compute unit accumulated power.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 drivers/hwmon/fam15h_power.c | 31 +++++++++++++++++++++++++++----
 1 file changed, 27 insertions(+), 4 deletions(-)

diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index fdfa18e..f5ff48f 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -43,7 +43,9 @@ MODULE_LICENSE("GPL");
 #define REG_TDP_LIMIT3			0xe8
 
 #define FAM15H_MIN_POWER_GROUPS		2
+#define MAX_CUS				8
 
+#define MSR_F15H_CU_PWR_ACCUMULATOR	0xc001007a
 #define MSR_F15H_CU_MAX_PWR_ACCUMULATOR	0xc001007b
 
 struct fam15h_power_data {
@@ -54,6 +56,8 @@ struct fam15h_power_data {
 	unsigned int cpu_pwr_sample_ratio;
 	/* maximum accumulated power of a compute unit */
 	u64 max_cu_acc_power;
+	/* accumulated power of the compute units */
+	u64 cu_acc_power[MAX_CUS];
 };
 
 static ssize_t show_power(struct device *dev,
@@ -207,6 +211,7 @@ static int fam15h_power_resume(struct pci_dev *pdev)
 static int fam15h_power_init_data(struct pci_dev *f4,
 				  struct fam15h_power_data *data)
 {
+	int cu_num, cores_per_cu, cpu, cu;
 	u32 val, eax, ebx, ecx, edx;
 	u64 tmp;
 
@@ -249,6 +254,21 @@ static int fam15h_power_init_data(struct pci_dev *f4,
 
 	data->max_cu_acc_power = tmp;
 
+	cores_per_cu = amd_get_cores_per_cu();
+	cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
+
+	WARN_ON_ONCE(cu_num > MAX_CUS);
+
+	for (cpu = 0; cpu < cu_num * cores_per_cu; cpu += cores_per_cu) {
+		cu = cpu / cores_per_cu;
+		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_CU_PWR_ACCUMULATOR,
+				       &data->cu_acc_power[cu])) {
+			pr_err("Failed to read compute unit power accumulator MSR on core%d\n",
+			       cpu);
+			return -ENODEV;
+		}
+	}
+
 	return 0;
 }
 
@@ -258,6 +278,7 @@ static int fam15h_power_probe(struct pci_dev *pdev,
 	struct fam15h_power_data *data;
 	struct device *dev = &pdev->dev;
 	struct device *hwmon_dev;
+	int ret;
 
 	/*
 	 * though we ignore every other northbridge, we still have to
@@ -273,11 +294,13 @@ static int fam15h_power_probe(struct pci_dev *pdev,
 	if (!data)
 		return -ENOMEM;
 
-	if (fam15h_power_init_attrs(pdev))
-		return -ENOMEM;
+	ret = fam15h_power_init_attrs(pdev);
+	if (ret)
+		return ret;
 
-	if (fam15h_power_init_data(pdev, data))
-		return -ENODEV;
+	ret = fam15h_power_init_data(pdev, data);
+	if (ret)
+		return ret;
 
 	data->pdev = pdev;
 
-- 
1.9.1


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[PATCH 11/15] hwmon, fam15h_power: add ptsc counter value for accumulated power

[Huang Rui]

PTSC is the performance timestamp counter value in a cpu core and the
cores in one compute unit have the fixed frequency. So it picks up the
performance timestamp counter value of the first core per compute unit
to measure the interval for average power per compute unit.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 arch/x86/include/asm/msr-index.h | 1 +
 drivers/hwmon/fam15h_power.c     | 9 +++++++++
 2 files changed, 10 insertions(+)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 9ebc3d0..5566360 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -293,6 +293,7 @@
 #define MSR_F15H_PERF_CTR		0xc0010201
 #define MSR_F15H_NB_PERF_CTL		0xc0010240
 #define MSR_F15H_NB_PERF_CTR		0xc0010241
+#define MSR_F15H_PTSC			0xc0010280
 
 /* Fam 10h MSRs */
 #define MSR_FAM10H_MMIO_CONF_BASE	0xc0010058
diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index f5ff48f..d529e4b 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -58,6 +58,8 @@ struct fam15h_power_data {
 	u64 max_cu_acc_power;
 	/* accumulated power of the compute units */
 	u64 cu_acc_power[MAX_CUS];
+	/* performance timestamp counter */
+	u64 cpu_sw_pwr_ptsc[MAX_CUS];
 };
 
 static ssize_t show_power(struct device *dev,
@@ -267,6 +269,13 @@ static int fam15h_power_init_data(struct pci_dev *f4,
 			       cpu);
 			return -ENODEV;
 		}
+
+		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_PTSC,
+				       &data->cpu_sw_pwr_ptsc[cu])) {
+			pr_err("Failed to read performance timestamp counter MSR on core%d\n",
+			       cpu);
+			return -ENODEV;
+		}
 	}
 
 	return 0;
-- 
1.9.1

[lm-sensors] [PATCH 11/15] hwmon, fam15h_power: add ptsc counter value for accumulated power

[Huang Rui]

PTSC is the performance timestamp counter value in a cpu core and the
cores in one compute unit have the fixed frequency. So it picks up the
performance timestamp counter value of the first core per compute unit
to measure the interval for average power per compute unit.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 arch/x86/include/asm/msr-index.h | 1 +
 drivers/hwmon/fam15h_power.c     | 9 +++++++++
 2 files changed, 10 insertions(+)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 9ebc3d0..5566360 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -293,6 +293,7 @@
 #define MSR_F15H_PERF_CTR		0xc0010201
 #define MSR_F15H_NB_PERF_CTL		0xc0010240
 #define MSR_F15H_NB_PERF_CTR		0xc0010241
+#define MSR_F15H_PTSC			0xc0010280
 
 /* Fam 10h MSRs */
 #define MSR_FAM10H_MMIO_CONF_BASE	0xc0010058
diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index f5ff48f..d529e4b 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -58,6 +58,8 @@ struct fam15h_power_data {
 	u64 max_cu_acc_power;
 	/* accumulated power of the compute units */
 	u64 cu_acc_power[MAX_CUS];
+	/* performance timestamp counter */
+	u64 cpu_sw_pwr_ptsc[MAX_CUS];
 };
 
 static ssize_t show_power(struct device *dev,
@@ -267,6 +269,13 @@ static int fam15h_power_init_data(struct pci_dev *f4,
 			       cpu);
 			return -ENODEV;
 		}
+
+		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_PTSC,
+				       &data->cpu_sw_pwr_ptsc[cu])) {
+			pr_err("Failed to read performance timestamp counter MSR on core%d\n",
+			       cpu);
+			return -ENODEV;
+		}
 	}
 
 	return 0;
-- 
1.9.1


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algorithm

[Huang Rui]

This patch introduces an algorithm that computes the average power by
reading a delta value of “core power accumulator” register during
measurement interval, and then dividing delta value by the length of
the time interval.

User is able to use power1_acc entry to measure the processor power
consumption and power1_acc just needs to be read twice with an needed
interval in-between.

A simple example:

$ cat /sys/bus/pci/devices/0000\:00\:18.4/hwmon/hwmon0/power1_acc
$ sleep 10000s
$ cat /sys/bus/pci/devices/0000\:00\:18.4/hwmon/hwmon0/power1_acc

The result is current average processor power consumption in 10000
seconds. The unit of the result is uWatt.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 drivers/hwmon/fam15h_power.c | 62 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 62 insertions(+)

diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index d529e4b..3bab797 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -60,6 +60,7 @@ struct fam15h_power_data {
 	u64 cu_acc_power[MAX_CUS];
 	/* performance timestamp counter */
 	u64 cpu_sw_pwr_ptsc[MAX_CUS];
+	struct mutex acc_pwr_mutex;
 };
 
 static ssize_t show_power(struct device *dev,
@@ -121,17 +122,74 @@ static DEVICE_ATTR(power1_crit, S_IRUGO, show_power_crit, NULL);
 static struct attribute_group fam15h_power_group;
 __ATTRIBUTE_GROUPS(fam15h_power);
 
+static ssize_t show_power_acc(struct device *dev,
+			      struct device_attribute *attr, char *buf)
+{
+	int cpu, cu, cu_num, cores_per_cu;
+	u64 curr_cu_acc_power[MAX_CUS],
+	    curr_ptsc[MAX_CUS], jdelta[MAX_CUS];
+	u64 tdelta, avg_acc;
+	struct fam15h_power_data *data = dev_get_drvdata(dev);
+
+	cores_per_cu = amd_get_cores_per_cu();
+	cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
+
+	for (cpu = 0, avg_acc = 0; cpu < cu_num * cores_per_cu; cpu += cores_per_cu) {
+		cu = cpu / cores_per_cu;
+		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_PTSC, &curr_ptsc[cu])) {
+			pr_err("Failed to read PTSC counter MSR on core%d\n",
+			       cpu);
+			return 0;
+		}
+
+		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_CU_PWR_ACCUMULATOR,
+				       &curr_cu_acc_power[cu])) {
+			pr_err("Failed to read compute unit power accumulator MSR on core%d\n",
+			       cpu);
+			return 0;
+		}
+
+		if (curr_cu_acc_power[cu] < data->cu_acc_power[cu]) {
+			jdelta[cu] = data->max_cu_acc_power + curr_cu_acc_power[cu];
+			jdelta[cu] -= data->cu_acc_power[cu];
+		} else {
+			jdelta[cu] = curr_cu_acc_power[cu] - data->cu_acc_power[cu];
+		}
+		tdelta = curr_ptsc[cu] - data->cpu_sw_pwr_ptsc[cu];
+		jdelta[cu] *= data->cpu_pwr_sample_ratio * 1000;
+		do_div(jdelta[cu], tdelta);
+
+		mutex_lock(&data->acc_pwr_mutex);
+		data->cu_acc_power[cu] = curr_cu_acc_power[cu];
+		data->cpu_sw_pwr_ptsc[cu] = curr_ptsc[cu];
+		mutex_unlock(&data->acc_pwr_mutex);
+
+		/* the unit is microWatt */
+		avg_acc += jdelta[cu];
+	}
+
+	return sprintf(buf, "%u\n", (unsigned int) avg_acc);
+}
+static DEVICE_ATTR(power1_acc, S_IRUGO, show_power_acc, NULL);
+
 static int fam15h_power_init_attrs(struct pci_dev *pdev)
 {
 	int n = FAM15H_MIN_POWER_GROUPS;
 	struct attribute **fam15h_power_attrs;
 	struct cpuinfo_x86 *c = &boot_cpu_data;
+	u32 cpuid;
 
 	if (c->x86 == 0x15 &&
 	    ((c->x86_model <= 0xf) ||
 	     (c->x86_model >= 0x60 && c->x86_model <= 0x6f)))
 		n += 1;
 
+	cpuid = cpuid_edx(0x80000007);
+
+	/* check if processor supports accumulated power */
+	if (cpuid & BIT(12))
+		n += 1;
+
 	fam15h_power_attrs = devm_kcalloc(&pdev->dev, n,
 					  sizeof(*fam15h_power_attrs),
 					  GFP_KERNEL);
@@ -148,6 +206,9 @@ static int fam15h_power_init_attrs(struct pci_dev *pdev)
 	     (c->x86_model >= 0x60 && c->x86_model <= 0x6f)))
 		fam15h_power_attrs[n++] = &dev_attr_power1_input.attr;
 
+	if (cpuid & BIT(12))
+		fam15h_power_attrs[n++] = &dev_attr_power1_acc.attr;
+
 	fam15h_power_group.attrs = fam15h_power_attrs;
 
 	return 0;
@@ -311,6 +372,7 @@ static int fam15h_power_probe(struct pci_dev *pdev,
 	if (ret)
 		return ret;
 
+	mutex_init(&data->acc_pwr_mutex);
 	data->pdev = pdev;
 
 	hwmon_dev = devm_hwmon_device_register_with_groups(dev, "fam15h_power",
-- 
1.9.1

[lm-sensors] [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algorith

[Huang Rui]

VGhpcyBwYXRjaCBpbnRyb2R1Y2VzIGFuIGFsZ29yaXRobSB0aGF0IGNvbXB1dGVzIHRoZSBhdmVy
YWdlIHBvd2VyIGJ5CnJlYWRpbmcgYSBkZWx0YSB2YWx1ZSBvZiDigJxjb3JlIHBvd2VyIGFjY3Vt
dWxhdG9y4oCdIHJlZ2lzdGVyIGR1cmluZwptZWFzdXJlbWVudCBpbnRlcnZhbCwgYW5kIHRoZW4g
ZGl2aWRpbmcgZGVsdGEgdmFsdWUgYnkgdGhlIGxlbmd0aCBvZgp0aGUgdGltZSBpbnRlcnZhbC4K
ClVzZXIgaXMgYWJsZSB0byB1c2UgcG93ZXIxX2FjYyBlbnRyeSB0byBtZWFzdXJlIHRoZSBwcm9j
ZXNzb3IgcG93ZXIKY29uc3VtcHRpb24gYW5kIHBvd2VyMV9hY2MganVzdCBuZWVkcyB0byBiZSBy
ZWFkIHR3aWNlIHdpdGggYW4gbmVlZGVkCmludGVydmFsIGluLWJldHdlZW4uCgpBIHNpbXBsZSBl
eGFtcGxlOgoKJCBjYXQgL3N5cy9idXMvcGNpL2RldmljZXMvMDAwMFw6MDBcOjE4LjQvaHdtb24v
aHdtb24wL3Bvd2VyMV9hY2MKJCBzbGVlcCAxMDAwMHMKJCBjYXQgL3N5cy9idXMvcGNpL2Rldmlj
ZXMvMDAwMFw6MDBcOjE4LjQvaHdtb24vaHdtb24wL3Bvd2VyMV9hY2MKClRoZSByZXN1bHQgaXMg
Y3VycmVudCBhdmVyYWdlIHByb2Nlc3NvciBwb3dlciBjb25zdW1wdGlvbiBpbiAxMDAwMApzZWNv
bmRzLiBUaGUgdW5pdCBvZiB0aGUgcmVzdWx0IGlzIHVXYXR0LgoKU2lnbmVkLW9mZi1ieTogSHVh
bmcgUnVpIDxyYXkuaHVhbmdAYW1kLmNvbT4KLS0tCiBkcml2ZXJzL2h3bW9uL2ZhbTE1aF9wb3dl
ci5jIHwgNjIgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKIDEg
ZmlsZSBjaGFuZ2VkLCA2MiBpbnNlcnRpb25zKCspCgpkaWZmIC0tZ2l0IGEvZHJpdmVycy9od21v
bi9mYW0xNWhfcG93ZXIuYyBiL2RyaXZlcnMvaHdtb24vZmFtMTVoX3Bvd2VyLmMKaW5kZXggZDUy
OWU0Yi4uM2JhYjc5NyAxMDA2NDQKLS0tIGEvZHJpdmVycy9od21vbi9mYW0xNWhfcG93ZXIuYwor
KysgYi9kcml2ZXJzL2h3bW9uL2ZhbTE1aF9wb3dlci5jCkBAIC02MCw2ICs2MCw3IEBAIHN0cnVj
dCBmYW0xNWhfcG93ZXJfZGF0YSB7CiAJdTY0IGN1X2FjY19wb3dlcltNQVhfQ1VTXTsKIAkvKiBw
ZXJmb3JtYW5jZSB0aW1lc3RhbXAgY291bnRlciAqLwogCXU2NCBjcHVfc3dfcHdyX3B0c2NbTUFY
X0NVU107CisJc3RydWN0IG11dGV4IGFjY19wd3JfbXV0ZXg7CiB9OwogCiBzdGF0aWMgc3NpemVf
dCBzaG93X3Bvd2VyKHN0cnVjdCBkZXZpY2UgKmRldiwKQEAgLTEyMSwxNyArMTIyLDc0IEBAIHN0
YXRpYyBERVZJQ0VfQVRUUihwb3dlcjFfY3JpdCwgU19JUlVHTywgc2hvd19wb3dlcl9jcml0LCBO
VUxMKTsKIHN0YXRpYyBzdHJ1Y3QgYXR0cmlidXRlX2dyb3VwIGZhbTE1aF9wb3dlcl9ncm91cDsK
IF9fQVRUUklCVVRFX0dST1VQUyhmYW0xNWhfcG93ZXIpOwogCitzdGF0aWMgc3NpemVfdCBzaG93
X3Bvd2VyX2FjYyhzdHJ1Y3QgZGV2aWNlICpkZXYsCisJCQkgICAgICBzdHJ1Y3QgZGV2aWNlX2F0
dHJpYnV0ZSAqYXR0ciwgY2hhciAqYnVmKQoreworCWludCBjcHUsIGN1LCBjdV9udW0sIGNvcmVz
X3Blcl9jdTsKKwl1NjQgY3Vycl9jdV9hY2NfcG93ZXJbTUFYX0NVU10sCisJICAgIGN1cnJfcHRz
Y1tNQVhfQ1VTXSwgamRlbHRhW01BWF9DVVNdOworCXU2NCB0ZGVsdGEsIGF2Z19hY2M7CisJc3Ry
dWN0IGZhbTE1aF9wb3dlcl9kYXRhICpkYXRhID0gZGV2X2dldF9kcnZkYXRhKGRldik7CisKKwlj
b3Jlc19wZXJfY3UgPSBhbWRfZ2V0X2NvcmVzX3Blcl9jdSgpOworCWN1X251bSA9IGJvb3RfY3B1
X2RhdGEueDg2X21heF9jb3JlcyAvIGNvcmVzX3Blcl9jdTsKKworCWZvciAoY3B1ID0gMCwgYXZn
X2FjYyA9IDA7IGNwdSA8IGN1X251bSAqIGNvcmVzX3Blcl9jdTsgY3B1ICs9IGNvcmVzX3Blcl9j
dSkgeworCQljdSA9IGNwdSAvIGNvcmVzX3Blcl9jdTsKKwkJaWYgKHJkbXNybF9zYWZlX29uX2Nw
dShjcHUsIE1TUl9GMTVIX1BUU0MsICZjdXJyX3B0c2NbY3VdKSkgeworCQkJcHJfZXJyKCJGYWls
ZWQgdG8gcmVhZCBQVFNDIGNvdW50ZXIgTVNSIG9uIGNvcmUlZFxuIiwKKwkJCSAgICAgICBjcHUp
OworCQkJcmV0dXJuIDA7CisJCX0KKworCQlpZiAocmRtc3JsX3NhZmVfb25fY3B1KGNwdSwgTVNS
X0YxNUhfQ1VfUFdSX0FDQ1VNVUxBVE9SLAorCQkJCSAgICAgICAmY3Vycl9jdV9hY2NfcG93ZXJb
Y3VdKSkgeworCQkJcHJfZXJyKCJGYWlsZWQgdG8gcmVhZCBjb21wdXRlIHVuaXQgcG93ZXIgYWNj
dW11bGF0b3IgTVNSIG9uIGNvcmUlZFxuIiwKKwkJCSAgICAgICBjcHUpOworCQkJcmV0dXJuIDA7
CisJCX0KKworCQlpZiAoY3Vycl9jdV9hY2NfcG93ZXJbY3VdIDwgZGF0YS0+Y3VfYWNjX3Bvd2Vy
W2N1XSkgeworCQkJamRlbHRhW2N1XSA9IGRhdGEtPm1heF9jdV9hY2NfcG93ZXIgKyBjdXJyX2N1
X2FjY19wb3dlcltjdV07CisJCQlqZGVsdGFbY3VdIC09IGRhdGEtPmN1X2FjY19wb3dlcltjdV07
CisJCX0gZWxzZSB7CisJCQlqZGVsdGFbY3VdID0gY3Vycl9jdV9hY2NfcG93ZXJbY3VdIC0gZGF0
YS0+Y3VfYWNjX3Bvd2VyW2N1XTsKKwkJfQorCQl0ZGVsdGEgPSBjdXJyX3B0c2NbY3VdIC0gZGF0
YS0+Y3B1X3N3X3B3cl9wdHNjW2N1XTsKKwkJamRlbHRhW2N1XSAqPSBkYXRhLT5jcHVfcHdyX3Nh
bXBsZV9yYXRpbyAqIDEwMDA7CisJCWRvX2RpdihqZGVsdGFbY3VdLCB0ZGVsdGEpOworCisJCW11
dGV4X2xvY2soJmRhdGEtPmFjY19wd3JfbXV0ZXgpOworCQlkYXRhLT5jdV9hY2NfcG93ZXJbY3Vd
ID0gY3Vycl9jdV9hY2NfcG93ZXJbY3VdOworCQlkYXRhLT5jcHVfc3dfcHdyX3B0c2NbY3VdID0g
Y3Vycl9wdHNjW2N1XTsKKwkJbXV0ZXhfdW5sb2NrKCZkYXRhLT5hY2NfcHdyX211dGV4KTsKKwor
CQkvKiB0aGUgdW5pdCBpcyBtaWNyb1dhdHQgKi8KKwkJYXZnX2FjYyArPSBqZGVsdGFbY3VdOwor
CX0KKworCXJldHVybiBzcHJpbnRmKGJ1ZiwgIiV1XG4iLCAodW5zaWduZWQgaW50KSBhdmdfYWNj
KTsKK30KK3N0YXRpYyBERVZJQ0VfQVRUUihwb3dlcjFfYWNjLCBTX0lSVUdPLCBzaG93X3Bvd2Vy
X2FjYywgTlVMTCk7CisKIHN0YXRpYyBpbnQgZmFtMTVoX3Bvd2VyX2luaXRfYXR0cnMoc3RydWN0
IHBjaV9kZXYgKnBkZXYpCiB7CiAJaW50IG4gPSBGQU0xNUhfTUlOX1BPV0VSX0dST1VQUzsKIAlz
dHJ1Y3QgYXR0cmlidXRlICoqZmFtMTVoX3Bvd2VyX2F0dHJzOwogCXN0cnVjdCBjcHVpbmZvX3g4
NiAqYyA9ICZib290X2NwdV9kYXRhOworCXUzMiBjcHVpZDsKIAogCWlmIChjLT54ODYgPT0gMHgx
NSAmJgogCSAgICAoKGMtPng4Nl9tb2RlbCA8PSAweGYpIHx8CiAJICAgICAoYy0+eDg2X21vZGVs
ID49IDB4NjAgJiYgYy0+eDg2X21vZGVsIDw9IDB4NmYpKSkKIAkJbiArPSAxOwogCisJY3B1aWQg
PSBjcHVpZF9lZHgoMHg4MDAwMDAwNyk7CisKKwkvKiBjaGVjayBpZiBwcm9jZXNzb3Igc3VwcG9y
dHMgYWNjdW11bGF0ZWQgcG93ZXIgKi8KKwlpZiAoY3B1aWQgJiBCSVQoMTIpKQorCQluICs9IDE7
CisKIAlmYW0xNWhfcG93ZXJfYXR0cnMgPSBkZXZtX2tjYWxsb2MoJnBkZXYtPmRldiwgbiwKIAkJ
CQkJICBzaXplb2YoKmZhbTE1aF9wb3dlcl9hdHRycyksCiAJCQkJCSAgR0ZQX0tFUk5FTCk7CkBA
IC0xNDgsNiArMjA2LDkgQEAgc3RhdGljIGludCBmYW0xNWhfcG93ZXJfaW5pdF9hdHRycyhzdHJ1
Y3QgcGNpX2RldiAqcGRldikKIAkgICAgIChjLT54ODZfbW9kZWwgPj0gMHg2MCAmJiBjLT54ODZf
bW9kZWwgPD0gMHg2ZikpKQogCQlmYW0xNWhfcG93ZXJfYXR0cnNbbisrXSA9ICZkZXZfYXR0cl9w
b3dlcjFfaW5wdXQuYXR0cjsKIAorCWlmIChjcHVpZCAmIEJJVCgxMikpCisJCWZhbTE1aF9wb3dl
cl9hdHRyc1tuKytdID0gJmRldl9hdHRyX3Bvd2VyMV9hY2MuYXR0cjsKKwogCWZhbTE1aF9wb3dl
cl9ncm91cC5hdHRycyA9IGZhbTE1aF9wb3dlcl9hdHRyczsKIAogCXJldHVybiAwOwpAQCAtMzEx
LDYgKzM3Miw3IEBAIHN0YXRpYyBpbnQgZmFtMTVoX3Bvd2VyX3Byb2JlKHN0cnVjdCBwY2lfZGV2
ICpwZGV2LAogCWlmIChyZXQpCiAJCXJldHVybiByZXQ7CiAKKwltdXRleF9pbml0KCZkYXRhLT5h
Y2NfcHdyX211dGV4KTsKIAlkYXRhLT5wZGV2ID0gcGRldjsKIAogCWh3bW9uX2RldiA9IGRldm1f
aHdtb25fZGV2aWNlX3JlZ2lzdGVyX3dpdGhfZ3JvdXBzKGRldiwgImZhbTE1aF9wb3dlciIsCi0t
IAoxLjkuMQoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
CmxtLXNlbnNvcnMgbWFpbGluZyBsaXN0CmxtLXNlbnNvcnNAbG0tc2Vuc29ycy5vcmcKaHR0cDov
L2xpc3RzLmxtLXNlbnNvcnMub3JnL21haWxtYW4vbGlzdGluZm8vbG0tc2Vuc29ycw=

[PATCH 13/15] hwmon, fam15h_power: add documentation for previous TDP reporting

[Huang Rui]

This patch adds description to explain the TDP reporting mechanism of
fam15h_power driver.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 Documentation/hwmon/fam15h_power | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/hwmon/fam15h_power b/Documentation/hwmon/fam15h_power
index e2b1b69..42bf04e 100644
--- a/Documentation/hwmon/fam15h_power
+++ b/Documentation/hwmon/fam15h_power
@@ -10,14 +10,22 @@ Supported chips:
   Datasheets:
   BIOS and Kernel Developer's Guide (BKDG) For AMD Family 15h Processors
   BIOS and Kernel Developer's Guide (BKDG) For AMD Family 16h Processors
+  AMD64 Architecture Programmer's Manual Volume 2: System Programming
 
 Author: Andreas Herrmann <herrmann.der.user@googlemail.com>
 
 Description
 -----------
 
+1) Processor TDP (Thermal design power)
+
+Given a fixed frequency and voltage, the power consumption of a
+processor varies based on the workload being executed. Derated power
+is the power consumed when running a specific application. Thermal
+design power (TDP) is an example of derated power.
+
 This driver permits reading of registers providing power information
-of AMD Family 15h and 16h processors.
+of AMD Family 15h and 16h processors via TDP algorithm.
 
 For AMD Family 15h and 16h processors the following power values can
 be calculated using different processor northbridge function
-- 
1.9.1

[lm-sensors] [PATCH 13/15] hwmon, fam15h_power: add documentation for previous TDP reporting

[Huang Rui]

This patch adds description to explain the TDP reporting mechanism of
fam15h_power driver.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 Documentation/hwmon/fam15h_power | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/hwmon/fam15h_power b/Documentation/hwmon/fam15h_power
index e2b1b69..42bf04e 100644
--- a/Documentation/hwmon/fam15h_power
+++ b/Documentation/hwmon/fam15h_power
@@ -10,14 +10,22 @@ Supported chips:
   Datasheets:
   BIOS and Kernel Developer's Guide (BKDG) For AMD Family 15h Processors
   BIOS and Kernel Developer's Guide (BKDG) For AMD Family 16h Processors
+  AMD64 Architecture Programmer's Manual Volume 2: System Programming
 
 Author: Andreas Herrmann <herrmann.der.user@googlemail.com>
 
 Description
 -----------
 
+1) Processor TDP (Thermal design power)
+
+Given a fixed frequency and voltage, the power consumption of a
+processor varies based on the workload being executed. Derated power
+is the power consumed when running a specific application. Thermal
+design power (TDP) is an example of derated power.
+
 This driver permits reading of registers providing power information
-of AMD Family 15h and 16h processors.
+of AMD Family 15h and 16h processors via TDP algorithm.
 
 For AMD Family 15h and 16h processors the following power values can
 be calculated using different processor northbridge function
-- 
1.9.1


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[PATCH 14/15] hwmon, fam15h_power: add documentation for accumulated power algorithm

[Huang Rui]

This patch adds the description to explain the accumulated power
algorithm.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 Documentation/hwmon/fam15h_power | 45 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/Documentation/hwmon/fam15h_power b/Documentation/hwmon/fam15h_power
index 42bf04e..dc2bc69 100644
--- a/Documentation/hwmon/fam15h_power
+++ b/Documentation/hwmon/fam15h_power
@@ -45,3 +45,48 @@ This driver provides ProcessorPwrWatts and CurrPwrWatts:
 On multi-node processors the calculated value is for the entire
 package and not for a single node. Thus the driver creates sysfs
 attributes only for internal node0 of a multi-node processor.
+
+2) Accumulated Power Mechanism
+
+This driver also introduces an algorithm that should be used to
+calculate the average power consumed by a processor during a
+measurement interval Tm. The feature of accumulated power mechanism is
+indicated by CPUID Fn8000_0007_EDX[12].
+
+* Tsample: compute unit power accumulator sample period
+* Tref: the PTSC counter period
+* PTSC: performance timestamp counter
+* N: the ratio of compute unit power accumulator sample period to the
+  PTSC period
+* Jmax: max compute unit accumulated power which is indicated by
+  MaxCpuSwPwrAcc MSR C001007b
+* Jx/Jy: compute unit accumulated power which is indicated by
+  CpuSwPwrAcc MSR C001007a
+* Tx/Ty: the value of performance timestamp counter which is indicated
+  by CU_PTSC MSR C0010280
+* PwrCPUave: CPU average power
+
+i. Determine the ratio of Tsample to Tref by executing CPUID Fn8000_0007.
+	N = value of CPUID Fn8000_0007_ECX[CpuPwrSampleTimeRatio[15:0]].
+
+ii. Read the full range of the cumulative energy value from the new
+MSR MaxCpuSwPwrAcc.
+	Jmax = value returned.
+iii. At time x, SW reads CpuSwPwrAcc MSR and samples the PTSC.
+	Jx = value read from CpuSwPwrAcc and Tx = value read from
+PTSC.
+
+iv. At time y, SW reads CpuSwPwrAcc MSR and samples the PTSC.
+	Jy = value read from CpuSwPwrAcc and Ty = value read from
+PTSC.
+
+v. Calculate the average power consumption for a compute unit over
+time period (y-x). Unit of result is uWatt.
+	if (Jy < Jx) // Rollover has occurred
+		Jdelta = (Jy + Jmax) - Jx
+	else
+		Jdelta = Jy - Jx
+	PwrCPUave = N * Jdelta * 1000 / (Ty - Tx)
+
+This driver provides PwrCPUave:
+* power1_acc (PwrCPUave)
-- 
1.9.1

[lm-sensors] [PATCH 14/15] hwmon, fam15h_power: add documentation for accumulated power algorithm

[Huang Rui]

This patch adds the description to explain the accumulated power
algorithm.

Signed-off-by: Huang Rui <ray.huang@amd.com>
---
 Documentation/hwmon/fam15h_power | 45 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 45 insertions(+)

diff --git a/Documentation/hwmon/fam15h_power b/Documentation/hwmon/fam15h_power
index 42bf04e..dc2bc69 100644
--- a/Documentation/hwmon/fam15h_power
+++ b/Documentation/hwmon/fam15h_power
@@ -45,3 +45,48 @@ This driver provides ProcessorPwrWatts and CurrPwrWatts:
 On multi-node processors the calculated value is for the entire
 package and not for a single node. Thus the driver creates sysfs
 attributes only for internal node0 of a multi-node processor.
+
+2) Accumulated Power Mechanism
+
+This driver also introduces an algorithm that should be used to
+calculate the average power consumed by a processor during a
+measurement interval Tm. The feature of accumulated power mechanism is
+indicated by CPUID Fn8000_0007_EDX[12].
+
+* Tsample: compute unit power accumulator sample period
+* Tref: the PTSC counter period
+* PTSC: performance timestamp counter
+* N: the ratio of compute unit power accumulator sample period to the
+  PTSC period
+* Jmax: max compute unit accumulated power which is indicated by
+  MaxCpuSwPwrAcc MSR C001007b
+* Jx/Jy: compute unit accumulated power which is indicated by
+  CpuSwPwrAcc MSR C001007a
+* Tx/Ty: the value of performance timestamp counter which is indicated
+  by CU_PTSC MSR C0010280
+* PwrCPUave: CPU average power
+
+i. Determine the ratio of Tsample to Tref by executing CPUID Fn8000_0007.
+	N = value of CPUID Fn8000_0007_ECX[CpuPwrSampleTimeRatio[15:0]].
+
+ii. Read the full range of the cumulative energy value from the new
+MSR MaxCpuSwPwrAcc.
+	Jmax = value returned.
+iii. At time x, SW reads CpuSwPwrAcc MSR and samples the PTSC.
+	Jx = value read from CpuSwPwrAcc and Tx = value read from
+PTSC.
+
+iv. At time y, SW reads CpuSwPwrAcc MSR and samples the PTSC.
+	Jy = value read from CpuSwPwrAcc and Ty = value read from
+PTSC.
+
+v. Calculate the average power consumption for a compute unit over
+time period (y-x). Unit of result is uWatt.
+	if (Jy < Jx) // Rollover has occurred
+		Jdelta = (Jy + Jmax) - Jx
+	else
+		Jdelta = Jy - Jx
+	PwrCPUave = N * Jdelta * 1000 / (Ty - Tx)
+
+This driver provides PwrCPUave:
+* power1_acc (PwrCPUave)
-- 
1.9.1


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

[PATCH 15/15] MAINTAINERS: change the maintainer of fam15h_power driver

[Huang Rui]

Andreas Herrmann won't take the maintainer of fam15h_power driver. I
will take it and appreciate him for the great contributions on this
driver.

Signed-off-by: Huang Rui <ray.huang@amd.com>
Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
---
 MAINTAINERS | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 941d7b7..241d45e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -601,9 +601,9 @@ F:	drivers/crypto/ccp/
 F:	include/linux/ccp.h
 
 AMD FAM15H PROCESSOR POWER MONITORING DRIVER
-M:	Andreas Herrmann <herrmann.der.user@googlemail.com>
+M:	Huang Rui <ray.huang@amd.com>
 L:	lm-sensors@lm-sensors.org
-S:	Maintained
+S:	Supported
 F:	Documentation/hwmon/fam15h_power
 F:	drivers/hwmon/fam15h_power.c
 
-- 
1.9.1

[lm-sensors] [PATCH 15/15] MAINTAINERS: change the maintainer of fam15h_power driver

[Huang Rui]

Andreas Herrmann won't take the maintainer of fam15h_power driver. I
will take it and appreciate him for the great contributions on this
driver.

Signed-off-by: Huang Rui <ray.huang@amd.com>
Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
---
 MAINTAINERS | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 941d7b7..241d45e 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -601,9 +601,9 @@ F:	drivers/crypto/ccp/
 F:	include/linux/ccp.h
 
 AMD FAM15H PROCESSOR POWER MONITORING DRIVER
-M:	Andreas Herrmann <herrmann.der.user@googlemail.com>
+M:	Huang Rui <ray.huang@amd.com>
 L:	lm-sensors@lm-sensors.org
-S:	Maintained
+S:	Supported
 F:	Documentation/hwmon/fam15h_power
 F:	drivers/hwmon/fam15h_power.c
 
-- 
1.9.1


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 01/15] hwmon, fam15h_power: add support for AMD Carrizo

[Guenter Roeck]

On 08/27/2015 01:07 AM, Huang Rui wrote:
> AMD Carrizo(Fam15h, M60h) processors can report power1_crit
> (ProcessorPwrWatts) and power1_input (CurrPwrWatts) values.
> And this patch adds support for CZ.
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>

Applied to hwmon-next.

Thanks,
Guenter

Re: [lm-sensors] [PATCH 01/15] hwmon, fam15h_power: add support for AMD Carrizo

[Guenter Roeck]

On 08/27/2015 01:07 AM, Huang Rui wrote:
> AMD Carrizo(Fam15h, M60h) processors can report power1_crit
> (ProcessorPwrWatts) and power1_input (CurrPwrWatts) values.
> And this patch adds support for CZ.
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>

Applied to hwmon-next.

Thanks,
Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 02/15] hwmon, fam15h_power: rename fam15h_power_is_internal_node0 function

[Guenter Roeck]

On 08/27/2015 01:07 AM, Huang Rui wrote:
> We rename fam15h_power_is_internal_node0() function to
> should_load_on_this_node(), because it may not be node0 from KV and
> on, and they are single-node processors.
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>

Applied to hwmon-next.

Thanks,
Guenter

Re: [lm-sensors] [PATCH 02/15] hwmon, fam15h_power: rename fam15h_power_is_internal_node0 function

[Guenter Roeck]

On 08/27/2015 01:07 AM, Huang Rui wrote:
> We rename fam15h_power_is_internal_node0() function to
> should_load_on_this_node(), because it may not be node0 from KV and
> on, and they are single-node processors.
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>

Applied to hwmon-next.

Thanks,
Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 03/15] hwmon, fam15h_power: refactor attributes for dynamically added

[Guenter Roeck]

On 08/27/2015 01:07 AM, Huang Rui wrote:
> Attributes depend on the CPU model the driver gets loaded on.
> Therefore, add those attributes dynamically at init time. This is more
> flexible to control the different attributes on different platforms.
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> ---
>   drivers/hwmon/fam15h_power.c | 49 +++++++++++++++++++++++++++-----------------
>   1 file changed, 30 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> index 820adf1..65ffb06 100644
> --- a/drivers/hwmon/fam15h_power.c
> +++ b/drivers/hwmon/fam15h_power.c
> @@ -41,6 +41,8 @@ MODULE_LICENSE("GPL");
>   #define REG_TDP_RUNNING_AVERAGE		0xe0
>   #define REG_TDP_LIMIT3			0xe8
>
> +#define FAM15H_MIN_POWER_GROUPS		2

This should be something like FAM15H_MIN_NUM_ATTRS.
There is only one group with a variable number of attributes.

> +
>   struct fam15h_power_data {
>   	struct pci_dev *pdev;
>   	unsigned int tdp_to_watts;
> @@ -93,29 +95,35 @@ static ssize_t show_power_crit(struct device *dev,
>   }
>   static DEVICE_ATTR(power1_crit, S_IRUGO, show_power_crit, NULL);
>
> -static umode_t fam15h_power_is_visible(struct kobject *kobj,
> -				       struct attribute *attr,
> -				       int index)
> +static struct attribute_group fam15h_power_group;
> +__ATTRIBUTE_GROUPS(fam15h_power);
> +
> +static int fam15h_power_init_attrs(struct pci_dev *pdev)
>   {
> -	/* power1_input is only reported for Fam15h, Models 00h-0fh */
> -	if (attr == &dev_attr_power1_input.attr &&
> -	   (boot_cpu_data.x86 != 0x15 || boot_cpu_data.x86_model > 0xf))
> -		return 0;
> +	int n = FAM15H_MIN_POWER_GROUPS;
> +	struct attribute **fam15h_power_attrs;
>
> -	return attr->mode;
> -}
> +	if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model <= 0xf)
> +		n += 1;
>
> -static struct attribute *fam15h_power_attrs[] = {
> -	&dev_attr_power1_input.attr,
> -	&dev_attr_power1_crit.attr,
> -	NULL
> -};
> +	fam15h_power_attrs = devm_kcalloc(&pdev->dev, n,
> +					  sizeof(*fam15h_power_attrs),
> +					  GFP_KERNEL);
>
> -static const struct attribute_group fam15h_power_group = {
> -	.attrs = fam15h_power_attrs,
> -	.is_visible = fam15h_power_is_visible,
> -};
> -__ATTRIBUTE_GROUPS(fam15h_power);
> +	if (!fam15h_power_attrs) {
> +		dev_err(&pdev->dev, "failed to alloc fam15h_power_attrs\n");

The infrastructure already dumps a message for memory allocation errors.
No need for another one.

> +		return -ENOMEM;
> +	}
> +
> +	n = 0;
> +	fam15h_power_attrs[n++] = &dev_attr_power1_crit.attr;
> +	if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model <= 0xf)
> +		fam15h_power_attrs[n++] = &dev_attr_power1_input.attr;
> +
> +	fam15h_power_group.attrs = fam15h_power_attrs;
> +
Assuming this will be called for each CPU in a multi-CPU system,
this will be overwritten each time a new CPU comes online.
fam15h_power_group and fam15h_power_groups probably need to be moved
into fam15h_power_data to avoid that. In essence, there should only
be read-only static variables. Everything else should be allocated.

> +	return 0;
> +}
>
>   static bool should_load_on_this_node(struct pci_dev *f4)
>   {
> @@ -221,6 +229,9 @@ static int fam15h_power_probe(struct pci_dev *pdev,
>   	if (!data)
>   		return -ENOMEM;
>
> +	if (fam15h_power_init_attrs(pdev))
> +		return -ENOMEM;

This should return the error code from fam15h_power_init_attrs().

> +
>   	fam15h_power_init_data(pdev, data);
>   	data->pdev = pdev;
>
>

Re: [lm-sensors] [PATCH 03/15] hwmon, fam15h_power: refactor attributes for dynamically added

[Guenter Roeck]

On 08/27/2015 01:07 AM, Huang Rui wrote:
> Attributes depend on the CPU model the driver gets loaded on.
> Therefore, add those attributes dynamically at init time. This is more
> flexible to control the different attributes on different platforms.
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> ---
>   drivers/hwmon/fam15h_power.c | 49 +++++++++++++++++++++++++++-----------------
>   1 file changed, 30 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> index 820adf1..65ffb06 100644
> --- a/drivers/hwmon/fam15h_power.c
> +++ b/drivers/hwmon/fam15h_power.c
> @@ -41,6 +41,8 @@ MODULE_LICENSE("GPL");
>   #define REG_TDP_RUNNING_AVERAGE		0xe0
>   #define REG_TDP_LIMIT3			0xe8
>
> +#define FAM15H_MIN_POWER_GROUPS		2

This should be something like FAM15H_MIN_NUM_ATTRS.
There is only one group with a variable number of attributes.

> +
>   struct fam15h_power_data {
>   	struct pci_dev *pdev;
>   	unsigned int tdp_to_watts;
> @@ -93,29 +95,35 @@ static ssize_t show_power_crit(struct device *dev,
>   }
>   static DEVICE_ATTR(power1_crit, S_IRUGO, show_power_crit, NULL);
>
> -static umode_t fam15h_power_is_visible(struct kobject *kobj,
> -				       struct attribute *attr,
> -				       int index)
> +static struct attribute_group fam15h_power_group;
> +__ATTRIBUTE_GROUPS(fam15h_power);
> +
> +static int fam15h_power_init_attrs(struct pci_dev *pdev)
>   {
> -	/* power1_input is only reported for Fam15h, Models 00h-0fh */
> -	if (attr = &dev_attr_power1_input.attr &&
> -	   (boot_cpu_data.x86 != 0x15 || boot_cpu_data.x86_model > 0xf))
> -		return 0;
> +	int n = FAM15H_MIN_POWER_GROUPS;
> +	struct attribute **fam15h_power_attrs;
>
> -	return attr->mode;
> -}
> +	if (boot_cpu_data.x86 = 0x15 && boot_cpu_data.x86_model <= 0xf)
> +		n += 1;
>
> -static struct attribute *fam15h_power_attrs[] = {
> -	&dev_attr_power1_input.attr,
> -	&dev_attr_power1_crit.attr,
> -	NULL
> -};
> +	fam15h_power_attrs = devm_kcalloc(&pdev->dev, n,
> +					  sizeof(*fam15h_power_attrs),
> +					  GFP_KERNEL);
>
> -static const struct attribute_group fam15h_power_group = {
> -	.attrs = fam15h_power_attrs,
> -	.is_visible = fam15h_power_is_visible,
> -};
> -__ATTRIBUTE_GROUPS(fam15h_power);
> +	if (!fam15h_power_attrs) {
> +		dev_err(&pdev->dev, "failed to alloc fam15h_power_attrs\n");

The infrastructure already dumps a message for memory allocation errors.
No need for another one.

> +		return -ENOMEM;
> +	}
> +
> +	n = 0;
> +	fam15h_power_attrs[n++] = &dev_attr_power1_crit.attr;
> +	if (boot_cpu_data.x86 = 0x15 && boot_cpu_data.x86_model <= 0xf)
> +		fam15h_power_attrs[n++] = &dev_attr_power1_input.attr;
> +
> +	fam15h_power_group.attrs = fam15h_power_attrs;
> +
Assuming this will be called for each CPU in a multi-CPU system,
this will be overwritten each time a new CPU comes online.
fam15h_power_group and fam15h_power_groups probably need to be moved
into fam15h_power_data to avoid that. In essence, there should only
be read-only static variables. Everything else should be allocated.

> +	return 0;
> +}
>
>   static bool should_load_on_this_node(struct pci_dev *f4)
>   {
> @@ -221,6 +229,9 @@ static int fam15h_power_probe(struct pci_dev *pdev,
>   	if (!data)
>   		return -ENOMEM;
>
> +	if (fam15h_power_init_attrs(pdev))
> +		return -ENOMEM;

This should return the error code from fam15h_power_init_attrs().

> +
>   	fam15h_power_init_data(pdev, data);
>   	data->pdev = pdev;
>
>


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 04/15] hwmon, fam15h_power: update running_avg_capture bit field to 28

[Guenter Roeck]

On 08/27/2015 01:07 AM, Huang Rui wrote:
> On Carrizo and later platforms, running_avg_capture bit field is
> extended to 4:31 (28 bits) from 4:25.
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>

Applied to hwmon-next.

Thanks,
Guenter

Re: [lm-sensors] [PATCH 04/15] hwmon, fam15h_power: update running_avg_capture bit field to 28

[Guenter Roeck]

On 08/27/2015 01:07 AM, Huang Rui wrote:
> On Carrizo and later platforms, running_avg_capture bit field is
> extended to 4:31 (28 bits) from 4:25.
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>

Applied to hwmon-next.

Thanks,
Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 05/15] hwmon, fam15h_power: enable power1_input on AMD Carrizo

[Guenter Roeck]

On 08/27/2015 01:07 AM, Huang Rui wrote:
> This patch enables power1_input attribute for Carrizo platform.
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>

Needs rebase to updated #3, otherwise looks good.

Thanks,
Guenter

> ---
>   drivers/hwmon/fam15h_power.c | 9 +++++++--
>   1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> index 3e9b3b9..55b25ef 100644
> --- a/drivers/hwmon/fam15h_power.c
> +++ b/drivers/hwmon/fam15h_power.c
> @@ -113,8 +113,11 @@ static int fam15h_power_init_attrs(struct pci_dev *pdev)
>   {
>   	int n = FAM15H_MIN_POWER_GROUPS;
>   	struct attribute **fam15h_power_attrs;
> +	struct cpuinfo_x86 *c = &boot_cpu_data;
>
> -	if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model <= 0xf)
> +	if (c->x86 == 0x15 &&
> +	    ((c->x86_model <= 0xf) ||
> +	     (c->x86_model >= 0x60 && c->x86_model <= 0x6f)))
>   		n += 1;
>
>   	fam15h_power_attrs = devm_kcalloc(&pdev->dev, n,
> @@ -128,7 +131,9 @@ static int fam15h_power_init_attrs(struct pci_dev *pdev)
>
>   	n = 0;
>   	fam15h_power_attrs[n++] = &dev_attr_power1_crit.attr;
> -	if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model <= 0xf)
> +	if (c->x86 == 0x15 &&
> +	    ((c->x86_model <= 0xf) ||
> +	     (c->x86_model >= 0x60 && c->x86_model <= 0x6f)))
>   		fam15h_power_attrs[n++] = &dev_attr_power1_input.attr;
>
>   	fam15h_power_group.attrs = fam15h_power_attrs;
>

Re: [lm-sensors] [PATCH 05/15] hwmon, fam15h_power: enable power1_input on AMD Carrizo

[Guenter Roeck]

On 08/27/2015 01:07 AM, Huang Rui wrote:
> This patch enables power1_input attribute for Carrizo platform.
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>

Needs rebase to updated #3, otherwise looks good.

Thanks,
Guenter

> ---
>   drivers/hwmon/fam15h_power.c | 9 +++++++--
>   1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> index 3e9b3b9..55b25ef 100644
> --- a/drivers/hwmon/fam15h_power.c
> +++ b/drivers/hwmon/fam15h_power.c
> @@ -113,8 +113,11 @@ static int fam15h_power_init_attrs(struct pci_dev *pdev)
>   {
>   	int n = FAM15H_MIN_POWER_GROUPS;
>   	struct attribute **fam15h_power_attrs;
> +	struct cpuinfo_x86 *c = &boot_cpu_data;
>
> -	if (boot_cpu_data.x86 = 0x15 && boot_cpu_data.x86_model <= 0xf)
> +	if (c->x86 = 0x15 &&
> +	    ((c->x86_model <= 0xf) ||
> +	     (c->x86_model >= 0x60 && c->x86_model <= 0x6f)))
>   		n += 1;
>
>   	fam15h_power_attrs = devm_kcalloc(&pdev->dev, n,
> @@ -128,7 +131,9 @@ static int fam15h_power_init_attrs(struct pci_dev *pdev)
>
>   	n = 0;
>   	fam15h_power_attrs[n++] = &dev_attr_power1_crit.attr;
> -	if (boot_cpu_data.x86 = 0x15 && boot_cpu_data.x86_model <= 0xf)
> +	if (c->x86 = 0x15 &&
> +	    ((c->x86_model <= 0xf) ||
> +	     (c->x86_model >= 0x60 && c->x86_model <= 0x6f)))
>   		fam15h_power_attrs[n++] = &dev_attr_power1_input.attr;
>
>   	fam15h_power_group.attrs = fam15h_power_attrs;
>


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 06/15] hwmon, fam15h_power: add documentation for new processors support

[Guenter Roeck]

On 08/27/2015 01:07 AM, Huang Rui wrote:
> This patch updates description of fam15h_power driver, its scope is
> extended to family 16h processsors.
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>

Applied to hwmon-next.

Thanks,
Guenter

Re: [lm-sensors] [PATCH 06/15] hwmon, fam15h_power: add documentation for new processors support

[Guenter Roeck]

On 08/27/2015 01:07 AM, Huang Rui wrote:
> This patch updates description of fam15h_power driver, its scope is
> extended to family 16h processsors.
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>

Applied to hwmon-next.

Thanks,
Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 07/15] hwmon, fam15h_power: add ratio of Tsample to the PTSC period

[Guenter Roeck]

On 08/27/2015 01:07 AM, Huang Rui wrote:
> This patch adds a member (cpu_pwr_sample_ratio) of fam15h_power_data,
> that represents the ratio of compute unit power accumulator sample
> period to the PTSC counter period.
>
> Tsample: compute unit power accumulator sample period
> Tref: the performance timestamp counter period
> PTSC: performance timestamp counter
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>

Applied to hwmon-next (after fixing spelling error 'detemine').

Thanks,
Guenter

> ---
>   drivers/hwmon/fam15h_power.c | 16 +++++++++++++++-
>   1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> index 55b25ef..d6efcf6 100644
> --- a/drivers/hwmon/fam15h_power.c
> +++ b/drivers/hwmon/fam15h_power.c
> @@ -48,6 +48,7 @@ struct fam15h_power_data {
>   	unsigned int tdp_to_watts;
>   	unsigned int base_tdp;
>   	unsigned int processor_pwr_watts;
> +	unsigned int cpu_pwr_sample_ratio;
>   };
>
>   static ssize_t show_power(struct device *dev,
> @@ -201,7 +202,7 @@ static int fam15h_power_resume(struct pci_dev *pdev)
>   static void fam15h_power_init_data(struct pci_dev *f4,
>   					     struct fam15h_power_data *data)
>   {
> -	u32 val;
> +	u32 val, eax, ebx, ecx, edx;
>   	u64 tmp;
>
>   	pci_read_config_dword(f4, REG_PROCESSOR_TDP, &val);
> @@ -222,6 +223,19 @@ static void fam15h_power_init_data(struct pci_dev *f4,
>
>   	/* convert to microWatt */
>   	data->processor_pwr_watts = (tmp * 15625) >> 10;
> +
> +	cpuid(0x80000007, &eax, &ebx, &ecx, &edx);
> +
> +	/* CPUID Fn8000_0007:EDX[12] indicates to support accumulated power */
> +	if (!(edx & BIT(12)))
> +		return;
> +
> +	/*
> +	 * detemine the ratio of the compute unit power accumulator
> +	 * sample period to the PTSC counter period by executing CPUID
> +	 * Fn8000_0007:ECX
> +	 */
> +	data->cpu_pwr_sample_ratio = ecx;
>   }
>
>   static int fam15h_power_probe(struct pci_dev *pdev,
>

Re: [lm-sensors] [PATCH 07/15] hwmon, fam15h_power: add ratio of Tsample to the PTSC period

[Guenter Roeck]

On 08/27/2015 01:07 AM, Huang Rui wrote:
> This patch adds a member (cpu_pwr_sample_ratio) of fam15h_power_data,
> that represents the ratio of compute unit power accumulator sample
> period to the PTSC counter period.
>
> Tsample: compute unit power accumulator sample period
> Tref: the performance timestamp counter period
> PTSC: performance timestamp counter
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>

Applied to hwmon-next (after fixing spelling error 'detemine').

Thanks,
Guenter

> ---
>   drivers/hwmon/fam15h_power.c | 16 +++++++++++++++-
>   1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> index 55b25ef..d6efcf6 100644
> --- a/drivers/hwmon/fam15h_power.c
> +++ b/drivers/hwmon/fam15h_power.c
> @@ -48,6 +48,7 @@ struct fam15h_power_data {
>   	unsigned int tdp_to_watts;
>   	unsigned int base_tdp;
>   	unsigned int processor_pwr_watts;
> +	unsigned int cpu_pwr_sample_ratio;
>   };
>
>   static ssize_t show_power(struct device *dev,
> @@ -201,7 +202,7 @@ static int fam15h_power_resume(struct pci_dev *pdev)
>   static void fam15h_power_init_data(struct pci_dev *f4,
>   					     struct fam15h_power_data *data)
>   {
> -	u32 val;
> +	u32 val, eax, ebx, ecx, edx;
>   	u64 tmp;
>
>   	pci_read_config_dword(f4, REG_PROCESSOR_TDP, &val);
> @@ -222,6 +223,19 @@ static void fam15h_power_init_data(struct pci_dev *f4,
>
>   	/* convert to microWatt */
>   	data->processor_pwr_watts = (tmp * 15625) >> 10;
> +
> +	cpuid(0x80000007, &eax, &ebx, &ecx, &edx);
> +
> +	/* CPUID Fn8000_0007:EDX[12] indicates to support accumulated power */
> +	if (!(edx & BIT(12)))
> +		return;
> +
> +	/*
> +	 * detemine the ratio of the compute unit power accumulator
> +	 * sample period to the PTSC counter period by executing CPUID
> +	 * Fn8000_0007:ECX
> +	 */
> +	data->cpu_pwr_sample_ratio = ecx;
>   }
>
>   static int fam15h_power_probe(struct pci_dev *pdev,
>


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 08/15] hwmon, fam15h_power: add max compute unit accumulated power

[Guenter Roeck]

On 08/27/2015 01:07 AM, Huang Rui wrote:
> This patch adds a member in fam15h_power_data which specifies the
> maximum accumulated power in a compute unit.
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> ---
>   drivers/hwmon/fam15h_power.c | 24 ++++++++++++++++++++----
>   1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> index d6efcf6..fdfa18e 100644
> --- a/drivers/hwmon/fam15h_power.c
> +++ b/drivers/hwmon/fam15h_power.c
> @@ -26,6 +26,7 @@
>   #include <linux/pci.h>
>   #include <linux/bitops.h>
>   #include <asm/processor.h>
> +#include <asm/msr.h>
>
>   MODULE_DESCRIPTION("AMD Family 15h CPU processor power monitor");
>   MODULE_AUTHOR("Andreas Herrmann <herrmann.der.user@googlemail.com>");
> @@ -43,12 +44,16 @@ MODULE_LICENSE("GPL");
>
>   #define FAM15H_MIN_POWER_GROUPS		2
>
> +#define MSR_F15H_CU_MAX_PWR_ACCUMULATOR	0xc001007b
> +
>   struct fam15h_power_data {
>   	struct pci_dev *pdev;
>   	unsigned int tdp_to_watts;
>   	unsigned int base_tdp;
>   	unsigned int processor_pwr_watts;
>   	unsigned int cpu_pwr_sample_ratio;
> +	/* maximum accumulated power of a compute unit */
> +	u64 max_cu_acc_power;
>   };
>
>   static ssize_t show_power(struct device *dev,
> @@ -199,8 +204,8 @@ static int fam15h_power_resume(struct pci_dev *pdev)
>   #define fam15h_power_resume NULL
>   #endif
>
> -static void fam15h_power_init_data(struct pci_dev *f4,
> -					     struct fam15h_power_data *data)
> +static int fam15h_power_init_data(struct pci_dev *f4,
> +				  struct fam15h_power_data *data)
>   {
>   	u32 val, eax, ebx, ecx, edx;
>   	u64 tmp;
> @@ -228,7 +233,7 @@ static void fam15h_power_init_data(struct pci_dev *f4,
>
>   	/* CPUID Fn8000_0007:EDX[12] indicates to support accumulated power */
>   	if (!(edx & BIT(12)))
> -		return;
> +		return 0;
>
>   	/*
>   	 * detemine the ratio of the compute unit power accumulator
> @@ -236,6 +241,15 @@ static void fam15h_power_init_data(struct pci_dev *f4,
>   	 * Fn8000_0007:ECX
>   	 */
>   	data->cpu_pwr_sample_ratio = ecx;
> +
> +	if (rdmsrl_safe(MSR_F15H_CU_MAX_PWR_ACCUMULATOR, &tmp)) {
> +		pr_err("Failed to read max compute unit power accumulator MSR\n");
> +		return -ENODEV;
> +	}
> +
> +	data->max_cu_acc_power = tmp;
> +
> +	return 0;
>   }
>
>   static int fam15h_power_probe(struct pci_dev *pdev,
> @@ -262,7 +276,9 @@ static int fam15h_power_probe(struct pci_dev *pdev,
>   	if (fam15h_power_init_attrs(pdev))
>   		return -ENOMEM;
>
> -	fam15h_power_init_data(pdev, data);
> +	if (fam15h_power_init_data(pdev, data))
> +		return -ENODEV;
> +
This should return the error code from fam15h_power_init_data().

Thanks,
Guenter

Re: [lm-sensors] [PATCH 08/15] hwmon, fam15h_power: add max compute unit accumulated power

[Guenter Roeck]

On 08/27/2015 01:07 AM, Huang Rui wrote:
> This patch adds a member in fam15h_power_data which specifies the
> maximum accumulated power in a compute unit.
>
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> ---
>   drivers/hwmon/fam15h_power.c | 24 ++++++++++++++++++++----
>   1 file changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> index d6efcf6..fdfa18e 100644
> --- a/drivers/hwmon/fam15h_power.c
> +++ b/drivers/hwmon/fam15h_power.c
> @@ -26,6 +26,7 @@
>   #include <linux/pci.h>
>   #include <linux/bitops.h>
>   #include <asm/processor.h>
> +#include <asm/msr.h>
>
>   MODULE_DESCRIPTION("AMD Family 15h CPU processor power monitor");
>   MODULE_AUTHOR("Andreas Herrmann <herrmann.der.user@googlemail.com>");
> @@ -43,12 +44,16 @@ MODULE_LICENSE("GPL");
>
>   #define FAM15H_MIN_POWER_GROUPS		2
>
> +#define MSR_F15H_CU_MAX_PWR_ACCUMULATOR	0xc001007b
> +
>   struct fam15h_power_data {
>   	struct pci_dev *pdev;
>   	unsigned int tdp_to_watts;
>   	unsigned int base_tdp;
>   	unsigned int processor_pwr_watts;
>   	unsigned int cpu_pwr_sample_ratio;
> +	/* maximum accumulated power of a compute unit */
> +	u64 max_cu_acc_power;
>   };
>
>   static ssize_t show_power(struct device *dev,
> @@ -199,8 +204,8 @@ static int fam15h_power_resume(struct pci_dev *pdev)
>   #define fam15h_power_resume NULL
>   #endif
>
> -static void fam15h_power_init_data(struct pci_dev *f4,
> -					     struct fam15h_power_data *data)
> +static int fam15h_power_init_data(struct pci_dev *f4,
> +				  struct fam15h_power_data *data)
>   {
>   	u32 val, eax, ebx, ecx, edx;
>   	u64 tmp;
> @@ -228,7 +233,7 @@ static void fam15h_power_init_data(struct pci_dev *f4,
>
>   	/* CPUID Fn8000_0007:EDX[12] indicates to support accumulated power */
>   	if (!(edx & BIT(12)))
> -		return;
> +		return 0;
>
>   	/*
>   	 * detemine the ratio of the compute unit power accumulator
> @@ -236,6 +241,15 @@ static void fam15h_power_init_data(struct pci_dev *f4,
>   	 * Fn8000_0007:ECX
>   	 */
>   	data->cpu_pwr_sample_ratio = ecx;
> +
> +	if (rdmsrl_safe(MSR_F15H_CU_MAX_PWR_ACCUMULATOR, &tmp)) {
> +		pr_err("Failed to read max compute unit power accumulator MSR\n");
> +		return -ENODEV;
> +	}
> +
> +	data->max_cu_acc_power = tmp;
> +
> +	return 0;
>   }
>
>   static int fam15h_power_probe(struct pci_dev *pdev,
> @@ -262,7 +276,9 @@ static int fam15h_power_probe(struct pci_dev *pdev,
>   	if (fam15h_power_init_attrs(pdev))
>   		return -ENOMEM;
>
> -	fam15h_power_init_data(pdev, data);
> +	if (fam15h_power_init_data(pdev, data))
> +		return -ENODEV;
> +
This should return the error code from fam15h_power_init_data().

Thanks,
Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Guenter Roeck]

On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
> Add an accessor function amd_get_cores_per_cu() which returns the
> number of cores per compute unit.
> 
> In a subsequent patch, we will use this function in fam15h_power
> driver.
> 
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> ---
>  arch/x86/include/asm/processor.h |  1 +
>  arch/x86/kernel/cpu/amd.c        | 19 +++++++++++++++++--
>  2 files changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> index 19577dd..831ad682 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -810,6 +810,7 @@ static inline int mpx_disable_management(void)
>  
>  extern u16 amd_get_nb_id(int cpu);
>  extern u32 amd_get_nodes_per_socket(void);
> +extern u32 amd_get_cores_per_cu(void);
>  
>  static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
>  {
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 51ad2af..8ab939a 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -26,6 +26,9 @@
>   */
>  static u32 nodes_per_socket = 1;
>  
> +/* cores_per_cu: stores the number of cores per compute unit */
> +static u32 cores_per_cu = 1;
> +
Is this value going to be constant even if there are multiple CPUs
in the system ? In other words, if there are multiple CPUs, do
they always have to have the same number of cores per CU ?

Thanks,
Guenter

>  static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
>  {
>  	u32 gprs[8] = { 0 };
> @@ -298,7 +301,6 @@ static int nearby_node(int apicid)
>  #ifdef CONFIG_SMP
>  static void amd_get_topology(struct cpuinfo_x86 *c)
>  {
> -	u32 cores_per_cu = 1;
>  	u8 node_id;
>  	int cpu = smp_processor_id();
>  
> @@ -313,7 +315,6 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
>  		/* get compute unit information */
>  		smp_num_siblings = ((ebx >> 8) & 3) + 1;
>  		c->compute_unit_id = ebx & 0xff;
> -		cores_per_cu += ((ebx >> 8) & 3);
>  	} else if (cpu_has(c, X86_FEATURE_NODEID_MSR)) {
>  		u64 value;
>  
> @@ -379,6 +380,13 @@ u32 amd_get_nodes_per_socket(void)
>  }
>  EXPORT_SYMBOL_GPL(amd_get_nodes_per_socket);
>  
> +/* this function returns the number of cores per compute unit */
> +u32 amd_get_cores_per_cu(void)
> +{
> +	return cores_per_cu;
> +}
> +EXPORT_SYMBOL_GPL(amd_get_cores_per_cu);
> +
>  static void srat_detect_node(struct cpuinfo_x86 *c)
>  {
>  #ifdef CONFIG_NUMA
> @@ -506,6 +514,13 @@ static void bsp_init_amd(struct cpuinfo_x86 *c)
>  		/* A random value per boot for bit slice [12:upper_bit) */
>  		va_align.bits = get_random_int() & va_align.mask;
>  	}
> +
> +	if (cpu_has_topoext) {
> +		u32 cpuid;
> +
> +		cpuid = cpuid_ebx(0x8000001e);
> +		cores_per_cu += ((cpuid >> 8) & 3);
> +	}
>  }
>  
>  static void early_init_amd(struct cpuinfo_x86 *c)
> -- 
> 1.9.1
> 

Re: [lm-sensors] [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Guenter Roeck]

On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
> Add an accessor function amd_get_cores_per_cu() which returns the
> number of cores per compute unit.
> 
> In a subsequent patch, we will use this function in fam15h_power
> driver.
> 
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> ---
>  arch/x86/include/asm/processor.h |  1 +
>  arch/x86/kernel/cpu/amd.c        | 19 +++++++++++++++++--
>  2 files changed, 18 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> index 19577dd..831ad682 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -810,6 +810,7 @@ static inline int mpx_disable_management(void)
>  
>  extern u16 amd_get_nb_id(int cpu);
>  extern u32 amd_get_nodes_per_socket(void);
> +extern u32 amd_get_cores_per_cu(void);
>  
>  static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
>  {
> diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> index 51ad2af..8ab939a 100644
> --- a/arch/x86/kernel/cpu/amd.c
> +++ b/arch/x86/kernel/cpu/amd.c
> @@ -26,6 +26,9 @@
>   */
>  static u32 nodes_per_socket = 1;
>  
> +/* cores_per_cu: stores the number of cores per compute unit */
> +static u32 cores_per_cu = 1;
> +
Is this value going to be constant even if there are multiple CPUs
in the system ? In other words, if there are multiple CPUs, do
they always have to have the same number of cores per CU ?

Thanks,
Guenter

>  static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
>  {
>  	u32 gprs[8] = { 0 };
> @@ -298,7 +301,6 @@ static int nearby_node(int apicid)
>  #ifdef CONFIG_SMP
>  static void amd_get_topology(struct cpuinfo_x86 *c)
>  {
> -	u32 cores_per_cu = 1;
>  	u8 node_id;
>  	int cpu = smp_processor_id();
>  
> @@ -313,7 +315,6 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
>  		/* get compute unit information */
>  		smp_num_siblings = ((ebx >> 8) & 3) + 1;
>  		c->compute_unit_id = ebx & 0xff;
> -		cores_per_cu += ((ebx >> 8) & 3);
>  	} else if (cpu_has(c, X86_FEATURE_NODEID_MSR)) {
>  		u64 value;
>  
> @@ -379,6 +380,13 @@ u32 amd_get_nodes_per_socket(void)
>  }
>  EXPORT_SYMBOL_GPL(amd_get_nodes_per_socket);
>  
> +/* this function returns the number of cores per compute unit */
> +u32 amd_get_cores_per_cu(void)
> +{
> +	return cores_per_cu;
> +}
> +EXPORT_SYMBOL_GPL(amd_get_cores_per_cu);
> +
>  static void srat_detect_node(struct cpuinfo_x86 *c)
>  {
>  #ifdef CONFIG_NUMA
> @@ -506,6 +514,13 @@ static void bsp_init_amd(struct cpuinfo_x86 *c)
>  		/* A random value per boot for bit slice [12:upper_bit) */
>  		va_align.bits = get_random_int() & va_align.mask;
>  	}
> +
> +	if (cpu_has_topoext) {
> +		u32 cpuid;
> +
> +		cpuid = cpuid_ebx(0x8000001e);
> +		cores_per_cu += ((cpuid >> 8) & 3);
> +	}
>  }
>  
>  static void early_init_amd(struct cpuinfo_x86 *c)
> -- 
> 1.9.1
> 

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algorithm

[Guenter Roeck]

On Thu, Aug 27, 2015 at 04:07:43PM +0800, Huang Rui wrote:
> This patch introduces an algorithm that computes the average power by
> reading a delta value of “core power accumulator” register during
> measurement interval, and then dividing delta value by the length of
> the time interval.
> 
> User is able to use power1_acc entry to measure the processor power
> consumption and power1_acc just needs to be read twice with an needed
> interval in-between.
> 
> A simple example:
> 
> $ cat /sys/bus/pci/devices/0000\:00\:18.4/hwmon/hwmon0/power1_acc
> $ sleep 10000s
> $ cat /sys/bus/pci/devices/0000\:00\:18.4/hwmon/hwmon0/power1_acc
> 
> The result is current average processor power consumption in 10000
> seconds. The unit of the result is uWatt.
> 
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> ---
>  drivers/hwmon/fam15h_power.c | 62 ++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 62 insertions(+)
> 
> diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> index d529e4b..3bab797 100644
> --- a/drivers/hwmon/fam15h_power.c
> +++ b/drivers/hwmon/fam15h_power.c
> @@ -60,6 +60,7 @@ struct fam15h_power_data {
>  	u64 cu_acc_power[MAX_CUS];
>  	/* performance timestamp counter */
>  	u64 cpu_sw_pwr_ptsc[MAX_CUS];
> +	struct mutex acc_pwr_mutex;
>  };
>  
>  static ssize_t show_power(struct device *dev,
> @@ -121,17 +122,74 @@ static DEVICE_ATTR(power1_crit, S_IRUGO, show_power_crit, NULL);
>  static struct attribute_group fam15h_power_group;
>  __ATTRIBUTE_GROUPS(fam15h_power);
>  
> +static ssize_t show_power_acc(struct device *dev,
> +			      struct device_attribute *attr, char *buf)
> +{
> +	int cpu, cu, cu_num, cores_per_cu;
> +	u64 curr_cu_acc_power[MAX_CUS],
> +	    curr_ptsc[MAX_CUS], jdelta[MAX_CUS];
> +	u64 tdelta, avg_acc;
> +	struct fam15h_power_data *data = dev_get_drvdata(dev);
> +
> +	cores_per_cu = amd_get_cores_per_cu();
> +	cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> +
> +	for (cpu = 0, avg_acc = 0; cpu < cu_num * cores_per_cu; cpu += cores_per_cu) {
> +		cu = cpu / cores_per_cu;
> +		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_PTSC, &curr_ptsc[cu])) {
> +			pr_err("Failed to read PTSC counter MSR on core%d\n",
> +			       cpu);
> +			return 0;
> +		}
> +
> +		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_CU_PWR_ACCUMULATOR,
> +				       &curr_cu_acc_power[cu])) {
> +			pr_err("Failed to read compute unit power accumulator MSR on core%d\n",
> +			       cpu);
> +			return 0;
> +		}
> +
> +		if (curr_cu_acc_power[cu] < data->cu_acc_power[cu]) {
> +			jdelta[cu] = data->max_cu_acc_power + curr_cu_acc_power[cu];
> +			jdelta[cu] -= data->cu_acc_power[cu];
> +		} else {
> +			jdelta[cu] = curr_cu_acc_power[cu] - data->cu_acc_power[cu];
> +		}
> +		tdelta = curr_ptsc[cu] - data->cpu_sw_pwr_ptsc[cu];
> +		jdelta[cu] *= data->cpu_pwr_sample_ratio * 1000;
> +		do_div(jdelta[cu], tdelta);
> +
> +		mutex_lock(&data->acc_pwr_mutex);
> +		data->cu_acc_power[cu] = curr_cu_acc_power[cu];
> +		data->cpu_sw_pwr_ptsc[cu] = curr_ptsc[cu];
> +		mutex_unlock(&data->acc_pwr_mutex);
> +
> +		/* the unit is microWatt */
> +		avg_acc += jdelta[cu];
> +	}
> +
> +	return sprintf(buf, "%u\n", (unsigned int) avg_acc);
> +}
> +static DEVICE_ATTR(power1_acc, S_IRUGO, show_power_acc, NULL);

I am not really a friend of introducing a non-standard attribute.
Does the energy attribute not work here ?

Thanks,
Guenter

Re: [lm-sensors] [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algo

[Guenter Roeck]

T24gVGh1LCBBdWcgMjcsIDIwMTUgYXQgMDQ6MDc6NDNQTSArMDgwMCwgSHVhbmcgUnVpIHdyb3Rl
Ogo+IFRoaXMgcGF0Y2ggaW50cm9kdWNlcyBhbiBhbGdvcml0aG0gdGhhdCBjb21wdXRlcyB0aGUg
YXZlcmFnZSBwb3dlciBieQo+IHJlYWRpbmcgYSBkZWx0YSB2YWx1ZSBvZiDigJxjb3JlIHBvd2Vy
IGFjY3VtdWxhdG9y4oCdIHJlZ2lzdGVyIGR1cmluZwo+IG1lYXN1cmVtZW50IGludGVydmFsLCBh
bmQgdGhlbiBkaXZpZGluZyBkZWx0YSB2YWx1ZSBieSB0aGUgbGVuZ3RoIG9mCj4gdGhlIHRpbWUg
aW50ZXJ2YWwuCj4gCj4gVXNlciBpcyBhYmxlIHRvIHVzZSBwb3dlcjFfYWNjIGVudHJ5IHRvIG1l
YXN1cmUgdGhlIHByb2Nlc3NvciBwb3dlcgo+IGNvbnN1bXB0aW9uIGFuZCBwb3dlcjFfYWNjIGp1
c3QgbmVlZHMgdG8gYmUgcmVhZCB0d2ljZSB3aXRoIGFuIG5lZWRlZAo+IGludGVydmFsIGluLWJl
dHdlZW4uCj4gCj4gQSBzaW1wbGUgZXhhbXBsZToKPiAKPiAkIGNhdCAvc3lzL2J1cy9wY2kvZGV2
aWNlcy8wMDAwXDowMFw6MTguNC9od21vbi9od21vbjAvcG93ZXIxX2FjYwo+ICQgc2xlZXAgMTAw
MDBzCj4gJCBjYXQgL3N5cy9idXMvcGNpL2RldmljZXMvMDAwMFw6MDBcOjE4LjQvaHdtb24vaHdt
b24wL3Bvd2VyMV9hY2MKPiAKPiBUaGUgcmVzdWx0IGlzIGN1cnJlbnQgYXZlcmFnZSBwcm9jZXNz
b3IgcG93ZXIgY29uc3VtcHRpb24gaW4gMTAwMDAKPiBzZWNvbmRzLiBUaGUgdW5pdCBvZiB0aGUg
cmVzdWx0IGlzIHVXYXR0Lgo+IAo+IFNpZ25lZC1vZmYtYnk6IEh1YW5nIFJ1aSA8cmF5Lmh1YW5n
QGFtZC5jb20+Cj4gLS0tCj4gIGRyaXZlcnMvaHdtb24vZmFtMTVoX3Bvd2VyLmMgfCA2MiArKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKwo+ICAxIGZpbGUgY2hhbmdl
ZCwgNjIgaW5zZXJ0aW9ucygrKQo+IAo+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2h3bW9uL2ZhbTE1
aF9wb3dlci5jIGIvZHJpdmVycy9od21vbi9mYW0xNWhfcG93ZXIuYwo+IGluZGV4IGQ1MjllNGIu
LjNiYWI3OTcgMTAwNjQ0Cj4gLS0tIGEvZHJpdmVycy9od21vbi9mYW0xNWhfcG93ZXIuYwo+ICsr
KyBiL2RyaXZlcnMvaHdtb24vZmFtMTVoX3Bvd2VyLmMKPiBAQCAtNjAsNiArNjAsNyBAQCBzdHJ1
Y3QgZmFtMTVoX3Bvd2VyX2RhdGEgewo+ICAJdTY0IGN1X2FjY19wb3dlcltNQVhfQ1VTXTsKPiAg
CS8qIHBlcmZvcm1hbmNlIHRpbWVzdGFtcCBjb3VudGVyICovCj4gIAl1NjQgY3B1X3N3X3B3cl9w
dHNjW01BWF9DVVNdOwo+ICsJc3RydWN0IG11dGV4IGFjY19wd3JfbXV0ZXg7Cj4gIH07Cj4gIAo+
ICBzdGF0aWMgc3NpemVfdCBzaG93X3Bvd2VyKHN0cnVjdCBkZXZpY2UgKmRldiwKPiBAQCAtMTIx
LDE3ICsxMjIsNzQgQEAgc3RhdGljIERFVklDRV9BVFRSKHBvd2VyMV9jcml0LCBTX0lSVUdPLCBz
aG93X3Bvd2VyX2NyaXQsIE5VTEwpOwo+ICBzdGF0aWMgc3RydWN0IGF0dHJpYnV0ZV9ncm91cCBm
YW0xNWhfcG93ZXJfZ3JvdXA7Cj4gIF9fQVRUUklCVVRFX0dST1VQUyhmYW0xNWhfcG93ZXIpOwo+
ICAKPiArc3RhdGljIHNzaXplX3Qgc2hvd19wb3dlcl9hY2Moc3RydWN0IGRldmljZSAqZGV2LAo+
ICsJCQkgICAgICBzdHJ1Y3QgZGV2aWNlX2F0dHJpYnV0ZSAqYXR0ciwgY2hhciAqYnVmKQo+ICt7
Cj4gKwlpbnQgY3B1LCBjdSwgY3VfbnVtLCBjb3Jlc19wZXJfY3U7Cj4gKwl1NjQgY3Vycl9jdV9h
Y2NfcG93ZXJbTUFYX0NVU10sCj4gKwkgICAgY3Vycl9wdHNjW01BWF9DVVNdLCBqZGVsdGFbTUFY
X0NVU107Cj4gKwl1NjQgdGRlbHRhLCBhdmdfYWNjOwo+ICsJc3RydWN0IGZhbTE1aF9wb3dlcl9k
YXRhICpkYXRhID0gZGV2X2dldF9kcnZkYXRhKGRldik7Cj4gKwo+ICsJY29yZXNfcGVyX2N1ID0g
YW1kX2dldF9jb3Jlc19wZXJfY3UoKTsKPiArCWN1X251bSA9IGJvb3RfY3B1X2RhdGEueDg2X21h
eF9jb3JlcyAvIGNvcmVzX3Blcl9jdTsKPiArCj4gKwlmb3IgKGNwdSA9IDAsIGF2Z19hY2MgPSAw
OyBjcHUgPCBjdV9udW0gKiBjb3Jlc19wZXJfY3U7IGNwdSArPSBjb3Jlc19wZXJfY3UpIHsKPiAr
CQljdSA9IGNwdSAvIGNvcmVzX3Blcl9jdTsKPiArCQlpZiAocmRtc3JsX3NhZmVfb25fY3B1KGNw
dSwgTVNSX0YxNUhfUFRTQywgJmN1cnJfcHRzY1tjdV0pKSB7Cj4gKwkJCXByX2VycigiRmFpbGVk
IHRvIHJlYWQgUFRTQyBjb3VudGVyIE1TUiBvbiBjb3JlJWRcbiIsCj4gKwkJCSAgICAgICBjcHUp
Owo+ICsJCQlyZXR1cm4gMDsKPiArCQl9Cj4gKwo+ICsJCWlmIChyZG1zcmxfc2FmZV9vbl9jcHUo
Y3B1LCBNU1JfRjE1SF9DVV9QV1JfQUNDVU1VTEFUT1IsCj4gKwkJCQkgICAgICAgJmN1cnJfY3Vf
YWNjX3Bvd2VyW2N1XSkpIHsKPiArCQkJcHJfZXJyKCJGYWlsZWQgdG8gcmVhZCBjb21wdXRlIHVu
aXQgcG93ZXIgYWNjdW11bGF0b3IgTVNSIG9uIGNvcmUlZFxuIiwKPiArCQkJICAgICAgIGNwdSk7
Cj4gKwkJCXJldHVybiAwOwo+ICsJCX0KPiArCj4gKwkJaWYgKGN1cnJfY3VfYWNjX3Bvd2VyW2N1
XSA8IGRhdGEtPmN1X2FjY19wb3dlcltjdV0pIHsKPiArCQkJamRlbHRhW2N1XSA9IGRhdGEtPm1h
eF9jdV9hY2NfcG93ZXIgKyBjdXJyX2N1X2FjY19wb3dlcltjdV07Cj4gKwkJCWpkZWx0YVtjdV0g
LT0gZGF0YS0+Y3VfYWNjX3Bvd2VyW2N1XTsKPiArCQl9IGVsc2Ugewo+ICsJCQlqZGVsdGFbY3Vd
ID0gY3Vycl9jdV9hY2NfcG93ZXJbY3VdIC0gZGF0YS0+Y3VfYWNjX3Bvd2VyW2N1XTsKPiArCQl9
Cj4gKwkJdGRlbHRhID0gY3Vycl9wdHNjW2N1XSAtIGRhdGEtPmNwdV9zd19wd3JfcHRzY1tjdV07
Cj4gKwkJamRlbHRhW2N1XSAqPSBkYXRhLT5jcHVfcHdyX3NhbXBsZV9yYXRpbyAqIDEwMDA7Cj4g
KwkJZG9fZGl2KGpkZWx0YVtjdV0sIHRkZWx0YSk7Cj4gKwo+ICsJCW11dGV4X2xvY2soJmRhdGEt
PmFjY19wd3JfbXV0ZXgpOwo+ICsJCWRhdGEtPmN1X2FjY19wb3dlcltjdV0gPSBjdXJyX2N1X2Fj
Y19wb3dlcltjdV07Cj4gKwkJZGF0YS0+Y3B1X3N3X3B3cl9wdHNjW2N1XSA9IGN1cnJfcHRzY1tj
dV07Cj4gKwkJbXV0ZXhfdW5sb2NrKCZkYXRhLT5hY2NfcHdyX211dGV4KTsKPiArCj4gKwkJLyog
dGhlIHVuaXQgaXMgbWljcm9XYXR0ICovCj4gKwkJYXZnX2FjYyArPSBqZGVsdGFbY3VdOwo+ICsJ
fQo+ICsKPiArCXJldHVybiBzcHJpbnRmKGJ1ZiwgIiV1XG4iLCAodW5zaWduZWQgaW50KSBhdmdf
YWNjKTsKPiArfQo+ICtzdGF0aWMgREVWSUNFX0FUVFIocG93ZXIxX2FjYywgU19JUlVHTywgc2hv
d19wb3dlcl9hY2MsIE5VTEwpOwoKSSBhbSBub3QgcmVhbGx5IGEgZnJpZW5kIG9mIGludHJvZHVj
aW5nIGEgbm9uLXN0YW5kYXJkIGF0dHJpYnV0ZS4KRG9lcyB0aGUgZW5lcmd5IGF0dHJpYnV0ZSBu
b3Qgd29yayBoZXJlID8KClRoYW5rcywKR3VlbnRlcgoKX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18KbG0tc2Vuc29ycyBtYWlsaW5nIGxpc3QKbG0tc2Vuc29y
c0BsbS1zZW5zb3JzLm9yZwpodHRwOi8vbGlzdHMubG0tc2Vuc29ycy5vcmcvbWFpbG1hbi9saXN0
aW5mby9sbS1zZW5zb3Jz

Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Borislav Petkov]

On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
> Add an accessor function amd_get_cores_per_cu() which returns the
> number of cores per compute unit.
> 
> In a subsequent patch, we will use this function in fam15h_power
> driver.
> 
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> ---
>  arch/x86/include/asm/processor.h |  1 +
>  arch/x86/kernel/cpu/amd.c        | 19 +++++++++++++++++--
>  2 files changed, 18 insertions(+), 2 deletions(-)

Btw, this needs an ACK from a tip person if it goes through the hwmon
tree.

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [lm-sensors] [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Borislav Petkov]

On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
> Add an accessor function amd_get_cores_per_cu() which returns the
> number of cores per compute unit.
> 
> In a subsequent patch, we will use this function in fam15h_power
> driver.
> 
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> ---
>  arch/x86/include/asm/processor.h |  1 +
>  arch/x86/kernel/cpu/amd.c        | 19 +++++++++++++++++--
>  2 files changed, 18 insertions(+), 2 deletions(-)

Btw, this needs an ACK from a tip person if it goes through the hwmon
tree.

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Guenter Roeck]

On 08/27/2015 11:48 PM, Borislav Petkov wrote:
> On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
>> Add an accessor function amd_get_cores_per_cu() which returns the
>> number of cores per compute unit.
>>
>> In a subsequent patch, we will use this function in fam15h_power
>> driver.
>>
>> Signed-off-by: Huang Rui <ray.huang@amd.com>
>> ---
>>   arch/x86/include/asm/processor.h |  1 +
>>   arch/x86/kernel/cpu/amd.c        | 19 +++++++++++++++++--
>>   2 files changed, 18 insertions(+), 2 deletions(-)
>
> Btw, this needs an ACK from a tip person if it goes through the hwmon
> tree.
>
Yes, most definitely.

Guenter

Re: [lm-sensors] [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Guenter Roeck]

On 08/27/2015 11:48 PM, Borislav Petkov wrote:
> On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
>> Add an accessor function amd_get_cores_per_cu() which returns the
>> number of cores per compute unit.
>>
>> In a subsequent patch, we will use this function in fam15h_power
>> driver.
>>
>> Signed-off-by: Huang Rui <ray.huang@amd.com>
>> ---
>>   arch/x86/include/asm/processor.h |  1 +
>>   arch/x86/kernel/cpu/amd.c        | 19 +++++++++++++++++--
>>   2 files changed, 18 insertions(+), 2 deletions(-)
>
> Btw, this needs an ACK from a tip person if it goes through the hwmon
> tree.
>
Yes, most definitely.

Guenter



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 10/15] hwmon, fam15h_power: add compute unit accumulated power

[Ingo Molnar]

* Huang Rui <ray.huang@amd.com> wrote:

> This patch adds a member in fam15h_power_data which specifies the
> compute unit accumulated power.
> 
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> ---
>  drivers/hwmon/fam15h_power.c | 31 +++++++++++++++++++++++++++----
>  1 file changed, 27 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> index fdfa18e..f5ff48f 100644
> --- a/drivers/hwmon/fam15h_power.c
> +++ b/drivers/hwmon/fam15h_power.c
> @@ -43,7 +43,9 @@ MODULE_LICENSE("GPL");
>  #define REG_TDP_LIMIT3			0xe8
>  
>  #define FAM15H_MIN_POWER_GROUPS		2
> +#define MAX_CUS				8
>  
> +#define MSR_F15H_CU_PWR_ACCUMULATOR	0xc001007a
>  #define MSR_F15H_CU_MAX_PWR_ACCUMULATOR	0xc001007b
>  
>  struct fam15h_power_data {
> @@ -54,6 +56,8 @@ struct fam15h_power_data {
>  	unsigned int cpu_pwr_sample_ratio;
>  	/* maximum accumulated power of a compute unit */
>  	u64 max_cu_acc_power;
> +	/* accumulated power of the compute units */
> +	u64 cu_acc_power[MAX_CUS];
>  };
>  
>  static ssize_t show_power(struct device *dev,
> @@ -207,6 +211,7 @@ static int fam15h_power_resume(struct pci_dev *pdev)
>  static int fam15h_power_init_data(struct pci_dev *f4,
>  				  struct fam15h_power_data *data)
>  {
> +	int cu_num, cores_per_cu, cpu, cu;
>  	u32 val, eax, ebx, ecx, edx;
>  	u64 tmp;
>  
> @@ -249,6 +254,21 @@ static int fam15h_power_init_data(struct pci_dev *f4,
>  
>  	data->max_cu_acc_power = tmp;
>  
> +	cores_per_cu = amd_get_cores_per_cu();
> +	cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> +
> +	WARN_ON_ONCE(cu_num > MAX_CUS);
> +
> +	for (cpu = 0; cpu < cu_num * cores_per_cu; cpu += cores_per_cu) {

so 'cu_num * cores_per_cu' is really a roundabout way to say 
boot_cpu_data.x86_max_cores?

> +		cu = cpu / cores_per_cu;
> +		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_CU_PWR_ACCUMULATOR,
> +				       &data->cu_acc_power[cu])) {
> +			pr_err("Failed to read compute unit power accumulator MSR on core%d\n",
> +			       cpu);

Please don't break printk lines mid-line - ignore checkpatch in this case.

Also, the message talks about 'core', while a CPU ID is printed.

Thanks,

	Ingo

Re: [lm-sensors] [PATCH 10/15] hwmon, fam15h_power: add compute unit accumulated power

[Ingo Molnar]

* Huang Rui <ray.huang@amd.com> wrote:

> This patch adds a member in fam15h_power_data which specifies the
> compute unit accumulated power.
> 
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> ---
>  drivers/hwmon/fam15h_power.c | 31 +++++++++++++++++++++++++++----
>  1 file changed, 27 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> index fdfa18e..f5ff48f 100644
> --- a/drivers/hwmon/fam15h_power.c
> +++ b/drivers/hwmon/fam15h_power.c
> @@ -43,7 +43,9 @@ MODULE_LICENSE("GPL");
>  #define REG_TDP_LIMIT3			0xe8
>  
>  #define FAM15H_MIN_POWER_GROUPS		2
> +#define MAX_CUS				8
>  
> +#define MSR_F15H_CU_PWR_ACCUMULATOR	0xc001007a
>  #define MSR_F15H_CU_MAX_PWR_ACCUMULATOR	0xc001007b
>  
>  struct fam15h_power_data {
> @@ -54,6 +56,8 @@ struct fam15h_power_data {
>  	unsigned int cpu_pwr_sample_ratio;
>  	/* maximum accumulated power of a compute unit */
>  	u64 max_cu_acc_power;
> +	/* accumulated power of the compute units */
> +	u64 cu_acc_power[MAX_CUS];
>  };
>  
>  static ssize_t show_power(struct device *dev,
> @@ -207,6 +211,7 @@ static int fam15h_power_resume(struct pci_dev *pdev)
>  static int fam15h_power_init_data(struct pci_dev *f4,
>  				  struct fam15h_power_data *data)
>  {
> +	int cu_num, cores_per_cu, cpu, cu;
>  	u32 val, eax, ebx, ecx, edx;
>  	u64 tmp;
>  
> @@ -249,6 +254,21 @@ static int fam15h_power_init_data(struct pci_dev *f4,
>  
>  	data->max_cu_acc_power = tmp;
>  
> +	cores_per_cu = amd_get_cores_per_cu();
> +	cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> +
> +	WARN_ON_ONCE(cu_num > MAX_CUS);
> +
> +	for (cpu = 0; cpu < cu_num * cores_per_cu; cpu += cores_per_cu) {

so 'cu_num * cores_per_cu' is really a roundabout way to say 
boot_cpu_data.x86_max_cores?

> +		cu = cpu / cores_per_cu;
> +		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_CU_PWR_ACCUMULATOR,
> +				       &data->cu_acc_power[cu])) {
> +			pr_err("Failed to read compute unit power accumulator MSR on core%d\n",
> +			       cpu);

Please don't break printk lines mid-line - ignore checkpatch in this case.

Also, the message talks about 'core', while a CPU ID is printed.

Thanks,

	Ingo

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Ingo Molnar]

* Borislav Petkov <bp@alien8.de> wrote:

> On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
> > Add an accessor function amd_get_cores_per_cu() which returns the
> > number of cores per compute unit.
> > 
> > In a subsequent patch, we will use this function in fam15h_power
> > driver.
> > 
> > Signed-off-by: Huang Rui <ray.huang@amd.com>
> > ---
> >  arch/x86/include/asm/processor.h |  1 +
> >  arch/x86/kernel/cpu/amd.c        | 19 +++++++++++++++++--
> >  2 files changed, 18 insertions(+), 2 deletions(-)
> 
> Btw, this needs an ACK from a tip person if it goes through the hwmon
> tree.

Looks good to me in theory.

I suspect we might want to factor the 'compute unit' logic out a bit more if usage 
becomes more widespread - but right now it's hwmon drivers only,right?

Thanks,

	Ingo

Re: [lm-sensors] [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Ingo Molnar]

* Borislav Petkov <bp@alien8.de> wrote:

> On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
> > Add an accessor function amd_get_cores_per_cu() which returns the
> > number of cores per compute unit.
> > 
> > In a subsequent patch, we will use this function in fam15h_power
> > driver.
> > 
> > Signed-off-by: Huang Rui <ray.huang@amd.com>
> > ---
> >  arch/x86/include/asm/processor.h |  1 +
> >  arch/x86/kernel/cpu/amd.c        | 19 +++++++++++++++++--
> >  2 files changed, 18 insertions(+), 2 deletions(-)
> 
> Btw, this needs an ACK from a tip person if it goes through the hwmon
> tree.

Looks good to me in theory.

I suspect we might want to factor the 'compute unit' logic out a bit more if usage 
becomes more widespread - but right now it's hwmon drivers only,right?

Thanks,

	Ingo

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Borislav Petkov]

On Fri, Aug 28, 2015 at 10:04:18AM +0200, Ingo Molnar wrote:
> Looks good to me in theory.

Thanks.

> I suspect we might want to factor the 'compute unit' logic out a bit
> more if usage becomes more widespread - but right now it's hwmon
> drivers only,right?

Yeah.

My angle is to extend stuff as we go and only when we need it.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [lm-sensors] [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Borislav Petkov]

On Fri, Aug 28, 2015 at 10:04:18AM +0200, Ingo Molnar wrote:
> Looks good to me in theory.

Thanks.

> I suspect we might want to factor the 'compute unit' logic out a bit
> more if usage becomes more widespread - but right now it's hwmon
> drivers only,right?

Yeah.

My angle is to extend stuff as we go and only when we need it.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 03/15] hwmon, fam15h_power: refactor attributes for dynamically added

[Huang Rui]

On Thu, Aug 27, 2015 at 07:46:18AM -0700, Guenter Roeck wrote:
> On 08/27/2015 01:07 AM, Huang Rui wrote:
> >
> >diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> >index 820adf1..65ffb06 100644
> >--- a/drivers/hwmon/fam15h_power.c
> >+++ b/drivers/hwmon/fam15h_power.c
> >@@ -41,6 +41,8 @@ MODULE_LICENSE("GPL");
> >  #define REG_TDP_RUNNING_AVERAGE		0xe0
> >  #define REG_TDP_LIMIT3			0xe8
> >
> >+#define FAM15H_MIN_POWER_GROUPS		2
> 
> This should be something like FAM15H_MIN_NUM_ATTRS.
> There is only one group with a variable number of attributes.
> 

Right, it should be attribute. I will rename this macro.

> >+	n = 0;
> >+	fam15h_power_attrs[n++] = &dev_attr_power1_crit.attr;
> >+	if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model <= 0xf)
> >+		fam15h_power_attrs[n++] = &dev_attr_power1_input.attr;
> >+
> >+	fam15h_power_group.attrs = fam15h_power_attrs;
> >+
> Assuming this will be called for each CPU in a multi-CPU system,
> this will be overwritten each time a new CPU comes online.
> fam15h_power_group and fam15h_power_groups probably need to be moved
> into fam15h_power_data to avoid that. In essence, there should only
> be read-only static variables. Everything else should be allocated.
> 

Yes, setting fam15h_power_group as static and not const would cause to
overwrite in multi-CPU platforms. I don't have to set it as read-only
because I use dynamical attributes. :)

I will move them into fam15h_power_data at v2.

> >+	return 0;
> >+}
> >
> >  static bool should_load_on_this_node(struct pci_dev *f4)
> >  {
> >@@ -221,6 +229,9 @@ static int fam15h_power_probe(struct pci_dev *pdev,
> >  	if (!data)
> >  		return -ENOMEM;
> >
> >+	if (fam15h_power_init_attrs(pdev))
> >+		return -ENOMEM;
> 
> This should return the error code from fam15h_power_init_attrs().
> 

Actually, I do this at the following patch of this serial. But never
mind, I will update it here at v2.

Thanks,
Rui

Re: [lm-sensors] [PATCH 03/15] hwmon, fam15h_power: refactor attributes for dynamically added

[Huang Rui]

On Thu, Aug 27, 2015 at 07:46:18AM -0700, Guenter Roeck wrote:
> On 08/27/2015 01:07 AM, Huang Rui wrote:
> >
> >diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> >index 820adf1..65ffb06 100644
> >--- a/drivers/hwmon/fam15h_power.c
> >+++ b/drivers/hwmon/fam15h_power.c
> >@@ -41,6 +41,8 @@ MODULE_LICENSE("GPL");
> >  #define REG_TDP_RUNNING_AVERAGE		0xe0
> >  #define REG_TDP_LIMIT3			0xe8
> >
> >+#define FAM15H_MIN_POWER_GROUPS		2
> 
> This should be something like FAM15H_MIN_NUM_ATTRS.
> There is only one group with a variable number of attributes.
> 

Right, it should be attribute. I will rename this macro.

> >+	n = 0;
> >+	fam15h_power_attrs[n++] = &dev_attr_power1_crit.attr;
> >+	if (boot_cpu_data.x86 = 0x15 && boot_cpu_data.x86_model <= 0xf)
> >+		fam15h_power_attrs[n++] = &dev_attr_power1_input.attr;
> >+
> >+	fam15h_power_group.attrs = fam15h_power_attrs;
> >+
> Assuming this will be called for each CPU in a multi-CPU system,
> this will be overwritten each time a new CPU comes online.
> fam15h_power_group and fam15h_power_groups probably need to be moved
> into fam15h_power_data to avoid that. In essence, there should only
> be read-only static variables. Everything else should be allocated.
> 

Yes, setting fam15h_power_group as static and not const would cause to
overwrite in multi-CPU platforms. I don't have to set it as read-only
because I use dynamical attributes. :)

I will move them into fam15h_power_data at v2.

> >+	return 0;
> >+}
> >
> >  static bool should_load_on_this_node(struct pci_dev *f4)
> >  {
> >@@ -221,6 +229,9 @@ static int fam15h_power_probe(struct pci_dev *pdev,
> >  	if (!data)
> >  		return -ENOMEM;
> >
> >+	if (fam15h_power_init_attrs(pdev))
> >+		return -ENOMEM;
> 
> This should return the error code from fam15h_power_init_attrs().
> 

Actually, I do this at the following patch of this serial. But never
mind, I will update it here at v2.

Thanks,
Rui

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Huang Rui]

On Fri, Aug 28, 2015 at 04:04:18PM +0800, Ingo Molnar wrote:
> 
> * Borislav Petkov <bp@alien8.de> wrote:
> 
> > On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
> > > Add an accessor function amd_get_cores_per_cu() which returns the
> > > number of cores per compute unit.
> > > 
> > > In a subsequent patch, we will use this function in fam15h_power
> > > driver.
> > > 
> > > Signed-off-by: Huang Rui <ray.huang@amd.com>
> > > ---
> > >  arch/x86/include/asm/processor.h |  1 +
> > >  arch/x86/kernel/cpu/amd.c        | 19 +++++++++++++++++--
> > >  2 files changed, 18 insertions(+), 2 deletions(-)
> > 
> > Btw, this needs an ACK from a tip person if it goes through the hwmon
> > tree.
> 
> Looks good to me in theory.
> 
> I suspect we might want to factor the 'compute unit' logic out a bit more if usage 
> becomes more widespread - but right now it's hwmon drivers only,right?
> 

Actually, the cores with the same compute unit share some resources
such as power domain, it might be useful in other parts not only for
hwmon. :)

Thanks,
Rui

Re: [lm-sensors] [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Huang Rui]

On Fri, Aug 28, 2015 at 04:04:18PM +0800, Ingo Molnar wrote:
> 
> * Borislav Petkov <bp@alien8.de> wrote:
> 
> > On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
> > > Add an accessor function amd_get_cores_per_cu() which returns the
> > > number of cores per compute unit.
> > > 
> > > In a subsequent patch, we will use this function in fam15h_power
> > > driver.
> > > 
> > > Signed-off-by: Huang Rui <ray.huang@amd.com>
> > > ---
> > >  arch/x86/include/asm/processor.h |  1 +
> > >  arch/x86/kernel/cpu/amd.c        | 19 +++++++++++++++++--
> > >  2 files changed, 18 insertions(+), 2 deletions(-)
> > 
> > Btw, this needs an ACK from a tip person if it goes through the hwmon
> > tree.
> 
> Looks good to me in theory.
> 
> I suspect we might want to factor the 'compute unit' logic out a bit more if usage 
> becomes more widespread - but right now it's hwmon drivers only,right?
> 

Actually, the cores with the same compute unit share some resources
such as power domain, it might be useful in other parts not only for
hwmon. :)

Thanks,
Rui

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Huang Rui]

On Thu, Aug 27, 2015 at 10:27:46AM -0700, Guenter Roeck wrote:
> On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
> > Add an accessor function amd_get_cores_per_cu() which returns the
> > number of cores per compute unit.
> > 
> > In a subsequent patch, we will use this function in fam15h_power
> > driver.
> > 
> > Signed-off-by: Huang Rui <ray.huang@amd.com>
> > ---
> >  arch/x86/include/asm/processor.h |  1 +
> >  arch/x86/kernel/cpu/amd.c        | 19 +++++++++++++++++--
> >  2 files changed, 18 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> > index 19577dd..831ad682 100644
> > --- a/arch/x86/include/asm/processor.h
> > +++ b/arch/x86/include/asm/processor.h
> > @@ -810,6 +810,7 @@ static inline int mpx_disable_management(void)
> >  
> >  extern u16 amd_get_nb_id(int cpu);
> >  extern u32 amd_get_nodes_per_socket(void);
> > +extern u32 amd_get_cores_per_cu(void);
> >  
> >  static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
> >  {
> > diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> > index 51ad2af..8ab939a 100644
> > --- a/arch/x86/kernel/cpu/amd.c
> > +++ b/arch/x86/kernel/cpu/amd.c
> > @@ -26,6 +26,9 @@
> >   */
> >  static u32 nodes_per_socket = 1;
> >  
> > +/* cores_per_cu: stores the number of cores per compute unit */
> > +static u32 cores_per_cu = 1;
> > +
> Is this value going to be constant even if there are multiple CPUs
> in the system ? In other words, if there are multiple CPUs, do
> they always have to have the same number of cores per CU ?
> 

Yes, the same type of processors have the fixed number of cores per
compute unit. Currently, the number is 2, but it might be more in
future.

Thanks,
Rui

Re: [lm-sensors] [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Huang Rui]

On Thu, Aug 27, 2015 at 10:27:46AM -0700, Guenter Roeck wrote:
> On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
> > Add an accessor function amd_get_cores_per_cu() which returns the
> > number of cores per compute unit.
> > 
> > In a subsequent patch, we will use this function in fam15h_power
> > driver.
> > 
> > Signed-off-by: Huang Rui <ray.huang@amd.com>
> > ---
> >  arch/x86/include/asm/processor.h |  1 +
> >  arch/x86/kernel/cpu/amd.c        | 19 +++++++++++++++++--
> >  2 files changed, 18 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> > index 19577dd..831ad682 100644
> > --- a/arch/x86/include/asm/processor.h
> > +++ b/arch/x86/include/asm/processor.h
> > @@ -810,6 +810,7 @@ static inline int mpx_disable_management(void)
> >  
> >  extern u16 amd_get_nb_id(int cpu);
> >  extern u32 amd_get_nodes_per_socket(void);
> > +extern u32 amd_get_cores_per_cu(void);
> >  
> >  static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
> >  {
> > diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
> > index 51ad2af..8ab939a 100644
> > --- a/arch/x86/kernel/cpu/amd.c
> > +++ b/arch/x86/kernel/cpu/amd.c
> > @@ -26,6 +26,9 @@
> >   */
> >  static u32 nodes_per_socket = 1;
> >  
> > +/* cores_per_cu: stores the number of cores per compute unit */
> > +static u32 cores_per_cu = 1;
> > +
> Is this value going to be constant even if there are multiple CPUs
> in the system ? In other words, if there are multiple CPUs, do
> they always have to have the same number of cores per CU ?
> 

Yes, the same type of processors have the fixed number of cores per
compute unit. Currently, the number is 2, but it might be more in
future.

Thanks,
Rui

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 10/15] hwmon, fam15h_power: add compute unit accumulated power

[Huang Rui]

On Fri, Aug 28, 2015 at 10:03:35AM +0200, Ingo Molnar wrote:
> 
> * Huang Rui <ray.huang@amd.com> wrote:
> 
> > @@ -249,6 +254,21 @@ static int fam15h_power_init_data(struct pci_dev *f4,
> >  
> >  	data->max_cu_acc_power = tmp;
> >  
> > +	cores_per_cu = amd_get_cores_per_cu();
> > +	cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> > +
> > +	WARN_ON_ONCE(cu_num > MAX_CUS);
> > +
> > +	for (cpu = 0; cpu < cu_num * cores_per_cu; cpu += cores_per_cu) {
> 
> so 'cu_num * cores_per_cu' is really a roundabout way to say 
> boot_cpu_data.x86_max_cores?
> 

Oh, yes. :)
I will update it at v2.

> > +		cu = cpu / cores_per_cu;
> > +		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_CU_PWR_ACCUMULATOR,
> > +				       &data->cu_acc_power[cu])) {
> > +			pr_err("Failed to read compute unit power accumulator MSR on core%d\n",
> > +			       cpu);
> 
> Please don't break printk lines mid-line - ignore checkpatch in this case.
> 

OK, I got it.

> Also, the message talks about 'core', while a CPU ID is printed.
> 

Yes, but actually this value is for the compute unit which the core
belongs to.
E.X. the MSR_F15H_CU_PWR_ACCUMULATOR value is the same between core 0
and core 1. Because they belong to the same compute unit.

Thanks,
Rui

Re: [lm-sensors] [PATCH 10/15] hwmon, fam15h_power: add compute unit accumulated power

[Huang Rui]

On Fri, Aug 28, 2015 at 10:03:35AM +0200, Ingo Molnar wrote:
> 
> * Huang Rui <ray.huang@amd.com> wrote:
> 
> > @@ -249,6 +254,21 @@ static int fam15h_power_init_data(struct pci_dev *f4,
> >  
> >  	data->max_cu_acc_power = tmp;
> >  
> > +	cores_per_cu = amd_get_cores_per_cu();
> > +	cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> > +
> > +	WARN_ON_ONCE(cu_num > MAX_CUS);
> > +
> > +	for (cpu = 0; cpu < cu_num * cores_per_cu; cpu += cores_per_cu) {
> 
> so 'cu_num * cores_per_cu' is really a roundabout way to say 
> boot_cpu_data.x86_max_cores?
> 

Oh, yes. :)
I will update it at v2.

> > +		cu = cpu / cores_per_cu;
> > +		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_CU_PWR_ACCUMULATOR,
> > +				       &data->cu_acc_power[cu])) {
> > +			pr_err("Failed to read compute unit power accumulator MSR on core%d\n",
> > +			       cpu);
> 
> Please don't break printk lines mid-line - ignore checkpatch in this case.
> 

OK, I got it.

> Also, the message talks about 'core', while a CPU ID is printed.
> 

Yes, but actually this value is for the compute unit which the core
belongs to.
E.X. the MSR_F15H_CU_PWR_ACCUMULATOR value is the same between core 0
and core 1. Because they belong to the same compute unit.

Thanks,
Rui

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algorithm

[Huang Rui]

On Thu, Aug 27, 2015 at 10:30:43AM -0700, Guenter Roeck wrote:
> On Thu, Aug 27, 2015 at 04:07:43PM +0800, Huang Rui wrote:
> > This patch introduces an algorithm that computes the average power by
> > reading a delta value of “core power accumulator” register during
> > measurement interval, and then dividing delta value by the length of
> > the time interval.
> > 
> > User is able to use power1_acc entry to measure the processor power
> > consumption and power1_acc just needs to be read twice with an needed
> > interval in-between.
> > 
> > A simple example:
> > 
> > $ cat /sys/bus/pci/devices/0000\:00\:18.4/hwmon/hwmon0/power1_acc
> > $ sleep 10000s
> > $ cat /sys/bus/pci/devices/0000\:00\:18.4/hwmon/hwmon0/power1_acc
> > 
> > The result is current average processor power consumption in 10000
> > seconds. The unit of the result is uWatt.
> > 
> > Signed-off-by: Huang Rui <ray.huang@amd.com>
> > ---
> >  drivers/hwmon/fam15h_power.c | 62 ++++++++++++++++++++++++++++++++++++++++++++
> >  1 file changed, 62 insertions(+)
> > 
> > diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> > index d529e4b..3bab797 100644
> > --- a/drivers/hwmon/fam15h_power.c
> > +++ b/drivers/hwmon/fam15h_power.c
> > @@ -60,6 +60,7 @@ struct fam15h_power_data {
> >  	u64 cu_acc_power[MAX_CUS];
> >  	/* performance timestamp counter */
> >  	u64 cpu_sw_pwr_ptsc[MAX_CUS];
> > +	struct mutex acc_pwr_mutex;
> >  };
> >  
> >  static ssize_t show_power(struct device *dev,
> > @@ -121,17 +122,74 @@ static DEVICE_ATTR(power1_crit, S_IRUGO, show_power_crit, NULL);
> >  static struct attribute_group fam15h_power_group;
> >  __ATTRIBUTE_GROUPS(fam15h_power);
> >  
> > +static ssize_t show_power_acc(struct device *dev,
> > +			      struct device_attribute *attr, char *buf)
> > +{
> > +	int cpu, cu, cu_num, cores_per_cu;
> > +	u64 curr_cu_acc_power[MAX_CUS],
> > +	    curr_ptsc[MAX_CUS], jdelta[MAX_CUS];
> > +	u64 tdelta, avg_acc;
> > +	struct fam15h_power_data *data = dev_get_drvdata(dev);
> > +
> > +	cores_per_cu = amd_get_cores_per_cu();
> > +	cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> > +
> > +	for (cpu = 0, avg_acc = 0; cpu < cu_num * cores_per_cu; cpu += cores_per_cu) {
> > +		cu = cpu / cores_per_cu;
> > +		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_PTSC, &curr_ptsc[cu])) {
> > +			pr_err("Failed to read PTSC counter MSR on core%d\n",
> > +			       cpu);
> > +			return 0;
> > +		}
> > +
> > +		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_CU_PWR_ACCUMULATOR,
> > +				       &curr_cu_acc_power[cu])) {
> > +			pr_err("Failed to read compute unit power accumulator MSR on core%d\n",
> > +			       cpu);
> > +			return 0;
> > +		}
> > +
> > +		if (curr_cu_acc_power[cu] < data->cu_acc_power[cu]) {
> > +			jdelta[cu] = data->max_cu_acc_power + curr_cu_acc_power[cu];
> > +			jdelta[cu] -= data->cu_acc_power[cu];
> > +		} else {
> > +			jdelta[cu] = curr_cu_acc_power[cu] - data->cu_acc_power[cu];
> > +		}
> > +		tdelta = curr_ptsc[cu] - data->cpu_sw_pwr_ptsc[cu];
> > +		jdelta[cu] *= data->cpu_pwr_sample_ratio * 1000;
> > +		do_div(jdelta[cu], tdelta);
> > +
> > +		mutex_lock(&data->acc_pwr_mutex);
> > +		data->cu_acc_power[cu] = curr_cu_acc_power[cu];
> > +		data->cpu_sw_pwr_ptsc[cu] = curr_ptsc[cu];
> > +		mutex_unlock(&data->acc_pwr_mutex);
> > +
> > +		/* the unit is microWatt */
> > +		avg_acc += jdelta[cu];
> > +	}
> > +
> > +	return sprintf(buf, "%u\n", (unsigned int) avg_acc);
> > +}
> > +static DEVICE_ATTR(power1_acc, S_IRUGO, show_power_acc, NULL);
> 
> I am not really a friend of introducing a non-standard attribute.
> Does the energy attribute not work here ?
> 

You're right. Non-standard attribute might not be good. Could you
please give me some hints if I use "energy" instead?

Thanks,
Rui

Re: [lm-sensors] [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algo

[Huang Rui]

T24gVGh1LCBBdWcgMjcsIDIwMTUgYXQgMTA6MzA6NDNBTSAtMDcwMCwgR3VlbnRlciBSb2VjayB3
cm90ZToKPiBPbiBUaHUsIEF1ZyAyNywgMjAxNSBhdCAwNDowNzo0M1BNICswODAwLCBIdWFuZyBS
dWkgd3JvdGU6Cj4gPiBUaGlzIHBhdGNoIGludHJvZHVjZXMgYW4gYWxnb3JpdGhtIHRoYXQgY29t
cHV0ZXMgdGhlIGF2ZXJhZ2UgcG93ZXIgYnkKPiA+IHJlYWRpbmcgYSBkZWx0YSB2YWx1ZSBvZiDi
gJxjb3JlIHBvd2VyIGFjY3VtdWxhdG9y4oCdIHJlZ2lzdGVyIGR1cmluZwo+ID4gbWVhc3VyZW1l
bnQgaW50ZXJ2YWwsIGFuZCB0aGVuIGRpdmlkaW5nIGRlbHRhIHZhbHVlIGJ5IHRoZSBsZW5ndGgg
b2YKPiA+IHRoZSB0aW1lIGludGVydmFsLgo+ID4gCj4gPiBVc2VyIGlzIGFibGUgdG8gdXNlIHBv
d2VyMV9hY2MgZW50cnkgdG8gbWVhc3VyZSB0aGUgcHJvY2Vzc29yIHBvd2VyCj4gPiBjb25zdW1w
dGlvbiBhbmQgcG93ZXIxX2FjYyBqdXN0IG5lZWRzIHRvIGJlIHJlYWQgdHdpY2Ugd2l0aCBhbiBu
ZWVkZWQKPiA+IGludGVydmFsIGluLWJldHdlZW4uCj4gPiAKPiA+IEEgc2ltcGxlIGV4YW1wbGU6
Cj4gPiAKPiA+ICQgY2F0IC9zeXMvYnVzL3BjaS9kZXZpY2VzLzAwMDBcOjAwXDoxOC40L2h3bW9u
L2h3bW9uMC9wb3dlcjFfYWNjCj4gPiAkIHNsZWVwIDEwMDAwcwo+ID4gJCBjYXQgL3N5cy9idXMv
cGNpL2RldmljZXMvMDAwMFw6MDBcOjE4LjQvaHdtb24vaHdtb24wL3Bvd2VyMV9hY2MKPiA+IAo+
ID4gVGhlIHJlc3VsdCBpcyBjdXJyZW50IGF2ZXJhZ2UgcHJvY2Vzc29yIHBvd2VyIGNvbnN1bXB0
aW9uIGluIDEwMDAwCj4gPiBzZWNvbmRzLiBUaGUgdW5pdCBvZiB0aGUgcmVzdWx0IGlzIHVXYXR0
Lgo+ID4gCj4gPiBTaWduZWQtb2ZmLWJ5OiBIdWFuZyBSdWkgPHJheS5odWFuZ0BhbWQuY29tPgo+
ID4gLS0tCj4gPiAgZHJpdmVycy9od21vbi9mYW0xNWhfcG93ZXIuYyB8IDYyICsrKysrKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrCj4gPiAgMSBmaWxlIGNoYW5nZWQsIDYy
IGluc2VydGlvbnMoKykKPiA+IAo+ID4gZGlmZiAtLWdpdCBhL2RyaXZlcnMvaHdtb24vZmFtMTVo
X3Bvd2VyLmMgYi9kcml2ZXJzL2h3bW9uL2ZhbTE1aF9wb3dlci5jCj4gPiBpbmRleCBkNTI5ZTRi
Li4zYmFiNzk3IDEwMDY0NAo+ID4gLS0tIGEvZHJpdmVycy9od21vbi9mYW0xNWhfcG93ZXIuYwo+
ID4gKysrIGIvZHJpdmVycy9od21vbi9mYW0xNWhfcG93ZXIuYwo+ID4gQEAgLTYwLDYgKzYwLDcg
QEAgc3RydWN0IGZhbTE1aF9wb3dlcl9kYXRhIHsKPiA+ICAJdTY0IGN1X2FjY19wb3dlcltNQVhf
Q1VTXTsKPiA+ICAJLyogcGVyZm9ybWFuY2UgdGltZXN0YW1wIGNvdW50ZXIgKi8KPiA+ICAJdTY0
IGNwdV9zd19wd3JfcHRzY1tNQVhfQ1VTXTsKPiA+ICsJc3RydWN0IG11dGV4IGFjY19wd3JfbXV0
ZXg7Cj4gPiAgfTsKPiA+ICAKPiA+ICBzdGF0aWMgc3NpemVfdCBzaG93X3Bvd2VyKHN0cnVjdCBk
ZXZpY2UgKmRldiwKPiA+IEBAIC0xMjEsMTcgKzEyMiw3NCBAQCBzdGF0aWMgREVWSUNFX0FUVFIo
cG93ZXIxX2NyaXQsIFNfSVJVR08sIHNob3dfcG93ZXJfY3JpdCwgTlVMTCk7Cj4gPiAgc3RhdGlj
IHN0cnVjdCBhdHRyaWJ1dGVfZ3JvdXAgZmFtMTVoX3Bvd2VyX2dyb3VwOwo+ID4gIF9fQVRUUklC
VVRFX0dST1VQUyhmYW0xNWhfcG93ZXIpOwo+ID4gIAo+ID4gK3N0YXRpYyBzc2l6ZV90IHNob3df
cG93ZXJfYWNjKHN0cnVjdCBkZXZpY2UgKmRldiwKPiA+ICsJCQkgICAgICBzdHJ1Y3QgZGV2aWNl
X2F0dHJpYnV0ZSAqYXR0ciwgY2hhciAqYnVmKQo+ID4gK3sKPiA+ICsJaW50IGNwdSwgY3UsIGN1
X251bSwgY29yZXNfcGVyX2N1Owo+ID4gKwl1NjQgY3Vycl9jdV9hY2NfcG93ZXJbTUFYX0NVU10s
Cj4gPiArCSAgICBjdXJyX3B0c2NbTUFYX0NVU10sIGpkZWx0YVtNQVhfQ1VTXTsKPiA+ICsJdTY0
IHRkZWx0YSwgYXZnX2FjYzsKPiA+ICsJc3RydWN0IGZhbTE1aF9wb3dlcl9kYXRhICpkYXRhID0g
ZGV2X2dldF9kcnZkYXRhKGRldik7Cj4gPiArCj4gPiArCWNvcmVzX3Blcl9jdSA9IGFtZF9nZXRf
Y29yZXNfcGVyX2N1KCk7Cj4gPiArCWN1X251bSA9IGJvb3RfY3B1X2RhdGEueDg2X21heF9jb3Jl
cyAvIGNvcmVzX3Blcl9jdTsKPiA+ICsKPiA+ICsJZm9yIChjcHUgPSAwLCBhdmdfYWNjID0gMDsg
Y3B1IDwgY3VfbnVtICogY29yZXNfcGVyX2N1OyBjcHUgKz0gY29yZXNfcGVyX2N1KSB7Cj4gPiAr
CQljdSA9IGNwdSAvIGNvcmVzX3Blcl9jdTsKPiA+ICsJCWlmIChyZG1zcmxfc2FmZV9vbl9jcHUo
Y3B1LCBNU1JfRjE1SF9QVFNDLCAmY3Vycl9wdHNjW2N1XSkpIHsKPiA+ICsJCQlwcl9lcnIoIkZh
aWxlZCB0byByZWFkIFBUU0MgY291bnRlciBNU1Igb24gY29yZSVkXG4iLAo+ID4gKwkJCSAgICAg
ICBjcHUpOwo+ID4gKwkJCXJldHVybiAwOwo+ID4gKwkJfQo+ID4gKwo+ID4gKwkJaWYgKHJkbXNy
bF9zYWZlX29uX2NwdShjcHUsIE1TUl9GMTVIX0NVX1BXUl9BQ0NVTVVMQVRPUiwKPiA+ICsJCQkJ
ICAgICAgICZjdXJyX2N1X2FjY19wb3dlcltjdV0pKSB7Cj4gPiArCQkJcHJfZXJyKCJGYWlsZWQg
dG8gcmVhZCBjb21wdXRlIHVuaXQgcG93ZXIgYWNjdW11bGF0b3IgTVNSIG9uIGNvcmUlZFxuIiwK
PiA+ICsJCQkgICAgICAgY3B1KTsKPiA+ICsJCQlyZXR1cm4gMDsKPiA+ICsJCX0KPiA+ICsKPiA+
ICsJCWlmIChjdXJyX2N1X2FjY19wb3dlcltjdV0gPCBkYXRhLT5jdV9hY2NfcG93ZXJbY3VdKSB7
Cj4gPiArCQkJamRlbHRhW2N1XSA9IGRhdGEtPm1heF9jdV9hY2NfcG93ZXIgKyBjdXJyX2N1X2Fj
Y19wb3dlcltjdV07Cj4gPiArCQkJamRlbHRhW2N1XSAtPSBkYXRhLT5jdV9hY2NfcG93ZXJbY3Vd
Owo+ID4gKwkJfSBlbHNlIHsKPiA+ICsJCQlqZGVsdGFbY3VdID0gY3Vycl9jdV9hY2NfcG93ZXJb
Y3VdIC0gZGF0YS0+Y3VfYWNjX3Bvd2VyW2N1XTsKPiA+ICsJCX0KPiA+ICsJCXRkZWx0YSA9IGN1
cnJfcHRzY1tjdV0gLSBkYXRhLT5jcHVfc3dfcHdyX3B0c2NbY3VdOwo+ID4gKwkJamRlbHRhW2N1
XSAqPSBkYXRhLT5jcHVfcHdyX3NhbXBsZV9yYXRpbyAqIDEwMDA7Cj4gPiArCQlkb19kaXYoamRl
bHRhW2N1XSwgdGRlbHRhKTsKPiA+ICsKPiA+ICsJCW11dGV4X2xvY2soJmRhdGEtPmFjY19wd3Jf
bXV0ZXgpOwo+ID4gKwkJZGF0YS0+Y3VfYWNjX3Bvd2VyW2N1XSA9IGN1cnJfY3VfYWNjX3Bvd2Vy
W2N1XTsKPiA+ICsJCWRhdGEtPmNwdV9zd19wd3JfcHRzY1tjdV0gPSBjdXJyX3B0c2NbY3VdOwo+
ID4gKwkJbXV0ZXhfdW5sb2NrKCZkYXRhLT5hY2NfcHdyX211dGV4KTsKPiA+ICsKPiA+ICsJCS8q
IHRoZSB1bml0IGlzIG1pY3JvV2F0dCAqLwo+ID4gKwkJYXZnX2FjYyArPSBqZGVsdGFbY3VdOwo+
ID4gKwl9Cj4gPiArCj4gPiArCXJldHVybiBzcHJpbnRmKGJ1ZiwgIiV1XG4iLCAodW5zaWduZWQg
aW50KSBhdmdfYWNjKTsKPiA+ICt9Cj4gPiArc3RhdGljIERFVklDRV9BVFRSKHBvd2VyMV9hY2Ms
IFNfSVJVR08sIHNob3dfcG93ZXJfYWNjLCBOVUxMKTsKPiAKPiBJIGFtIG5vdCByZWFsbHkgYSBm
cmllbmQgb2YgaW50cm9kdWNpbmcgYSBub24tc3RhbmRhcmQgYXR0cmlidXRlLgo+IERvZXMgdGhl
IGVuZXJneSBhdHRyaWJ1dGUgbm90IHdvcmsgaGVyZSA/Cj4gCgpZb3UncmUgcmlnaHQuIE5vbi1z
dGFuZGFyZCBhdHRyaWJ1dGUgbWlnaHQgbm90IGJlIGdvb2QuIENvdWxkIHlvdQpwbGVhc2UgZ2l2
ZSBtZSBzb21lIGhpbnRzIGlmIEkgdXNlICJlbmVyZ3kiIGluc3RlYWQ/CgpUaGFua3MsClJ1aQoK
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KbG0tc2Vuc29y
cyBtYWlsaW5nIGxpc3QKbG0tc2Vuc29yc0BsbS1zZW5zb3JzLm9yZwpodHRwOi8vbGlzdHMubG0t
c2Vuc29ycy5vcmcvbWFpbG1hbi9saXN0aW5mby9sbS1zZW5zb3Jz

Re: [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algorithm

[Guenter Roeck]

On 08/28/2015 03:45 AM, Huang Rui wrote:
> On Thu, Aug 27, 2015 at 10:30:43AM -0700, Guenter Roeck wrote:
>> On Thu, Aug 27, 2015 at 04:07:43PM +0800, Huang Rui wrote:
>>> This patch introduces an algorithm that computes the average power by
>>> reading a delta value of “core power accumulator” register during
>>> measurement interval, and then dividing delta value by the length of
>>> the time interval.
>>>
>>> User is able to use power1_acc entry to measure the processor power
>>> consumption and power1_acc just needs to be read twice with an needed
>>> interval in-between.
>>>
>>> A simple example:
>>>
>>> $ cat /sys/bus/pci/devices/0000\:00\:18.4/hwmon/hwmon0/power1_acc
>>> $ sleep 10000s
>>> $ cat /sys/bus/pci/devices/0000\:00\:18.4/hwmon/hwmon0/power1_acc
>>>
>>> The result is current average processor power consumption in 10000
>>> seconds. The unit of the result is uWatt.
>>>
>>> Signed-off-by: Huang Rui <ray.huang@amd.com>
>>> ---
>>>   drivers/hwmon/fam15h_power.c | 62 ++++++++++++++++++++++++++++++++++++++++++++
>>>   1 file changed, 62 insertions(+)
>>>
>>> diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
>>> index d529e4b..3bab797 100644
>>> --- a/drivers/hwmon/fam15h_power.c
>>> +++ b/drivers/hwmon/fam15h_power.c
>>> @@ -60,6 +60,7 @@ struct fam15h_power_data {
>>>   	u64 cu_acc_power[MAX_CUS];
>>>   	/* performance timestamp counter */
>>>   	u64 cpu_sw_pwr_ptsc[MAX_CUS];
>>> +	struct mutex acc_pwr_mutex;
>>>   };
>>>
>>>   static ssize_t show_power(struct device *dev,
>>> @@ -121,17 +122,74 @@ static DEVICE_ATTR(power1_crit, S_IRUGO, show_power_crit, NULL);
>>>   static struct attribute_group fam15h_power_group;
>>>   __ATTRIBUTE_GROUPS(fam15h_power);
>>>
>>> +static ssize_t show_power_acc(struct device *dev,
>>> +			      struct device_attribute *attr, char *buf)
>>> +{
>>> +	int cpu, cu, cu_num, cores_per_cu;
>>> +	u64 curr_cu_acc_power[MAX_CUS],
>>> +	    curr_ptsc[MAX_CUS], jdelta[MAX_CUS];
>>> +	u64 tdelta, avg_acc;
>>> +	struct fam15h_power_data *data = dev_get_drvdata(dev);
>>> +
>>> +	cores_per_cu = amd_get_cores_per_cu();
>>> +	cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
>>> +
>>> +	for (cpu = 0, avg_acc = 0; cpu < cu_num * cores_per_cu; cpu += cores_per_cu) {
>>> +		cu = cpu / cores_per_cu;
>>> +		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_PTSC, &curr_ptsc[cu])) {
>>> +			pr_err("Failed to read PTSC counter MSR on core%d\n",
>>> +			       cpu);
>>> +			return 0;
>>> +		}
>>> +
>>> +		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_CU_PWR_ACCUMULATOR,
>>> +				       &curr_cu_acc_power[cu])) {
>>> +			pr_err("Failed to read compute unit power accumulator MSR on core%d\n",
>>> +			       cpu);
>>> +			return 0;
>>> +		}
>>> +
>>> +		if (curr_cu_acc_power[cu] < data->cu_acc_power[cu]) {
>>> +			jdelta[cu] = data->max_cu_acc_power + curr_cu_acc_power[cu];
>>> +			jdelta[cu] -= data->cu_acc_power[cu];
>>> +		} else {
>>> +			jdelta[cu] = curr_cu_acc_power[cu] - data->cu_acc_power[cu];
>>> +		}
>>> +		tdelta = curr_ptsc[cu] - data->cpu_sw_pwr_ptsc[cu];
>>> +		jdelta[cu] *= data->cpu_pwr_sample_ratio * 1000;
>>> +		do_div(jdelta[cu], tdelta);
>>> +
>>> +		mutex_lock(&data->acc_pwr_mutex);
>>> +		data->cu_acc_power[cu] = curr_cu_acc_power[cu];
>>> +		data->cpu_sw_pwr_ptsc[cu] = curr_ptsc[cu];
>>> +		mutex_unlock(&data->acc_pwr_mutex);
>>> +
>>> +		/* the unit is microWatt */
>>> +		avg_acc += jdelta[cu];
>>> +	}
>>> +
>>> +	return sprintf(buf, "%u\n", (unsigned int) avg_acc);
>>> +}
>>> +static DEVICE_ATTR(power1_acc, S_IRUGO, show_power_acc, NULL);
>>
>> I am not really a friend of introducing a non-standard attribute.
>> Does the energy attribute not work here ?
>>
>
> You're right. Non-standard attribute might not be good. Could you
> please give me some hints if I use "energy" instead?
>
1 Joule = 1 Watt-second.

Something else, though - did you make sure that your code doesn't overflow ?
Even though you calculate the average in an u64, you display it as unsigned.

100w * 10,000s = 1,000,000ws = 1,000,000,000,000 micro-watt-seconds, which is
a bit large for an unsigned.

Also, the values should not be reset after reading, but accumulate.

Also, I think your code may be vulnerable to overflows on the CPU register side.
How long does it take before the CPU counters overflow ?

Thanks,
Guenter

Re: [lm-sensors] [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algo

[Guenter Roeck]

T24gMDgvMjgvMjAxNSAwMzo0NSBBTSwgSHVhbmcgUnVpIHdyb3RlOgo+IE9uIFRodSwgQXVnIDI3
LCAyMDE1IGF0IDEwOjMwOjQzQU0gLTA3MDAsIEd1ZW50ZXIgUm9lY2sgd3JvdGU6Cj4+IE9uIFRo
dSwgQXVnIDI3LCAyMDE1IGF0IDA0OjA3OjQzUE0gKzA4MDAsIEh1YW5nIFJ1aSB3cm90ZToKPj4+
IFRoaXMgcGF0Y2ggaW50cm9kdWNlcyBhbiBhbGdvcml0aG0gdGhhdCBjb21wdXRlcyB0aGUgYXZl
cmFnZSBwb3dlciBieQo+Pj4gcmVhZGluZyBhIGRlbHRhIHZhbHVlIG9mIOKAnGNvcmUgcG93ZXIg
YWNjdW11bGF0b3LigJ0gcmVnaXN0ZXIgZHVyaW5nCj4+PiBtZWFzdXJlbWVudCBpbnRlcnZhbCwg
YW5kIHRoZW4gZGl2aWRpbmcgZGVsdGEgdmFsdWUgYnkgdGhlIGxlbmd0aCBvZgo+Pj4gdGhlIHRp
bWUgaW50ZXJ2YWwuCj4+Pgo+Pj4gVXNlciBpcyBhYmxlIHRvIHVzZSBwb3dlcjFfYWNjIGVudHJ5
IHRvIG1lYXN1cmUgdGhlIHByb2Nlc3NvciBwb3dlcgo+Pj4gY29uc3VtcHRpb24gYW5kIHBvd2Vy
MV9hY2MganVzdCBuZWVkcyB0byBiZSByZWFkIHR3aWNlIHdpdGggYW4gbmVlZGVkCj4+PiBpbnRl
cnZhbCBpbi1iZXR3ZWVuLgo+Pj4KPj4+IEEgc2ltcGxlIGV4YW1wbGU6Cj4+Pgo+Pj4gJCBjYXQg
L3N5cy9idXMvcGNpL2RldmljZXMvMDAwMFw6MDBcOjE4LjQvaHdtb24vaHdtb24wL3Bvd2VyMV9h
Y2MKPj4+ICQgc2xlZXAgMTAwMDBzCj4+PiAkIGNhdCAvc3lzL2J1cy9wY2kvZGV2aWNlcy8wMDAw
XDowMFw6MTguNC9od21vbi9od21vbjAvcG93ZXIxX2FjYwo+Pj4KPj4+IFRoZSByZXN1bHQgaXMg
Y3VycmVudCBhdmVyYWdlIHByb2Nlc3NvciBwb3dlciBjb25zdW1wdGlvbiBpbiAxMDAwMAo+Pj4g
c2Vjb25kcy4gVGhlIHVuaXQgb2YgdGhlIHJlc3VsdCBpcyB1V2F0dC4KPj4+Cj4+PiBTaWduZWQt
b2ZmLWJ5OiBIdWFuZyBSdWkgPHJheS5odWFuZ0BhbWQuY29tPgo+Pj4gLS0tCj4+PiAgIGRyaXZl
cnMvaHdtb24vZmFtMTVoX3Bvd2VyLmMgfCA2MiArKysrKysrKysrKysrKysrKysrKysrKysrKysr
KysrKysrKysrKysrKysrKwo+Pj4gICAxIGZpbGUgY2hhbmdlZCwgNjIgaW5zZXJ0aW9ucygrKQo+
Pj4KPj4+IGRpZmYgLS1naXQgYS9kcml2ZXJzL2h3bW9uL2ZhbTE1aF9wb3dlci5jIGIvZHJpdmVy
cy9od21vbi9mYW0xNWhfcG93ZXIuYwo+Pj4gaW5kZXggZDUyOWU0Yi4uM2JhYjc5NyAxMDA2NDQK
Pj4+IC0tLSBhL2RyaXZlcnMvaHdtb24vZmFtMTVoX3Bvd2VyLmMKPj4+ICsrKyBiL2RyaXZlcnMv
aHdtb24vZmFtMTVoX3Bvd2VyLmMKPj4+IEBAIC02MCw2ICs2MCw3IEBAIHN0cnVjdCBmYW0xNWhf
cG93ZXJfZGF0YSB7Cj4+PiAgIAl1NjQgY3VfYWNjX3Bvd2VyW01BWF9DVVNdOwo+Pj4gICAJLyog
cGVyZm9ybWFuY2UgdGltZXN0YW1wIGNvdW50ZXIgKi8KPj4+ICAgCXU2NCBjcHVfc3dfcHdyX3B0
c2NbTUFYX0NVU107Cj4+PiArCXN0cnVjdCBtdXRleCBhY2NfcHdyX211dGV4Owo+Pj4gICB9Owo+
Pj4KPj4+ICAgc3RhdGljIHNzaXplX3Qgc2hvd19wb3dlcihzdHJ1Y3QgZGV2aWNlICpkZXYsCj4+
PiBAQCAtMTIxLDE3ICsxMjIsNzQgQEAgc3RhdGljIERFVklDRV9BVFRSKHBvd2VyMV9jcml0LCBT
X0lSVUdPLCBzaG93X3Bvd2VyX2NyaXQsIE5VTEwpOwo+Pj4gICBzdGF0aWMgc3RydWN0IGF0dHJp
YnV0ZV9ncm91cCBmYW0xNWhfcG93ZXJfZ3JvdXA7Cj4+PiAgIF9fQVRUUklCVVRFX0dST1VQUyhm
YW0xNWhfcG93ZXIpOwo+Pj4KPj4+ICtzdGF0aWMgc3NpemVfdCBzaG93X3Bvd2VyX2FjYyhzdHJ1
Y3QgZGV2aWNlICpkZXYsCj4+PiArCQkJICAgICAgc3RydWN0IGRldmljZV9hdHRyaWJ1dGUgKmF0
dHIsIGNoYXIgKmJ1ZikKPj4+ICt7Cj4+PiArCWludCBjcHUsIGN1LCBjdV9udW0sIGNvcmVzX3Bl
cl9jdTsKPj4+ICsJdTY0IGN1cnJfY3VfYWNjX3Bvd2VyW01BWF9DVVNdLAo+Pj4gKwkgICAgY3Vy
cl9wdHNjW01BWF9DVVNdLCBqZGVsdGFbTUFYX0NVU107Cj4+PiArCXU2NCB0ZGVsdGEsIGF2Z19h
Y2M7Cj4+PiArCXN0cnVjdCBmYW0xNWhfcG93ZXJfZGF0YSAqZGF0YSA9IGRldl9nZXRfZHJ2ZGF0
YShkZXYpOwo+Pj4gKwo+Pj4gKwljb3Jlc19wZXJfY3UgPSBhbWRfZ2V0X2NvcmVzX3Blcl9jdSgp
Owo+Pj4gKwljdV9udW0gPSBib290X2NwdV9kYXRhLng4Nl9tYXhfY29yZXMgLyBjb3Jlc19wZXJf
Y3U7Cj4+PiArCj4+PiArCWZvciAoY3B1ID0gMCwgYXZnX2FjYyA9IDA7IGNwdSA8IGN1X251bSAq
IGNvcmVzX3Blcl9jdTsgY3B1ICs9IGNvcmVzX3Blcl9jdSkgewo+Pj4gKwkJY3UgPSBjcHUgLyBj
b3Jlc19wZXJfY3U7Cj4+PiArCQlpZiAocmRtc3JsX3NhZmVfb25fY3B1KGNwdSwgTVNSX0YxNUhf
UFRTQywgJmN1cnJfcHRzY1tjdV0pKSB7Cj4+PiArCQkJcHJfZXJyKCJGYWlsZWQgdG8gcmVhZCBQ
VFNDIGNvdW50ZXIgTVNSIG9uIGNvcmUlZFxuIiwKPj4+ICsJCQkgICAgICAgY3B1KTsKPj4+ICsJ
CQlyZXR1cm4gMDsKPj4+ICsJCX0KPj4+ICsKPj4+ICsJCWlmIChyZG1zcmxfc2FmZV9vbl9jcHUo
Y3B1LCBNU1JfRjE1SF9DVV9QV1JfQUNDVU1VTEFUT1IsCj4+PiArCQkJCSAgICAgICAmY3Vycl9j
dV9hY2NfcG93ZXJbY3VdKSkgewo+Pj4gKwkJCXByX2VycigiRmFpbGVkIHRvIHJlYWQgY29tcHV0
ZSB1bml0IHBvd2VyIGFjY3VtdWxhdG9yIE1TUiBvbiBjb3JlJWRcbiIsCj4+PiArCQkJICAgICAg
IGNwdSk7Cj4+PiArCQkJcmV0dXJuIDA7Cj4+PiArCQl9Cj4+PiArCj4+PiArCQlpZiAoY3Vycl9j
dV9hY2NfcG93ZXJbY3VdIDwgZGF0YS0+Y3VfYWNjX3Bvd2VyW2N1XSkgewo+Pj4gKwkJCWpkZWx0
YVtjdV0gPSBkYXRhLT5tYXhfY3VfYWNjX3Bvd2VyICsgY3Vycl9jdV9hY2NfcG93ZXJbY3VdOwo+
Pj4gKwkJCWpkZWx0YVtjdV0gLT0gZGF0YS0+Y3VfYWNjX3Bvd2VyW2N1XTsKPj4+ICsJCX0gZWxz
ZSB7Cj4+PiArCQkJamRlbHRhW2N1XSA9IGN1cnJfY3VfYWNjX3Bvd2VyW2N1XSAtIGRhdGEtPmN1
X2FjY19wb3dlcltjdV07Cj4+PiArCQl9Cj4+PiArCQl0ZGVsdGEgPSBjdXJyX3B0c2NbY3VdIC0g
ZGF0YS0+Y3B1X3N3X3B3cl9wdHNjW2N1XTsKPj4+ICsJCWpkZWx0YVtjdV0gKj0gZGF0YS0+Y3B1
X3B3cl9zYW1wbGVfcmF0aW8gKiAxMDAwOwo+Pj4gKwkJZG9fZGl2KGpkZWx0YVtjdV0sIHRkZWx0
YSk7Cj4+PiArCj4+PiArCQltdXRleF9sb2NrKCZkYXRhLT5hY2NfcHdyX211dGV4KTsKPj4+ICsJ
CWRhdGEtPmN1X2FjY19wb3dlcltjdV0gPSBjdXJyX2N1X2FjY19wb3dlcltjdV07Cj4+PiArCQlk
YXRhLT5jcHVfc3dfcHdyX3B0c2NbY3VdID0gY3Vycl9wdHNjW2N1XTsKPj4+ICsJCW11dGV4X3Vu
bG9jaygmZGF0YS0+YWNjX3B3cl9tdXRleCk7Cj4+PiArCj4+PiArCQkvKiB0aGUgdW5pdCBpcyBt
aWNyb1dhdHQgKi8KPj4+ICsJCWF2Z19hY2MgKz0gamRlbHRhW2N1XTsKPj4+ICsJfQo+Pj4gKwo+
Pj4gKwlyZXR1cm4gc3ByaW50ZihidWYsICIldVxuIiwgKHVuc2lnbmVkIGludCkgYXZnX2FjYyk7
Cj4+PiArfQo+Pj4gK3N0YXRpYyBERVZJQ0VfQVRUUihwb3dlcjFfYWNjLCBTX0lSVUdPLCBzaG93
X3Bvd2VyX2FjYywgTlVMTCk7Cj4+Cj4+IEkgYW0gbm90IHJlYWxseSBhIGZyaWVuZCBvZiBpbnRy
b2R1Y2luZyBhIG5vbi1zdGFuZGFyZCBhdHRyaWJ1dGUuCj4+IERvZXMgdGhlIGVuZXJneSBhdHRy
aWJ1dGUgbm90IHdvcmsgaGVyZSA/Cj4+Cj4KPiBZb3UncmUgcmlnaHQuIE5vbi1zdGFuZGFyZCBh
dHRyaWJ1dGUgbWlnaHQgbm90IGJlIGdvb2QuIENvdWxkIHlvdQo+IHBsZWFzZSBnaXZlIG1lIHNv
bWUgaGludHMgaWYgSSB1c2UgImVuZXJneSIgaW5zdGVhZD8KPgoxIEpvdWxlID0gMSBXYXR0LXNl
Y29uZC4KClNvbWV0aGluZyBlbHNlLCB0aG91Z2ggLSBkaWQgeW91IG1ha2Ugc3VyZSB0aGF0IHlv
dXIgY29kZSBkb2Vzbid0IG92ZXJmbG93ID8KRXZlbiB0aG91Z2ggeW91IGNhbGN1bGF0ZSB0aGUg
YXZlcmFnZSBpbiBhbiB1NjQsIHlvdSBkaXNwbGF5IGl0IGFzIHVuc2lnbmVkLgoKMTAwdyAqIDEw
LDAwMHMgPSAxLDAwMCwwMDB3cyA9IDEsMDAwLDAwMCwwMDAsMDAwIG1pY3JvLXdhdHQtc2Vjb25k
cywgd2hpY2ggaXMKYSBiaXQgbGFyZ2UgZm9yIGFuIHVuc2lnbmVkLgoKQWxzbywgdGhlIHZhbHVl
cyBzaG91bGQgbm90IGJlIHJlc2V0IGFmdGVyIHJlYWRpbmcsIGJ1dCBhY2N1bXVsYXRlLgoKQWxz
bywgSSB0aGluayB5b3VyIGNvZGUgbWF5IGJlIHZ1bG5lcmFibGUgdG8gb3ZlcmZsb3dzIG9uIHRo
ZSBDUFUgcmVnaXN0ZXIgc2lkZS4KSG93IGxvbmcgZG9lcyBpdCB0YWtlIGJlZm9yZSB0aGUgQ1BV
IGNvdW50ZXJzIG92ZXJmbG93ID8KClRoYW5rcywKR3VlbnRlcgoKCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxtLXNlbnNvcnMgbWFpbGluZyBsaXN0Cmxt
LXNlbnNvcnNAbG0tc2Vuc29ycy5vcmcKaHR0cDovL2xpc3RzLmxtLXNlbnNvcnMub3JnL21haWxt
YW4vbGlzdGluZm8vbG0tc2Vuc29ycw=

Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Ingo Molnar]

* Ingo Molnar <mingo@kernel.org> wrote:

> 
> * Borislav Petkov <bp@alien8.de> wrote:
> 
> > On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
> > > Add an accessor function amd_get_cores_per_cu() which returns the
> > > number of cores per compute unit.
> > > 
> > > In a subsequent patch, we will use this function in fam15h_power
> > > driver.
> > > 
> > > Signed-off-by: Huang Rui <ray.huang@amd.com>
> > > ---
> > >  arch/x86/include/asm/processor.h |  1 +
> > >  arch/x86/kernel/cpu/amd.c        | 19 +++++++++++++++++--
> > >  2 files changed, 18 insertions(+), 2 deletions(-)
> > 
> > Btw, this needs an ACK from a tip person if it goes through the hwmon
> > tree.
> 
> Looks good to me in theory.
> 
> I suspect we might want to factor the 'compute unit' logic out a bit more if usage 
> becomes more widespread - but right now it's hwmon drivers only,right?

So let me withdraw my ack: the much more important question that I missed first 
time around, why is this reporting feature living in hwmon, not in perf? We have 
energy reporting facilities in perf that this should be synced to.

Thanks,

	Ingo

Re: [lm-sensors] [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Ingo Molnar]

* Ingo Molnar <mingo@kernel.org> wrote:

> 
> * Borislav Petkov <bp@alien8.de> wrote:
> 
> > On Thu, Aug 27, 2015 at 04:07:40PM +0800, Huang Rui wrote:
> > > Add an accessor function amd_get_cores_per_cu() which returns the
> > > number of cores per compute unit.
> > > 
> > > In a subsequent patch, we will use this function in fam15h_power
> > > driver.
> > > 
> > > Signed-off-by: Huang Rui <ray.huang@amd.com>
> > > ---
> > >  arch/x86/include/asm/processor.h |  1 +
> > >  arch/x86/kernel/cpu/amd.c        | 19 +++++++++++++++++--
> > >  2 files changed, 18 insertions(+), 2 deletions(-)
> > 
> > Btw, this needs an ACK from a tip person if it goes through the hwmon
> > tree.
> 
> Looks good to me in theory.
> 
> I suspect we might want to factor the 'compute unit' logic out a bit more if usage 
> becomes more widespread - but right now it's hwmon drivers only,right?

So let me withdraw my ack: the much more important question that I missed first 
time around, why is this reporting feature living in hwmon, not in perf? We have 
energy reporting facilities in perf that this should be synced to.

Thanks,

	Ingo

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [15/15] MAINTAINERS: change the maintainer of fam15h_power driver

[Guenter Roeck]

On Thu, Aug 27, 2015 at 04:07:46PM +0800, Huang Rui wrote:
> Andreas Herrmann won't take the maintainer of fam15h_power driver. I
> will take it and appreciate him for the great contributions on this
> driver.
> 
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>

Please add Andreas to CREDITS.

Andreas, can you Ack this change ?

Thanks,
Guenter

> ---
>  MAINTAINERS | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 941d7b7..241d45e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -601,9 +601,9 @@ F:	drivers/crypto/ccp/
>  F:	include/linux/ccp.h
>  
>  AMD FAM15H PROCESSOR POWER MONITORING DRIVER
> -M:	Andreas Herrmann <herrmann.der.user@googlemail.com>
> +M:	Huang Rui <ray.huang@amd.com>
>  L:	lm-sensors@lm-sensors.org
> -S:	Maintained
> +S:	Supported
>  F:	Documentation/hwmon/fam15h_power
>  F:	drivers/hwmon/fam15h_power.c
>  

Re: [lm-sensors] [15/15] MAINTAINERS: change the maintainer of fam15h_power driver

[Guenter Roeck]

On Thu, Aug 27, 2015 at 04:07:46PM +0800, Huang Rui wrote:
> Andreas Herrmann won't take the maintainer of fam15h_power driver. I
> will take it and appreciate him for the great contributions on this
> driver.
> 
> Signed-off-by: Huang Rui <ray.huang@amd.com>
> Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>

Please add Andreas to CREDITS.

Andreas, can you Ack this change ?

Thanks,
Guenter

> ---
>  MAINTAINERS | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 941d7b7..241d45e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -601,9 +601,9 @@ F:	drivers/crypto/ccp/
>  F:	include/linux/ccp.h
>  
>  AMD FAM15H PROCESSOR POWER MONITORING DRIVER
> -M:	Andreas Herrmann <herrmann.der.user@googlemail.com>
> +M:	Huang Rui <ray.huang@amd.com>
>  L:	lm-sensors@lm-sensors.org
> -S:	Maintained
> +S:	Supported
>  F:	Documentation/hwmon/fam15h_power
>  F:	drivers/hwmon/fam15h_power.c
>  

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Borislav Petkov]

On Sat, Aug 29, 2015 at 11:19:14AM +0200, Ingo Molnar wrote:
> So let me withdraw my ack: the much more important question that I
> missed first time around, why is this reporting feature living in
> hwmon, not in perf? We have energy reporting facilities in perf that
> this should be synced to.

Because there's already fam15h_power driver which is exactly for that.
Making it part of perf is then a question of cat-ting the same sysfs
file twice, at the beginning and at the end of the trace, which is
trivial.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [lm-sensors] [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Borislav Petkov]

On Sat, Aug 29, 2015 at 11:19:14AM +0200, Ingo Molnar wrote:
> So let me withdraw my ack: the much more important question that I
> missed first time around, why is this reporting feature living in
> hwmon, not in perf? We have energy reporting facilities in perf that
> this should be synced to.

Because there's already fam15h_power driver which is exactly for that.
Making it part of perf is then a question of cat-ting the same sysfs
file twice, at the beginning and at the end of the trace, which is
trivial.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [15/15] MAINTAINERS: change the maintainer of fam15h_power driver

[Huang Rui]

On Sat, Aug 29, 2015 at 09:33:54AM -0700, Guenter Roeck wrote:
> On Thu, Aug 27, 2015 at 04:07:46PM +0800, Huang Rui wrote:
> > Andreas Herrmann won't take the maintainer of fam15h_power driver. I
> > will take it and appreciate him for the great contributions on this
> > driver.
> > 
> > Signed-off-by: Huang Rui <ray.huang@amd.com>
> > Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
> 
> Please add Andreas to CREDITS.
> 

OK.

N: Andreas Herrmann
E: herrmann.der.user@gmail.com
E: herrmann.der.user@googlemail.com
D: Key developer of x86/AMD64
D: Author of AMD family 15h processor power monintoring driver
D: Maintainer of AMD Athlon 64 and Opteron processor frequency driver
S: Germany

Andreas, Boris, how about above description at CREDITS? Please let me
know if I something is wrong or missed.
BTW, could you give your snail-mail address? I just know Germany :)

Thanks,
Rui

> Andreas, can you Ack this change ?
> 
> Thanks,
> Guenter
> 
> > ---
> >  MAINTAINERS | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 941d7b7..241d45e 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -601,9 +601,9 @@ F:	drivers/crypto/ccp/
> >  F:	include/linux/ccp.h
> >  
> >  AMD FAM15H PROCESSOR POWER MONITORING DRIVER
> > -M:	Andreas Herrmann <herrmann.der.user@googlemail.com>
> > +M:	Huang Rui <ray.huang@amd.com>
> >  L:	lm-sensors@lm-sensors.org
> > -S:	Maintained
> > +S:	Supported
> >  F:	Documentation/hwmon/fam15h_power
> >  F:	drivers/hwmon/fam15h_power.c
> >  

Re: [lm-sensors] [15/15] MAINTAINERS: change the maintainer of fam15h_power driver

[Huang Rui]

On Sat, Aug 29, 2015 at 09:33:54AM -0700, Guenter Roeck wrote:
> On Thu, Aug 27, 2015 at 04:07:46PM +0800, Huang Rui wrote:
> > Andreas Herrmann won't take the maintainer of fam15h_power driver. I
> > will take it and appreciate him for the great contributions on this
> > driver.
> > 
> > Signed-off-by: Huang Rui <ray.huang@amd.com>
> > Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
> 
> Please add Andreas to CREDITS.
> 

OK.

N: Andreas Herrmann
E: herrmann.der.user@gmail.com
E: herrmann.der.user@googlemail.com
D: Key developer of x86/AMD64
D: Author of AMD family 15h processor power monintoring driver
D: Maintainer of AMD Athlon 64 and Opteron processor frequency driver
S: Germany

Andreas, Boris, how about above description at CREDITS? Please let me
know if I something is wrong or missed.
BTW, could you give your snail-mail address? I just know Germany :)

Thanks,
Rui

> Andreas, can you Ack this change ?
> 
> Thanks,
> Guenter
> 
> > ---
> >  MAINTAINERS | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 941d7b7..241d45e 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -601,9 +601,9 @@ F:	drivers/crypto/ccp/
> >  F:	include/linux/ccp.h
> >  
> >  AMD FAM15H PROCESSOR POWER MONITORING DRIVER
> > -M:	Andreas Herrmann <herrmann.der.user@googlemail.com>
> > +M:	Huang Rui <ray.huang@amd.com>
> >  L:	lm-sensors@lm-sensors.org
> > -S:	Maintained
> > +S:	Supported
> >  F:	Documentation/hwmon/fam15h_power
> >  F:	drivers/hwmon/fam15h_power.c
> >  

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algorithm

[Huang Rui]

On Fri, Aug 28, 2015 at 07:05:13AM -0700, Guenter Roeck wrote:
> On 08/28/2015 03:45 AM, Huang Rui wrote:
> >On Thu, Aug 27, 2015 at 10:30:43AM -0700, Guenter Roeck wrote:
> >>On Thu, Aug 27, 2015 at 04:07:43PM +0800, Huang Rui wrote:
> >>>This patch introduces an algorithm that computes the average power by
> >>>reading a delta value of “core power accumulator” register during
> >>>measurement interval, and then dividing delta value by the length of
> >>>the time interval.
> >>>
> >>>User is able to use power1_acc entry to measure the processor power
> >>>consumption and power1_acc just needs to be read twice with an needed
> >>>interval in-between.
> >>>
> >>>A simple example:
> >>>
> >>>$ cat /sys/bus/pci/devices/0000\:00\:18.4/hwmon/hwmon0/power1_acc
> >>>$ sleep 10000s
> >>>$ cat /sys/bus/pci/devices/0000\:00\:18.4/hwmon/hwmon0/power1_acc
> >>>
> >>>The result is current average processor power consumption in 10000
> >>>seconds. The unit of the result is uWatt.
> >>>
> >>>Signed-off-by: Huang Rui <ray.huang@amd.com>
> >>>---
> >>>  drivers/hwmon/fam15h_power.c | 62 ++++++++++++++++++++++++++++++++++++++++++++
> >>>  1 file changed, 62 insertions(+)
> >>>
> >>>diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> >>>index d529e4b..3bab797 100644
> >>>--- a/drivers/hwmon/fam15h_power.c
> >>>+++ b/drivers/hwmon/fam15h_power.c
> >>>@@ -60,6 +60,7 @@ struct fam15h_power_data {
> >>>  	u64 cu_acc_power[MAX_CUS];
> >>>  	/* performance timestamp counter */
> >>>  	u64 cpu_sw_pwr_ptsc[MAX_CUS];
> >>>+	struct mutex acc_pwr_mutex;
> >>>  };
> >>>
> >>>  static ssize_t show_power(struct device *dev,
> >>>@@ -121,17 +122,74 @@ static DEVICE_ATTR(power1_crit, S_IRUGO, show_power_crit, NULL);
> >>>  static struct attribute_group fam15h_power_group;
> >>>  __ATTRIBUTE_GROUPS(fam15h_power);
> >>>
> >>>+static ssize_t show_power_acc(struct device *dev,
> >>>+			      struct device_attribute *attr, char *buf)
> >>>+{
> >>>+	int cpu, cu, cu_num, cores_per_cu;
> >>>+	u64 curr_cu_acc_power[MAX_CUS],
> >>>+	    curr_ptsc[MAX_CUS], jdelta[MAX_CUS];
> >>>+	u64 tdelta, avg_acc;
> >>>+	struct fam15h_power_data *data = dev_get_drvdata(dev);
> >>>+
> >>>+	cores_per_cu = amd_get_cores_per_cu();
> >>>+	cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> >>>+
> >>>+	for (cpu = 0, avg_acc = 0; cpu < cu_num * cores_per_cu; cpu += cores_per_cu) {
> >>>+		cu = cpu / cores_per_cu;
> >>>+		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_PTSC, &curr_ptsc[cu])) {
> >>>+			pr_err("Failed to read PTSC counter MSR on core%d\n",
> >>>+			       cpu);
> >>>+			return 0;
> >>>+		}
> >>>+
> >>>+		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_CU_PWR_ACCUMULATOR,
> >>>+				       &curr_cu_acc_power[cu])) {
> >>>+			pr_err("Failed to read compute unit power accumulator MSR on core%d\n",
> >>>+			       cpu);
> >>>+			return 0;
> >>>+		}
> >>>+
> >>>+		if (curr_cu_acc_power[cu] < data->cu_acc_power[cu]) {
> >>>+			jdelta[cu] = data->max_cu_acc_power + curr_cu_acc_power[cu];
> >>>+			jdelta[cu] -= data->cu_acc_power[cu];
> >>>+		} else {
> >>>+			jdelta[cu] = curr_cu_acc_power[cu] - data->cu_acc_power[cu];
> >>>+		}
> >>>+		tdelta = curr_ptsc[cu] - data->cpu_sw_pwr_ptsc[cu];
> >>>+		jdelta[cu] *= data->cpu_pwr_sample_ratio * 1000;
> >>>+		do_div(jdelta[cu], tdelta);
> >>>+
> >>>+		mutex_lock(&data->acc_pwr_mutex);
> >>>+		data->cu_acc_power[cu] = curr_cu_acc_power[cu];
> >>>+		data->cpu_sw_pwr_ptsc[cu] = curr_ptsc[cu];
> >>>+		mutex_unlock(&data->acc_pwr_mutex);
> >>>+
> >>>+		/* the unit is microWatt */
> >>>+		avg_acc += jdelta[cu];
> >>>+	}
> >>>+
> >>>+	return sprintf(buf, "%u\n", (unsigned int) avg_acc);
> >>>+}
> >>>+static DEVICE_ATTR(power1_acc, S_IRUGO, show_power_acc, NULL);
> >>
> >>I am not really a friend of introducing a non-standard attribute.
> >>Does the energy attribute not work here ?
> >>
> >
> >You're right. Non-standard attribute might not be good. Could you
> >please give me some hints if I use "energy" instead?
> >
> 1 Joule = 1 Watt-second.
> 
> Something else, though - did you make sure that your code doesn't overflow ?
> Even though you calculate the average in an u64, you display it as unsigned.
> 

Thanks to your reminder. It should not be overflow. The maximum power
consumption of processor (AMD CZ and future 15h) is about 15 Watts =
15,000,000 uWatts = 0xE4E1C0 uWatts, the size is 24 < 32 < 64 bits.

Actually, the unit of jdelta is not Joule. Because the tdelta is the
loops (cycles) that PTSC counter (the freqency is about 100 MHz)
counts not seconds.

So avg_acc is the average power consumption not the accumulated energy.

> 100w * 10,000s = 1,000,000ws = 1,000,000,000,000 micro-watt-seconds, which is
> a bit large for an unsigned.
> 
> Also, the values should not be reset after reading, but accumulate.
> 
> Also, I think your code may be vulnerable to overflows on the CPU register side.
> How long does it take before the CPU counters overflow ?
> 

If I use "energy", 15w * 10,000s = 150,000,000,000 microWatt-seconds.
Yes, it's large for an unsigned, but suitable for u64.

The accumulated power of one compute unit is recorded at 64bit MSR.

Let me calculate the extreme case that how long does it take before
overflow:

Use power consumption 15w, max power 2^64 = 1.8 * 10^19
mWatt-ptsc_loops, and PTSC freqency 100 MHz:

        1.8 * 10^19 = (15,000) * (Tmax/Tcycle)
        1.8 * 10^19 = (15,000) * (Tmax * PTSC_Freq)
        1.8 * 10^19 = (15,000) * (Tmax * 100,000,000)
        Tmax = 1.2 * 10^7 seconds

Thanks
Rui

Re: [lm-sensors] [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algo

[Huang Rui]

T24gRnJpLCBBdWcgMjgsIDIwMTUgYXQgMDc6MDU6MTNBTSAtMDcwMCwgR3VlbnRlciBSb2VjayB3
cm90ZToKPiBPbiAwOC8yOC8yMDE1IDAzOjQ1IEFNLCBIdWFuZyBSdWkgd3JvdGU6Cj4gPk9uIFRo
dSwgQXVnIDI3LCAyMDE1IGF0IDEwOjMwOjQzQU0gLTA3MDAsIEd1ZW50ZXIgUm9lY2sgd3JvdGU6
Cj4gPj5PbiBUaHUsIEF1ZyAyNywgMjAxNSBhdCAwNDowNzo0M1BNICswODAwLCBIdWFuZyBSdWkg
d3JvdGU6Cj4gPj4+VGhpcyBwYXRjaCBpbnRyb2R1Y2VzIGFuIGFsZ29yaXRobSB0aGF0IGNvbXB1
dGVzIHRoZSBhdmVyYWdlIHBvd2VyIGJ5Cj4gPj4+cmVhZGluZyBhIGRlbHRhIHZhbHVlIG9mIOKA
nGNvcmUgcG93ZXIgYWNjdW11bGF0b3LigJ0gcmVnaXN0ZXIgZHVyaW5nCj4gPj4+bWVhc3VyZW1l
bnQgaW50ZXJ2YWwsIGFuZCB0aGVuIGRpdmlkaW5nIGRlbHRhIHZhbHVlIGJ5IHRoZSBsZW5ndGgg
b2YKPiA+Pj50aGUgdGltZSBpbnRlcnZhbC4KPiA+Pj4KPiA+Pj5Vc2VyIGlzIGFibGUgdG8gdXNl
IHBvd2VyMV9hY2MgZW50cnkgdG8gbWVhc3VyZSB0aGUgcHJvY2Vzc29yIHBvd2VyCj4gPj4+Y29u
c3VtcHRpb24gYW5kIHBvd2VyMV9hY2MganVzdCBuZWVkcyB0byBiZSByZWFkIHR3aWNlIHdpdGgg
YW4gbmVlZGVkCj4gPj4+aW50ZXJ2YWwgaW4tYmV0d2Vlbi4KPiA+Pj4KPiA+Pj5BIHNpbXBsZSBl
eGFtcGxlOgo+ID4+Pgo+ID4+PiQgY2F0IC9zeXMvYnVzL3BjaS9kZXZpY2VzLzAwMDBcOjAwXDox
OC40L2h3bW9uL2h3bW9uMC9wb3dlcjFfYWNjCj4gPj4+JCBzbGVlcCAxMDAwMHMKPiA+Pj4kIGNh
dCAvc3lzL2J1cy9wY2kvZGV2aWNlcy8wMDAwXDowMFw6MTguNC9od21vbi9od21vbjAvcG93ZXIx
X2FjYwo+ID4+Pgo+ID4+PlRoZSByZXN1bHQgaXMgY3VycmVudCBhdmVyYWdlIHByb2Nlc3NvciBw
b3dlciBjb25zdW1wdGlvbiBpbiAxMDAwMAo+ID4+PnNlY29uZHMuIFRoZSB1bml0IG9mIHRoZSBy
ZXN1bHQgaXMgdVdhdHQuCj4gPj4+Cj4gPj4+U2lnbmVkLW9mZi1ieTogSHVhbmcgUnVpIDxyYXku
aHVhbmdAYW1kLmNvbT4KPiA+Pj4tLS0KPiA+Pj4gIGRyaXZlcnMvaHdtb24vZmFtMTVoX3Bvd2Vy
LmMgfCA2MiArKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKwo+ID4+
PiAgMSBmaWxlIGNoYW5nZWQsIDYyIGluc2VydGlvbnMoKykKPiA+Pj4KPiA+Pj5kaWZmIC0tZ2l0
IGEvZHJpdmVycy9od21vbi9mYW0xNWhfcG93ZXIuYyBiL2RyaXZlcnMvaHdtb24vZmFtMTVoX3Bv
d2VyLmMKPiA+Pj5pbmRleCBkNTI5ZTRiLi4zYmFiNzk3IDEwMDY0NAo+ID4+Pi0tLSBhL2RyaXZl
cnMvaHdtb24vZmFtMTVoX3Bvd2VyLmMKPiA+Pj4rKysgYi9kcml2ZXJzL2h3bW9uL2ZhbTE1aF9w
b3dlci5jCj4gPj4+QEAgLTYwLDYgKzYwLDcgQEAgc3RydWN0IGZhbTE1aF9wb3dlcl9kYXRhIHsK
PiA+Pj4gIAl1NjQgY3VfYWNjX3Bvd2VyW01BWF9DVVNdOwo+ID4+PiAgCS8qIHBlcmZvcm1hbmNl
IHRpbWVzdGFtcCBjb3VudGVyICovCj4gPj4+ICAJdTY0IGNwdV9zd19wd3JfcHRzY1tNQVhfQ1VT
XTsKPiA+Pj4rCXN0cnVjdCBtdXRleCBhY2NfcHdyX211dGV4Owo+ID4+PiAgfTsKPiA+Pj4KPiA+
Pj4gIHN0YXRpYyBzc2l6ZV90IHNob3dfcG93ZXIoc3RydWN0IGRldmljZSAqZGV2LAo+ID4+PkBA
IC0xMjEsMTcgKzEyMiw3NCBAQCBzdGF0aWMgREVWSUNFX0FUVFIocG93ZXIxX2NyaXQsIFNfSVJV
R08sIHNob3dfcG93ZXJfY3JpdCwgTlVMTCk7Cj4gPj4+ICBzdGF0aWMgc3RydWN0IGF0dHJpYnV0
ZV9ncm91cCBmYW0xNWhfcG93ZXJfZ3JvdXA7Cj4gPj4+ICBfX0FUVFJJQlVURV9HUk9VUFMoZmFt
MTVoX3Bvd2VyKTsKPiA+Pj4KPiA+Pj4rc3RhdGljIHNzaXplX3Qgc2hvd19wb3dlcl9hY2Moc3Ry
dWN0IGRldmljZSAqZGV2LAo+ID4+PisJCQkgICAgICBzdHJ1Y3QgZGV2aWNlX2F0dHJpYnV0ZSAq
YXR0ciwgY2hhciAqYnVmKQo+ID4+Pit7Cj4gPj4+KwlpbnQgY3B1LCBjdSwgY3VfbnVtLCBjb3Jl
c19wZXJfY3U7Cj4gPj4+Kwl1NjQgY3Vycl9jdV9hY2NfcG93ZXJbTUFYX0NVU10sCj4gPj4+Kwkg
ICAgY3Vycl9wdHNjW01BWF9DVVNdLCBqZGVsdGFbTUFYX0NVU107Cj4gPj4+Kwl1NjQgdGRlbHRh
LCBhdmdfYWNjOwo+ID4+PisJc3RydWN0IGZhbTE1aF9wb3dlcl9kYXRhICpkYXRhID0gZGV2X2dl
dF9kcnZkYXRhKGRldik7Cj4gPj4+Kwo+ID4+PisJY29yZXNfcGVyX2N1ID0gYW1kX2dldF9jb3Jl
c19wZXJfY3UoKTsKPiA+Pj4rCWN1X251bSA9IGJvb3RfY3B1X2RhdGEueDg2X21heF9jb3JlcyAv
IGNvcmVzX3Blcl9jdTsKPiA+Pj4rCj4gPj4+Kwlmb3IgKGNwdSA9IDAsIGF2Z19hY2MgPSAwOyBj
cHUgPCBjdV9udW0gKiBjb3Jlc19wZXJfY3U7IGNwdSArPSBjb3Jlc19wZXJfY3UpIHsKPiA+Pj4r
CQljdSA9IGNwdSAvIGNvcmVzX3Blcl9jdTsKPiA+Pj4rCQlpZiAocmRtc3JsX3NhZmVfb25fY3B1
KGNwdSwgTVNSX0YxNUhfUFRTQywgJmN1cnJfcHRzY1tjdV0pKSB7Cj4gPj4+KwkJCXByX2Vycigi
RmFpbGVkIHRvIHJlYWQgUFRTQyBjb3VudGVyIE1TUiBvbiBjb3JlJWRcbiIsCj4gPj4+KwkJCSAg
ICAgICBjcHUpOwo+ID4+PisJCQlyZXR1cm4gMDsKPiA+Pj4rCQl9Cj4gPj4+Kwo+ID4+PisJCWlm
IChyZG1zcmxfc2FmZV9vbl9jcHUoY3B1LCBNU1JfRjE1SF9DVV9QV1JfQUNDVU1VTEFUT1IsCj4g
Pj4+KwkJCQkgICAgICAgJmN1cnJfY3VfYWNjX3Bvd2VyW2N1XSkpIHsKPiA+Pj4rCQkJcHJfZXJy
KCJGYWlsZWQgdG8gcmVhZCBjb21wdXRlIHVuaXQgcG93ZXIgYWNjdW11bGF0b3IgTVNSIG9uIGNv
cmUlZFxuIiwKPiA+Pj4rCQkJICAgICAgIGNwdSk7Cj4gPj4+KwkJCXJldHVybiAwOwo+ID4+PisJ
CX0KPiA+Pj4rCj4gPj4+KwkJaWYgKGN1cnJfY3VfYWNjX3Bvd2VyW2N1XSA8IGRhdGEtPmN1X2Fj
Y19wb3dlcltjdV0pIHsKPiA+Pj4rCQkJamRlbHRhW2N1XSA9IGRhdGEtPm1heF9jdV9hY2NfcG93
ZXIgKyBjdXJyX2N1X2FjY19wb3dlcltjdV07Cj4gPj4+KwkJCWpkZWx0YVtjdV0gLT0gZGF0YS0+
Y3VfYWNjX3Bvd2VyW2N1XTsKPiA+Pj4rCQl9IGVsc2Ugewo+ID4+PisJCQlqZGVsdGFbY3VdID0g
Y3Vycl9jdV9hY2NfcG93ZXJbY3VdIC0gZGF0YS0+Y3VfYWNjX3Bvd2VyW2N1XTsKPiA+Pj4rCQl9
Cj4gPj4+KwkJdGRlbHRhID0gY3Vycl9wdHNjW2N1XSAtIGRhdGEtPmNwdV9zd19wd3JfcHRzY1tj
dV07Cj4gPj4+KwkJamRlbHRhW2N1XSAqPSBkYXRhLT5jcHVfcHdyX3NhbXBsZV9yYXRpbyAqIDEw
MDA7Cj4gPj4+KwkJZG9fZGl2KGpkZWx0YVtjdV0sIHRkZWx0YSk7Cj4gPj4+Kwo+ID4+PisJCW11
dGV4X2xvY2soJmRhdGEtPmFjY19wd3JfbXV0ZXgpOwo+ID4+PisJCWRhdGEtPmN1X2FjY19wb3dl
cltjdV0gPSBjdXJyX2N1X2FjY19wb3dlcltjdV07Cj4gPj4+KwkJZGF0YS0+Y3B1X3N3X3B3cl9w
dHNjW2N1XSA9IGN1cnJfcHRzY1tjdV07Cj4gPj4+KwkJbXV0ZXhfdW5sb2NrKCZkYXRhLT5hY2Nf
cHdyX211dGV4KTsKPiA+Pj4rCj4gPj4+KwkJLyogdGhlIHVuaXQgaXMgbWljcm9XYXR0ICovCj4g
Pj4+KwkJYXZnX2FjYyArPSBqZGVsdGFbY3VdOwo+ID4+PisJfQo+ID4+PisKPiA+Pj4rCXJldHVy
biBzcHJpbnRmKGJ1ZiwgIiV1XG4iLCAodW5zaWduZWQgaW50KSBhdmdfYWNjKTsKPiA+Pj4rfQo+
ID4+PitzdGF0aWMgREVWSUNFX0FUVFIocG93ZXIxX2FjYywgU19JUlVHTywgc2hvd19wb3dlcl9h
Y2MsIE5VTEwpOwo+ID4+Cj4gPj5JIGFtIG5vdCByZWFsbHkgYSBmcmllbmQgb2YgaW50cm9kdWNp
bmcgYSBub24tc3RhbmRhcmQgYXR0cmlidXRlLgo+ID4+RG9lcyB0aGUgZW5lcmd5IGF0dHJpYnV0
ZSBub3Qgd29yayBoZXJlID8KPiA+Pgo+ID4KPiA+WW91J3JlIHJpZ2h0LiBOb24tc3RhbmRhcmQg
YXR0cmlidXRlIG1pZ2h0IG5vdCBiZSBnb29kLiBDb3VsZCB5b3UKPiA+cGxlYXNlIGdpdmUgbWUg
c29tZSBoaW50cyBpZiBJIHVzZSAiZW5lcmd5IiBpbnN0ZWFkPwo+ID4KPiAxIEpvdWxlID0gMSBX
YXR0LXNlY29uZC4KPiAKPiBTb21ldGhpbmcgZWxzZSwgdGhvdWdoIC0gZGlkIHlvdSBtYWtlIHN1
cmUgdGhhdCB5b3VyIGNvZGUgZG9lc24ndCBvdmVyZmxvdyA/Cj4gRXZlbiB0aG91Z2ggeW91IGNh
bGN1bGF0ZSB0aGUgYXZlcmFnZSBpbiBhbiB1NjQsIHlvdSBkaXNwbGF5IGl0IGFzIHVuc2lnbmVk
Lgo+IAoKVGhhbmtzIHRvIHlvdXIgcmVtaW5kZXIuIEl0IHNob3VsZCBub3QgYmUgb3ZlcmZsb3cu
IFRoZSBtYXhpbXVtIHBvd2VyCmNvbnN1bXB0aW9uIG9mIHByb2Nlc3NvciAoQU1EIENaIGFuZCBm
dXR1cmUgMTVoKSBpcyBhYm91dCAxNSBXYXR0cyA9CjE1LDAwMCwwMDAgdVdhdHRzID0gMHhFNEUx
QzAgdVdhdHRzLCB0aGUgc2l6ZSBpcyAyNCA8IDMyIDwgNjQgYml0cy4KCkFjdHVhbGx5LCB0aGUg
dW5pdCBvZiBqZGVsdGEgaXMgbm90IEpvdWxlLiBCZWNhdXNlIHRoZSB0ZGVsdGEgaXMgdGhlCmxv
b3BzIChjeWNsZXMpIHRoYXQgUFRTQyBjb3VudGVyICh0aGUgZnJlcWVuY3kgaXMgYWJvdXQgMTAw
IE1IeikKY291bnRzIG5vdCBzZWNvbmRzLgoKU28gYXZnX2FjYyBpcyB0aGUgYXZlcmFnZSBwb3dl
ciBjb25zdW1wdGlvbiBub3QgdGhlIGFjY3VtdWxhdGVkIGVuZXJneS4KCj4gMTAwdyAqIDEwLDAw
MHMgPSAxLDAwMCwwMDB3cyA9IDEsMDAwLDAwMCwwMDAsMDAwIG1pY3JvLXdhdHQtc2Vjb25kcywg
d2hpY2ggaXMKPiBhIGJpdCBsYXJnZSBmb3IgYW4gdW5zaWduZWQuCj4gCj4gQWxzbywgdGhlIHZh
bHVlcyBzaG91bGQgbm90IGJlIHJlc2V0IGFmdGVyIHJlYWRpbmcsIGJ1dCBhY2N1bXVsYXRlLgo+
IAo+IEFsc28sIEkgdGhpbmsgeW91ciBjb2RlIG1heSBiZSB2dWxuZXJhYmxlIHRvIG92ZXJmbG93
cyBvbiB0aGUgQ1BVIHJlZ2lzdGVyIHNpZGUuCj4gSG93IGxvbmcgZG9lcyBpdCB0YWtlIGJlZm9y
ZSB0aGUgQ1BVIGNvdW50ZXJzIG92ZXJmbG93ID8KPiAKCklmIEkgdXNlICJlbmVyZ3kiLCAxNXcg
KiAxMCwwMDBzID0gMTUwLDAwMCwwMDAsMDAwIG1pY3JvV2F0dC1zZWNvbmRzLgpZZXMsIGl0J3Mg
bGFyZ2UgZm9yIGFuIHVuc2lnbmVkLCBidXQgc3VpdGFibGUgZm9yIHU2NC4KClRoZSBhY2N1bXVs
YXRlZCBwb3dlciBvZiBvbmUgY29tcHV0ZSB1bml0IGlzIHJlY29yZGVkIGF0IDY0Yml0IE1TUi4K
CkxldCBtZSBjYWxjdWxhdGUgdGhlIGV4dHJlbWUgY2FzZSB0aGF0IGhvdyBsb25nIGRvZXMgaXQg
dGFrZSBiZWZvcmUKb3ZlcmZsb3c6CgpVc2UgcG93ZXIgY29uc3VtcHRpb24gMTV3LCBtYXggcG93
ZXIgMl42NCA9IDEuOCAqIDEwXjE5Cm1XYXR0LXB0c2NfbG9vcHMsIGFuZCBQVFNDIGZyZXFlbmN5
IDEwMCBNSHo6CgogICAgICAgIDEuOCAqIDEwXjE5ID0gKDE1LDAwMCkgKiAoVG1heC9UY3ljbGUp
CiAgICAgICAgMS44ICogMTBeMTkgPSAoMTUsMDAwKSAqIChUbWF4ICogUFRTQ19GcmVxKQogICAg
ICAgIDEuOCAqIDEwXjE5ID0gKDE1LDAwMCkgKiAoVG1heCAqIDEwMCwwMDAsMDAwKQogICAgICAg
IFRtYXggPSAxLjIgKiAxMF43IHNlY29uZHMKClRoYW5rcwpSdWkKCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxtLXNlbnNvcnMgbWFpbGluZyBsaXN0Cmxt
LXNlbnNvcnNAbG0tc2Vuc29ycy5vcmcKaHR0cDovL2xpc3RzLmxtLXNlbnNvcnMub3JnL21haWxt
YW4vbGlzdGluZm8vbG0tc2Vuc29ycw=

Re: [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algorithm

[Guenter Roeck]

On 08/30/2015 09:16 PM, Huang Rui wrote:
> On Fri, Aug 28, 2015 at 07:05:13AM -0700, Guenter Roeck wrote:
>> On 08/28/2015 03:45 AM, Huang Rui wrote:
>>> On Thu, Aug 27, 2015 at 10:30:43AM -0700, Guenter Roeck wrote:
>>>> On Thu, Aug 27, 2015 at 04:07:43PM +0800, Huang Rui wrote:
>>>>> This patch introduces an algorithm that computes the average power by
>>>>> reading a delta value of “core power accumulator” register during
>>>>> measurement interval, and then dividing delta value by the length of
>>>>> the time interval.
>>>>>
>>>>> User is able to use power1_acc entry to measure the processor power
>>>>> consumption and power1_acc just needs to be read twice with an needed
>>>>> interval in-between.
>>>>>
>>>>> A simple example:
>>>>>
>>>>> $ cat /sys/bus/pci/devices/0000\:00\:18.4/hwmon/hwmon0/power1_acc
>>>>> $ sleep 10000s
>>>>> $ cat /sys/bus/pci/devices/0000\:00\:18.4/hwmon/hwmon0/power1_acc
>>>>>
>>>>> The result is current average processor power consumption in 10000
>>>>> seconds. The unit of the result is uWatt.
>>>>>
>>>>> Signed-off-by: Huang Rui <ray.huang@amd.com>
>>>>> ---
>>>>>   drivers/hwmon/fam15h_power.c | 62 ++++++++++++++++++++++++++++++++++++++++++++
>>>>>   1 file changed, 62 insertions(+)
>>>>>
>>>>> diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
>>>>> index d529e4b..3bab797 100644
>>>>> --- a/drivers/hwmon/fam15h_power.c
>>>>> +++ b/drivers/hwmon/fam15h_power.c
>>>>> @@ -60,6 +60,7 @@ struct fam15h_power_data {
>>>>>   	u64 cu_acc_power[MAX_CUS];
>>>>>   	/* performance timestamp counter */
>>>>>   	u64 cpu_sw_pwr_ptsc[MAX_CUS];
>>>>> +	struct mutex acc_pwr_mutex;
>>>>>   };
>>>>>
>>>>>   static ssize_t show_power(struct device *dev,
>>>>> @@ -121,17 +122,74 @@ static DEVICE_ATTR(power1_crit, S_IRUGO, show_power_crit, NULL);
>>>>>   static struct attribute_group fam15h_power_group;
>>>>>   __ATTRIBUTE_GROUPS(fam15h_power);
>>>>>
>>>>> +static ssize_t show_power_acc(struct device *dev,
>>>>> +			      struct device_attribute *attr, char *buf)
>>>>> +{
>>>>> +	int cpu, cu, cu_num, cores_per_cu;
>>>>> +	u64 curr_cu_acc_power[MAX_CUS],
>>>>> +	    curr_ptsc[MAX_CUS], jdelta[MAX_CUS];
>>>>> +	u64 tdelta, avg_acc;
>>>>> +	struct fam15h_power_data *data = dev_get_drvdata(dev);
>>>>> +
>>>>> +	cores_per_cu = amd_get_cores_per_cu();
>>>>> +	cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
>>>>> +
>>>>> +	for (cpu = 0, avg_acc = 0; cpu < cu_num * cores_per_cu; cpu += cores_per_cu) {
>>>>> +		cu = cpu / cores_per_cu;
>>>>> +		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_PTSC, &curr_ptsc[cu])) {
>>>>> +			pr_err("Failed to read PTSC counter MSR on core%d\n",
>>>>> +			       cpu);
>>>>> +			return 0;
>>>>> +		}
>>>>> +
>>>>> +		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_CU_PWR_ACCUMULATOR,
>>>>> +				       &curr_cu_acc_power[cu])) {
>>>>> +			pr_err("Failed to read compute unit power accumulator MSR on core%d\n",
>>>>> +			       cpu);
>>>>> +			return 0;
>>>>> +		}
>>>>> +
>>>>> +		if (curr_cu_acc_power[cu] < data->cu_acc_power[cu]) {
>>>>> +			jdelta[cu] = data->max_cu_acc_power + curr_cu_acc_power[cu];
>>>>> +			jdelta[cu] -= data->cu_acc_power[cu];
>>>>> +		} else {
>>>>> +			jdelta[cu] = curr_cu_acc_power[cu] - data->cu_acc_power[cu];
>>>>> +		}
>>>>> +		tdelta = curr_ptsc[cu] - data->cpu_sw_pwr_ptsc[cu];
>>>>> +		jdelta[cu] *= data->cpu_pwr_sample_ratio * 1000;
>>>>> +		do_div(jdelta[cu], tdelta);
>>>>> +
>>>>> +		mutex_lock(&data->acc_pwr_mutex);
>>>>> +		data->cu_acc_power[cu] = curr_cu_acc_power[cu];
>>>>> +		data->cpu_sw_pwr_ptsc[cu] = curr_ptsc[cu];
>>>>> +		mutex_unlock(&data->acc_pwr_mutex);
>>>>> +
>>>>> +		/* the unit is microWatt */
>>>>> +		avg_acc += jdelta[cu];
>>>>> +	}
>>>>> +
>>>>> +	return sprintf(buf, "%u\n", (unsigned int) avg_acc);
>>>>> +}
>>>>> +static DEVICE_ATTR(power1_acc, S_IRUGO, show_power_acc, NULL);
>>>>
>>>> I am not really a friend of introducing a non-standard attribute.
>>>> Does the energy attribute not work here ?
>>>>
>>>
>>> You're right. Non-standard attribute might not be good. Could you
>>> please give me some hints if I use "energy" instead?
>>>
>> 1 Joule = 1 Watt-second.
>>
>> Something else, though - did you make sure that your code doesn't overflow ?
>> Even though you calculate the average in an u64, you display it as unsigned.
>>
>
> Thanks to your reminder. It should not be overflow. The maximum power
> consumption of processor (AMD CZ and future 15h) is about 15 Watts =
> 15,000,000 uWatts = 0xE4E1C0 uWatts, the size is 24 < 32 < 64 bits.
>
> Actually, the unit of jdelta is not Joule. Because the tdelta is the
> loops (cycles) that PTSC counter (the freqency is about 100 MHz)
> counts not seconds.
>
> So avg_acc is the average power consumption not the accumulated energy.
>

Would power1_average then be better suitable for the attribute ?
There is also power1_average_interval which could be used to make
the interval configurable.

Thanks,
Guenter

Re: [lm-sensors] [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algo

[Guenter Roeck]

T24gMDgvMzAvMjAxNSAwOToxNiBQTSwgSHVhbmcgUnVpIHdyb3RlOgo+IE9uIEZyaSwgQXVnIDI4
LCAyMDE1IGF0IDA3OjA1OjEzQU0gLTA3MDAsIEd1ZW50ZXIgUm9lY2sgd3JvdGU6Cj4+IE9uIDA4
LzI4LzIwMTUgMDM6NDUgQU0sIEh1YW5nIFJ1aSB3cm90ZToKPj4+IE9uIFRodSwgQXVnIDI3LCAy
MDE1IGF0IDEwOjMwOjQzQU0gLTA3MDAsIEd1ZW50ZXIgUm9lY2sgd3JvdGU6Cj4+Pj4gT24gVGh1
LCBBdWcgMjcsIDIwMTUgYXQgMDQ6MDc6NDNQTSArMDgwMCwgSHVhbmcgUnVpIHdyb3RlOgo+Pj4+
PiBUaGlzIHBhdGNoIGludHJvZHVjZXMgYW4gYWxnb3JpdGhtIHRoYXQgY29tcHV0ZXMgdGhlIGF2
ZXJhZ2UgcG93ZXIgYnkKPj4+Pj4gcmVhZGluZyBhIGRlbHRhIHZhbHVlIG9mIOKAnGNvcmUgcG93
ZXIgYWNjdW11bGF0b3LigJ0gcmVnaXN0ZXIgZHVyaW5nCj4+Pj4+IG1lYXN1cmVtZW50IGludGVy
dmFsLCBhbmQgdGhlbiBkaXZpZGluZyBkZWx0YSB2YWx1ZSBieSB0aGUgbGVuZ3RoIG9mCj4+Pj4+
IHRoZSB0aW1lIGludGVydmFsLgo+Pj4+Pgo+Pj4+PiBVc2VyIGlzIGFibGUgdG8gdXNlIHBvd2Vy
MV9hY2MgZW50cnkgdG8gbWVhc3VyZSB0aGUgcHJvY2Vzc29yIHBvd2VyCj4+Pj4+IGNvbnN1bXB0
aW9uIGFuZCBwb3dlcjFfYWNjIGp1c3QgbmVlZHMgdG8gYmUgcmVhZCB0d2ljZSB3aXRoIGFuIG5l
ZWRlZAo+Pj4+PiBpbnRlcnZhbCBpbi1iZXR3ZWVuLgo+Pj4+Pgo+Pj4+PiBBIHNpbXBsZSBleGFt
cGxlOgo+Pj4+Pgo+Pj4+PiAkIGNhdCAvc3lzL2J1cy9wY2kvZGV2aWNlcy8wMDAwXDowMFw6MTgu
NC9od21vbi9od21vbjAvcG93ZXIxX2FjYwo+Pj4+PiAkIHNsZWVwIDEwMDAwcwo+Pj4+PiAkIGNh
dCAvc3lzL2J1cy9wY2kvZGV2aWNlcy8wMDAwXDowMFw6MTguNC9od21vbi9od21vbjAvcG93ZXIx
X2FjYwo+Pj4+Pgo+Pj4+PiBUaGUgcmVzdWx0IGlzIGN1cnJlbnQgYXZlcmFnZSBwcm9jZXNzb3Ig
cG93ZXIgY29uc3VtcHRpb24gaW4gMTAwMDAKPj4+Pj4gc2Vjb25kcy4gVGhlIHVuaXQgb2YgdGhl
IHJlc3VsdCBpcyB1V2F0dC4KPj4+Pj4KPj4+Pj4gU2lnbmVkLW9mZi1ieTogSHVhbmcgUnVpIDxy
YXkuaHVhbmdAYW1kLmNvbT4KPj4+Pj4gLS0tCj4+Pj4+ICAgZHJpdmVycy9od21vbi9mYW0xNWhf
cG93ZXIuYyB8IDYyICsrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysr
Cj4+Pj4+ICAgMSBmaWxlIGNoYW5nZWQsIDYyIGluc2VydGlvbnMoKykKPj4+Pj4KPj4+Pj4gZGlm
ZiAtLWdpdCBhL2RyaXZlcnMvaHdtb24vZmFtMTVoX3Bvd2VyLmMgYi9kcml2ZXJzL2h3bW9uL2Zh
bTE1aF9wb3dlci5jCj4+Pj4+IGluZGV4IGQ1MjllNGIuLjNiYWI3OTcgMTAwNjQ0Cj4+Pj4+IC0t
LSBhL2RyaXZlcnMvaHdtb24vZmFtMTVoX3Bvd2VyLmMKPj4+Pj4gKysrIGIvZHJpdmVycy9od21v
bi9mYW0xNWhfcG93ZXIuYwo+Pj4+PiBAQCAtNjAsNiArNjAsNyBAQCBzdHJ1Y3QgZmFtMTVoX3Bv
d2VyX2RhdGEgewo+Pj4+PiAgIAl1NjQgY3VfYWNjX3Bvd2VyW01BWF9DVVNdOwo+Pj4+PiAgIAkv
KiBwZXJmb3JtYW5jZSB0aW1lc3RhbXAgY291bnRlciAqLwo+Pj4+PiAgIAl1NjQgY3B1X3N3X3B3
cl9wdHNjW01BWF9DVVNdOwo+Pj4+PiArCXN0cnVjdCBtdXRleCBhY2NfcHdyX211dGV4Owo+Pj4+
PiAgIH07Cj4+Pj4+Cj4+Pj4+ICAgc3RhdGljIHNzaXplX3Qgc2hvd19wb3dlcihzdHJ1Y3QgZGV2
aWNlICpkZXYsCj4+Pj4+IEBAIC0xMjEsMTcgKzEyMiw3NCBAQCBzdGF0aWMgREVWSUNFX0FUVFIo
cG93ZXIxX2NyaXQsIFNfSVJVR08sIHNob3dfcG93ZXJfY3JpdCwgTlVMTCk7Cj4+Pj4+ICAgc3Rh
dGljIHN0cnVjdCBhdHRyaWJ1dGVfZ3JvdXAgZmFtMTVoX3Bvd2VyX2dyb3VwOwo+Pj4+PiAgIF9f
QVRUUklCVVRFX0dST1VQUyhmYW0xNWhfcG93ZXIpOwo+Pj4+Pgo+Pj4+PiArc3RhdGljIHNzaXpl
X3Qgc2hvd19wb3dlcl9hY2Moc3RydWN0IGRldmljZSAqZGV2LAo+Pj4+PiArCQkJICAgICAgc3Ry
dWN0IGRldmljZV9hdHRyaWJ1dGUgKmF0dHIsIGNoYXIgKmJ1ZikKPj4+Pj4gK3sKPj4+Pj4gKwlp
bnQgY3B1LCBjdSwgY3VfbnVtLCBjb3Jlc19wZXJfY3U7Cj4+Pj4+ICsJdTY0IGN1cnJfY3VfYWNj
X3Bvd2VyW01BWF9DVVNdLAo+Pj4+PiArCSAgICBjdXJyX3B0c2NbTUFYX0NVU10sIGpkZWx0YVtN
QVhfQ1VTXTsKPj4+Pj4gKwl1NjQgdGRlbHRhLCBhdmdfYWNjOwo+Pj4+PiArCXN0cnVjdCBmYW0x
NWhfcG93ZXJfZGF0YSAqZGF0YSA9IGRldl9nZXRfZHJ2ZGF0YShkZXYpOwo+Pj4+PiArCj4+Pj4+
ICsJY29yZXNfcGVyX2N1ID0gYW1kX2dldF9jb3Jlc19wZXJfY3UoKTsKPj4+Pj4gKwljdV9udW0g
PSBib290X2NwdV9kYXRhLng4Nl9tYXhfY29yZXMgLyBjb3Jlc19wZXJfY3U7Cj4+Pj4+ICsKPj4+
Pj4gKwlmb3IgKGNwdSA9IDAsIGF2Z19hY2MgPSAwOyBjcHUgPCBjdV9udW0gKiBjb3Jlc19wZXJf
Y3U7IGNwdSArPSBjb3Jlc19wZXJfY3UpIHsKPj4+Pj4gKwkJY3UgPSBjcHUgLyBjb3Jlc19wZXJf
Y3U7Cj4+Pj4+ICsJCWlmIChyZG1zcmxfc2FmZV9vbl9jcHUoY3B1LCBNU1JfRjE1SF9QVFNDLCAm
Y3Vycl9wdHNjW2N1XSkpIHsKPj4+Pj4gKwkJCXByX2VycigiRmFpbGVkIHRvIHJlYWQgUFRTQyBj
b3VudGVyIE1TUiBvbiBjb3JlJWRcbiIsCj4+Pj4+ICsJCQkgICAgICAgY3B1KTsKPj4+Pj4gKwkJ
CXJldHVybiAwOwo+Pj4+PiArCQl9Cj4+Pj4+ICsKPj4+Pj4gKwkJaWYgKHJkbXNybF9zYWZlX29u
X2NwdShjcHUsIE1TUl9GMTVIX0NVX1BXUl9BQ0NVTVVMQVRPUiwKPj4+Pj4gKwkJCQkgICAgICAg
JmN1cnJfY3VfYWNjX3Bvd2VyW2N1XSkpIHsKPj4+Pj4gKwkJCXByX2VycigiRmFpbGVkIHRvIHJl
YWQgY29tcHV0ZSB1bml0IHBvd2VyIGFjY3VtdWxhdG9yIE1TUiBvbiBjb3JlJWRcbiIsCj4+Pj4+
ICsJCQkgICAgICAgY3B1KTsKPj4+Pj4gKwkJCXJldHVybiAwOwo+Pj4+PiArCQl9Cj4+Pj4+ICsK
Pj4+Pj4gKwkJaWYgKGN1cnJfY3VfYWNjX3Bvd2VyW2N1XSA8IGRhdGEtPmN1X2FjY19wb3dlcltj
dV0pIHsKPj4+Pj4gKwkJCWpkZWx0YVtjdV0gPSBkYXRhLT5tYXhfY3VfYWNjX3Bvd2VyICsgY3Vy
cl9jdV9hY2NfcG93ZXJbY3VdOwo+Pj4+PiArCQkJamRlbHRhW2N1XSAtPSBkYXRhLT5jdV9hY2Nf
cG93ZXJbY3VdOwo+Pj4+PiArCQl9IGVsc2Ugewo+Pj4+PiArCQkJamRlbHRhW2N1XSA9IGN1cnJf
Y3VfYWNjX3Bvd2VyW2N1XSAtIGRhdGEtPmN1X2FjY19wb3dlcltjdV07Cj4+Pj4+ICsJCX0KPj4+
Pj4gKwkJdGRlbHRhID0gY3Vycl9wdHNjW2N1XSAtIGRhdGEtPmNwdV9zd19wd3JfcHRzY1tjdV07
Cj4+Pj4+ICsJCWpkZWx0YVtjdV0gKj0gZGF0YS0+Y3B1X3B3cl9zYW1wbGVfcmF0aW8gKiAxMDAw
Owo+Pj4+PiArCQlkb19kaXYoamRlbHRhW2N1XSwgdGRlbHRhKTsKPj4+Pj4gKwo+Pj4+PiArCQlt
dXRleF9sb2NrKCZkYXRhLT5hY2NfcHdyX211dGV4KTsKPj4+Pj4gKwkJZGF0YS0+Y3VfYWNjX3Bv
d2VyW2N1XSA9IGN1cnJfY3VfYWNjX3Bvd2VyW2N1XTsKPj4+Pj4gKwkJZGF0YS0+Y3B1X3N3X3B3
cl9wdHNjW2N1XSA9IGN1cnJfcHRzY1tjdV07Cj4+Pj4+ICsJCW11dGV4X3VubG9jaygmZGF0YS0+
YWNjX3B3cl9tdXRleCk7Cj4+Pj4+ICsKPj4+Pj4gKwkJLyogdGhlIHVuaXQgaXMgbWljcm9XYXR0
ICovCj4+Pj4+ICsJCWF2Z19hY2MgKz0gamRlbHRhW2N1XTsKPj4+Pj4gKwl9Cj4+Pj4+ICsKPj4+
Pj4gKwlyZXR1cm4gc3ByaW50ZihidWYsICIldVxuIiwgKHVuc2lnbmVkIGludCkgYXZnX2FjYyk7
Cj4+Pj4+ICt9Cj4+Pj4+ICtzdGF0aWMgREVWSUNFX0FUVFIocG93ZXIxX2FjYywgU19JUlVHTywg
c2hvd19wb3dlcl9hY2MsIE5VTEwpOwo+Pj4+Cj4+Pj4gSSBhbSBub3QgcmVhbGx5IGEgZnJpZW5k
IG9mIGludHJvZHVjaW5nIGEgbm9uLXN0YW5kYXJkIGF0dHJpYnV0ZS4KPj4+PiBEb2VzIHRoZSBl
bmVyZ3kgYXR0cmlidXRlIG5vdCB3b3JrIGhlcmUgPwo+Pj4+Cj4+Pgo+Pj4gWW91J3JlIHJpZ2h0
LiBOb24tc3RhbmRhcmQgYXR0cmlidXRlIG1pZ2h0IG5vdCBiZSBnb29kLiBDb3VsZCB5b3UKPj4+
IHBsZWFzZSBnaXZlIG1lIHNvbWUgaGludHMgaWYgSSB1c2UgImVuZXJneSIgaW5zdGVhZD8KPj4+
Cj4+IDEgSm91bGUgPSAxIFdhdHQtc2Vjb25kLgo+Pgo+PiBTb21ldGhpbmcgZWxzZSwgdGhvdWdo
IC0gZGlkIHlvdSBtYWtlIHN1cmUgdGhhdCB5b3VyIGNvZGUgZG9lc24ndCBvdmVyZmxvdyA/Cj4+
IEV2ZW4gdGhvdWdoIHlvdSBjYWxjdWxhdGUgdGhlIGF2ZXJhZ2UgaW4gYW4gdTY0LCB5b3UgZGlz
cGxheSBpdCBhcyB1bnNpZ25lZC4KPj4KPgo+IFRoYW5rcyB0byB5b3VyIHJlbWluZGVyLiBJdCBz
aG91bGQgbm90IGJlIG92ZXJmbG93LiBUaGUgbWF4aW11bSBwb3dlcgo+IGNvbnN1bXB0aW9uIG9m
IHByb2Nlc3NvciAoQU1EIENaIGFuZCBmdXR1cmUgMTVoKSBpcyBhYm91dCAxNSBXYXR0cyA9Cj4g
MTUsMDAwLDAwMCB1V2F0dHMgPSAweEU0RTFDMCB1V2F0dHMsIHRoZSBzaXplIGlzIDI0IDwgMzIg
PCA2NCBiaXRzLgo+Cj4gQWN0dWFsbHksIHRoZSB1bml0IG9mIGpkZWx0YSBpcyBub3QgSm91bGUu
IEJlY2F1c2UgdGhlIHRkZWx0YSBpcyB0aGUKPiBsb29wcyAoY3ljbGVzKSB0aGF0IFBUU0MgY291
bnRlciAodGhlIGZyZXFlbmN5IGlzIGFib3V0IDEwMCBNSHopCj4gY291bnRzIG5vdCBzZWNvbmRz
Lgo+Cj4gU28gYXZnX2FjYyBpcyB0aGUgYXZlcmFnZSBwb3dlciBjb25zdW1wdGlvbiBub3QgdGhl
IGFjY3VtdWxhdGVkIGVuZXJneS4KPgoKV291bGQgcG93ZXIxX2F2ZXJhZ2UgdGhlbiBiZSBiZXR0
ZXIgc3VpdGFibGUgZm9yIHRoZSBhdHRyaWJ1dGUgPwpUaGVyZSBpcyBhbHNvIHBvd2VyMV9hdmVy
YWdlX2ludGVydmFsIHdoaWNoIGNvdWxkIGJlIHVzZWQgdG8gbWFrZQp0aGUgaW50ZXJ2YWwgY29u
ZmlndXJhYmxlLgoKVGhhbmtzLApHdWVudGVyCgoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KbG0tc2Vuc29ycyBtYWlsaW5nIGxpc3QKbG0tc2Vuc29yc0Bs
bS1zZW5zb3JzLm9yZwpodHRwOi8vbGlzdHMubG0tc2Vuc29ycy5vcmcvbWFpbG1hbi9saXN0aW5m
by9sbS1zZW5zb3Jz

Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Peter Zijlstra]

On Sun, Aug 30, 2015 at 05:53:22PM +0200, Borislav Petkov wrote:
> On Sat, Aug 29, 2015 at 11:19:14AM +0200, Ingo Molnar wrote:
> > So let me withdraw my ack: the much more important question that I
> > missed first time around, why is this reporting feature living in
> > hwmon, not in perf? We have energy reporting facilities in perf that
> > this should be synced to.
> 
> Because there's already fam15h_power driver which is exactly for that.
> Making it part of perf is then a question of cat-ting the same sysfs
> file twice, at the beginning and at the end of the trace, which is
> trivial.

That don't make sense.

Looking at the BKDG Fam 15h 60h-6Fh these MSRs are per compute unit.
This means you can do much finer grained measurements than system wide
-- which is all hwmon seems capable of.

Not to mention the proposed code is horrible, who in their right mind
does two rdmsrl_safe_on_cpu() back to back.

Re: [lm-sensors] [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Peter Zijlstra]

On Sun, Aug 30, 2015 at 05:53:22PM +0200, Borislav Petkov wrote:
> On Sat, Aug 29, 2015 at 11:19:14AM +0200, Ingo Molnar wrote:
> > So let me withdraw my ack: the much more important question that I
> > missed first time around, why is this reporting feature living in
> > hwmon, not in perf? We have energy reporting facilities in perf that
> > this should be synced to.
> 
> Because there's already fam15h_power driver which is exactly for that.
> Making it part of perf is then a question of cat-ting the same sysfs
> file twice, at the beginning and at the end of the trace, which is
> trivial.

That don't make sense.

Looking at the BKDG Fam 15h 60h-6Fh these MSRs are per compute unit.
This means you can do much finer grained measurements than system wide
-- which is all hwmon seems capable of.

Not to mention the proposed code is horrible, who in their right mind
does two rdmsrl_safe_on_cpu() back to back.



_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algorithm

[Huang Rui]

On Sun, Aug 30, 2015 at 09:30:28PM -0700, Guenter Roeck wrote:
> On 08/30/2015 09:16 PM, Huang Rui wrote:
> >On Fri, Aug 28, 2015 at 07:05:13AM -0700, Guenter Roeck wrote:
> >>On 08/28/2015 03:45 AM, Huang Rui wrote:
> >>>On Thu, Aug 27, 2015 at 10:30:43AM -0700, Guenter Roeck wrote:
> >>>>On Thu, Aug 27, 2015 at 04:07:43PM +0800, Huang Rui wrote:
> >>>>>This patch introduces an algorithm that computes the average power by
> >>>>>reading a delta value of “core power accumulator” register during
> >>>>>measurement interval, and then dividing delta value by the length of
> >>>>>the time interval.
> >>>>>
> >>>>>User is able to use power1_acc entry to measure the processor power
> >>>>>consumption and power1_acc just needs to be read twice with an needed
> >>>>>interval in-between.
> >>>>>
> >>>>>A simple example:
> >>>>>
> >>>>>$ cat /sys/bus/pci/devices/0000\:00\:18.4/hwmon/hwmon0/power1_acc
> >>>>>$ sleep 10000s
> >>>>>$ cat /sys/bus/pci/devices/0000\:00\:18.4/hwmon/hwmon0/power1_acc
> >>>>>
> >>>>>The result is current average processor power consumption in 10000
> >>>>>seconds. The unit of the result is uWatt.
> >>>>>
> >>>>>Signed-off-by: Huang Rui <ray.huang@amd.com>
> >>>>>---
> >>>>>  drivers/hwmon/fam15h_power.c | 62 ++++++++++++++++++++++++++++++++++++++++++++
> >>>>>  1 file changed, 62 insertions(+)
> >>>>>
> >>>>>diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
> >>>>>index d529e4b..3bab797 100644
> >>>>>--- a/drivers/hwmon/fam15h_power.c
> >>>>>+++ b/drivers/hwmon/fam15h_power.c
> >>>>>@@ -60,6 +60,7 @@ struct fam15h_power_data {
> >>>>>  	u64 cu_acc_power[MAX_CUS];
> >>>>>  	/* performance timestamp counter */
> >>>>>  	u64 cpu_sw_pwr_ptsc[MAX_CUS];
> >>>>>+	struct mutex acc_pwr_mutex;
> >>>>>  };
> >>>>>
> >>>>>  static ssize_t show_power(struct device *dev,
> >>>>>@@ -121,17 +122,74 @@ static DEVICE_ATTR(power1_crit, S_IRUGO, show_power_crit, NULL);
> >>>>>  static struct attribute_group fam15h_power_group;
> >>>>>  __ATTRIBUTE_GROUPS(fam15h_power);
> >>>>>
> >>>>>+static ssize_t show_power_acc(struct device *dev,
> >>>>>+			      struct device_attribute *attr, char *buf)
> >>>>>+{
> >>>>>+	int cpu, cu, cu_num, cores_per_cu;
> >>>>>+	u64 curr_cu_acc_power[MAX_CUS],
> >>>>>+	    curr_ptsc[MAX_CUS], jdelta[MAX_CUS];
> >>>>>+	u64 tdelta, avg_acc;
> >>>>>+	struct fam15h_power_data *data = dev_get_drvdata(dev);
> >>>>>+
> >>>>>+	cores_per_cu = amd_get_cores_per_cu();
> >>>>>+	cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> >>>>>+
> >>>>>+	for (cpu = 0, avg_acc = 0; cpu < cu_num * cores_per_cu; cpu += cores_per_cu) {
> >>>>>+		cu = cpu / cores_per_cu;
> >>>>>+		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_PTSC, &curr_ptsc[cu])) {
> >>>>>+			pr_err("Failed to read PTSC counter MSR on core%d\n",
> >>>>>+			       cpu);
> >>>>>+			return 0;
> >>>>>+		}
> >>>>>+
> >>>>>+		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_CU_PWR_ACCUMULATOR,
> >>>>>+				       &curr_cu_acc_power[cu])) {
> >>>>>+			pr_err("Failed to read compute unit power accumulator MSR on core%d\n",
> >>>>>+			       cpu);
> >>>>>+			return 0;
> >>>>>+		}
> >>>>>+
> >>>>>+		if (curr_cu_acc_power[cu] < data->cu_acc_power[cu]) {
> >>>>>+			jdelta[cu] = data->max_cu_acc_power + curr_cu_acc_power[cu];
> >>>>>+			jdelta[cu] -= data->cu_acc_power[cu];
> >>>>>+		} else {
> >>>>>+			jdelta[cu] = curr_cu_acc_power[cu] - data->cu_acc_power[cu];
> >>>>>+		}
> >>>>>+		tdelta = curr_ptsc[cu] - data->cpu_sw_pwr_ptsc[cu];
> >>>>>+		jdelta[cu] *= data->cpu_pwr_sample_ratio * 1000;
> >>>>>+		do_div(jdelta[cu], tdelta);
> >>>>>+
> >>>>>+		mutex_lock(&data->acc_pwr_mutex);
> >>>>>+		data->cu_acc_power[cu] = curr_cu_acc_power[cu];
> >>>>>+		data->cpu_sw_pwr_ptsc[cu] = curr_ptsc[cu];
> >>>>>+		mutex_unlock(&data->acc_pwr_mutex);
> >>>>>+
> >>>>>+		/* the unit is microWatt */
> >>>>>+		avg_acc += jdelta[cu];
> >>>>>+	}
> >>>>>+
> >>>>>+	return sprintf(buf, "%u\n", (unsigned int) avg_acc);
> >>>>>+}
> >>>>>+static DEVICE_ATTR(power1_acc, S_IRUGO, show_power_acc, NULL);
> >>>>
> >>>>I am not really a friend of introducing a non-standard attribute.
> >>>>Does the energy attribute not work here ?
> >>>>
> >>>
> >>>You're right. Non-standard attribute might not be good. Could you
> >>>please give me some hints if I use "energy" instead?
> >>>
> >>1 Joule = 1 Watt-second.
> >>
> >>Something else, though - did you make sure that your code doesn't overflow ?
> >>Even though you calculate the average in an u64, you display it as unsigned.
> >>
> >
> >Thanks to your reminder. It should not be overflow. The maximum power
> >consumption of processor (AMD CZ and future 15h) is about 15 Watts =
> >15,000,000 uWatts = 0xE4E1C0 uWatts, the size is 24 < 32 < 64 bits.
> >
> >Actually, the unit of jdelta is not Joule. Because the tdelta is the
> >loops (cycles) that PTSC counter (the freqency is about 100 MHz)
> >counts not seconds.
> >
> >So avg_acc is the average power consumption not the accumulated energy.
> >
> 
> Would power1_average then be better suitable for the attribute ?
> There is also power1_average_interval which could be used to make
> the interval configurable.
> 

power1_average and power1_average_interval looks better except we
might use a conversion that make interval from milliseconds to PTSC
cycles instead of "cat-ting" the sysfs file twice, right? 

Thanks,
Rui

Re: [lm-sensors] [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algo

[Huang Rui]

T24gU3VuLCBBdWcgMzAsIDIwMTUgYXQgMDk6MzA6MjhQTSAtMDcwMCwgR3VlbnRlciBSb2VjayB3
cm90ZToKPiBPbiAwOC8zMC8yMDE1IDA5OjE2IFBNLCBIdWFuZyBSdWkgd3JvdGU6Cj4gPk9uIEZy
aSwgQXVnIDI4LCAyMDE1IGF0IDA3OjA1OjEzQU0gLTA3MDAsIEd1ZW50ZXIgUm9lY2sgd3JvdGU6
Cj4gPj5PbiAwOC8yOC8yMDE1IDAzOjQ1IEFNLCBIdWFuZyBSdWkgd3JvdGU6Cj4gPj4+T24gVGh1
LCBBdWcgMjcsIDIwMTUgYXQgMTA6MzA6NDNBTSAtMDcwMCwgR3VlbnRlciBSb2VjayB3cm90ZToK
PiA+Pj4+T24gVGh1LCBBdWcgMjcsIDIwMTUgYXQgMDQ6MDc6NDNQTSArMDgwMCwgSHVhbmcgUnVp
IHdyb3RlOgo+ID4+Pj4+VGhpcyBwYXRjaCBpbnRyb2R1Y2VzIGFuIGFsZ29yaXRobSB0aGF0IGNv
bXB1dGVzIHRoZSBhdmVyYWdlIHBvd2VyIGJ5Cj4gPj4+Pj5yZWFkaW5nIGEgZGVsdGEgdmFsdWUg
b2Yg4oCcY29yZSBwb3dlciBhY2N1bXVsYXRvcuKAnSByZWdpc3RlciBkdXJpbmcKPiA+Pj4+Pm1l
YXN1cmVtZW50IGludGVydmFsLCBhbmQgdGhlbiBkaXZpZGluZyBkZWx0YSB2YWx1ZSBieSB0aGUg
bGVuZ3RoIG9mCj4gPj4+Pj50aGUgdGltZSBpbnRlcnZhbC4KPiA+Pj4+Pgo+ID4+Pj4+VXNlciBp
cyBhYmxlIHRvIHVzZSBwb3dlcjFfYWNjIGVudHJ5IHRvIG1lYXN1cmUgdGhlIHByb2Nlc3NvciBw
b3dlcgo+ID4+Pj4+Y29uc3VtcHRpb24gYW5kIHBvd2VyMV9hY2MganVzdCBuZWVkcyB0byBiZSBy
ZWFkIHR3aWNlIHdpdGggYW4gbmVlZGVkCj4gPj4+Pj5pbnRlcnZhbCBpbi1iZXR3ZWVuLgo+ID4+
Pj4+Cj4gPj4+Pj5BIHNpbXBsZSBleGFtcGxlOgo+ID4+Pj4+Cj4gPj4+Pj4kIGNhdCAvc3lzL2J1
cy9wY2kvZGV2aWNlcy8wMDAwXDowMFw6MTguNC9od21vbi9od21vbjAvcG93ZXIxX2FjYwo+ID4+
Pj4+JCBzbGVlcCAxMDAwMHMKPiA+Pj4+PiQgY2F0IC9zeXMvYnVzL3BjaS9kZXZpY2VzLzAwMDBc
OjAwXDoxOC40L2h3bW9uL2h3bW9uMC9wb3dlcjFfYWNjCj4gPj4+Pj4KPiA+Pj4+PlRoZSByZXN1
bHQgaXMgY3VycmVudCBhdmVyYWdlIHByb2Nlc3NvciBwb3dlciBjb25zdW1wdGlvbiBpbiAxMDAw
MAo+ID4+Pj4+c2Vjb25kcy4gVGhlIHVuaXQgb2YgdGhlIHJlc3VsdCBpcyB1V2F0dC4KPiA+Pj4+
Pgo+ID4+Pj4+U2lnbmVkLW9mZi1ieTogSHVhbmcgUnVpIDxyYXkuaHVhbmdAYW1kLmNvbT4KPiA+
Pj4+Pi0tLQo+ID4+Pj4+ICBkcml2ZXJzL2h3bW9uL2ZhbTE1aF9wb3dlci5jIHwgNjIgKysrKysr
KysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysKPiA+Pj4+PiAgMSBmaWxlIGNo
YW5nZWQsIDYyIGluc2VydGlvbnMoKykKPiA+Pj4+Pgo+ID4+Pj4+ZGlmZiAtLWdpdCBhL2RyaXZl
cnMvaHdtb24vZmFtMTVoX3Bvd2VyLmMgYi9kcml2ZXJzL2h3bW9uL2ZhbTE1aF9wb3dlci5jCj4g
Pj4+Pj5pbmRleCBkNTI5ZTRiLi4zYmFiNzk3IDEwMDY0NAo+ID4+Pj4+LS0tIGEvZHJpdmVycy9o
d21vbi9mYW0xNWhfcG93ZXIuYwo+ID4+Pj4+KysrIGIvZHJpdmVycy9od21vbi9mYW0xNWhfcG93
ZXIuYwo+ID4+Pj4+QEAgLTYwLDYgKzYwLDcgQEAgc3RydWN0IGZhbTE1aF9wb3dlcl9kYXRhIHsK
PiA+Pj4+PiAgCXU2NCBjdV9hY2NfcG93ZXJbTUFYX0NVU107Cj4gPj4+Pj4gIAkvKiBwZXJmb3Jt
YW5jZSB0aW1lc3RhbXAgY291bnRlciAqLwo+ID4+Pj4+ICAJdTY0IGNwdV9zd19wd3JfcHRzY1tN
QVhfQ1VTXTsKPiA+Pj4+PisJc3RydWN0IG11dGV4IGFjY19wd3JfbXV0ZXg7Cj4gPj4+Pj4gIH07
Cj4gPj4+Pj4KPiA+Pj4+PiAgc3RhdGljIHNzaXplX3Qgc2hvd19wb3dlcihzdHJ1Y3QgZGV2aWNl
ICpkZXYsCj4gPj4+Pj5AQCAtMTIxLDE3ICsxMjIsNzQgQEAgc3RhdGljIERFVklDRV9BVFRSKHBv
d2VyMV9jcml0LCBTX0lSVUdPLCBzaG93X3Bvd2VyX2NyaXQsIE5VTEwpOwo+ID4+Pj4+ICBzdGF0
aWMgc3RydWN0IGF0dHJpYnV0ZV9ncm91cCBmYW0xNWhfcG93ZXJfZ3JvdXA7Cj4gPj4+Pj4gIF9f
QVRUUklCVVRFX0dST1VQUyhmYW0xNWhfcG93ZXIpOwo+ID4+Pj4+Cj4gPj4+Pj4rc3RhdGljIHNz
aXplX3Qgc2hvd19wb3dlcl9hY2Moc3RydWN0IGRldmljZSAqZGV2LAo+ID4+Pj4+KwkJCSAgICAg
IHN0cnVjdCBkZXZpY2VfYXR0cmlidXRlICphdHRyLCBjaGFyICpidWYpCj4gPj4+Pj4rewo+ID4+
Pj4+KwlpbnQgY3B1LCBjdSwgY3VfbnVtLCBjb3Jlc19wZXJfY3U7Cj4gPj4+Pj4rCXU2NCBjdXJy
X2N1X2FjY19wb3dlcltNQVhfQ1VTXSwKPiA+Pj4+PisJICAgIGN1cnJfcHRzY1tNQVhfQ1VTXSwg
amRlbHRhW01BWF9DVVNdOwo+ID4+Pj4+Kwl1NjQgdGRlbHRhLCBhdmdfYWNjOwo+ID4+Pj4+Kwlz
dHJ1Y3QgZmFtMTVoX3Bvd2VyX2RhdGEgKmRhdGEgPSBkZXZfZ2V0X2RydmRhdGEoZGV2KTsKPiA+
Pj4+PisKPiA+Pj4+PisJY29yZXNfcGVyX2N1ID0gYW1kX2dldF9jb3Jlc19wZXJfY3UoKTsKPiA+
Pj4+PisJY3VfbnVtID0gYm9vdF9jcHVfZGF0YS54ODZfbWF4X2NvcmVzIC8gY29yZXNfcGVyX2N1
Owo+ID4+Pj4+Kwo+ID4+Pj4+Kwlmb3IgKGNwdSA9IDAsIGF2Z19hY2MgPSAwOyBjcHUgPCBjdV9u
dW0gKiBjb3Jlc19wZXJfY3U7IGNwdSArPSBjb3Jlc19wZXJfY3UpIHsKPiA+Pj4+PisJCWN1ID0g
Y3B1IC8gY29yZXNfcGVyX2N1Owo+ID4+Pj4+KwkJaWYgKHJkbXNybF9zYWZlX29uX2NwdShjcHUs
IE1TUl9GMTVIX1BUU0MsICZjdXJyX3B0c2NbY3VdKSkgewo+ID4+Pj4+KwkJCXByX2VycigiRmFp
bGVkIHRvIHJlYWQgUFRTQyBjb3VudGVyIE1TUiBvbiBjb3JlJWRcbiIsCj4gPj4+Pj4rCQkJICAg
ICAgIGNwdSk7Cj4gPj4+Pj4rCQkJcmV0dXJuIDA7Cj4gPj4+Pj4rCQl9Cj4gPj4+Pj4rCj4gPj4+
Pj4rCQlpZiAocmRtc3JsX3NhZmVfb25fY3B1KGNwdSwgTVNSX0YxNUhfQ1VfUFdSX0FDQ1VNVUxB
VE9SLAo+ID4+Pj4+KwkJCQkgICAgICAgJmN1cnJfY3VfYWNjX3Bvd2VyW2N1XSkpIHsKPiA+Pj4+
PisJCQlwcl9lcnIoIkZhaWxlZCB0byByZWFkIGNvbXB1dGUgdW5pdCBwb3dlciBhY2N1bXVsYXRv
ciBNU1Igb24gY29yZSVkXG4iLAo+ID4+Pj4+KwkJCSAgICAgICBjcHUpOwo+ID4+Pj4+KwkJCXJl
dHVybiAwOwo+ID4+Pj4+KwkJfQo+ID4+Pj4+Kwo+ID4+Pj4+KwkJaWYgKGN1cnJfY3VfYWNjX3Bv
d2VyW2N1XSA8IGRhdGEtPmN1X2FjY19wb3dlcltjdV0pIHsKPiA+Pj4+PisJCQlqZGVsdGFbY3Vd
ID0gZGF0YS0+bWF4X2N1X2FjY19wb3dlciArIGN1cnJfY3VfYWNjX3Bvd2VyW2N1XTsKPiA+Pj4+
PisJCQlqZGVsdGFbY3VdIC09IGRhdGEtPmN1X2FjY19wb3dlcltjdV07Cj4gPj4+Pj4rCQl9IGVs
c2Ugewo+ID4+Pj4+KwkJCWpkZWx0YVtjdV0gPSBjdXJyX2N1X2FjY19wb3dlcltjdV0gLSBkYXRh
LT5jdV9hY2NfcG93ZXJbY3VdOwo+ID4+Pj4+KwkJfQo+ID4+Pj4+KwkJdGRlbHRhID0gY3Vycl9w
dHNjW2N1XSAtIGRhdGEtPmNwdV9zd19wd3JfcHRzY1tjdV07Cj4gPj4+Pj4rCQlqZGVsdGFbY3Vd
ICo9IGRhdGEtPmNwdV9wd3Jfc2FtcGxlX3JhdGlvICogMTAwMDsKPiA+Pj4+PisJCWRvX2Rpdihq
ZGVsdGFbY3VdLCB0ZGVsdGEpOwo+ID4+Pj4+Kwo+ID4+Pj4+KwkJbXV0ZXhfbG9jaygmZGF0YS0+
YWNjX3B3cl9tdXRleCk7Cj4gPj4+Pj4rCQlkYXRhLT5jdV9hY2NfcG93ZXJbY3VdID0gY3Vycl9j
dV9hY2NfcG93ZXJbY3VdOwo+ID4+Pj4+KwkJZGF0YS0+Y3B1X3N3X3B3cl9wdHNjW2N1XSA9IGN1
cnJfcHRzY1tjdV07Cj4gPj4+Pj4rCQltdXRleF91bmxvY2soJmRhdGEtPmFjY19wd3JfbXV0ZXgp
Owo+ID4+Pj4+Kwo+ID4+Pj4+KwkJLyogdGhlIHVuaXQgaXMgbWljcm9XYXR0ICovCj4gPj4+Pj4r
CQlhdmdfYWNjICs9IGpkZWx0YVtjdV07Cj4gPj4+Pj4rCX0KPiA+Pj4+PisKPiA+Pj4+PisJcmV0
dXJuIHNwcmludGYoYnVmLCAiJXVcbiIsICh1bnNpZ25lZCBpbnQpIGF2Z19hY2MpOwo+ID4+Pj4+
K30KPiA+Pj4+PitzdGF0aWMgREVWSUNFX0FUVFIocG93ZXIxX2FjYywgU19JUlVHTywgc2hvd19w
b3dlcl9hY2MsIE5VTEwpOwo+ID4+Pj4KPiA+Pj4+SSBhbSBub3QgcmVhbGx5IGEgZnJpZW5kIG9m
IGludHJvZHVjaW5nIGEgbm9uLXN0YW5kYXJkIGF0dHJpYnV0ZS4KPiA+Pj4+RG9lcyB0aGUgZW5l
cmd5IGF0dHJpYnV0ZSBub3Qgd29yayBoZXJlID8KPiA+Pj4+Cj4gPj4+Cj4gPj4+WW91J3JlIHJp
Z2h0LiBOb24tc3RhbmRhcmQgYXR0cmlidXRlIG1pZ2h0IG5vdCBiZSBnb29kLiBDb3VsZCB5b3UK
PiA+Pj5wbGVhc2UgZ2l2ZSBtZSBzb21lIGhpbnRzIGlmIEkgdXNlICJlbmVyZ3kiIGluc3RlYWQ/
Cj4gPj4+Cj4gPj4xIEpvdWxlID0gMSBXYXR0LXNlY29uZC4KPiA+Pgo+ID4+U29tZXRoaW5nIGVs
c2UsIHRob3VnaCAtIGRpZCB5b3UgbWFrZSBzdXJlIHRoYXQgeW91ciBjb2RlIGRvZXNuJ3Qgb3Zl
cmZsb3cgPwo+ID4+RXZlbiB0aG91Z2ggeW91IGNhbGN1bGF0ZSB0aGUgYXZlcmFnZSBpbiBhbiB1
NjQsIHlvdSBkaXNwbGF5IGl0IGFzIHVuc2lnbmVkLgo+ID4+Cj4gPgo+ID5UaGFua3MgdG8geW91
ciByZW1pbmRlci4gSXQgc2hvdWxkIG5vdCBiZSBvdmVyZmxvdy4gVGhlIG1heGltdW0gcG93ZXIK
PiA+Y29uc3VtcHRpb24gb2YgcHJvY2Vzc29yIChBTUQgQ1ogYW5kIGZ1dHVyZSAxNWgpIGlzIGFi
b3V0IDE1IFdhdHRzID0KPiA+MTUsMDAwLDAwMCB1V2F0dHMgPSAweEU0RTFDMCB1V2F0dHMsIHRo
ZSBzaXplIGlzIDI0IDwgMzIgPCA2NCBiaXRzLgo+ID4KPiA+QWN0dWFsbHksIHRoZSB1bml0IG9m
IGpkZWx0YSBpcyBub3QgSm91bGUuIEJlY2F1c2UgdGhlIHRkZWx0YSBpcyB0aGUKPiA+bG9vcHMg
KGN5Y2xlcykgdGhhdCBQVFNDIGNvdW50ZXIgKHRoZSBmcmVxZW5jeSBpcyBhYm91dCAxMDAgTUh6
KQo+ID5jb3VudHMgbm90IHNlY29uZHMuCj4gPgo+ID5TbyBhdmdfYWNjIGlzIHRoZSBhdmVyYWdl
IHBvd2VyIGNvbnN1bXB0aW9uIG5vdCB0aGUgYWNjdW11bGF0ZWQgZW5lcmd5Lgo+ID4KPiAKPiBX
b3VsZCBwb3dlcjFfYXZlcmFnZSB0aGVuIGJlIGJldHRlciBzdWl0YWJsZSBmb3IgdGhlIGF0dHJp
YnV0ZSA/Cj4gVGhlcmUgaXMgYWxzbyBwb3dlcjFfYXZlcmFnZV9pbnRlcnZhbCB3aGljaCBjb3Vs
ZCBiZSB1c2VkIHRvIG1ha2UKPiB0aGUgaW50ZXJ2YWwgY29uZmlndXJhYmxlLgo+IAoKcG93ZXIx
X2F2ZXJhZ2UgYW5kIHBvd2VyMV9hdmVyYWdlX2ludGVydmFsIGxvb2tzIGJldHRlciBleGNlcHQg
d2UKbWlnaHQgdXNlIGEgY29udmVyc2lvbiB0aGF0IG1ha2UgaW50ZXJ2YWwgZnJvbSBtaWxsaXNl
Y29uZHMgdG8gUFRTQwpjeWNsZXMgaW5zdGVhZCBvZiAiY2F0LXRpbmciIHRoZSBzeXNmcyBmaWxl
IHR3aWNlLCByaWdodD8gCgpUaGFua3MsClJ1aQoKX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18KbG0tc2Vuc29ycyBtYWlsaW5nIGxpc3QKbG0tc2Vuc29yc0Bs
bS1zZW5zb3JzLm9yZwpodHRwOi8vbGlzdHMubG0tc2Vuc29ycy5vcmcvbWFpbG1hbi9saXN0aW5m
by9sbS1zZW5zb3Jz

Re: [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algorithm

[Peter Zijlstra]

On Thu, Aug 27, 2015 at 04:07:43PM +0800, Huang Rui wrote:
> +static ssize_t show_power_acc(struct device *dev,
> +			      struct device_attribute *attr, char *buf)
> +{
> +	int cpu, cu, cu_num, cores_per_cu;
> +	u64 curr_cu_acc_power[MAX_CUS],
> +	    curr_ptsc[MAX_CUS], jdelta[MAX_CUS];
> +	u64 tdelta, avg_acc;
> +	struct fam15h_power_data *data = dev_get_drvdata(dev);
> +
> +	cores_per_cu = amd_get_cores_per_cu();
> +	cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> +
> +	for (cpu = 0, avg_acc = 0; cpu < cu_num * cores_per_cu; cpu += cores_per_cu) {
> +		cu = cpu / cores_per_cu;
> +		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_PTSC, &curr_ptsc[cu])) {
> +			pr_err("Failed to read PTSC counter MSR on core%d\n",
> +			       cpu);
> +			return 0;
> +		}
> +
> +		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_CU_PWR_ACCUMULATOR,
> +				       &curr_cu_acc_power[cu])) {
> +			pr_err("Failed to read compute unit power accumulator MSR on core%d\n",
> +			       cpu);
> +			return 0;
> +		}
> +
> +		if (curr_cu_acc_power[cu] < data->cu_acc_power[cu]) {
> +			jdelta[cu] = data->max_cu_acc_power + curr_cu_acc_power[cu];
> +			jdelta[cu] -= data->cu_acc_power[cu];
> +		} else {
> +			jdelta[cu] = curr_cu_acc_power[cu] - data->cu_acc_power[cu];
> +		}
> +		tdelta = curr_ptsc[cu] - data->cpu_sw_pwr_ptsc[cu];
> +		jdelta[cu] *= data->cpu_pwr_sample_ratio * 1000;
> +		do_div(jdelta[cu], tdelta);
> +
> +		mutex_lock(&data->acc_pwr_mutex);
> +		data->cu_acc_power[cu] = curr_cu_acc_power[cu];
> +		data->cpu_sw_pwr_ptsc[cu] = curr_ptsc[cu];
> +		mutex_unlock(&data->acc_pwr_mutex);
> +
> +		/* the unit is microWatt */
> +		avg_acc += jdelta[cu];
> +	}
> +
> +	return sprintf(buf, "%u\n", (unsigned int) avg_acc);
> +}
> +static DEVICE_ATTR(power1_acc, S_IRUGO, show_power_acc, NULL);

This is a world readable file that sprays IPIs across the entire system,
how is that a good idea?

Re: [lm-sensors] [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algo

[Peter Zijlstra]

On Thu, Aug 27, 2015 at 04:07:43PM +0800, Huang Rui wrote:
> +static ssize_t show_power_acc(struct device *dev,
> +			      struct device_attribute *attr, char *buf)
> +{
> +	int cpu, cu, cu_num, cores_per_cu;
> +	u64 curr_cu_acc_power[MAX_CUS],
> +	    curr_ptsc[MAX_CUS], jdelta[MAX_CUS];
> +	u64 tdelta, avg_acc;
> +	struct fam15h_power_data *data = dev_get_drvdata(dev);
> +
> +	cores_per_cu = amd_get_cores_per_cu();
> +	cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> +
> +	for (cpu = 0, avg_acc = 0; cpu < cu_num * cores_per_cu; cpu += cores_per_cu) {
> +		cu = cpu / cores_per_cu;
> +		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_PTSC, &curr_ptsc[cu])) {
> +			pr_err("Failed to read PTSC counter MSR on core%d\n",
> +			       cpu);
> +			return 0;
> +		}
> +
> +		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_CU_PWR_ACCUMULATOR,
> +				       &curr_cu_acc_power[cu])) {
> +			pr_err("Failed to read compute unit power accumulator MSR on core%d\n",
> +			       cpu);
> +			return 0;
> +		}
> +
> +		if (curr_cu_acc_power[cu] < data->cu_acc_power[cu]) {
> +			jdelta[cu] = data->max_cu_acc_power + curr_cu_acc_power[cu];
> +			jdelta[cu] -= data->cu_acc_power[cu];
> +		} else {
> +			jdelta[cu] = curr_cu_acc_power[cu] - data->cu_acc_power[cu];
> +		}
> +		tdelta = curr_ptsc[cu] - data->cpu_sw_pwr_ptsc[cu];
> +		jdelta[cu] *= data->cpu_pwr_sample_ratio * 1000;
> +		do_div(jdelta[cu], tdelta);
> +
> +		mutex_lock(&data->acc_pwr_mutex);
> +		data->cu_acc_power[cu] = curr_cu_acc_power[cu];
> +		data->cpu_sw_pwr_ptsc[cu] = curr_ptsc[cu];
> +		mutex_unlock(&data->acc_pwr_mutex);
> +
> +		/* the unit is microWatt */
> +		avg_acc += jdelta[cu];
> +	}
> +
> +	return sprintf(buf, "%u\n", (unsigned int) avg_acc);
> +}
> +static DEVICE_ATTR(power1_acc, S_IRUGO, show_power_acc, NULL);

This is a world readable file that sprays IPIs across the entire system,
how is that a good idea?

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Guenter Roeck]

On 08/31/2015 01:38 AM, Peter Zijlstra wrote:
> On Sun, Aug 30, 2015 at 05:53:22PM +0200, Borislav Petkov wrote:
>> On Sat, Aug 29, 2015 at 11:19:14AM +0200, Ingo Molnar wrote:
>>> So let me withdraw my ack: the much more important question that I
>>> missed first time around, why is this reporting feature living in
>>> hwmon, not in perf? We have energy reporting facilities in perf that
>>> this should be synced to.
>>
>> Because there's already fam15h_power driver which is exactly for that.
>> Making it part of perf is then a question of cat-ting the same sysfs
>> file twice, at the beginning and at the end of the trace, which is
>> trivial.
>
> That don't make sense.
>
> Looking at the BKDG Fam 15h 60h-6Fh these MSRs are per compute unit.
> This means you can do much finer grained measurements than system wide
> -- which is all hwmon seems capable of.
>

Is it ? Why ?

Guenter

Re: [lm-sensors] [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Guenter Roeck]

On 08/31/2015 01:38 AM, Peter Zijlstra wrote:
> On Sun, Aug 30, 2015 at 05:53:22PM +0200, Borislav Petkov wrote:
>> On Sat, Aug 29, 2015 at 11:19:14AM +0200, Ingo Molnar wrote:
>>> So let me withdraw my ack: the much more important question that I
>>> missed first time around, why is this reporting feature living in
>>> hwmon, not in perf? We have energy reporting facilities in perf that
>>> this should be synced to.
>>
>> Because there's already fam15h_power driver which is exactly for that.
>> Making it part of perf is then a question of cat-ting the same sysfs
>> file twice, at the beginning and at the end of the trace, which is
>> trivial.
>
> That don't make sense.
>
> Looking at the BKDG Fam 15h 60h-6Fh these MSRs are per compute unit.
> This means you can do much finer grained measurements than system wide
> -- which is all hwmon seems capable of.
>

Is it ? Why ?

Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Peter Zijlstra]

On Mon, Aug 31, 2015 at 06:26:00AM -0700, Guenter Roeck wrote:
> On 08/31/2015 01:38 AM, Peter Zijlstra wrote:
> >On Sun, Aug 30, 2015 at 05:53:22PM +0200, Borislav Petkov wrote:
> >>On Sat, Aug 29, 2015 at 11:19:14AM +0200, Ingo Molnar wrote:
> >>>So let me withdraw my ack: the much more important question that I
> >>>missed first time around, why is this reporting feature living in
> >>>hwmon, not in perf? We have energy reporting facilities in perf that
> >>>this should be synced to.
> >>
> >>Because there's already fam15h_power driver which is exactly for that.
> >>Making it part of perf is then a question of cat-ting the same sysfs
> >>file twice, at the beginning and at the end of the trace, which is
> >>trivial.
> >
> >That don't make sense.
> >
> >Looking at the BKDG Fam 15h 60h-6Fh these MSRs are per compute unit.
> >This means you can do much finer grained measurements than system wide
> >-- which is all hwmon seems capable of.
> >
> 
> Is it ? Why ?

Dunno, because there's that big old loop iterating all cpus?

Re: [lm-sensors] [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Peter Zijlstra]

On Mon, Aug 31, 2015 at 06:26:00AM -0700, Guenter Roeck wrote:
> On 08/31/2015 01:38 AM, Peter Zijlstra wrote:
> >On Sun, Aug 30, 2015 at 05:53:22PM +0200, Borislav Petkov wrote:
> >>On Sat, Aug 29, 2015 at 11:19:14AM +0200, Ingo Molnar wrote:
> >>>So let me withdraw my ack: the much more important question that I
> >>>missed first time around, why is this reporting feature living in
> >>>hwmon, not in perf? We have energy reporting facilities in perf that
> >>>this should be synced to.
> >>
> >>Because there's already fam15h_power driver which is exactly for that.
> >>Making it part of perf is then a question of cat-ting the same sysfs
> >>file twice, at the beginning and at the end of the trace, which is
> >>trivial.
> >
> >That don't make sense.
> >
> >Looking at the BKDG Fam 15h 60h-6Fh these MSRs are per compute unit.
> >This means you can do much finer grained measurements than system wide
> >-- which is all hwmon seems capable of.
> >
> 
> Is it ? Why ?

Dunno, because there's that big old loop iterating all cpus?

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Guenter Roeck]

On 08/31/2015 06:38 AM, Peter Zijlstra wrote:
> On Mon, Aug 31, 2015 at 06:26:00AM -0700, Guenter Roeck wrote:
>> On 08/31/2015 01:38 AM, Peter Zijlstra wrote:
>>> On Sun, Aug 30, 2015 at 05:53:22PM +0200, Borislav Petkov wrote:
>>>> On Sat, Aug 29, 2015 at 11:19:14AM +0200, Ingo Molnar wrote:
>>>>> So let me withdraw my ack: the much more important question that I
>>>>> missed first time around, why is this reporting feature living in
>>>>> hwmon, not in perf? We have energy reporting facilities in perf that
>>>>> this should be synced to.
>>>>
>>>> Because there's already fam15h_power driver which is exactly for that.
>>>> Making it part of perf is then a question of cat-ting the same sysfs
>>>> file twice, at the beginning and at the end of the trace, which is
>>>> trivial.
>>>
>>> That don't make sense.
>>>
>>> Looking at the BKDG Fam 15h 60h-6Fh these MSRs are per compute unit.
>>> This means you can do much finer grained measurements than system wide
>>> -- which is all hwmon seems capable of.
>>>
>>
>> Is it ? Why ?
>
> Dunno, because there's that big old loop iterating all cpus?
>

What does that have to do with 'hwmon' ? The current implementation in the
driver may not be a good idea, and maybe for good reasons; I can not
comment on that. However, you concluded from that implementation that
hwmon, the subsystem, would not be able to support 'much finer grained
measurements than system wide'. I would like to understand how you reached
that conclusion.

Thanks,
Guenter

Re: [lm-sensors] [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Guenter Roeck]

On 08/31/2015 06:38 AM, Peter Zijlstra wrote:
> On Mon, Aug 31, 2015 at 06:26:00AM -0700, Guenter Roeck wrote:
>> On 08/31/2015 01:38 AM, Peter Zijlstra wrote:
>>> On Sun, Aug 30, 2015 at 05:53:22PM +0200, Borislav Petkov wrote:
>>>> On Sat, Aug 29, 2015 at 11:19:14AM +0200, Ingo Molnar wrote:
>>>>> So let me withdraw my ack: the much more important question that I
>>>>> missed first time around, why is this reporting feature living in
>>>>> hwmon, not in perf? We have energy reporting facilities in perf that
>>>>> this should be synced to.
>>>>
>>>> Because there's already fam15h_power driver which is exactly for that.
>>>> Making it part of perf is then a question of cat-ting the same sysfs
>>>> file twice, at the beginning and at the end of the trace, which is
>>>> trivial.
>>>
>>> That don't make sense.
>>>
>>> Looking at the BKDG Fam 15h 60h-6Fh these MSRs are per compute unit.
>>> This means you can do much finer grained measurements than system wide
>>> -- which is all hwmon seems capable of.
>>>
>>
>> Is it ? Why ?
>
> Dunno, because there's that big old loop iterating all cpus?
>

What does that have to do with 'hwmon' ? The current implementation in the
driver may not be a good idea, and maybe for good reasons; I can not
comment on that. However, you concluded from that implementation that
hwmon, the subsystem, would not be able to support 'much finer grained
measurements than system wide'. I would like to understand how you reached
that conclusion.

Thanks,
Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Peter Zijlstra]

On Mon, Aug 31, 2015 at 06:53:58AM -0700, Guenter Roeck wrote:

> What does that have to do with 'hwmon' ? The current implementation in the
> driver may not be a good idea, and maybe for good reasons; I can not
> comment on that. However, you concluded from that implementation that
> hwmon, the subsystem, would not be able to support 'much finer grained
> measurements than system wide'. I would like to understand how you reached
> that conclusion.

Purely going on what this driver does here. I assumed it was
representative of things, if not then good.

Re: [lm-sensors] [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Peter Zijlstra]

On Mon, Aug 31, 2015 at 06:53:58AM -0700, Guenter Roeck wrote:

> What does that have to do with 'hwmon' ? The current implementation in the
> driver may not be a good idea, and maybe for good reasons; I can not
> comment on that. However, you concluded from that implementation that
> hwmon, the subsystem, would not be able to support 'much finer grained
> measurements than system wide'. I would like to understand how you reached
> that conclusion.

Purely going on what this driver does here. I assumed it was
representative of things, if not then good.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algorithm

[Peter Zijlstra]

On Mon, Aug 31, 2015 at 03:25:35PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 27, 2015 at 04:07:43PM +0800, Huang Rui wrote:
> > +static ssize_t show_power_acc(struct device *dev,
> > +			      struct device_attribute *attr, char *buf)
> > +{
> > +	int cpu, cu, cu_num, cores_per_cu;
> > +	u64 curr_cu_acc_power[MAX_CUS],
> > +	    curr_ptsc[MAX_CUS], jdelta[MAX_CUS];
> > +	u64 tdelta, avg_acc;
> > +	struct fam15h_power_data *data = dev_get_drvdata(dev);
> > +
> > +	cores_per_cu = amd_get_cores_per_cu();
> > +	cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> > +
> > +	for (cpu = 0, avg_acc = 0; cpu < cu_num * cores_per_cu; cpu += cores_per_cu) {
> > +		cu = cpu / cores_per_cu;
> > +		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_PTSC, &curr_ptsc[cu])) {
> > +			pr_err("Failed to read PTSC counter MSR on core%d\n",
> > +			       cpu);
> > +			return 0;
> > +		}
> > +
> > +		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_CU_PWR_ACCUMULATOR,
> > +				       &curr_cu_acc_power[cu])) {
> > +			pr_err("Failed to read compute unit power accumulator MSR on core%d\n",
> > +			       cpu);
> > +			return 0;
> > +		}
> > +
> > +		if (curr_cu_acc_power[cu] < data->cu_acc_power[cu]) {
> > +			jdelta[cu] = data->max_cu_acc_power + curr_cu_acc_power[cu];
> > +			jdelta[cu] -= data->cu_acc_power[cu];
> > +		} else {
> > +			jdelta[cu] = curr_cu_acc_power[cu] - data->cu_acc_power[cu];
> > +		}
> > +		tdelta = curr_ptsc[cu] - data->cpu_sw_pwr_ptsc[cu];
> > +		jdelta[cu] *= data->cpu_pwr_sample_ratio * 1000;
> > +		do_div(jdelta[cu], tdelta);
> > +
> > +		mutex_lock(&data->acc_pwr_mutex);
> > +		data->cu_acc_power[cu] = curr_cu_acc_power[cu];
> > +		data->cpu_sw_pwr_ptsc[cu] = curr_ptsc[cu];
> > +		mutex_unlock(&data->acc_pwr_mutex);
> > +
> > +		/* the unit is microWatt */
> > +		avg_acc += jdelta[cu];
> > +	}
> > +
> > +	return sprintf(buf, "%u\n", (unsigned int) avg_acc);
> > +}
> > +static DEVICE_ATTR(power1_acc, S_IRUGO, show_power_acc, NULL);
> 
> This is a world readable file that sprays IPIs across the entire system,
> how is that a good idea?

FWIW this driver is also hotplug challenged. Not to mention it relies on
cpu number layout in unhealthy ways.

Re: [lm-sensors] [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algo

[Peter Zijlstra]

On Mon, Aug 31, 2015 at 03:25:35PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 27, 2015 at 04:07:43PM +0800, Huang Rui wrote:
> > +static ssize_t show_power_acc(struct device *dev,
> > +			      struct device_attribute *attr, char *buf)
> > +{
> > +	int cpu, cu, cu_num, cores_per_cu;
> > +	u64 curr_cu_acc_power[MAX_CUS],
> > +	    curr_ptsc[MAX_CUS], jdelta[MAX_CUS];
> > +	u64 tdelta, avg_acc;
> > +	struct fam15h_power_data *data = dev_get_drvdata(dev);
> > +
> > +	cores_per_cu = amd_get_cores_per_cu();
> > +	cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
> > +
> > +	for (cpu = 0, avg_acc = 0; cpu < cu_num * cores_per_cu; cpu += cores_per_cu) {
> > +		cu = cpu / cores_per_cu;
> > +		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_PTSC, &curr_ptsc[cu])) {
> > +			pr_err("Failed to read PTSC counter MSR on core%d\n",
> > +			       cpu);
> > +			return 0;
> > +		}
> > +
> > +		if (rdmsrl_safe_on_cpu(cpu, MSR_F15H_CU_PWR_ACCUMULATOR,
> > +				       &curr_cu_acc_power[cu])) {
> > +			pr_err("Failed to read compute unit power accumulator MSR on core%d\n",
> > +			       cpu);
> > +			return 0;
> > +		}
> > +
> > +		if (curr_cu_acc_power[cu] < data->cu_acc_power[cu]) {
> > +			jdelta[cu] = data->max_cu_acc_power + curr_cu_acc_power[cu];
> > +			jdelta[cu] -= data->cu_acc_power[cu];
> > +		} else {
> > +			jdelta[cu] = curr_cu_acc_power[cu] - data->cu_acc_power[cu];
> > +		}
> > +		tdelta = curr_ptsc[cu] - data->cpu_sw_pwr_ptsc[cu];
> > +		jdelta[cu] *= data->cpu_pwr_sample_ratio * 1000;
> > +		do_div(jdelta[cu], tdelta);
> > +
> > +		mutex_lock(&data->acc_pwr_mutex);
> > +		data->cu_acc_power[cu] = curr_cu_acc_power[cu];
> > +		data->cpu_sw_pwr_ptsc[cu] = curr_ptsc[cu];
> > +		mutex_unlock(&data->acc_pwr_mutex);
> > +
> > +		/* the unit is microWatt */
> > +		avg_acc += jdelta[cu];
> > +	}
> > +
> > +	return sprintf(buf, "%u\n", (unsigned int) avg_acc);
> > +}
> > +static DEVICE_ATTR(power1_acc, S_IRUGO, show_power_acc, NULL);
> 
> This is a world readable file that sprays IPIs across the entire system,
> how is that a good idea?

FWIW this driver is also hotplug challenged. Not to mention it relies on
cpu number layout in unhealthy ways.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Guenter Roeck]

On 08/31/2015 07:57 AM, Peter Zijlstra wrote:
> On Mon, Aug 31, 2015 at 06:53:58AM -0700, Guenter Roeck wrote:
>
>> What does that have to do with 'hwmon' ? The current implementation in the
>> driver may not be a good idea, and maybe for good reasons; I can not
>> comment on that. However, you concluded from that implementation that
>> hwmon, the subsystem, would not be able to support 'much finer grained
>> measurements than system wide'. I would like to understand how you reached
>> that conclusion.
>
> Purely going on what this driver does here. I assumed it was
> representative of things, if not then good.
>
Corollary: If a driver in subsystem X doesn't support interrupts,
it is a fair conclusion that subsystem X doesn't support interrupts.

The hwmon subsystem may have its limitations, and for sure would deserve
an overhaul, but at the same time people should refrain from bashing it
for no good reason.

Guenter

Re: [lm-sensors] [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Guenter Roeck]

On 08/31/2015 07:57 AM, Peter Zijlstra wrote:
> On Mon, Aug 31, 2015 at 06:53:58AM -0700, Guenter Roeck wrote:
>
>> What does that have to do with 'hwmon' ? The current implementation in the
>> driver may not be a good idea, and maybe for good reasons; I can not
>> comment on that. However, you concluded from that implementation that
>> hwmon, the subsystem, would not be able to support 'much finer grained
>> measurements than system wide'. I would like to understand how you reached
>> that conclusion.
>
> Purely going on what this driver does here. I assumed it was
> representative of things, if not then good.
>
Corollary: If a driver in subsystem X doesn't support interrupts,
it is a fair conclusion that subsystem X doesn't support interrupts.

The hwmon subsystem may have its limitations, and for sure would deserve
an overhaul, but at the same time people should refrain from bashing it
for no good reason.

Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [15/15] MAINTAINERS: change the maintainer of fam15h_power driver

[Andreas Herrmann]

On Sat, Aug 29, 2015 at 09:33:54AM -0700, Guenter Roeck wrote:
> On Thu, Aug 27, 2015 at 04:07:46PM +0800, Huang Rui wrote:
> > Andreas Herrmann won't take the maintainer of fam15h_power driver. I
> > will take it and appreciate him for the great contributions on this
> > driver.
> > 
> > Signed-off-by: Huang Rui <ray.huang@amd.com>
> > Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
> 
> Please add Andreas to CREDITS.
> 
> Andreas, can you Ack this change ?

Acked-by: Andreas Herrmann <herrmann.der.user@googlemail.com>

Thanks,
Andreas

> Thanks,
> Guenter
> 
> > ---
> >  MAINTAINERS | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 941d7b7..241d45e 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -601,9 +601,9 @@ F:	drivers/crypto/ccp/
> >  F:	include/linux/ccp.h
> >  
> >  AMD FAM15H PROCESSOR POWER MONITORING DRIVER
> > -M:	Andreas Herrmann <herrmann.der.user@googlemail.com>
> > +M:	Huang Rui <ray.huang@amd.com>
> >  L:	lm-sensors@lm-sensors.org
> > -S:	Maintained
> > +S:	Supported
> >  F:	Documentation/hwmon/fam15h_power
> >  F:	drivers/hwmon/fam15h_power.c
> >  

Re: [lm-sensors] [15/15] MAINTAINERS: change the maintainer of fam15h_power driver

[Andreas Herrmann]

On Sat, Aug 29, 2015 at 09:33:54AM -0700, Guenter Roeck wrote:
> On Thu, Aug 27, 2015 at 04:07:46PM +0800, Huang Rui wrote:
> > Andreas Herrmann won't take the maintainer of fam15h_power driver. I
> > will take it and appreciate him for the great contributions on this
> > driver.
> > 
> > Signed-off-by: Huang Rui <ray.huang@amd.com>
> > Cc: Andreas Herrmann <herrmann.der.user@googlemail.com>
> 
> Please add Andreas to CREDITS.
> 
> Andreas, can you Ack this change ?

Acked-by: Andreas Herrmann <herrmann.der.user@googlemail.com>

Thanks,
Andreas

> Thanks,
> Guenter
> 
> > ---
> >  MAINTAINERS | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 941d7b7..241d45e 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -601,9 +601,9 @@ F:	drivers/crypto/ccp/
> >  F:	include/linux/ccp.h
> >  
> >  AMD FAM15H PROCESSOR POWER MONITORING DRIVER
> > -M:	Andreas Herrmann <herrmann.der.user@googlemail.com>
> > +M:	Huang Rui <ray.huang@amd.com>
> >  L:	lm-sensors@lm-sensors.org
> > -S:	Maintained
> > +S:	Supported
> >  F:	Documentation/hwmon/fam15h_power
> >  F:	drivers/hwmon/fam15h_power.c
> >  

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Borislav Petkov]

On Mon, Aug 31, 2015 at 10:38:21AM +0200, Peter Zijlstra wrote:
> Looking at the BKDG Fam 15h 60h-6Fh these MSRs are per compute unit.
> This means you can do much finer grained measurements than system wide

Well, we can do finer-grained if needed. I'm all for everything which
has a good use case. The use case we had in mind here was the physical
processor power consumption for a time period.

> -- which is all hwmon seems capable of.

I guess we can do both - perf and hwmon. I don't see why not.

> Not to mention the proposed code is horrible, who in their right mind
> does two rdmsrl_safe_on_cpu() back to back.

That's a good point - I missed that during previous review. Rui, please
put the rdmsrl_safe_on_cpu() accesses in a separate function which you
run on a particular CPU, for your next version.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [lm-sensors] [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Borislav Petkov]

On Mon, Aug 31, 2015 at 10:38:21AM +0200, Peter Zijlstra wrote:
> Looking at the BKDG Fam 15h 60h-6Fh these MSRs are per compute unit.
> This means you can do much finer grained measurements than system wide

Well, we can do finer-grained if needed. I'm all for everything which
has a good use case. The use case we had in mind here was the physical
processor power consumption for a time period.

> -- which is all hwmon seems capable of.

I guess we can do both - perf and hwmon. I don't see why not.

> Not to mention the proposed code is horrible, who in their right mind
> does two rdmsrl_safe_on_cpu() back to back.

That's a good point - I missed that during previous review. Rui, please
put the rdmsrl_safe_on_cpu() accesses in a separate function which you
run on a particular CPU, for your next version.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Guenter Roeck]

On 08/31/2015 09:06 AM, Borislav Petkov wrote:
> On Mon, Aug 31, 2015 at 10:38:21AM +0200, Peter Zijlstra wrote:
>> Looking at the BKDG Fam 15h 60h-6Fh these MSRs are per compute unit.
>> This means you can do much finer grained measurements than system wide
>
> Well, we can do finer-grained if needed. I'm all for everything which
> has a good use case. The use case we had in mind here was the physical
> processor power consumption for a time period.
>
>> -- which is all hwmon seems capable of.
>
> I guess we can do both - perf and hwmon. I don't see why not.
>
>> Not to mention the proposed code is horrible, who in their right mind
>> does two rdmsrl_safe_on_cpu() back to back.
>
> That's a good point - I missed that during previous review. Rui, please
> put the rdmsrl_safe_on_cpu() accesses in a separate function which you
> run on a particular CPU, for your next version.
>
... and maybe work with Peter to address the other hotplug related issues.

It might also be worthwhile thinking about per-CU attributes, if that
provides any value (Peter's comments suggested that this might be the case).

Thanks,
Guenter

Re: [lm-sensors] [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Guenter Roeck]

On 08/31/2015 09:06 AM, Borislav Petkov wrote:
> On Mon, Aug 31, 2015 at 10:38:21AM +0200, Peter Zijlstra wrote:
>> Looking at the BKDG Fam 15h 60h-6Fh these MSRs are per compute unit.
>> This means you can do much finer grained measurements than system wide
>
> Well, we can do finer-grained if needed. I'm all for everything which
> has a good use case. The use case we had in mind here was the physical
> processor power consumption for a time period.
>
>> -- which is all hwmon seems capable of.
>
> I guess we can do both - perf and hwmon. I don't see why not.
>
>> Not to mention the proposed code is horrible, who in their right mind
>> does two rdmsrl_safe_on_cpu() back to back.
>
> That's a good point - I missed that during previous review. Rui, please
> put the rdmsrl_safe_on_cpu() accesses in a separate function which you
> run on a particular CPU, for your next version.
>
... and maybe work with Peter to address the other hotplug related issues.

It might also be worthwhile thinking about per-CU attributes, if that
provides any value (Peter's comments suggested that this might be the case).

Thanks,
Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Peter Zijlstra]

On Mon, Aug 31, 2015 at 09:19:20AM -0700, Guenter Roeck wrote:
> On 08/31/2015 09:06 AM, Borislav Petkov wrote:

> >That's a good point - I missed that during previous review. Rui, please
> >put the rdmsrl_safe_on_cpu() accesses in a separate function which you
> >run on a particular CPU, for your next version.
> >
> ... and maybe work with Peter to address the other hotplug related issues.
> 
> It might also be worthwhile thinking about per-CU attributes, if that
> provides any value (Peter's comments suggested that this might be the case).

Yeah, so it would allow measuring the power of a subset of compute
units. Typically only useful if you've partitioned your workload. But
since the hardware trivially supports it, its a waste to not expose it.

(Note that its not per-cpu, its per compute unit. What we do with perf
is export a cpumask)

My biggest problem is that all this is user readable and unthrottled. It
basically allows DoS (perf does not typically allow user access to CPU
wide resources).

Imagine joe user doing:

	for ((i=0; i<1000; i++)); do
		(while :; do cat /sys/foo/file > /dev/null ; done) &
	done

Even when contained to a subset of CPUs, that will cause an IPI storm on
all (/2) CPUs, even if you've tried really hard to keep users away from
some of them (see the above partitioning) because you're running some
important RT workload or whatnot.


As to hotplug, if you unplug any of the even numbered CPUs the whole
thing bails and returns 0, even if the corresponding odd CPU of the
compute unit it still online and perfectly capable of accessing the MSR.


As to relying on CPU numbering, maybe I should go write an APICID -> cpu
number randomizer, just for kicks to see what else fails.

We have topology information and cpumasks aplenty for things like this.

Re: [lm-sensors] [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Peter Zijlstra]

On Mon, Aug 31, 2015 at 09:19:20AM -0700, Guenter Roeck wrote:
> On 08/31/2015 09:06 AM, Borislav Petkov wrote:

> >That's a good point - I missed that during previous review. Rui, please
> >put the rdmsrl_safe_on_cpu() accesses in a separate function which you
> >run on a particular CPU, for your next version.
> >
> ... and maybe work with Peter to address the other hotplug related issues.
> 
> It might also be worthwhile thinking about per-CU attributes, if that
> provides any value (Peter's comments suggested that this might be the case).

Yeah, so it would allow measuring the power of a subset of compute
units. Typically only useful if you've partitioned your workload. But
since the hardware trivially supports it, its a waste to not expose it.

(Note that its not per-cpu, its per compute unit. What we do with perf
is export a cpumask)

My biggest problem is that all this is user readable and unthrottled. It
basically allows DoS (perf does not typically allow user access to CPU
wide resources).

Imagine joe user doing:

	for ((i=0; i<1000; i++)); do
		(while :; do cat /sys/foo/file > /dev/null ; done) &
	done

Even when contained to a subset of CPUs, that will cause an IPI storm on
all (/2) CPUs, even if you've tried really hard to keep users away from
some of them (see the above partitioning) because you're running some
important RT workload or whatnot.


As to hotplug, if you unplug any of the even numbered CPUs the whole
thing bails and returns 0, even if the corresponding odd CPU of the
compute unit it still online and perfectly capable of accessing the MSR.


As to relying on CPU numbering, maybe I should go write an APICID -> cpu
number randomizer, just for kicks to see what else fails.

We have topology information and cpumasks aplenty for things like this.

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Guenter Roeck]

On 08/31/2015 01:44 PM, Peter Zijlstra wrote:
> On Mon, Aug 31, 2015 at 09:19:20AM -0700, Guenter Roeck wrote:
>> On 08/31/2015 09:06 AM, Borislav Petkov wrote:
>
>>> That's a good point - I missed that during previous review. Rui, please
>>> put the rdmsrl_safe_on_cpu() accesses in a separate function which you
>>> run on a particular CPU, for your next version.
>>>
>> ... and maybe work with Peter to address the other hotplug related issues.
>>
>> It might also be worthwhile thinking about per-CU attributes, if that
>> provides any value (Peter's comments suggested that this might be the case).
>
> Yeah, so it would allow measuring the power of a subset of compute
> units. Typically only useful if you've partitioned your workload. But
> since the hardware trivially supports it, its a waste to not expose it.
>
> (Note that its not per-cpu, its per compute unit. What we do with perf
> is export a cpumask)
>
> My biggest problem is that all this is user readable and unthrottled. It
> basically allows DoS (perf does not typically allow user access to CPU
> wide resources).
>
> Imagine joe user doing:
>
> 	for ((i=0; i<1000; i++)); do
> 		(while :; do cat /sys/foo/file > /dev/null ; done) &
> 	done
>
> Even when contained to a subset of CPUs, that will cause an IPI storm on
> all (/2) CPUs, even if you've tried really hard to keep users away from
> some of them (see the above partitioning) because you're running some
> important RT workload or whatnot.
>

That is a matter of driver implementation. Very commonly hwmon drivers
implement value caching, where data from the device is only read at
minimum intervals, and the cached values are reported if the information
is polled too rapidly. For the most part, that is used with i2c temperature
sensors, which tend to update their readings only a few times per second
anyway, but the same mechanism can (and possibly should) be used in
situations like this.

At some point I would like to move the caching mechanism into the hwmon core,
but that is going to take a while.

>
> As to hotplug, if you unplug any of the even numbered CPUs the whole
> thing bails and returns 0, even if the corresponding odd CPU of the
> compute unit it still online and perfectly capable of accessing the MSR.
>

Ah yes, I recall there was a similar problem in the coretemp driver
some time ago.

Guenter

Re: [lm-sensors] [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Guenter Roeck]

On 08/31/2015 01:44 PM, Peter Zijlstra wrote:
> On Mon, Aug 31, 2015 at 09:19:20AM -0700, Guenter Roeck wrote:
>> On 08/31/2015 09:06 AM, Borislav Petkov wrote:
>
>>> That's a good point - I missed that during previous review. Rui, please
>>> put the rdmsrl_safe_on_cpu() accesses in a separate function which you
>>> run on a particular CPU, for your next version.
>>>
>> ... and maybe work with Peter to address the other hotplug related issues.
>>
>> It might also be worthwhile thinking about per-CU attributes, if that
>> provides any value (Peter's comments suggested that this might be the case).
>
> Yeah, so it would allow measuring the power of a subset of compute
> units. Typically only useful if you've partitioned your workload. But
> since the hardware trivially supports it, its a waste to not expose it.
>
> (Note that its not per-cpu, its per compute unit. What we do with perf
> is export a cpumask)
>
> My biggest problem is that all this is user readable and unthrottled. It
> basically allows DoS (perf does not typically allow user access to CPU
> wide resources).
>
> Imagine joe user doing:
>
> 	for ((i=0; i<1000; i++)); do
> 		(while :; do cat /sys/foo/file > /dev/null ; done) &
> 	done
>
> Even when contained to a subset of CPUs, that will cause an IPI storm on
> all (/2) CPUs, even if you've tried really hard to keep users away from
> some of them (see the above partitioning) because you're running some
> important RT workload or whatnot.
>

That is a matter of driver implementation. Very commonly hwmon drivers
implement value caching, where data from the device is only read at
minimum intervals, and the cached values are reported if the information
is polled too rapidly. For the most part, that is used with i2c temperature
sensors, which tend to update their readings only a few times per second
anyway, but the same mechanism can (and possibly should) be used in
situations like this.

At some point I would like to move the caching mechanism into the hwmon core,
but that is going to take a while.

>
> As to hotplug, if you unplug any of the even numbered CPUs the whole
> thing bails and returns 0, even if the corresponding odd CPU of the
> compute unit it still online and perfectly capable of accessing the MSR.
>

Ah yes, I recall there was a similar problem in the coretemp driver
some time ago.

Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Borislav Petkov]

On Mon, Aug 31, 2015 at 02:24:08PM -0700, Guenter Roeck wrote:
> That is a matter of driver implementation. Very commonly hwmon drivers
> implement value caching, where data from the device is only read at
> minimum intervals, and the cached values are reported if the information
> is polled too rapidly.

I don't see how we can use cached values in that case as they'd be
basically a lie as to how much power the CU/processor has consumed. I
guess it would be fairer to the user to warn instead and not issue any
values or to simply delay the read to a min timeout...

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

Re: [lm-sensors] [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Borislav Petkov]

On Mon, Aug 31, 2015 at 02:24:08PM -0700, Guenter Roeck wrote:
> That is a matter of driver implementation. Very commonly hwmon drivers
> implement value caching, where data from the device is only read at
> minimum intervals, and the cached values are reported if the information
> is polled too rapidly.

I don't see how we can use cached values in that case as they'd be
basically a lie as to how much power the CU/processor has consumed. I
guess it would be fairer to the user to warn instead and not issue any
values or to simply delay the read to a min timeout...

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Guenter Roeck]

On 09/01/2015 08:56 AM, Borislav Petkov wrote:
> On Mon, Aug 31, 2015 at 02:24:08PM -0700, Guenter Roeck wrote:
>> That is a matter of driver implementation. Very commonly hwmon drivers
>> implement value caching, where data from the device is only read at
>> minimum intervals, and the cached values are reported if the information
>> is polled too rapidly.
>
> I don't see how we can use cached values in that case as they'd be
> basically a lie as to how much power the CU/processor has consumed. I
> guess it would be fairer to the user to warn instead and not issue any
> values or to simply delay the read to a min timeout...
>

This is all a matter of ABI description. I personally don't see the
harm in caching values for up to <n> milliseconds and documenting that
readings may reflect power consumption from <n> milliseconds ago.
However, I don't mind any other solution either if that is considered
unacceptable, as long as that solution doesn't break the ABI.

Guenter

Re: [lm-sensors] [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit

[Guenter Roeck]

On 09/01/2015 08:56 AM, Borislav Petkov wrote:
> On Mon, Aug 31, 2015 at 02:24:08PM -0700, Guenter Roeck wrote:
>> That is a matter of driver implementation. Very commonly hwmon drivers
>> implement value caching, where data from the device is only read at
>> minimum intervals, and the cached values are reported if the information
>> is polled too rapidly.
>
> I don't see how we can use cached values in that case as they'd be
> basically a lie as to how much power the CU/processor has consumed. I
> guess it would be fairer to the user to warn instead and not issue any
> values or to simply delay the read to a min timeout...
>

This is all a matter of ABI description. I personally don't see the
harm in caching values for up to <n> milliseconds and documenting that
readings may reflect power consumption from <n> milliseconds ago.
However, I don't mind any other solution either if that is considered
unacceptable, as long as that solution doesn't break the ABI.

Guenter


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors