hwmon, fam15h_power: introduce an accumulated power reporting algorithm
Huang Rui
maintainercover hwmon, fam15h_power: introduce an accumulated power reporting algorithm
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&m3874573111310&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(-)
Signature · 7 lines
1.9.1 _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Huang Rui
maintainerPATCH 1/15 hwmon, fam15h_power: add support for AMD Carrizo
AMD Carrizo(Fam15h, M60h) processors can report power1_crit (ProcessorPwrWatts) and power1_input (CurrPwrWatts) values. And this patch adds support for CZ.
--- drivers/hwmon/fam15h_power.c | 1 + 1 file changed, 1 insertion(+)
drivers/hwmon/fam15h_power.c +1 -0
@@ -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 ) }, {}
Signature · 7 lines
1.9.1 _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Re: [PATCH 01/15] hwmon, fam15h_power: add support for AMD Carrizo
Quoted 5 lines · Huang Rui
AMD
Carrizo(Fam15h, M60h)processors can reportpower1_crit(ProcessorPwrWatts) andpower1_input(CurrPwrWatts) values. And this patch adds support for CZ.Signed-off-by Huang Rui <[email protected]>
Applied to hwmon-next.
Thanks,
Guenter
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Huang Rui
maintainerPATCH 2/15 hwmon, fam15h_power: rename fam15h_power_is_internal_node0 function
In reply to Huang RuiWe 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.
--- drivers/hwmon/fam15h_power.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/hwmon/fam15h_power.c +2 -2
@@ -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 );
Signature · 7 lines
1.9.1 _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Re: [PATCH 02/15] hwmon, fam15h_power: rename fam15h_power_is_internal_node0 function
Quoted 5 lines · Huang Rui
We rename
fam15h_power_is_internal_node0()function toshould_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 <[email protected]>
Applied to hwmon-next.
Thanks,
Guenter
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Huang Rui
maintainerPATCH 3/15 hwmon, fam15h_power: refactor attributes for dynamically added
In reply to Huang RuiAttributes 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.
--- drivers/hwmon/fam15h_power.c | 49 +++++++++++++++++++++++++++----------------- 1 file changed, 30 insertions(+), 19 deletions(-)
drivers/hwmon/fam15h_power.c +30 -19
@@ -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;
Signature · 7 lines
1.9.1 _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Guenter Roeck
maintainerRe: [PATCH 03/15] hwmon, fam15h_power: refactor attributes for dynamically added
Quoted 14 lines · 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 <[email protected]>--- drivers/hwmon/fam15h_power.c | 49 +++++++++++++++++++++++++++----------------- 1 file changed, 30 insertions(+), 19 deletions(-)drivers/hwmon/fam15h_power.c +0
-0
drivers/hwmon/fam15h_power.c MODULE_LICENSE("GPL"); · line 44
Quoted 4 lines
drivers/hwmon/fam15h_power.c +1
-0@@ -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.
Quoted 34 lines
drivers/hwmon/fam15h_power.c +10
-14+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,
drivers/hwmon/fam15h_power.c static ssize_t show_power_crit(struct device *dev, · line 114
Quoted 10 lines
drivers/hwmon/fam15h_power.c +4
-5+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.
drivers/hwmon/fam15h_power.c static ssize_t show_power_crit(struct device *dev, · line 124
Quoted 10 lines
drivers/hwmon/fam15h_power.c +10
-0+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.
drivers/hwmon/fam15h_power.c static int fam15h_power_probe(struct pci_dev *pdev, · line 233
Quoted 11 lines
drivers/hwmon/fam15h_power.c +4
-0+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().
drivers/hwmon/fam15h_power.c static int fam15h_power_probe(struct pci_dev *pdev, · line 237
Quoted 5 lines
drivers/hwmon/fam15h_power.c +1
-0+fam15h_power_init_data (pdev, data); data->pdev = pdev;
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Huang Rui
maintainerRe: [PATCH 03/15] hwmon, fam15h_power: refactor attributes for dynamically added
Quoted 10 lines · Guenter Roeck
Quoted 9 lines · Huang Rui
drivers/hwmon/fam15h_power.c +0
-0@@ -41,6 +41,8 @@ MODULE_LICENSE("GPL");#define REG_TDP_RUNNING_AVERAGE 0xe0#define REG_TDP_LIMIT3 0xe8
Quoted 5 lines
drivers/hwmon/fam15h_power.c MODULE_LICENSE("GPL"); · line 44
Quoted 1 line
drivers/hwmon/fam15h_power.c +1
-0+#define FAM15H_MIN_POWER_GROUPS 2This 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.
Quoted 4 lines
Quoted 4 lines
drivers/hwmon/fam15h_power.c +4
-0+ 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;
Quoted 9 lines
drivers/hwmon/fam15h_power.c static ssize_t show_power_crit(struct device *dev, · line 124
Quoted 3 lines
drivers/hwmon/fam15h_power.c +3
-0+ + 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_groupandfam15h_power_groupsprobably need to be moved intofam15h_power_datato 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.
Quoted 9 lines
Quoted 9 lines
drivers/hwmon/fam15h_power.c +2
-0+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 ;
Quoted 5 lines
drivers/hwmon/fam15h_power.c static int fam15h_power_probe(struct pci_dev *pdev, · line 233
Quoted 2 lines
drivers/hwmon/fam15h_power.c +2
-0+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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Huang Rui
maintainerPATCH 4/15 hwmon, fam15h_power: update running_avg_capture bit field to 28
In reply to Huang RuiOn Carrizo and later platforms, running_avg_capture bit field is extended to 4:31 (28 bits) from 4:25.
--- drivers/hwmon/fam15h_power.c | 15 +++++++++++++-- 1 file changed, 13 insertions(+), 2 deletions(-)
drivers/hwmon/fam15h_power.c +13 -2
@@ -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),
Signature · 7 lines
1.9.1 _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Re: [PATCH 04/15] hwmon, fam15h_power: update running_avg_capture bit field to 28
Quoted 4 lines · Huang Rui
On Carrizo and later platforms,
running_avg_capturebit field is extended to 4:31 (28 bits) from 4:25.Signed-off-by Huang Rui <[email protected]>
Applied to hwmon-next.
Thanks,
Guenter
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Huang Rui
maintainerPATCH 5/15 hwmon, fam15h_power: enable power1_input on AMD Carrizo
In reply to Huang RuiThis patch enables power1_input attribute for Carrizo platform.
--- drivers/hwmon/fam15h_power.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
drivers/hwmon/fam15h_power.c +7 -2
@@ -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;
Signature · 7 lines
1.9.1 _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Guenter Roeck
maintainerRe: [PATCH 05/15] hwmon, fam15h_power: enable power1_input on AMD Carrizo
Quoted 3 lines · Huang Rui
This patch enables
power1_inputattribute for Carrizo platform.Signed-off-by Huang Rui <[email protected]>
Needs rebase to updated #3, otherwise looks good.
Thanks,
Guenter
Quoted 23 lines
--- drivers/hwmon/fam15h_power.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)drivers/hwmon/fam15h_power.c +4
-1@@ -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,
drivers/hwmon/fam15h_power.c static int fam15h_power_init_attrs(struct pci_dev *pdev) · line 139
Quoted 10 lines
drivers/hwmon/fam15h_power.c +3
-1@@ -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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Huang Rui
maintainerPATCH 6/15 hwmon, fam15h_power: add documentation for new processors support
In reply to Huang RuiThis patch updates description of fam15h_power driver, its scope is extended to family 16h processsors.
--- Documentation/hwmon/fam15h_power | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-)
Documentation/hwmon/fam15h_power +6 -4
@@ -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 <[email protected]>
@@ -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.
Signature · 7 lines
1.9.1 _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Re: [PATCH 06/15] hwmon, fam15h_power: add documentation for new processors support
Quoted 4 lines · Huang Rui
This patch updates description of
fam15h_powerdriver, its scope is extended to family 16h processsors.Signed-off-by Huang Rui <[email protected]>
Applied to hwmon-next.
Thanks,
Guenter
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Huang Rui
maintainerPATCH 7/15 hwmon, fam15h_power: add ratio of Tsample to the PTSC period
In reply to Huang RuiThis 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
--- drivers/hwmon/fam15h_power.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-)
drivers/hwmon/fam15h_power.c +15 -1
@@ -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,
Signature · 7 lines
1.9.1 _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Re: [PATCH 07/15] hwmon, fam15h_power: add ratio of Tsample to the PTSC period
Quoted 9 lines · Huang Rui
This patch adds a member (
cpu_pwr_sample_ratio) offam15h_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 counterSigned-off-by Huang Rui <[email protected]>
Applied to hwmon-next (after fixing spelling error 'detemine').
Thanks,
Guenter
Quoted 36 lines
--- drivers/hwmon/fam15h_power.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-)drivers/hwmon/fam15h_power.c +8
-1@@ -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 ;
drivers/hwmon/fam15h_power.c static void fam15h_power_init_data(struct pci_dev *f4, · line 241
Quoted 10 lines
drivers/hwmon/fam15h_power.c +7
-0+ +/* +* 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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Huang Rui
maintainerPATCH 8/15 hwmon, fam15h_power: add max compute unit accumulated power
In reply to Huang RuiThis patch adds a member in fam15h_power_data which specifies the maximum accumulated power in a compute unit.
--- drivers/hwmon/fam15h_power.c | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-)
drivers/hwmon/fam15h_power.c +20 -4
@@ -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 <[email protected]>" );
@@ -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",
Signature · 7 lines
1.9.1 _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Guenter Roeck
maintainerRe: [PATCH 08/15] hwmon, fam15h_power: add max compute unit accumulated power
Quoted 74 lines · Huang Rui
This patch adds a member in
fam15h_power_datawhich specifies the maximum accumulated power in a compute unit.Signed-off-by Huang Rui <[email protected]>--- drivers/hwmon/fam15h_power.c | 24 ++++++++++++++++++++---- 1 file changed, 20 insertions(+), 4 deletions(-)drivers/hwmon/fam15h_power.c +17
-3@@ -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 <[email protected]>" );@@ -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,
drivers/hwmon/fam15h_power.c static int fam15h_power_probe(struct pci_dev *pdev, · line 281
Quoted 7 lines
drivers/hwmon/fam15h_power.c +3
-1@@ -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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Huang Rui
maintainerPATCH 9/15 x86, amd: add accessor for number of cores per compute unit
In reply to Huang RuiAdd 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.
--- arch/x86/include/asm/processor.h | 1 + arch/x86/kernel/cpu/amd.c | 19 +++++++++++++++++-- 2 files changed, 18 insertions(+), 2 deletions(-)
arch/x86/include/asm/processor.h +1 -0
@@ -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) {
arch/x86/kernel/cpu/amd.c +17 -2
@@ -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)
Signature · 7 lines
1.9.1 _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Guenter Roeck
maintainerRe: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit
Quoted 29 lines · 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_powerdriver.Signed-off-by Huang Rui <[email protected]>--- arch/x86/include/asm/processor.h | 1 + arch/x86/kernel/cpu/amd.c | 19 +++++++++++++++++-- 2 files changed, 18 insertions(+), 2 deletions(-)arch/x86/include/asm/processor.h +1
-0@@ -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) {arch/x86/kernel/cpu/amd.c +0
-0
arch/x86/kernel/cpu/amd.c line 31
Quoted 6 lines
arch/x86/kernel/cpu/amd.c +3
-0@@ -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
Quoted 50 lines
arch/x86/kernel/cpu/amd.c +14
-2static 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)Signature · 1 line
1.9.1
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Huang Rui
maintainerRe: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit
Quoted 33 lines · Guenter Roeck
Quoted 32 lines · 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_powerdriver.Signed-off-by Huang Rui <[email protected]>--- arch/x86/include/asm/processor.h | 1 + arch/x86/kernel/cpu/amd.c | 19 +++++++++++++++++-- 2 files changed, 18 insertions(+), 2 deletions(-)arch/x86/include/asm/processor.h +1
-0@@ -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) {arch/x86/kernel/cpu/amd.c +0
-0@@ -26,6 +26,9 @@*/ static u32 nodes_per_socket =1 ;
Quoted 7 lines
arch/x86/kernel/cpu/amd.c line 31
Quoted 3 lines
arch/x86/kernel/cpu/amd.c +3
-0+/* 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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Borislav Petkov
maintainerRe: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit
In reply to Huang RuiQuoted 11 lines · 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_powerdriver.Signed-off-by Huang Rui <[email protected]>--- 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.
Signature · 5 lines
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--Guenter Roeck
maintainerRe: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit
Quoted 7 lines · Borislav Petkov
Quoted 6 lines · 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_powerdriver.
Quoted 9 lines
Quoted 5 lines
Signed-off-by Huang Rui <[email protected]>--- 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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit
In reply to Borislav PetkovQuoted 7 lines · Borislav Petkov
Quoted 6 lines · 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_powerdriver.
Quoted 8 lines
Quoted 5 lines
Signed-off-by Huang Rui <[email protected]>--- 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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Borislav Petkov
maintainerRe: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit
Quoted 1 line · Ingo Molnar
Looks good to me in theory.
Thanks.
Quoted 3 lines
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.
Signature · 5 lines
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--Huang Rui
maintainerRe: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit
In reply to Ingo MolnarQuoted 16 lines · Ingo Molnar
Quoted 13 lines · Borislav Petkov
Quoted 11 lines · 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_powerdriver.Signed-off-by Huang Rui <[email protected]>--- arch/x86/include/asm/processor.h | 1 + arch/x86/kernel/cpu/amd.c | 19 +++++++++++++++++-- 2 files changed, 18 insertions(+), 2 deletions(-)
Quoted 8 lines
Quoted 2 lines
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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit
In reply to Ingo MolnarQuoted 16 lines · Ingo Molnar
Quoted 13 lines · Borislav Petkov
Quoted 11 lines · 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_powerdriver.Signed-off-by Huang Rui <[email protected]>--- arch/x86/include/asm/processor.h | 1 + arch/x86/kernel/cpu/amd.c | 19 +++++++++++++++++-- 2 files changed, 18 insertions(+), 2 deletions(-)
Quoted 7 lines
Quoted 2 lines
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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Borislav Petkov
maintainerRe: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit
Quoted 4 lines · Ingo Molnar
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.
Signature · 10 lines
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensorsRe: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit
Quoted 10 lines · Borislav Petkov
Quoted 4 lines · Ingo Molnar
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_powerdriver 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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Guenter Roeck
maintainerRe: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit
Quoted 12 lines · Peter Zijlstra
Quoted 10 lines · Borislav Petkov
Quoted 4 lines · Ingo Molnar
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_powerdriver 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.
Quoted 6 lines
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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit
Quoted 13 lines · Guenter Roeck
Quoted 12 lines · Peter Zijlstra
Quoted 10 lines · Borislav Petkov
Quoted 4 lines · Ingo Molnar
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_powerdriver 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.
Quoted 8 lines
Quoted 6 lines
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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Guenter Roeck
maintainerRe: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit
Quoted 16 lines · Peter Zijlstra
Quoted 15 lines · Guenter Roeck
Quoted 14 lines · Peter Zijlstra
Quoted 10 lines · Borislav Petkov
Quoted 4 lines · Ingo Molnar
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_powerdriver 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.
Quoted 9 lines
Quoted 6 lines
Quoted 4 lines
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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit
Quoted 6 lines · Guenter Roeck
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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Guenter Roeck
maintainerRe: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit
Quoted 9 lines · Peter Zijlstra
Quoted 6 lines · Guenter Roeck
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.
Quoted 3 lines
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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Borislav Petkov
maintainerRe: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit
In reply to Peter ZijlstraQuoted 2 lines · Peter Zijlstra
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.
Quoted 1 line
-- which is all hwmon seems capable of.
I guess we can do both - perf and hwmon. I don't see why not.
Quoted 2 lines
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.
Signature · 5 lines
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--Guenter Roeck
maintainerRe: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit
Quoted 10 lines · Borislav Petkov
Quoted 2 lines · Peter Zijlstra
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.
Quoted 1 line
-- which is all hwmon seems capable of.
Quoted 9 lines
I guess we can do both - perf and hwmon. I don't see why not.
Quoted 2 lines
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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Re: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit
Quoted 10 lines · Guenter Roeck
Quoted 4 lines · Borislav Petkov
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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Guenter Roeck
maintainerRe: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit
Quoted 25 lines · Peter Zijlstra
Quoted 10 lines · Guenter Roeck
Quoted 4 lines · Borislav Petkov
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:
Quoted 9 lines
for ((i=0; i<1000; i++)); do (while :; do cat /sys/foo/file > /dev/null ; done) & doneEven 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.
Quoted 5 lines
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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Borislav Petkov
maintainerRe: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit
Quoted 4 lines · Guenter Roeck
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...
Signature · 5 lines
Regards/Gruss,
Boris.
ECO tip #101: Trim your mails when you reply.
--Guenter Roeck
maintainerRe: [PATCH 09/15] x86, amd: add accessor for number of cores per compute unit
Quoted 11 lines · Borislav Petkov
Quoted 4 lines · Guenter Roeck
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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Huang Rui
maintainerPATCH 10/15 hwmon, fam15h_power: add compute unit accumulated power
In reply to Huang RuiThis patch adds a member in fam15h_power_data which specifies the compute unit accumulated power.
--- drivers/hwmon/fam15h_power.c | 31 +++++++++++++++++++++++++++---- 1 file changed, 27 insertions(+), 4 deletions(-)
drivers/hwmon/fam15h_power.c +27 -4
@@ -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 0xc001007bstruct 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;
Signature · 7 lines
1.9.1 _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Re: [PATCH 10/15] hwmon, fam15h_power: add compute unit accumulated power
Quoted 40 lines · Huang Rui
This patch adds a member in
fam15h_power_datawhich specifies the compute unit accumulated power.Signed-off-by Huang Rui <[email protected]>--- drivers/hwmon/fam15h_power.c | 31 +++++++++++++++++++++++++++---- 1 file changed, 27 insertions(+), 4 deletions(-)drivers/hwmon/fam15h_power.c +5
-0@@ -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 0xc001007bstruct 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;
drivers/hwmon/fam15h_power.c static int fam15h_power_init_data(struct pci_dev *f4, · line 262
Quoted 9 lines
drivers/hwmon/fam15h_power.c +6
-0@@ -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?
drivers/hwmon/fam15h_power.c static int fam15h_power_init_data(struct pci_dev *f4, · line 267
Quoted 5 lines
drivers/hwmon/fam15h_power.c +5
-0+ 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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Huang Rui
maintainerRe: [PATCH 10/15] hwmon, fam15h_power: add compute unit accumulated power
Quoted 7 lines · Ingo Molnar
Quoted 4 lines · Huang Rui
drivers/hwmon/fam15h_power.c +0
-0@@ -249,6 +254,21 @@ static int fam15h_power_init_data(struct pci_dev *f4, data->max_cu_acc_power = tmp;
Quoted 10 lines
drivers/hwmon/fam15h_power.c static int fam15h_power_init_data(struct pci_dev *f4, · line 262
Quoted 6 lines
drivers/hwmon/fam15h_power.c +6
-0+ 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.
Quoted 8 lines
drivers/hwmon/fam15h_power.c static int fam15h_power_init_data(struct pci_dev *f4, · line 267
Quoted 5 lines
drivers/hwmon/fam15h_power.c +5
-0+ 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.
Quoted 2 lines
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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Huang Rui
maintainerPATCH 11/15 hwmon, fam15h_power: add ptsc counter value for accumulated power
In reply to Huang RuiPTSC 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.
--- arch/x86/include/asm/msr-index.h | 1 + drivers/hwmon/fam15h_power.c | 9 +++++++++ 2 files changed, 10 insertions(+)
arch/x86/include/asm/msr-index.h +1 -0
@@ -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
drivers/hwmon/fam15h_power.c +9 -0
@@ -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 ;
Signature · 7 lines
1.9.1 _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Huang Rui
maintainerPATCH 12/15 hwmon, fam15h_power: introduce a cpu accumulated power reporting algorithm
In reply to Huang RuiVGhpcyBwYXRjaCBpbnRyb2R1Y2VzIGFuIGFsZ29yaXRobSB0aGF0IGNvbXB1dGVzIHRoZSBhdmVy 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=
Guenter Roeck
maintainerRe: [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algorithm
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
Huang Rui
maintainerRe: [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algorithm
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
Guenter Roeck
maintainerRe: [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algorithm
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=
Huang Rui
maintainerRe: [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algorithm
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=
Guenter Roeck
maintainerRe: [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algorithm
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
Huang Rui
maintainerRe: [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algorithm
Quoted 115 lines · Guenter Roeck
Quoted 114 lines · Huang Rui
Quoted 96 lines · Guenter Roeck
Quoted 95 lines · Huang Rui
Quoted 93 lines · Guenter Roeck
Quoted 78 lines · 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_accentry to measure the processor power consumption andpower1_accjust 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_accThe result is current average processor power consumption in 10000 seconds. The unit of the result is uWatt.
Signed-off-by Huang Rui <[email protected]>--- drivers/hwmon/fam15h_power.c | 62 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 62 insertions(+)drivers/hwmon/fam15h_power.c +40
-0@@ -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];drivers/hwmon/fam15h_power.c static DEVICE_ATTR(power1_crit, S_IRUGO, show_power_crit, NULL); · line 173
Quoted 10 lines
drivers/hwmon/fam15h_power.c +10
-0+ 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 ?
Quoted 8 lines
Quoted 3 lines
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 =
0xE4E1C0uWatts, 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.
Quoted 7 lines
Quoted 2 lines
So
avg_accis the average power consumption not the accumulated energy.Would
power1_averagethen be better suitable for the attribute ? There is alsopower1_average_intervalwhich 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: [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algorithm
In reply to Huang RuiQuoted 39 lines · Huang Rui
(quoted diff) +39
-0+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];
Review
Quoted 10 lines
(quoted diff) +10
-0+ 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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Re: [PATCH 12/15] hwmon, fam15h_power: introduce a cpu accumulated power reporting algorithm
Quoted 45 lines · Peter Zijlstra
Quoted 44 lines · Huang Rui
(quoted diff) +44
-0+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];
Quoted 8 lines
Review
Quoted 5 lines
(quoted diff) +5
-0+ } + + 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
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Huang Rui
maintainerPATCH 13/15 hwmon, fam15h_power: add documentation for previous TDP reporting
In reply to Huang RuiThis patch adds description to explain the TDP reporting mechanism of fam15h_power driver.
--- Documentation/hwmon/fam15h_power | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
Documentation/hwmon/fam15h_power +9 -1
@@ -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 <[email protected]> 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
Signature · 7 lines
1.9.1 _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Huang Rui
maintainerPATCH 14/15 hwmon, fam15h_power: add documentation for accumulated power algorithm
In reply to Huang RuiThis patch adds the description to explain the accumulated power algorithm.
--- Documentation/hwmon/fam15h_power | 45 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+)
Documentation/hwmon/fam15h_power +45 -0
@@ -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)
Signature · 7 lines
1.9.1 _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Huang Rui
maintainerPATCH 15/15 MAINTAINERS: change the maintainer of fam15h_power driver
In reply to Huang RuiAndreas Herrmann won't take the maintainer of fam15h_power driver. I will take it and appreciate him for the great contributions on this driver.
--- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
MAINTAINERS +2 -2
@@ -601,9 +601,9 @@ F: drivers/crypto/ccp/ F: include/linux/ccp.h AMD FAM15H PROCESSOR POWER MONITORING DRIVER -M: Andreas Herrmann <[email protected]> +M: Huang Rui <[email protected]> L: [email protected] -S: Maintained +S: Supported F: Documentation/hwmon/fam15h_power F: drivers/hwmon/fam15h_power.c
Signature · 7 lines
1.9.1 _______________________________________________ lm-sensors mailing list [email protected] http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Guenter Roeck
maintainerRe: [15/15] MAINTAINERS: change the maintainer of fam15h_power driver
Quoted 6 lines · Huang Rui
Andreas Herrmann won't take the maintainer of
fam15h_powerdriver. I will take it and appreciate him for the great contributions on this driver.Signed-off-by Huang Rui <[email protected]>Cc Andreas Herrmann <[email protected]>
Please add Andreas to CREDITS.
Andreas, can you Ack this change ?
Thanks,
Guenter
Quoted 10 lines
--- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)MAINTAINERS +0
-0@@ -601,9 +601,9 @@ F: drivers/crypto/ccp/ F: include/linux/ccp.h
MAINTAINERS F: drivers/crypto/ccp/ · line 609
Quoted 10 lines
MAINTAINERS +2
-2AMD FAM15H PROCESSOR POWER MONITORING DRIVER -M: Andreas Herrmann <[email protected]> +M: Huang Rui <[email protected]> L: [email protected] -S: Maintained +S: Supported F: Documentation/hwmon/fam15h_power F: drivers/hwmon/fam15h_power.c
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Huang Rui
maintainerRe: [15/15] MAINTAINERS: change the maintainer of fam15h_power driver
Quoted 10 lines · Guenter Roeck
Quoted 6 lines · Huang Rui
Andreas Herrmann won't take the maintainer of
fam15h_powerdriver. I will take it and appreciate him for the great contributions on this driver.Signed-off-by Huang Rui <[email protected]>Cc Andreas Herrmann <[email protected]>Please add Andreas to CREDITS.
OK.
N: Andreas Herrmann
E: [email protected]
E: [email protected]
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
Quoted 16 lines
Andreas, can you Ack this change ?
Thanks,
GuenterQuoted 11 lines
--- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)MAINTAINERS +0
-0@@ -601,9 +601,9 @@ F: drivers/crypto/ccp/ F: include/linux/ccp.h
Quoted 9 lines
MAINTAINERS F: drivers/crypto/ccp/ · line 609
Quoted 9 lines
MAINTAINERS +2
-2AMD FAM15H PROCESSOR POWER MONITORING DRIVER -M: Andreas Herrmann <[email protected]> +M: Huang Rui <[email protected]> L: [email protected] -S: Maintained +S: Supported F: Documentation/hwmon/fam15h_power F: drivers/hwmon/fam15h_power.c
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
Andreas Herrmann
Acked-byRe: [15/15] MAINTAINERS: change the maintainer of fam15h_power driver
In reply to Guenter RoeckQuoted 11 lines · Guenter Roeck
Quoted 6 lines · Huang Rui
Andreas Herrmann won't take the maintainer of
fam15h_powerdriver. I will take it and appreciate him for the great contributions on this driver.Signed-off-by Huang Rui <[email protected]>Cc Andreas Herrmann <[email protected]>Please add Andreas to CREDITS.
Andreas, can you Ack this change ?
Thanks,
Andreas
Quoted 14 lines
Thanks,
GuenterQuoted 11 lines
--- MAINTAINERS | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)MAINTAINERS +0
-0@@ -601,9 +601,9 @@ F: drivers/crypto/ccp/ F: include/linux/ccp.h
Quoted 9 lines
MAINTAINERS F: drivers/crypto/ccp/ · line 609
Quoted 9 lines
MAINTAINERS +2
-2AMD FAM15H PROCESSOR POWER MONITORING DRIVER -M: Andreas Herrmann <[email protected]> +M: Huang Rui <[email protected]> L: [email protected] -S: Maintained +S: Supported F: Documentation/hwmon/fam15h_power F: drivers/hwmon/fam15h_power.c
_______________________________________________
lm-sensors mailing list
[email protected]
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors