* [PATCH v4 0/3] add thermal/power management features for FPGA DFL drivers
@ 2019-06-27 4:53 Wu Hao
2019-06-27 4:53 ` [PATCH v4 1/3] Documentation: fpga: dfl: add descriptions for thermal/power management interfaces Wu Hao
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Wu Hao @ 2019-06-27 4:53 UTC (permalink / raw)
To: mdf, linux-fpga, linux-kernel
Cc: linux-api, linux-hwmon, jdelvare, linux, atull, gregkh, Wu Hao
This patchset adds thermal and power management features for FPGA DFL
drivers. Both patches are using hwmon as userspace interfaces.
Main changes from v3:
- use HWMON_CHANNEL_INFO.
Main changes from v2:
- switch to standard hwmon APIs for thermal hwmon:
temp1_alarm --> temp1_max
temp1_alarm_status --> temp1_max_alarm
temp1_crit_status --> temp1_crit_alarm
temp1_alarm_policy --> temp1_max_policy
- switch to standard hwmon APIs for power hwmon:
power1_cap --> power1_max
power1_cap_status --> power1_max_alarm
power1_crit_status --> power1_crit_alarm
Please note that this patchset is generated on top of this patchset.
[PATCH v4 00/15] add new features for FPGA DFL drivers
- https://lkml.org/lkml/2019/6/27/29
Wu Hao (2):
fpga: dfl: fme: add thermal management support
fpga: dfl: fme: add power management support
Xu Yilun (1):
Documentation: fpga: dfl: add descriptions for thermal/power
management interfaces
Documentation/ABI/testing/sysfs-platform-dfl-fme | 131 ++++++++
Documentation/fpga/dfl.txt | 10 +
drivers/fpga/Kconfig | 2 +-
drivers/fpga/dfl-fme-main.c | 408 +++++++++++++++++++++++
4 files changed, 550 insertions(+), 1 deletion(-)
--
1.8.3.1
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v4 1/3] Documentation: fpga: dfl: add descriptions for thermal/power management interfaces
2019-06-27 4:53 [PATCH v4 0/3] add thermal/power management features for FPGA DFL drivers Wu Hao
@ 2019-06-27 4:53 ` Wu Hao
2019-06-27 4:53 ` [PATCH v4 2/3] fpga: dfl: fme: add thermal management support Wu Hao
2019-06-27 4:53 ` [PATCH v4 3/3] fpga: dfl: fme: add power " Wu Hao
2 siblings, 0 replies; 8+ messages in thread
From: Wu Hao @ 2019-06-27 4:53 UTC (permalink / raw)
To: mdf, linux-fpga, linux-kernel
Cc: linux-api, linux-hwmon, jdelvare, linux, atull, gregkh, Xu Yilun, Wu Hao
From: Xu Yilun <yilun.xu@intel.com>
This patch add introductions to thermal/power interfaces. They are
implemented as hwmon sysfs interfaces by thermal/power private
feature drivers.
Signed-off-by: Xu Yilun <yilun.xu@intel.com>
Signed-off-by: Wu Hao <hao.wu@intel.com>
---
v4: rebased.
---
Documentation/fpga/dfl.txt | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/fpga/dfl.txt b/Documentation/fpga/dfl.txt
index a22631f..652917f 100644
--- a/Documentation/fpga/dfl.txt
+++ b/Documentation/fpga/dfl.txt
@@ -105,6 +105,16 @@ More functions are exposed through sysfs
error reporting sysfs interfaces allow user to read errors detected by the
hardware, and clear the logged errors.
+ Power management (dfl_fme_power hwmon)
+ power management hwmon sysfs interfaces allow user to read power management
+ information (power consumption, thresholds, threshold status, limits, etc.)
+ and configure power thresholds for different throttling levels.
+
+ Thermal management (dfl_fme_thermal hwmon)
+ thermal management hwmon sysfs interfaces allow user to read thermal
+ management information (current temperature, thresholds, threshold status,
+ etc.).
+
FIU - PORT
==========
--
1.8.3.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH v4 2/3] fpga: dfl: fme: add thermal management support
2019-06-27 4:53 [PATCH v4 0/3] add thermal/power management features for FPGA DFL drivers Wu Hao
2019-06-27 4:53 ` [PATCH v4 1/3] Documentation: fpga: dfl: add descriptions for thermal/power management interfaces Wu Hao
@ 2019-06-27 4:53 ` Wu Hao
2019-06-28 17:35 ` Guenter Roeck
2019-06-27 4:53 ` [PATCH v4 3/3] fpga: dfl: fme: add power " Wu Hao
2 siblings, 1 reply; 8+ messages in thread
From: Wu Hao @ 2019-06-27 4:53 UTC (permalink / raw)
To: mdf, linux-fpga, linux-kernel
Cc: linux-api, linux-hwmon, jdelvare, linux, atull, gregkh, Wu Hao,
Luwei Kang, Russ Weight, Xu Yilun
This patch adds support to thermal management private feature for DFL
FPGA Management Engine (FME). This private feature driver registers
a hwmon for thermal/temperature monitoring (hwmon temp1_input).
If hardware automatic throttling is supported by this hardware, then
driver also exposes sysfs interfaces under hwmon for thresholds
(temp1_max/ crit/ emergency), threshold alarms (temp1_max_alarm/
temp1_crit_alarm) and throttling policy (temp1_max_policy).
Signed-off-by: Luwei Kang <luwei.kang@intel.com>
Signed-off-by: Russ Weight <russell.h.weight@intel.com>
Signed-off-by: Xu Yilun <yilun.xu@intel.com>
Signed-off-by: Wu Hao <hao.wu@intel.com>
---
v2: create a dfl_fme_thermal hwmon to expose thermal information.
move all sysfs interfaces under hwmon
tempareture --> hwmon temp1_input
threshold1 --> hwmon temp1_alarm
threshold2 --> hwmon temp1_crit
trip_threshold --> hwmon temp1_emergency
threshold1_status --> hwmon temp1_alarm_status
threshold2_status --> hwmon temp1_crit_status
threshold1_policy --> hwmon temp1_alarm_policy
v3: rename some hwmon sysfs interfaces to follow hwmon ABI.
temp1_alarm --> temp1_max
temp1_alarm_status --> temp1_max_alarm
temp1_crit_status --> temp1_crit_alarm
temp1_alarm_policy --> temp1_max_policy
update sysfs doc for above sysfs interface changes.
replace scnprintf with sprintf in sysfs interface.
v4: use HWMON_CHANNEL_INFO.
rebase, and update date in sysfs doc.
---
Documentation/ABI/testing/sysfs-platform-dfl-fme | 64 ++++++++
drivers/fpga/Kconfig | 2 +-
drivers/fpga/dfl-fme-main.c | 187 +++++++++++++++++++++++
3 files changed, 252 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme b/Documentation/ABI/testing/sysfs-platform-dfl-fme
index 86eef83..2cd17dc 100644
--- a/Documentation/ABI/testing/sysfs-platform-dfl-fme
+++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme
@@ -119,3 +119,67 @@ Description: Write-only. Write error code to this file to clear all errors
logged in errors, first_error and next_error. Write fails with
-EINVAL if input parsing fails or input error code doesn't
match.
+
+What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/name
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao <hao.wu@intel.com>
+Description: Read-Only. Read this file to get the name of hwmon device, it
+ supports values:
+ 'dfl_fme_thermal' - thermal hwmon device name
+
+What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_input
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao <hao.wu@intel.com>
+Description: Read-Only. It returns FPGA device temperature in millidegrees
+ Celsius.
+
+What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_max
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao <hao.wu@intel.com>
+Description: Read-Only. It returns hardware threshold1 temperature in
+ millidegrees Celsius. If temperature rises at or above this
+ threshold, hardware starts 50% or 90% throttling (see
+ 'temp1_max_policy').
+
+What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_crit
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao <hao.wu@intel.com>
+Description: Read-Only. It returns hardware threshold2 temperature in
+ millidegrees Celsius. If temperature rises at or above this
+ threshold, hardware starts 100% throttling.
+
+What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_emergency
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao <hao.wu@intel.com>
+Description: Read-Only. It returns hardware trip threshold temperature in
+ millidegrees Celsius. If temperature rises at or above this
+ threshold, a fatal event will be triggered to board management
+ controller (BMC) to shutdown FPGA.
+
+What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_max_alarm
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao <hao.wu@intel.com>
+Description: Read-only. It returns 1 if temperature is currently at or above
+ hardware threshold1 (see 'temp1_max'), otherwise 0.
+
+What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_crit_alarm
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao <hao.wu@intel.com>
+Description: Read-only. It returns 1 if temperature is currently at or above
+ hardware threshold2 (see 'temp1_crit'), otherwise 0.
+
+What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_max_policy
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao <hao.wu@intel.com>
+Description: Read-Only. Read this file to get the policy of hardware threshold1
+ (see 'temp1_max'). It only supports two values (policies):
+ 0 - AP2 state (90% throttling)
+ 1 - AP1 state (50% throttling)
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index 8072c19..48f6224 100644
--- a/drivers/fpga/Kconfig
+++ b/drivers/fpga/Kconfig
@@ -155,7 +155,7 @@ config FPGA_DFL
config FPGA_DFL_FME
tristate "FPGA DFL FME Driver"
- depends on FPGA_DFL
+ depends on FPGA_DFL && HWMON
help
The FPGA Management Engine (FME) is a feature device implemented
under Device Feature List (DFL) framework. Select this option to
diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
index 4490cf4..59ff9f1 100644
--- a/drivers/fpga/dfl-fme-main.c
+++ b/drivers/fpga/dfl-fme-main.c
@@ -14,6 +14,8 @@
* Henry Mitchel <henry.mitchel@intel.com>
*/
+#include <linux/hwmon.h>
+#include <linux/hwmon-sysfs.h>
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/uaccess.h>
@@ -217,6 +219,187 @@ static long fme_hdr_ioctl(struct platform_device *pdev,
.ioctl = fme_hdr_ioctl,
};
+#define FME_THERM_THRESHOLD 0x8
+#define TEMP_THRESHOLD1 GENMASK_ULL(6, 0)
+#define TEMP_THRESHOLD1_EN BIT_ULL(7)
+#define TEMP_THRESHOLD2 GENMASK_ULL(14, 8)
+#define TEMP_THRESHOLD2_EN BIT_ULL(15)
+#define TRIP_THRESHOLD GENMASK_ULL(30, 24)
+#define TEMP_THRESHOLD1_STATUS BIT_ULL(32) /* threshold1 reached */
+#define TEMP_THRESHOLD2_STATUS BIT_ULL(33) /* threshold2 reached */
+/* threshold1 policy: 0 - AP2 (90% throttle) / 1 - AP1 (50% throttle) */
+#define TEMP_THRESHOLD1_POLICY BIT_ULL(44)
+
+#define FME_THERM_RDSENSOR_FMT1 0x10
+#define FPGA_TEMPERATURE GENMASK_ULL(6, 0)
+
+#define FME_THERM_CAP 0x20
+#define THERM_NO_THROTTLE BIT_ULL(0)
+
+#define MD_PRE_DEG
+
+static bool fme_thermal_throttle_support(void __iomem *base)
+{
+ u64 v = readq(base + FME_THERM_CAP);
+
+ return FIELD_GET(THERM_NO_THROTTLE, v) ? false : true;
+}
+
+static umode_t thermal_hwmon_attrs_visible(const void *drvdata,
+ enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ const struct dfl_feature *feature = drvdata;
+
+ /* temperature is always supported, and check hardware cap for others */
+ if (attr == hwmon_temp_input)
+ return 0444;
+
+ return fme_thermal_throttle_support(feature->ioaddr) ? 0444 : 0;
+}
+
+static int thermal_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long *val)
+{
+ struct dfl_feature *feature = dev_get_drvdata(dev);
+ u64 v;
+
+ switch (attr) {
+ case hwmon_temp_input:
+ v = readq(feature->ioaddr + FME_THERM_RDSENSOR_FMT1);
+ *val = (long)(FIELD_GET(FPGA_TEMPERATURE, v) * 1000);
+ break;
+ case hwmon_temp_max:
+ v = readq(feature->ioaddr + FME_THERM_THRESHOLD);
+ *val = (long)(FIELD_GET(TEMP_THRESHOLD1, v) * 1000);
+ break;
+ case hwmon_temp_crit:
+ v = readq(feature->ioaddr + FME_THERM_THRESHOLD);
+ *val = (long)(FIELD_GET(TEMP_THRESHOLD2, v) * 1000);
+ break;
+ case hwmon_temp_emergency:
+ v = readq(feature->ioaddr + FME_THERM_THRESHOLD);
+ *val = (long)(FIELD_GET(TRIP_THRESHOLD, v) * 1000);
+ break;
+ case hwmon_temp_max_alarm:
+ v = readq(feature->ioaddr + FME_THERM_THRESHOLD);
+ *val = (long)FIELD_GET(TEMP_THRESHOLD1_STATUS, v);
+ break;
+ case hwmon_temp_crit_alarm:
+ v = readq(feature->ioaddr + FME_THERM_THRESHOLD);
+ *val = (long)FIELD_GET(TEMP_THRESHOLD2_STATUS, v);
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ return 0;
+}
+
+static const struct hwmon_ops thermal_hwmon_ops = {
+ .is_visible = thermal_hwmon_attrs_visible,
+ .read = thermal_hwmon_read,
+};
+
+static const struct hwmon_channel_info *thermal_hwmon_info[] = {
+ HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT | HWMON_T_EMERGENCY |
+ HWMON_T_MAX | HWMON_T_MAX_ALARM |
+ HWMON_T_CRIT | HWMON_T_CRIT_ALARM),
+ NULL
+};
+
+static const struct hwmon_chip_info thermal_hwmon_chip_info = {
+ .ops = &thermal_hwmon_ops,
+ .info = thermal_hwmon_info,
+};
+
+static ssize_t temp1_max_policy_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct dfl_feature *feature = dev_get_drvdata(dev);
+ u64 v;
+
+ v = readq(feature->ioaddr + FME_THERM_THRESHOLD);
+
+ return sprintf(buf, "%u\n",
+ (unsigned int)FIELD_GET(TEMP_THRESHOLD1_POLICY, v));
+}
+
+static DEVICE_ATTR_RO(temp1_max_policy);
+
+static struct attribute *thermal_extra_attrs[] = {
+ &dev_attr_temp1_max_policy.attr,
+ NULL,
+};
+
+static umode_t thermal_extra_attrs_visible(struct kobject *kobj,
+ struct attribute *attr, int index)
+{
+ struct device *dev = kobj_to_dev(kobj);
+ struct dfl_feature *feature = dev_get_drvdata(dev);
+
+ return fme_thermal_throttle_support(feature->ioaddr) ? attr->mode : 0;
+}
+
+static const struct attribute_group thermal_extra_group = {
+ .attrs = thermal_extra_attrs,
+ .is_visible = thermal_extra_attrs_visible,
+};
+__ATTRIBUTE_GROUPS(thermal_extra);
+
+static int fme_thermal_mgmt_init(struct platform_device *pdev,
+ struct dfl_feature *feature)
+{
+ struct device *hwmon;
+
+ dev_dbg(&pdev->dev, "FME Thermal Management Init.\n");
+
+ /*
+ * create hwmon to allow userspace monitoring temperature and other
+ * threshold information.
+ *
+ * temp1_input -> FPGA device temperature
+ * temp1_max -> hardware threshold 1 -> 50% or 90% throttling
+ * temp1_crit -> hardware threshold 2 -> 100% throttling
+ * temp1_emergency -> hardware trip_threshold to shutdown FPGA
+ * temp1_max_alarm -> hardware threshold 1 alarm
+ * temp1_crit_alarm -> hardware threshold 2 alarm
+ *
+ * create device specific sysfs interfaces, e.g. read temp1_max_policy
+ * to understand the actual hardware throttling action (50% vs 90%).
+ *
+ * If hardware doesn't support automatic throttling per thresholds,
+ * then all above sysfs interfaces are not visible except temp1_input
+ * for temperature.
+ */
+ hwmon = devm_hwmon_device_register_with_info(&pdev->dev,
+ "dfl_fme_thermal", feature,
+ &thermal_hwmon_chip_info,
+ thermal_extra_groups);
+ if (IS_ERR(hwmon)) {
+ dev_err(&pdev->dev, "Fail to register thermal hwmon\n");
+ return PTR_ERR(hwmon);
+ }
+
+ return 0;
+}
+
+static void fme_thermal_mgmt_uinit(struct platform_device *pdev,
+ struct dfl_feature *feature)
+{
+ dev_dbg(&pdev->dev, "FME Thermal Management UInit.\n");
+}
+
+static const struct dfl_feature_id fme_thermal_mgmt_id_table[] = {
+ {.id = FME_FEATURE_ID_THERMAL_MGMT,},
+ {0,}
+};
+
+static const struct dfl_feature_ops fme_thermal_mgmt_ops = {
+ .init = fme_thermal_mgmt_init,
+ .uinit = fme_thermal_mgmt_uinit,
+};
+
static struct dfl_feature_driver fme_feature_drvs[] = {
{
.id_table = fme_hdr_id_table,
@@ -231,6 +414,10 @@ static long fme_hdr_ioctl(struct platform_device *pdev,
.ops = &fme_global_err_ops,
},
{
+ .id_table = fme_thermal_mgmt_id_table,
+ .ops = &fme_thermal_mgmt_ops,
+ },
+ {
.ops = NULL,
},
};
--
1.8.3.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* [PATCH v4 3/3] fpga: dfl: fme: add power management support
2019-06-27 4:53 [PATCH v4 0/3] add thermal/power management features for FPGA DFL drivers Wu Hao
2019-06-27 4:53 ` [PATCH v4 1/3] Documentation: fpga: dfl: add descriptions for thermal/power management interfaces Wu Hao
2019-06-27 4:53 ` [PATCH v4 2/3] fpga: dfl: fme: add thermal management support Wu Hao
@ 2019-06-27 4:53 ` Wu Hao
2019-06-28 17:55 ` Guenter Roeck
2 siblings, 1 reply; 8+ messages in thread
From: Wu Hao @ 2019-06-27 4:53 UTC (permalink / raw)
To: mdf, linux-fpga, linux-kernel
Cc: linux-api, linux-hwmon, jdelvare, linux, atull, gregkh, Wu Hao,
Luwei Kang, Xu Yilun
This patch adds support for power management private feature under
FPGA Management Engine (FME). This private feature driver registers
a hwmon for power (power1_input), thresholds information, e.g.
(power1_max / crit / max_alarm / crit_alarm) and also read-only sysfs
interfaces for other power management information. For configuration,
user could write threshold values via above power1_max / crit sysfs
interface under hwmon too.
Signed-off-by: Luwei Kang <luwei.kang@intel.com>
Signed-off-by: Xu Yilun <yilun.xu@intel.com>
Signed-off-by: Wu Hao <hao.wu@intel.com>
---
v2: create a dfl_fme_power hwmon to expose power sysfs interfaces.
move all sysfs interfaces under hwmon
consumed --> hwmon power1_input
threshold1 --> hwmon power1_cap
threshold2 --> hwmon power1_crit
threshold1_status --> hwmon power1_cap_status
threshold2_status --> hwmon power1_crit_status
xeon_limit --> hwmon power1_xeon_limit
fpga_limit --> hwmon power1_fpga_limit
ltr --> hwmon power1_ltr
v3: rename some hwmon sysfs interfaces to follow hwmon ABI.
power1_cap --> power1_max
power1_cap_status --> power1_max_alarm
power1_crit_status --> power1_crit_alarm
update sysfs doc for above sysfs interface changes.
replace scnprintf with sprintf in sysfs interface.
v4: use HWMON_CHANNEL_INFO.
update date in sysfs doc.
---
Documentation/ABI/testing/sysfs-platform-dfl-fme | 67 +++++++
drivers/fpga/dfl-fme-main.c | 221 +++++++++++++++++++++++
2 files changed, 288 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme b/Documentation/ABI/testing/sysfs-platform-dfl-fme
index 2cd17dc..a669548 100644
--- a/Documentation/ABI/testing/sysfs-platform-dfl-fme
+++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme
@@ -127,6 +127,7 @@ Contact: Wu Hao <hao.wu@intel.com>
Description: Read-Only. Read this file to get the name of hwmon device, it
supports values:
'dfl_fme_thermal' - thermal hwmon device name
+ 'dfl_fme_power' - power hwmon device name
What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_input
Date: June 2019
@@ -183,3 +184,69 @@ Description: Read-Only. Read this file to get the policy of hardware threshold1
(see 'temp1_max'). It only supports two values (policies):
0 - AP2 state (90% throttling)
1 - AP1 state (50% throttling)
+
+What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_input
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao <hao.wu@intel.com>
+Description: Read-Only. It returns current FPGA power consumption in uW.
+
+What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_max
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao <hao.wu@intel.com>
+Description: Read-Write. Read this file to get current hardware power
+ threshold1 in uW. If power consumption rises at or above
+ this threshold, hardware starts 50% throttling.
+ Write this file to set current hardware power threshold1 in uW.
+ As hardware only accepts values in Watts, so input value will
+ be round down per Watts (< 1 watts part will be discarded).
+ Write fails with -EINVAL if input parsing fails or input isn't
+ in the valid range (0 - 127000000 uW).
+
+What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_crit
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao <hao.wu@intel.com>
+Description: Read-Write. Read this file to get current hardware power
+ threshold2 in uW. If power consumption rises at or above
+ this threshold, hardware starts 90% throttling.
+ Write this file to set current hardware power threshold2 in uW.
+ As hardware only accepts values in Watts, so input value will
+ be round down per Watts (< 1 watts part will be discarded).
+ Write fails with -EINVAL if input parsing fails or input isn't
+ in the valid range (0 - 127000000 uW).
+
+What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_max_alarm
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao <hao.wu@intel.com>
+Description: Read-only. It returns 1 if power consumption is currently at or
+ above hardware threshold1 (see 'power1_max'), otherwise 0.
+
+What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_crit_alarm
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao <hao.wu@intel.com>
+Description: Read-only. It returns 1 if power consumption is currently at or
+ above hardware threshold2 (see 'power1_crit'), otherwise 0.
+
+What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_xeon_limit
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao <hao.wu@intel.com>
+Description: Read-Only. It returns power limit for XEON in uW.
+
+What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_fpga_limit
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao <hao.wu@intel.com>
+Description: Read-Only. It returns power limit for FPGA in uW.
+
+What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_ltr
+Date: June 2019
+KernelVersion: 5.3
+Contact: Wu Hao <hao.wu@intel.com>
+Description: Read-only. Read this file to get current Latency Tolerance
+ Reporting (ltr) value. This ltr impacts the CPU low power
+ state in integrated solution.
diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
index 59ff9f1..9225b68 100644
--- a/drivers/fpga/dfl-fme-main.c
+++ b/drivers/fpga/dfl-fme-main.c
@@ -400,6 +400,223 @@ static void fme_thermal_mgmt_uinit(struct platform_device *pdev,
.uinit = fme_thermal_mgmt_uinit,
};
+#define FME_PWR_STATUS 0x8
+#define FME_LATENCY_TOLERANCE BIT_ULL(18)
+#define PWR_CONSUMED GENMASK_ULL(17, 0)
+
+#define FME_PWR_THRESHOLD 0x10
+#define PWR_THRESHOLD1 GENMASK_ULL(6, 0) /* in Watts */
+#define PWR_THRESHOLD2 GENMASK_ULL(14, 8) /* in Watts */
+#define PWR_THRESHOLD_MAX 0x7f /* in Watts */
+#define PWR_THRESHOLD1_STATUS BIT_ULL(16)
+#define PWR_THRESHOLD2_STATUS BIT_ULL(17)
+
+#define FME_PWR_XEON_LIMIT 0x18
+#define XEON_PWR_LIMIT GENMASK_ULL(14, 0) /* in 0.1 Watts */
+#define XEON_PWR_EN BIT_ULL(15)
+#define FME_PWR_FPGA_LIMIT 0x20
+#define FPGA_PWR_LIMIT GENMASK_ULL(14, 0) /* in 0.1 Watts */
+#define FPGA_PWR_EN BIT_ULL(15)
+
+#define PWR_THRESHOLD_MAX_IN_UW (PWR_THRESHOLD_MAX * 1000000)
+
+static int power_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long *val)
+{
+ struct dfl_feature *feature = dev_get_drvdata(dev);
+ u64 v;
+
+ switch (attr) {
+ case hwmon_power_input:
+ v = readq(feature->ioaddr + FME_PWR_STATUS);
+ *val = (long)(FIELD_GET(PWR_CONSUMED, v) * 1000000);
+ break;
+ case hwmon_power_max:
+ v = readq(feature->ioaddr + FME_PWR_THRESHOLD);
+ *val = (long)(FIELD_GET(PWR_THRESHOLD1, v) * 1000000);
+ break;
+ case hwmon_power_crit:
+ v = readq(feature->ioaddr + FME_PWR_THRESHOLD);
+ *val = (long)(FIELD_GET(PWR_THRESHOLD2, v) * 1000000);
+ break;
+ case hwmon_power_max_alarm:
+ v = readq(feature->ioaddr + FME_PWR_THRESHOLD);
+ *val = (long)FIELD_GET(PWR_THRESHOLD1_STATUS, v);
+ break;
+ case hwmon_power_crit_alarm:
+ v = readq(feature->ioaddr + FME_PWR_THRESHOLD);
+ *val = (long)FIELD_GET(PWR_THRESHOLD2_STATUS, v);
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ return 0;
+}
+
+static int power_hwmon_write(struct device *dev, enum hwmon_sensor_types type,
+ u32 attr, int channel, long val)
+{
+ struct dfl_feature_platform_data *pdata = dev_get_platdata(dev->parent);
+ struct dfl_feature *feature = dev_get_drvdata(dev);
+ int ret = 0;
+ u64 v;
+
+ if (val < 0 || val > PWR_THRESHOLD_MAX_IN_UW)
+ return -EINVAL;
+
+ val = val / 1000000;
+
+ mutex_lock(&pdata->lock);
+
+ switch (attr) {
+ case hwmon_power_max:
+ v = readq(feature->ioaddr + FME_PWR_THRESHOLD);
+ v &= ~PWR_THRESHOLD1;
+ v |= FIELD_PREP(PWR_THRESHOLD1, val);
+ writeq(v, feature->ioaddr + FME_PWR_THRESHOLD);
+ break;
+ case hwmon_power_crit:
+ v = readq(feature->ioaddr + FME_PWR_THRESHOLD);
+ v &= ~PWR_THRESHOLD2;
+ v |= FIELD_PREP(PWR_THRESHOLD2, val);
+ writeq(v, feature->ioaddr + FME_PWR_THRESHOLD);
+ break;
+ default:
+ ret = -EOPNOTSUPP;
+ break;
+ }
+
+ mutex_unlock(&pdata->lock);
+
+ return ret;
+}
+
+static umode_t power_hwmon_attrs_visible(const void *drvdata,
+ enum hwmon_sensor_types type,
+ u32 attr, int channel)
+{
+ switch (attr) {
+ case hwmon_power_input:
+ case hwmon_power_max_alarm:
+ case hwmon_power_crit_alarm:
+ return 0444;
+ case hwmon_power_max:
+ case hwmon_power_crit:
+ return 0644;
+ }
+
+ return 0;
+}
+
+static const struct hwmon_ops power_hwmon_ops = {
+ .is_visible = power_hwmon_attrs_visible,
+ .read = power_hwmon_read,
+ .write = power_hwmon_write,
+};
+
+static const struct hwmon_channel_info *power_hwmon_info[] = {
+ HWMON_CHANNEL_INFO(power, HWMON_P_INPUT |
+ HWMON_P_MAX | HWMON_P_MAX_ALARM |
+ HWMON_P_CRIT | HWMON_P_CRIT_ALARM),
+ NULL
+};
+
+static const struct hwmon_chip_info power_hwmon_chip_info = {
+ .ops = &power_hwmon_ops,
+ .info = power_hwmon_info,
+};
+
+static ssize_t power1_xeon_limit_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct dfl_feature *feature = dev_get_drvdata(dev);
+ u16 xeon_limit = 0;
+ u64 v;
+
+ v = readq(feature->ioaddr + FME_PWR_XEON_LIMIT);
+
+ if (FIELD_GET(XEON_PWR_EN, v))
+ xeon_limit = FIELD_GET(XEON_PWR_LIMIT, v);
+
+ return sprintf(buf, "%u\n", xeon_limit * 100000);
+}
+
+static ssize_t power1_fpga_limit_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct dfl_feature *feature = dev_get_drvdata(dev);
+ u16 fpga_limit = 0;
+ u64 v;
+
+ v = readq(feature->ioaddr + FME_PWR_FPGA_LIMIT);
+
+ if (FIELD_GET(FPGA_PWR_EN, v))
+ fpga_limit = FIELD_GET(FPGA_PWR_LIMIT, v);
+
+ return sprintf(buf, "%u\n", fpga_limit * 100000);
+}
+
+static ssize_t power1_ltr_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct dfl_feature *feature = dev_get_drvdata(dev);
+ u64 v;
+
+ v = readq(feature->ioaddr + FME_PWR_STATUS);
+
+ return sprintf(buf, "%u\n",
+ (unsigned int)FIELD_GET(FME_LATENCY_TOLERANCE, v));
+}
+
+static DEVICE_ATTR_RO(power1_xeon_limit);
+static DEVICE_ATTR_RO(power1_fpga_limit);
+static DEVICE_ATTR_RO(power1_ltr);
+
+static struct attribute *power_extra_attrs[] = {
+ &dev_attr_power1_xeon_limit.attr,
+ &dev_attr_power1_fpga_limit.attr,
+ &dev_attr_power1_ltr.attr,
+ NULL
+};
+
+ATTRIBUTE_GROUPS(power_extra);
+
+static int fme_power_mgmt_init(struct platform_device *pdev,
+ struct dfl_feature *feature)
+{
+ struct device *hwmon;
+
+ dev_dbg(&pdev->dev, "FME Power Management Init.\n");
+
+ hwmon = devm_hwmon_device_register_with_info(&pdev->dev,
+ "dfl_fme_power", feature,
+ &power_hwmon_chip_info,
+ power_extra_groups);
+ if (IS_ERR(hwmon)) {
+ dev_err(&pdev->dev, "Fail to register power hwmon\n");
+ return PTR_ERR(hwmon);
+ }
+
+ return 0;
+}
+
+static void fme_power_mgmt_uinit(struct platform_device *pdev,
+ struct dfl_feature *feature)
+{
+ dev_dbg(&pdev->dev, "FME Power Management UInit.\n");
+}
+
+static const struct dfl_feature_id fme_power_mgmt_id_table[] = {
+ {.id = FME_FEATURE_ID_POWER_MGMT,},
+ {0,}
+};
+
+static const struct dfl_feature_ops fme_power_mgmt_ops = {
+ .init = fme_power_mgmt_init,
+ .uinit = fme_power_mgmt_uinit,
+};
+
static struct dfl_feature_driver fme_feature_drvs[] = {
{
.id_table = fme_hdr_id_table,
@@ -418,6 +635,10 @@ static void fme_thermal_mgmt_uinit(struct platform_device *pdev,
.ops = &fme_thermal_mgmt_ops,
},
{
+ .id_table = fme_power_mgmt_id_table,
+ .ops = &fme_power_mgmt_ops,
+ },
+ {
.ops = NULL,
},
};
--
1.8.3.1
^ permalink raw reply related [flat|nested] 8+ messages in thread
* Re: [PATCH v4 2/3] fpga: dfl: fme: add thermal management support
2019-06-27 4:53 ` [PATCH v4 2/3] fpga: dfl: fme: add thermal management support Wu Hao
@ 2019-06-28 17:35 ` Guenter Roeck
0 siblings, 0 replies; 8+ messages in thread
From: Guenter Roeck @ 2019-06-28 17:35 UTC (permalink / raw)
To: Wu Hao
Cc: mdf, linux-fpga, linux-kernel, linux-api, linux-hwmon, jdelvare,
atull, gregkh, Luwei Kang, Russ Weight, Xu Yilun
On Thu, Jun 27, 2019 at 12:53:37PM +0800, Wu Hao wrote:
> This patch adds support to thermal management private feature for DFL
> FPGA Management Engine (FME). This private feature driver registers
> a hwmon for thermal/temperature monitoring (hwmon temp1_input).
> If hardware automatic throttling is supported by this hardware, then
> driver also exposes sysfs interfaces under hwmon for thresholds
> (temp1_max/ crit/ emergency), threshold alarms (temp1_max_alarm/
> temp1_crit_alarm) and throttling policy (temp1_max_policy).
>
> Signed-off-by: Luwei Kang <luwei.kang@intel.com>
> Signed-off-by: Russ Weight <russell.h.weight@intel.com>
> Signed-off-by: Xu Yilun <yilun.xu@intel.com>
> Signed-off-by: Wu Hao <hao.wu@intel.com>
Acked-by: Guenter Roeck <linux@roeck-us.net>
> ---
> v2: create a dfl_fme_thermal hwmon to expose thermal information.
> move all sysfs interfaces under hwmon
> tempareture --> hwmon temp1_input
> threshold1 --> hwmon temp1_alarm
> threshold2 --> hwmon temp1_crit
> trip_threshold --> hwmon temp1_emergency
> threshold1_status --> hwmon temp1_alarm_status
> threshold2_status --> hwmon temp1_crit_status
> threshold1_policy --> hwmon temp1_alarm_policy
> v3: rename some hwmon sysfs interfaces to follow hwmon ABI.
> temp1_alarm --> temp1_max
> temp1_alarm_status --> temp1_max_alarm
> temp1_crit_status --> temp1_crit_alarm
> temp1_alarm_policy --> temp1_max_policy
> update sysfs doc for above sysfs interface changes.
> replace scnprintf with sprintf in sysfs interface.
> v4: use HWMON_CHANNEL_INFO.
> rebase, and update date in sysfs doc.
> ---
> Documentation/ABI/testing/sysfs-platform-dfl-fme | 64 ++++++++
> drivers/fpga/Kconfig | 2 +-
> drivers/fpga/dfl-fme-main.c | 187 +++++++++++++++++++++++
> 3 files changed, 252 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme b/Documentation/ABI/testing/sysfs-platform-dfl-fme
> index 86eef83..2cd17dc 100644
> --- a/Documentation/ABI/testing/sysfs-platform-dfl-fme
> +++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme
> @@ -119,3 +119,67 @@ Description: Write-only. Write error code to this file to clear all errors
> logged in errors, first_error and next_error. Write fails with
> -EINVAL if input parsing fails or input error code doesn't
> match.
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/name
> +Date: June 2019
> +KernelVersion: 5.3
> +Contact: Wu Hao <hao.wu@intel.com>
> +Description: Read-Only. Read this file to get the name of hwmon device, it
> + supports values:
> + 'dfl_fme_thermal' - thermal hwmon device name
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_input
> +Date: June 2019
> +KernelVersion: 5.3
> +Contact: Wu Hao <hao.wu@intel.com>
> +Description: Read-Only. It returns FPGA device temperature in millidegrees
> + Celsius.
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_max
> +Date: June 2019
> +KernelVersion: 5.3
> +Contact: Wu Hao <hao.wu@intel.com>
> +Description: Read-Only. It returns hardware threshold1 temperature in
> + millidegrees Celsius. If temperature rises at or above this
> + threshold, hardware starts 50% or 90% throttling (see
> + 'temp1_max_policy').
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_crit
> +Date: June 2019
> +KernelVersion: 5.3
> +Contact: Wu Hao <hao.wu@intel.com>
> +Description: Read-Only. It returns hardware threshold2 temperature in
> + millidegrees Celsius. If temperature rises at or above this
> + threshold, hardware starts 100% throttling.
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_emergency
> +Date: June 2019
> +KernelVersion: 5.3
> +Contact: Wu Hao <hao.wu@intel.com>
> +Description: Read-Only. It returns hardware trip threshold temperature in
> + millidegrees Celsius. If temperature rises at or above this
> + threshold, a fatal event will be triggered to board management
> + controller (BMC) to shutdown FPGA.
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_max_alarm
> +Date: June 2019
> +KernelVersion: 5.3
> +Contact: Wu Hao <hao.wu@intel.com>
> +Description: Read-only. It returns 1 if temperature is currently at or above
> + hardware threshold1 (see 'temp1_max'), otherwise 0.
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_crit_alarm
> +Date: June 2019
> +KernelVersion: 5.3
> +Contact: Wu Hao <hao.wu@intel.com>
> +Description: Read-only. It returns 1 if temperature is currently at or above
> + hardware threshold2 (see 'temp1_crit'), otherwise 0.
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_max_policy
> +Date: June 2019
> +KernelVersion: 5.3
> +Contact: Wu Hao <hao.wu@intel.com>
> +Description: Read-Only. Read this file to get the policy of hardware threshold1
> + (see 'temp1_max'). It only supports two values (policies):
> + 0 - AP2 state (90% throttling)
> + 1 - AP1 state (50% throttling)
> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> index 8072c19..48f6224 100644
> --- a/drivers/fpga/Kconfig
> +++ b/drivers/fpga/Kconfig
> @@ -155,7 +155,7 @@ config FPGA_DFL
>
> config FPGA_DFL_FME
> tristate "FPGA DFL FME Driver"
> - depends on FPGA_DFL
> + depends on FPGA_DFL && HWMON
> help
> The FPGA Management Engine (FME) is a feature device implemented
> under Device Feature List (DFL) framework. Select this option to
> diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
> index 4490cf4..59ff9f1 100644
> --- a/drivers/fpga/dfl-fme-main.c
> +++ b/drivers/fpga/dfl-fme-main.c
> @@ -14,6 +14,8 @@
> * Henry Mitchel <henry.mitchel@intel.com>
> */
>
> +#include <linux/hwmon.h>
> +#include <linux/hwmon-sysfs.h>
> #include <linux/kernel.h>
> #include <linux/module.h>
> #include <linux/uaccess.h>
> @@ -217,6 +219,187 @@ static long fme_hdr_ioctl(struct platform_device *pdev,
> .ioctl = fme_hdr_ioctl,
> };
>
> +#define FME_THERM_THRESHOLD 0x8
> +#define TEMP_THRESHOLD1 GENMASK_ULL(6, 0)
> +#define TEMP_THRESHOLD1_EN BIT_ULL(7)
> +#define TEMP_THRESHOLD2 GENMASK_ULL(14, 8)
> +#define TEMP_THRESHOLD2_EN BIT_ULL(15)
> +#define TRIP_THRESHOLD GENMASK_ULL(30, 24)
> +#define TEMP_THRESHOLD1_STATUS BIT_ULL(32) /* threshold1 reached */
> +#define TEMP_THRESHOLD2_STATUS BIT_ULL(33) /* threshold2 reached */
> +/* threshold1 policy: 0 - AP2 (90% throttle) / 1 - AP1 (50% throttle) */
> +#define TEMP_THRESHOLD1_POLICY BIT_ULL(44)
> +
> +#define FME_THERM_RDSENSOR_FMT1 0x10
> +#define FPGA_TEMPERATURE GENMASK_ULL(6, 0)
> +
> +#define FME_THERM_CAP 0x20
> +#define THERM_NO_THROTTLE BIT_ULL(0)
> +
> +#define MD_PRE_DEG
> +
> +static bool fme_thermal_throttle_support(void __iomem *base)
> +{
> + u64 v = readq(base + FME_THERM_CAP);
> +
> + return FIELD_GET(THERM_NO_THROTTLE, v) ? false : true;
> +}
> +
> +static umode_t thermal_hwmon_attrs_visible(const void *drvdata,
> + enum hwmon_sensor_types type,
> + u32 attr, int channel)
> +{
> + const struct dfl_feature *feature = drvdata;
> +
> + /* temperature is always supported, and check hardware cap for others */
> + if (attr == hwmon_temp_input)
> + return 0444;
> +
> + return fme_thermal_throttle_support(feature->ioaddr) ? 0444 : 0;
> +}
> +
> +static int thermal_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
> + u32 attr, int channel, long *val)
> +{
> + struct dfl_feature *feature = dev_get_drvdata(dev);
> + u64 v;
> +
> + switch (attr) {
> + case hwmon_temp_input:
> + v = readq(feature->ioaddr + FME_THERM_RDSENSOR_FMT1);
> + *val = (long)(FIELD_GET(FPGA_TEMPERATURE, v) * 1000);
> + break;
> + case hwmon_temp_max:
> + v = readq(feature->ioaddr + FME_THERM_THRESHOLD);
> + *val = (long)(FIELD_GET(TEMP_THRESHOLD1, v) * 1000);
> + break;
> + case hwmon_temp_crit:
> + v = readq(feature->ioaddr + FME_THERM_THRESHOLD);
> + *val = (long)(FIELD_GET(TEMP_THRESHOLD2, v) * 1000);
> + break;
> + case hwmon_temp_emergency:
> + v = readq(feature->ioaddr + FME_THERM_THRESHOLD);
> + *val = (long)(FIELD_GET(TRIP_THRESHOLD, v) * 1000);
> + break;
> + case hwmon_temp_max_alarm:
> + v = readq(feature->ioaddr + FME_THERM_THRESHOLD);
> + *val = (long)FIELD_GET(TEMP_THRESHOLD1_STATUS, v);
> + break;
> + case hwmon_temp_crit_alarm:
> + v = readq(feature->ioaddr + FME_THERM_THRESHOLD);
> + *val = (long)FIELD_GET(TEMP_THRESHOLD2_STATUS, v);
> + break;
> + default:
> + return -EOPNOTSUPP;
> + }
> +
> + return 0;
> +}
> +
> +static const struct hwmon_ops thermal_hwmon_ops = {
> + .is_visible = thermal_hwmon_attrs_visible,
> + .read = thermal_hwmon_read,
> +};
> +
> +static const struct hwmon_channel_info *thermal_hwmon_info[] = {
> + HWMON_CHANNEL_INFO(temp, HWMON_T_INPUT | HWMON_T_EMERGENCY |
> + HWMON_T_MAX | HWMON_T_MAX_ALARM |
> + HWMON_T_CRIT | HWMON_T_CRIT_ALARM),
> + NULL
> +};
> +
> +static const struct hwmon_chip_info thermal_hwmon_chip_info = {
> + .ops = &thermal_hwmon_ops,
> + .info = thermal_hwmon_info,
> +};
> +
> +static ssize_t temp1_max_policy_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct dfl_feature *feature = dev_get_drvdata(dev);
> + u64 v;
> +
> + v = readq(feature->ioaddr + FME_THERM_THRESHOLD);
> +
> + return sprintf(buf, "%u\n",
> + (unsigned int)FIELD_GET(TEMP_THRESHOLD1_POLICY, v));
> +}
> +
> +static DEVICE_ATTR_RO(temp1_max_policy);
> +
> +static struct attribute *thermal_extra_attrs[] = {
> + &dev_attr_temp1_max_policy.attr,
> + NULL,
> +};
> +
> +static umode_t thermal_extra_attrs_visible(struct kobject *kobj,
> + struct attribute *attr, int index)
> +{
> + struct device *dev = kobj_to_dev(kobj);
> + struct dfl_feature *feature = dev_get_drvdata(dev);
> +
> + return fme_thermal_throttle_support(feature->ioaddr) ? attr->mode : 0;
> +}
> +
> +static const struct attribute_group thermal_extra_group = {
> + .attrs = thermal_extra_attrs,
> + .is_visible = thermal_extra_attrs_visible,
> +};
> +__ATTRIBUTE_GROUPS(thermal_extra);
> +
> +static int fme_thermal_mgmt_init(struct platform_device *pdev,
> + struct dfl_feature *feature)
> +{
> + struct device *hwmon;
> +
> + dev_dbg(&pdev->dev, "FME Thermal Management Init.\n");
> +
> + /*
> + * create hwmon to allow userspace monitoring temperature and other
> + * threshold information.
> + *
> + * temp1_input -> FPGA device temperature
> + * temp1_max -> hardware threshold 1 -> 50% or 90% throttling
> + * temp1_crit -> hardware threshold 2 -> 100% throttling
> + * temp1_emergency -> hardware trip_threshold to shutdown FPGA
> + * temp1_max_alarm -> hardware threshold 1 alarm
> + * temp1_crit_alarm -> hardware threshold 2 alarm
> + *
> + * create device specific sysfs interfaces, e.g. read temp1_max_policy
> + * to understand the actual hardware throttling action (50% vs 90%).
> + *
> + * If hardware doesn't support automatic throttling per thresholds,
> + * then all above sysfs interfaces are not visible except temp1_input
> + * for temperature.
> + */
> + hwmon = devm_hwmon_device_register_with_info(&pdev->dev,
> + "dfl_fme_thermal", feature,
> + &thermal_hwmon_chip_info,
> + thermal_extra_groups);
> + if (IS_ERR(hwmon)) {
> + dev_err(&pdev->dev, "Fail to register thermal hwmon\n");
> + return PTR_ERR(hwmon);
> + }
> +
> + return 0;
> +}
> +
> +static void fme_thermal_mgmt_uinit(struct platform_device *pdev,
> + struct dfl_feature *feature)
> +{
> + dev_dbg(&pdev->dev, "FME Thermal Management UInit.\n");
> +}
> +
> +static const struct dfl_feature_id fme_thermal_mgmt_id_table[] = {
> + {.id = FME_FEATURE_ID_THERMAL_MGMT,},
> + {0,}
> +};
> +
> +static const struct dfl_feature_ops fme_thermal_mgmt_ops = {
> + .init = fme_thermal_mgmt_init,
> + .uinit = fme_thermal_mgmt_uinit,
> +};
> +
> static struct dfl_feature_driver fme_feature_drvs[] = {
> {
> .id_table = fme_hdr_id_table,
> @@ -231,6 +414,10 @@ static long fme_hdr_ioctl(struct platform_device *pdev,
> .ops = &fme_global_err_ops,
> },
> {
> + .id_table = fme_thermal_mgmt_id_table,
> + .ops = &fme_thermal_mgmt_ops,
> + },
> + {
> .ops = NULL,
> },
> };
> --
> 1.8.3.1
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v4 3/3] fpga: dfl: fme: add power management support
2019-06-27 4:53 ` [PATCH v4 3/3] fpga: dfl: fme: add power " Wu Hao
@ 2019-06-28 17:55 ` Guenter Roeck
2019-06-29 0:33 ` Wu Hao
0 siblings, 1 reply; 8+ messages in thread
From: Guenter Roeck @ 2019-06-28 17:55 UTC (permalink / raw)
To: Wu Hao
Cc: mdf, linux-fpga, linux-kernel, linux-api, linux-hwmon, jdelvare,
atull, gregkh, Luwei Kang, Xu Yilun
On Thu, Jun 27, 2019 at 12:53:38PM +0800, Wu Hao wrote:
> This patch adds support for power management private feature under
> FPGA Management Engine (FME). This private feature driver registers
> a hwmon for power (power1_input), thresholds information, e.g.
> (power1_max / crit / max_alarm / crit_alarm) and also read-only sysfs
> interfaces for other power management information. For configuration,
> user could write threshold values via above power1_max / crit sysfs
> interface under hwmon too.
>
> Signed-off-by: Luwei Kang <luwei.kang@intel.com>
> Signed-off-by: Xu Yilun <yilun.xu@intel.com>
> Signed-off-by: Wu Hao <hao.wu@intel.com>
> ---
> v2: create a dfl_fme_power hwmon to expose power sysfs interfaces.
> move all sysfs interfaces under hwmon
> consumed --> hwmon power1_input
> threshold1 --> hwmon power1_cap
> threshold2 --> hwmon power1_crit
> threshold1_status --> hwmon power1_cap_status
> threshold2_status --> hwmon power1_crit_status
> xeon_limit --> hwmon power1_xeon_limit
> fpga_limit --> hwmon power1_fpga_limit
How do those limits differ from the other limits ?
We do have powerX_cap and powerX_cap_max, and from the context
it appears that you could possibly at least use power1_cap_max
(and power1_cap instead of power1_max) instead of
power1_fpga_limit.
> ltr --> hwmon power1_ltr
> v3: rename some hwmon sysfs interfaces to follow hwmon ABI.
> power1_cap --> power1_max
> power1_cap_status --> power1_max_alarm
> power1_crit_status --> power1_crit_alarm
power1_cap is standard ABI, and since the value is enforced by HW,
it should be usable.
> update sysfs doc for above sysfs interface changes.
> replace scnprintf with sprintf in sysfs interface.
> v4: use HWMON_CHANNEL_INFO.
> update date in sysfs doc.
> ---
> Documentation/ABI/testing/sysfs-platform-dfl-fme | 67 +++++++
> drivers/fpga/dfl-fme-main.c | 221 +++++++++++++++++++++++
> 2 files changed, 288 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme b/Documentation/ABI/testing/sysfs-platform-dfl-fme
> index 2cd17dc..a669548 100644
> --- a/Documentation/ABI/testing/sysfs-platform-dfl-fme
> +++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme
> @@ -127,6 +127,7 @@ Contact: Wu Hao <hao.wu@intel.com>
> Description: Read-Only. Read this file to get the name of hwmon device, it
> supports values:
> 'dfl_fme_thermal' - thermal hwmon device name
> + 'dfl_fme_power' - power hwmon device name
>
> What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_input
> Date: June 2019
> @@ -183,3 +184,69 @@ Description: Read-Only. Read this file to get the policy of hardware threshold1
> (see 'temp1_max'). It only supports two values (policies):
> 0 - AP2 state (90% throttling)
> 1 - AP1 state (50% throttling)
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_input
> +Date: June 2019
> +KernelVersion: 5.3
> +Contact: Wu Hao <hao.wu@intel.com>
> +Description: Read-Only. It returns current FPGA power consumption in uW.
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_max
> +Date: June 2019
> +KernelVersion: 5.3
> +Contact: Wu Hao <hao.wu@intel.com>
> +Description: Read-Write. Read this file to get current hardware power
> + threshold1 in uW. If power consumption rises at or above
> + this threshold, hardware starts 50% throttling.
> + Write this file to set current hardware power threshold1 in uW.
> + As hardware only accepts values in Watts, so input value will
> + be round down per Watts (< 1 watts part will be discarded).
> + Write fails with -EINVAL if input parsing fails or input isn't
> + in the valid range (0 - 127000000 uW).
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_crit
> +Date: June 2019
> +KernelVersion: 5.3
> +Contact: Wu Hao <hao.wu@intel.com>
> +Description: Read-Write. Read this file to get current hardware power
> + threshold2 in uW. If power consumption rises at or above
> + this threshold, hardware starts 90% throttling.
> + Write this file to set current hardware power threshold2 in uW.
> + As hardware only accepts values in Watts, so input value will
> + be round down per Watts (< 1 watts part will be discarded).
> + Write fails with -EINVAL if input parsing fails or input isn't
> + in the valid range (0 - 127000000 uW).
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_max_alarm
> +Date: June 2019
> +KernelVersion: 5.3
> +Contact: Wu Hao <hao.wu@intel.com>
> +Description: Read-only. It returns 1 if power consumption is currently at or
> + above hardware threshold1 (see 'power1_max'), otherwise 0.
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_crit_alarm
> +Date: June 2019
> +KernelVersion: 5.3
> +Contact: Wu Hao <hao.wu@intel.com>
> +Description: Read-only. It returns 1 if power consumption is currently at or
> + above hardware threshold2 (see 'power1_crit'), otherwise 0.
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_xeon_limit
> +Date: June 2019
> +KernelVersion: 5.3
> +Contact: Wu Hao <hao.wu@intel.com>
> +Description: Read-Only. It returns power limit for XEON in uW.
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_fpga_limit
> +Date: June 2019
> +KernelVersion: 5.3
> +Contact: Wu Hao <hao.wu@intel.com>
> +Description: Read-Only. It returns power limit for FPGA in uW.
> +
> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_ltr
> +Date: June 2019
> +KernelVersion: 5.3
> +Contact: Wu Hao <hao.wu@intel.com>
> +Description: Read-only. Read this file to get current Latency Tolerance
> + Reporting (ltr) value. This ltr impacts the CPU low power
> + state in integrated solution.
Does that attribute add any value without any kind of unit or an explanation
of its meaning ? What is userspace supposed to do with that information ?
Without context, it is just a meaningless number.
Also, it appears that the information is supposed to be passed to power
management via the set_latency_tolerance() callback. If so, it would be
reported there. Would it possibly make more sense to use that interface ?
> diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
> index 59ff9f1..9225b68 100644
> --- a/drivers/fpga/dfl-fme-main.c
> +++ b/drivers/fpga/dfl-fme-main.c
> @@ -400,6 +400,223 @@ static void fme_thermal_mgmt_uinit(struct platform_device *pdev,
> .uinit = fme_thermal_mgmt_uinit,
> };
>
> +#define FME_PWR_STATUS 0x8
> +#define FME_LATENCY_TOLERANCE BIT_ULL(18)
> +#define PWR_CONSUMED GENMASK_ULL(17, 0)
> +
> +#define FME_PWR_THRESHOLD 0x10
> +#define PWR_THRESHOLD1 GENMASK_ULL(6, 0) /* in Watts */
> +#define PWR_THRESHOLD2 GENMASK_ULL(14, 8) /* in Watts */
> +#define PWR_THRESHOLD_MAX 0x7f /* in Watts */
> +#define PWR_THRESHOLD1_STATUS BIT_ULL(16)
> +#define PWR_THRESHOLD2_STATUS BIT_ULL(17)
> +
> +#define FME_PWR_XEON_LIMIT 0x18
> +#define XEON_PWR_LIMIT GENMASK_ULL(14, 0) /* in 0.1 Watts */
> +#define XEON_PWR_EN BIT_ULL(15)
> +#define FME_PWR_FPGA_LIMIT 0x20
> +#define FPGA_PWR_LIMIT GENMASK_ULL(14, 0) /* in 0.1 Watts */
> +#define FPGA_PWR_EN BIT_ULL(15)
> +
> +#define PWR_THRESHOLD_MAX_IN_UW (PWR_THRESHOLD_MAX * 1000000)
> +
> +static int power_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
> + u32 attr, int channel, long *val)
> +{
> + struct dfl_feature *feature = dev_get_drvdata(dev);
> + u64 v;
> +
> + switch (attr) {
> + case hwmon_power_input:
> + v = readq(feature->ioaddr + FME_PWR_STATUS);
> + *val = (long)(FIELD_GET(PWR_CONSUMED, v) * 1000000);
> + break;
> + case hwmon_power_max:
> + v = readq(feature->ioaddr + FME_PWR_THRESHOLD);
> + *val = (long)(FIELD_GET(PWR_THRESHOLD1, v) * 1000000);
> + break;
> + case hwmon_power_crit:
> + v = readq(feature->ioaddr + FME_PWR_THRESHOLD);
> + *val = (long)(FIELD_GET(PWR_THRESHOLD2, v) * 1000000);
> + break;
> + case hwmon_power_max_alarm:
> + v = readq(feature->ioaddr + FME_PWR_THRESHOLD);
> + *val = (long)FIELD_GET(PWR_THRESHOLD1_STATUS, v);
> + break;
> + case hwmon_power_crit_alarm:
> + v = readq(feature->ioaddr + FME_PWR_THRESHOLD);
> + *val = (long)FIELD_GET(PWR_THRESHOLD2_STATUS, v);
> + break;
> + default:
> + return -EOPNOTSUPP;
> + }
> +
> + return 0;
> +}
> +
> +static int power_hwmon_write(struct device *dev, enum hwmon_sensor_types type,
> + u32 attr, int channel, long val)
> +{
> + struct dfl_feature_platform_data *pdata = dev_get_platdata(dev->parent);
> + struct dfl_feature *feature = dev_get_drvdata(dev);
> + int ret = 0;
> + u64 v;
> +
> + if (val < 0 || val > PWR_THRESHOLD_MAX_IN_UW)
> + return -EINVAL;
We usually use clamp_val() in such cases because there is no useful means
for the user to know the valid range.
> +
> + val = val / 1000000;
> +
> + mutex_lock(&pdata->lock);
> +
> + switch (attr) {
> + case hwmon_power_max:
> + v = readq(feature->ioaddr + FME_PWR_THRESHOLD);
> + v &= ~PWR_THRESHOLD1;
> + v |= FIELD_PREP(PWR_THRESHOLD1, val);
> + writeq(v, feature->ioaddr + FME_PWR_THRESHOLD);
> + break;
> + case hwmon_power_crit:
> + v = readq(feature->ioaddr + FME_PWR_THRESHOLD);
> + v &= ~PWR_THRESHOLD2;
> + v |= FIELD_PREP(PWR_THRESHOLD2, val);
> + writeq(v, feature->ioaddr + FME_PWR_THRESHOLD);
> + break;
> + default:
> + ret = -EOPNOTSUPP;
> + break;
> + }
> +
> + mutex_unlock(&pdata->lock);
> +
> + return ret;
> +}
> +
> +static umode_t power_hwmon_attrs_visible(const void *drvdata,
> + enum hwmon_sensor_types type,
> + u32 attr, int channel)
> +{
> + switch (attr) {
> + case hwmon_power_input:
> + case hwmon_power_max_alarm:
> + case hwmon_power_crit_alarm:
> + return 0444;
> + case hwmon_power_max:
> + case hwmon_power_crit:
> + return 0644;
> + }
> +
> + return 0;
> +}
> +
> +static const struct hwmon_ops power_hwmon_ops = {
> + .is_visible = power_hwmon_attrs_visible,
> + .read = power_hwmon_read,
> + .write = power_hwmon_write,
> +};
> +
> +static const struct hwmon_channel_info *power_hwmon_info[] = {
> + HWMON_CHANNEL_INFO(power, HWMON_P_INPUT |
> + HWMON_P_MAX | HWMON_P_MAX_ALARM |
> + HWMON_P_CRIT | HWMON_P_CRIT_ALARM),
> + NULL
> +};
> +
> +static const struct hwmon_chip_info power_hwmon_chip_info = {
> + .ops = &power_hwmon_ops,
> + .info = power_hwmon_info,
> +};
> +
> +static ssize_t power1_xeon_limit_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct dfl_feature *feature = dev_get_drvdata(dev);
> + u16 xeon_limit = 0;
> + u64 v;
> +
> + v = readq(feature->ioaddr + FME_PWR_XEON_LIMIT);
> +
> + if (FIELD_GET(XEON_PWR_EN, v))
> + xeon_limit = FIELD_GET(XEON_PWR_LIMIT, v);
> +
> + return sprintf(buf, "%u\n", xeon_limit * 100000);
> +}
> +
> +static ssize_t power1_fpga_limit_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct dfl_feature *feature = dev_get_drvdata(dev);
> + u16 fpga_limit = 0;
> + u64 v;
> +
> + v = readq(feature->ioaddr + FME_PWR_FPGA_LIMIT);
> +
> + if (FIELD_GET(FPGA_PWR_EN, v))
> + fpga_limit = FIELD_GET(FPGA_PWR_LIMIT, v);
> +
> + return sprintf(buf, "%u\n", fpga_limit * 100000);
> +}
> +
> +static ssize_t power1_ltr_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + struct dfl_feature *feature = dev_get_drvdata(dev);
> + u64 v;
> +
> + v = readq(feature->ioaddr + FME_PWR_STATUS);
> +
> + return sprintf(buf, "%u\n",
> + (unsigned int)FIELD_GET(FME_LATENCY_TOLERANCE, v));
> +}
> +
> +static DEVICE_ATTR_RO(power1_xeon_limit);
> +static DEVICE_ATTR_RO(power1_fpga_limit);
> +static DEVICE_ATTR_RO(power1_ltr);
> +
> +static struct attribute *power_extra_attrs[] = {
> + &dev_attr_power1_xeon_limit.attr,
> + &dev_attr_power1_fpga_limit.attr,
> + &dev_attr_power1_ltr.attr,
> + NULL
> +};
> +
> +ATTRIBUTE_GROUPS(power_extra);
> +
> +static int fme_power_mgmt_init(struct platform_device *pdev,
> + struct dfl_feature *feature)
> +{
> + struct device *hwmon;
> +
> + dev_dbg(&pdev->dev, "FME Power Management Init.\n");
> +
> + hwmon = devm_hwmon_device_register_with_info(&pdev->dev,
> + "dfl_fme_power", feature,
> + &power_hwmon_chip_info,
> + power_extra_groups);
> + if (IS_ERR(hwmon)) {
> + dev_err(&pdev->dev, "Fail to register power hwmon\n");
> + return PTR_ERR(hwmon);
> + }
> +
> + return 0;
> +}
> +
> +static void fme_power_mgmt_uinit(struct platform_device *pdev,
> + struct dfl_feature *feature)
> +{
> + dev_dbg(&pdev->dev, "FME Power Management UInit.\n");
> +}
> +
> +static const struct dfl_feature_id fme_power_mgmt_id_table[] = {
> + {.id = FME_FEATURE_ID_POWER_MGMT,},
> + {0,}
> +};
> +
> +static const struct dfl_feature_ops fme_power_mgmt_ops = {
> + .init = fme_power_mgmt_init,
> + .uinit = fme_power_mgmt_uinit,
> +};
> +
> static struct dfl_feature_driver fme_feature_drvs[] = {
> {
> .id_table = fme_hdr_id_table,
> @@ -418,6 +635,10 @@ static void fme_thermal_mgmt_uinit(struct platform_device *pdev,
> .ops = &fme_thermal_mgmt_ops,
> },
> {
> + .id_table = fme_power_mgmt_id_table,
> + .ops = &fme_power_mgmt_ops,
> + },
> + {
> .ops = NULL,
> },
> };
> --
> 1.8.3.1
>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v4 3/3] fpga: dfl: fme: add power management support
2019-06-28 17:55 ` Guenter Roeck
@ 2019-06-29 0:33 ` Wu Hao
2019-06-29 16:21 ` Guenter Roeck
0 siblings, 1 reply; 8+ messages in thread
From: Wu Hao @ 2019-06-29 0:33 UTC (permalink / raw)
To: Guenter Roeck
Cc: mdf, linux-fpga, linux-kernel, linux-api, linux-hwmon, jdelvare,
atull, gregkh, Luwei Kang, Xu Yilun
On Fri, Jun 28, 2019 at 10:55:14AM -0700, Guenter Roeck wrote:
> On Thu, Jun 27, 2019 at 12:53:38PM +0800, Wu Hao wrote:
> > This patch adds support for power management private feature under
> > FPGA Management Engine (FME). This private feature driver registers
> > a hwmon for power (power1_input), thresholds information, e.g.
> > (power1_max / crit / max_alarm / crit_alarm) and also read-only sysfs
> > interfaces for other power management information. For configuration,
> > user could write threshold values via above power1_max / crit sysfs
> > interface under hwmon too.
> >
> > Signed-off-by: Luwei Kang <luwei.kang@intel.com>
> > Signed-off-by: Xu Yilun <yilun.xu@intel.com>
> > Signed-off-by: Wu Hao <hao.wu@intel.com>
> > ---
> > v2: create a dfl_fme_power hwmon to expose power sysfs interfaces.
> > move all sysfs interfaces under hwmon
> > consumed --> hwmon power1_input
> > threshold1 --> hwmon power1_cap
> > threshold2 --> hwmon power1_crit
> > threshold1_status --> hwmon power1_cap_status
> > threshold2_status --> hwmon power1_crit_status
> > xeon_limit --> hwmon power1_xeon_limit
> > fpga_limit --> hwmon power1_fpga_limit
>
> How do those limits differ from the other limits ?
> We do have powerX_cap and powerX_cap_max, and from the context
> it appears that you could possibly at least use power1_cap_max
> (and power1_cap instead of power1_max) instead of
> power1_fpga_limit.
Thanks a lot for the review and comments.
Actually xeon/fpga_limit are introduced for different purpose. It shows
the power limit of CPU and FPGA, that may be useful in some integrated
solution, e.g. CPU and FPGA shares power. We should never these
interfaces as throttling thresholds.
>
> > ltr --> hwmon power1_ltr
> > v3: rename some hwmon sysfs interfaces to follow hwmon ABI.
> > power1_cap --> power1_max
> > power1_cap_status --> power1_max_alarm
> > power1_crit_status --> power1_crit_alarm
>
> power1_cap is standard ABI, and since the value is enforced by HW,
> it should be usable.
As you see, in thermal management, threshold1 and threshold2 are
mapped to temp1_max_alarm and temp1_crit_alarm. So we feel that if
it will be friendly to user that we keep using max_alarm and crit_alarm
in power management for threshold1 and threshold2 too.
Do you think if we can keep this, or it's better to switch back to
power1_cap?
>
> > update sysfs doc for above sysfs interface changes.
> > replace scnprintf with sprintf in sysfs interface.
> > v4: use HWMON_CHANNEL_INFO.
> > update date in sysfs doc.
> > ---
> > Documentation/ABI/testing/sysfs-platform-dfl-fme | 67 +++++++
> > drivers/fpga/dfl-fme-main.c | 221 +++++++++++++++++++++++
> > 2 files changed, 288 insertions(+)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme b/Documentation/ABI/testing/sysfs-platform-dfl-fme
> > index 2cd17dc..a669548 100644
> > --- a/Documentation/ABI/testing/sysfs-platform-dfl-fme
> > +++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme
> > @@ -127,6 +127,7 @@ Contact: Wu Hao <hao.wu@intel.com>
> > Description: Read-Only. Read this file to get the name of hwmon device, it
> > supports values:
> > 'dfl_fme_thermal' - thermal hwmon device name
> > + 'dfl_fme_power' - power hwmon device name
> >
> > What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_input
> > Date: June 2019
> > @@ -183,3 +184,69 @@ Description: Read-Only. Read this file to get the policy of hardware threshold1
> > (see 'temp1_max'). It only supports two values (policies):
> > 0 - AP2 state (90% throttling)
> > 1 - AP1 state (50% throttling)
> > +
> > +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_input
> > +Date: June 2019
> > +KernelVersion: 5.3
> > +Contact: Wu Hao <hao.wu@intel.com>
> > +Description: Read-Only. It returns current FPGA power consumption in uW.
> > +
> > +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_max
> > +Date: June 2019
> > +KernelVersion: 5.3
> > +Contact: Wu Hao <hao.wu@intel.com>
> > +Description: Read-Write. Read this file to get current hardware power
> > + threshold1 in uW. If power consumption rises at or above
> > + this threshold, hardware starts 50% throttling.
> > + Write this file to set current hardware power threshold1 in uW.
> > + As hardware only accepts values in Watts, so input value will
> > + be round down per Watts (< 1 watts part will be discarded).
> > + Write fails with -EINVAL if input parsing fails or input isn't
> > + in the valid range (0 - 127000000 uW).
> > +
> > +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_crit
> > +Date: June 2019
> > +KernelVersion: 5.3
> > +Contact: Wu Hao <hao.wu@intel.com>
> > +Description: Read-Write. Read this file to get current hardware power
> > + threshold2 in uW. If power consumption rises at or above
> > + this threshold, hardware starts 90% throttling.
> > + Write this file to set current hardware power threshold2 in uW.
> > + As hardware only accepts values in Watts, so input value will
> > + be round down per Watts (< 1 watts part will be discarded).
> > + Write fails with -EINVAL if input parsing fails or input isn't
> > + in the valid range (0 - 127000000 uW).
> > +
> > +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_max_alarm
> > +Date: June 2019
> > +KernelVersion: 5.3
> > +Contact: Wu Hao <hao.wu@intel.com>
> > +Description: Read-only. It returns 1 if power consumption is currently at or
> > + above hardware threshold1 (see 'power1_max'), otherwise 0.
> > +
> > +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_crit_alarm
> > +Date: June 2019
> > +KernelVersion: 5.3
> > +Contact: Wu Hao <hao.wu@intel.com>
> > +Description: Read-only. It returns 1 if power consumption is currently at or
> > + above hardware threshold2 (see 'power1_crit'), otherwise 0.
> > +
> > +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_xeon_limit
> > +Date: June 2019
> > +KernelVersion: 5.3
> > +Contact: Wu Hao <hao.wu@intel.com>
> > +Description: Read-Only. It returns power limit for XEON in uW.
> > +
> > +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_fpga_limit
> > +Date: June 2019
> > +KernelVersion: 5.3
> > +Contact: Wu Hao <hao.wu@intel.com>
> > +Description: Read-Only. It returns power limit for FPGA in uW.
> > +
> > +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_ltr
> > +Date: June 2019
> > +KernelVersion: 5.3
> > +Contact: Wu Hao <hao.wu@intel.com>
> > +Description: Read-only. Read this file to get current Latency Tolerance
> > + Reporting (ltr) value. This ltr impacts the CPU low power
> > + state in integrated solution.
>
> Does that attribute add any value without any kind of unit or an explanation
> of its meaning ? What is userspace supposed to do with that information ?
> Without context, it is just a meaningless number.
I should add more description here, will fix it in the next version.
>
> Also, it appears that the information is supposed to be passed to power
> management via the set_latency_tolerance() callback. If so, it would be
> reported there. Would it possibly make more sense to use that interface ?
If I remember correctly set_latency_tolerance is used to communicate a tolerance
to device, but actually this is a read-only value, to indicate latency tolerance
requirement for memory access from FPGA device, as you know FPGA could be
programmed for different workloads, and different workloads may have different
latency requirements, if workloads in FPGA don't have any need for immediate
memory access, then it would be safe for deeper sleep state of system memory.
>
> > diff --git a/drivers/fpga/dfl-fme-main.c b/drivers/fpga/dfl-fme-main.c
> > index 59ff9f1..9225b68 100644
> > --- a/drivers/fpga/dfl-fme-main.c
> > +++ b/drivers/fpga/dfl-fme-main.c
> > @@ -400,6 +400,223 @@ static void fme_thermal_mgmt_uinit(struct platform_device *pdev,
> > .uinit = fme_thermal_mgmt_uinit,
> > };
> >
> > +#define FME_PWR_STATUS 0x8
> > +#define FME_LATENCY_TOLERANCE BIT_ULL(18)
> > +#define PWR_CONSUMED GENMASK_ULL(17, 0)
> > +
> > +#define FME_PWR_THRESHOLD 0x10
> > +#define PWR_THRESHOLD1 GENMASK_ULL(6, 0) /* in Watts */
> > +#define PWR_THRESHOLD2 GENMASK_ULL(14, 8) /* in Watts */
> > +#define PWR_THRESHOLD_MAX 0x7f /* in Watts */
> > +#define PWR_THRESHOLD1_STATUS BIT_ULL(16)
> > +#define PWR_THRESHOLD2_STATUS BIT_ULL(17)
> > +
> > +#define FME_PWR_XEON_LIMIT 0x18
> > +#define XEON_PWR_LIMIT GENMASK_ULL(14, 0) /* in 0.1 Watts */
> > +#define XEON_PWR_EN BIT_ULL(15)
> > +#define FME_PWR_FPGA_LIMIT 0x20
> > +#define FPGA_PWR_LIMIT GENMASK_ULL(14, 0) /* in 0.1 Watts */
> > +#define FPGA_PWR_EN BIT_ULL(15)
> > +
> > +#define PWR_THRESHOLD_MAX_IN_UW (PWR_THRESHOLD_MAX * 1000000)
> > +
> > +static int power_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
> > + u32 attr, int channel, long *val)
> > +{
> > + struct dfl_feature *feature = dev_get_drvdata(dev);
> > + u64 v;
> > +
> > + switch (attr) {
> > + case hwmon_power_input:
> > + v = readq(feature->ioaddr + FME_PWR_STATUS);
> > + *val = (long)(FIELD_GET(PWR_CONSUMED, v) * 1000000);
> > + break;
> > + case hwmon_power_max:
> > + v = readq(feature->ioaddr + FME_PWR_THRESHOLD);
> > + *val = (long)(FIELD_GET(PWR_THRESHOLD1, v) * 1000000);
> > + break;
> > + case hwmon_power_crit:
> > + v = readq(feature->ioaddr + FME_PWR_THRESHOLD);
> > + *val = (long)(FIELD_GET(PWR_THRESHOLD2, v) * 1000000);
> > + break;
> > + case hwmon_power_max_alarm:
> > + v = readq(feature->ioaddr + FME_PWR_THRESHOLD);
> > + *val = (long)FIELD_GET(PWR_THRESHOLD1_STATUS, v);
> > + break;
> > + case hwmon_power_crit_alarm:
> > + v = readq(feature->ioaddr + FME_PWR_THRESHOLD);
> > + *val = (long)FIELD_GET(PWR_THRESHOLD2_STATUS, v);
> > + break;
> > + default:
> > + return -EOPNOTSUPP;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int power_hwmon_write(struct device *dev, enum hwmon_sensor_types type,
> > + u32 attr, int channel, long val)
> > +{
> > + struct dfl_feature_platform_data *pdata = dev_get_platdata(dev->parent);
> > + struct dfl_feature *feature = dev_get_drvdata(dev);
> > + int ret = 0;
> > + u64 v;
> > +
> > + if (val < 0 || val > PWR_THRESHOLD_MAX_IN_UW)
> > + return -EINVAL;
>
> We usually use clamp_val() in such cases because there is no useful means
> for the user to know the valid range.
Sure. Will fix this in the next version. Thanks for the comments.
Thanks
Hao
>
> > +
> > + val = val / 1000000;
> > +
> > + mutex_lock(&pdata->lock);
> > +
> > + switch (attr) {
> > + case hwmon_power_max:
> > + v = readq(feature->ioaddr + FME_PWR_THRESHOLD);
> > + v &= ~PWR_THRESHOLD1;
> > + v |= FIELD_PREP(PWR_THRESHOLD1, val);
> > + writeq(v, feature->ioaddr + FME_PWR_THRESHOLD);
> > + break;
> > + case hwmon_power_crit:
> > + v = readq(feature->ioaddr + FME_PWR_THRESHOLD);
> > + v &= ~PWR_THRESHOLD2;
> > + v |= FIELD_PREP(PWR_THRESHOLD2, val);
> > + writeq(v, feature->ioaddr + FME_PWR_THRESHOLD);
> > + break;
> > + default:
> > + ret = -EOPNOTSUPP;
> > + break;
> > + }
> > +
> > + mutex_unlock(&pdata->lock);
> > +
> > + return ret;
> > +}
> > +
> > +static umode_t power_hwmon_attrs_visible(const void *drvdata,
> > + enum hwmon_sensor_types type,
> > + u32 attr, int channel)
> > +{
> > + switch (attr) {
> > + case hwmon_power_input:
> > + case hwmon_power_max_alarm:
> > + case hwmon_power_crit_alarm:
> > + return 0444;
> > + case hwmon_power_max:
> > + case hwmon_power_crit:
> > + return 0644;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static const struct hwmon_ops power_hwmon_ops = {
> > + .is_visible = power_hwmon_attrs_visible,
> > + .read = power_hwmon_read,
> > + .write = power_hwmon_write,
> > +};
> > +
> > +static const struct hwmon_channel_info *power_hwmon_info[] = {
> > + HWMON_CHANNEL_INFO(power, HWMON_P_INPUT |
> > + HWMON_P_MAX | HWMON_P_MAX_ALARM |
> > + HWMON_P_CRIT | HWMON_P_CRIT_ALARM),
> > + NULL
> > +};
> > +
> > +static const struct hwmon_chip_info power_hwmon_chip_info = {
> > + .ops = &power_hwmon_ops,
> > + .info = power_hwmon_info,
> > +};
> > +
> > +static ssize_t power1_xeon_limit_show(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + struct dfl_feature *feature = dev_get_drvdata(dev);
> > + u16 xeon_limit = 0;
> > + u64 v;
> > +
> > + v = readq(feature->ioaddr + FME_PWR_XEON_LIMIT);
> > +
> > + if (FIELD_GET(XEON_PWR_EN, v))
> > + xeon_limit = FIELD_GET(XEON_PWR_LIMIT, v);
> > +
> > + return sprintf(buf, "%u\n", xeon_limit * 100000);
> > +}
> > +
> > +static ssize_t power1_fpga_limit_show(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + struct dfl_feature *feature = dev_get_drvdata(dev);
> > + u16 fpga_limit = 0;
> > + u64 v;
> > +
> > + v = readq(feature->ioaddr + FME_PWR_FPGA_LIMIT);
> > +
> > + if (FIELD_GET(FPGA_PWR_EN, v))
> > + fpga_limit = FIELD_GET(FPGA_PWR_LIMIT, v);
> > +
> > + return sprintf(buf, "%u\n", fpga_limit * 100000);
> > +}
> > +
> > +static ssize_t power1_ltr_show(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + struct dfl_feature *feature = dev_get_drvdata(dev);
> > + u64 v;
> > +
> > + v = readq(feature->ioaddr + FME_PWR_STATUS);
> > +
> > + return sprintf(buf, "%u\n",
> > + (unsigned int)FIELD_GET(FME_LATENCY_TOLERANCE, v));
> > +}
> > +
> > +static DEVICE_ATTR_RO(power1_xeon_limit);
> > +static DEVICE_ATTR_RO(power1_fpga_limit);
> > +static DEVICE_ATTR_RO(power1_ltr);
> > +
> > +static struct attribute *power_extra_attrs[] = {
> > + &dev_attr_power1_xeon_limit.attr,
> > + &dev_attr_power1_fpga_limit.attr,
> > + &dev_attr_power1_ltr.attr,
> > + NULL
> > +};
> > +
> > +ATTRIBUTE_GROUPS(power_extra);
> > +
> > +static int fme_power_mgmt_init(struct platform_device *pdev,
> > + struct dfl_feature *feature)
> > +{
> > + struct device *hwmon;
> > +
> > + dev_dbg(&pdev->dev, "FME Power Management Init.\n");
> > +
> > + hwmon = devm_hwmon_device_register_with_info(&pdev->dev,
> > + "dfl_fme_power", feature,
> > + &power_hwmon_chip_info,
> > + power_extra_groups);
> > + if (IS_ERR(hwmon)) {
> > + dev_err(&pdev->dev, "Fail to register power hwmon\n");
> > + return PTR_ERR(hwmon);
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static void fme_power_mgmt_uinit(struct platform_device *pdev,
> > + struct dfl_feature *feature)
> > +{
> > + dev_dbg(&pdev->dev, "FME Power Management UInit.\n");
> > +}
> > +
> > +static const struct dfl_feature_id fme_power_mgmt_id_table[] = {
> > + {.id = FME_FEATURE_ID_POWER_MGMT,},
> > + {0,}
> > +};
> > +
> > +static const struct dfl_feature_ops fme_power_mgmt_ops = {
> > + .init = fme_power_mgmt_init,
> > + .uinit = fme_power_mgmt_uinit,
> > +};
> > +
> > static struct dfl_feature_driver fme_feature_drvs[] = {
> > {
> > .id_table = fme_hdr_id_table,
> > @@ -418,6 +635,10 @@ static void fme_thermal_mgmt_uinit(struct platform_device *pdev,
> > .ops = &fme_thermal_mgmt_ops,
> > },
> > {
> > + .id_table = fme_power_mgmt_id_table,
> > + .ops = &fme_power_mgmt_ops,
> > + },
> > + {
> > .ops = NULL,
> > },
> > };
> > --
> > 1.8.3.1
> >
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v4 3/3] fpga: dfl: fme: add power management support
2019-06-29 0:33 ` Wu Hao
@ 2019-06-29 16:21 ` Guenter Roeck
0 siblings, 0 replies; 8+ messages in thread
From: Guenter Roeck @ 2019-06-29 16:21 UTC (permalink / raw)
To: Wu Hao
Cc: mdf, linux-fpga, linux-kernel, linux-api, linux-hwmon, jdelvare,
atull, gregkh, Luwei Kang, Xu Yilun
On 6/28/19 5:33 PM, Wu Hao wrote:
> On Fri, Jun 28, 2019 at 10:55:14AM -0700, Guenter Roeck wrote:
>> On Thu, Jun 27, 2019 at 12:53:38PM +0800, Wu Hao wrote:
>>> This patch adds support for power management private feature under
>>> FPGA Management Engine (FME). This private feature driver registers
>>> a hwmon for power (power1_input), thresholds information, e.g.
>>> (power1_max / crit / max_alarm / crit_alarm) and also read-only sysfs
>>> interfaces for other power management information. For configuration,
>>> user could write threshold values via above power1_max / crit sysfs
>>> interface under hwmon too.
>>>
>>> Signed-off-by: Luwei Kang <luwei.kang@intel.com>
>>> Signed-off-by: Xu Yilun <yilun.xu@intel.com>
>>> Signed-off-by: Wu Hao <hao.wu@intel.com>
>>> ---
>>> v2: create a dfl_fme_power hwmon to expose power sysfs interfaces.
>>> move all sysfs interfaces under hwmon
>>> consumed --> hwmon power1_input
>>> threshold1 --> hwmon power1_cap
>>> threshold2 --> hwmon power1_crit
>>> threshold1_status --> hwmon power1_cap_status
>>> threshold2_status --> hwmon power1_crit_status
>>> xeon_limit --> hwmon power1_xeon_limit
>>> fpga_limit --> hwmon power1_fpga_limit
>>
>> How do those limits differ from the other limits ?
>> We do have powerX_cap and powerX_cap_max, and from the context
>> it appears that you could possibly at least use power1_cap_max
>> (and power1_cap instead of power1_max) instead of
>> power1_fpga_limit.
>
> Thanks a lot for the review and comments.
>
> Actually xeon/fpga_limit are introduced for different purpose. It shows
> the power limit of CPU and FPGA, that may be useful in some integrated
> solution, e.g. CPU and FPGA shares power. We should never these
> interfaces as throttling thresholds.
>
Ok, your call. Just keep in mind that non-standard attributes won't show
up with the sensors command, and won't be visible for libsensors.
>>
>>> ltr --> hwmon power1_ltr
>>> v3: rename some hwmon sysfs interfaces to follow hwmon ABI.
>>> power1_cap --> power1_max
>>> power1_cap_status --> power1_max_alarm
>>> power1_crit_status --> power1_crit_alarm
>>
>> power1_cap is standard ABI, and since the value is enforced by HW,
>> it should be usable.
>
> As you see, in thermal management, threshold1 and threshold2 are
> mapped to temp1_max_alarm and temp1_crit_alarm. So we feel that if
> it will be friendly to user that we keep using max_alarm and crit_alarm
> in power management for threshold1 and threshold2 too.
>
> Do you think if we can keep this, or it's better to switch back to
> power1_cap?
>
Again, your call.
>
>>
>>> update sysfs doc for above sysfs interface changes.
>>> replace scnprintf with sprintf in sysfs interface.
>>> v4: use HWMON_CHANNEL_INFO.
>>> update date in sysfs doc.
>>> ---
>>> Documentation/ABI/testing/sysfs-platform-dfl-fme | 67 +++++++
>>> drivers/fpga/dfl-fme-main.c | 221 +++++++++++++++++++++++
>>> 2 files changed, 288 insertions(+)
>>>
>>> diff --git a/Documentation/ABI/testing/sysfs-platform-dfl-fme b/Documentation/ABI/testing/sysfs-platform-dfl-fme
>>> index 2cd17dc..a669548 100644
>>> --- a/Documentation/ABI/testing/sysfs-platform-dfl-fme
>>> +++ b/Documentation/ABI/testing/sysfs-platform-dfl-fme
>>> @@ -127,6 +127,7 @@ Contact: Wu Hao <hao.wu@intel.com>
>>> Description: Read-Only. Read this file to get the name of hwmon device, it
>>> supports values:
>>> 'dfl_fme_thermal' - thermal hwmon device name
>>> + 'dfl_fme_power' - power hwmon device name
>>>
>>> What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/temp1_input
>>> Date: June 2019
>>> @@ -183,3 +184,69 @@ Description: Read-Only. Read this file to get the policy of hardware threshold1
>>> (see 'temp1_max'). It only supports two values (policies):
>>> 0 - AP2 state (90% throttling)
>>> 1 - AP1 state (50% throttling)
>>> +
>>> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_input
>>> +Date: June 2019
>>> +KernelVersion: 5.3
>>> +Contact: Wu Hao <hao.wu@intel.com>
>>> +Description: Read-Only. It returns current FPGA power consumption in uW.
>>> +
>>> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_max
>>> +Date: June 2019
>>> +KernelVersion: 5.3
>>> +Contact: Wu Hao <hao.wu@intel.com>
>>> +Description: Read-Write. Read this file to get current hardware power
>>> + threshold1 in uW. If power consumption rises at or above
>>> + this threshold, hardware starts 50% throttling.
>>> + Write this file to set current hardware power threshold1 in uW.
>>> + As hardware only accepts values in Watts, so input value will
>>> + be round down per Watts (< 1 watts part will be discarded).
>>> + Write fails with -EINVAL if input parsing fails or input isn't
>>> + in the valid range (0 - 127000000 uW).
>>> +
>>> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_crit
>>> +Date: June 2019
>>> +KernelVersion: 5.3
>>> +Contact: Wu Hao <hao.wu@intel.com>
>>> +Description: Read-Write. Read this file to get current hardware power
>>> + threshold2 in uW. If power consumption rises at or above
>>> + this threshold, hardware starts 90% throttling.
>>> + Write this file to set current hardware power threshold2 in uW.
>>> + As hardware only accepts values in Watts, so input value will
>>> + be round down per Watts (< 1 watts part will be discarded).
>>> + Write fails with -EINVAL if input parsing fails or input isn't
>>> + in the valid range (0 - 127000000 uW).
>>> +
>>> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_max_alarm
>>> +Date: June 2019
>>> +KernelVersion: 5.3
>>> +Contact: Wu Hao <hao.wu@intel.com>
>>> +Description: Read-only. It returns 1 if power consumption is currently at or
>>> + above hardware threshold1 (see 'power1_max'), otherwise 0.
>>> +
>>> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_crit_alarm
>>> +Date: June 2019
>>> +KernelVersion: 5.3
>>> +Contact: Wu Hao <hao.wu@intel.com>
>>> +Description: Read-only. It returns 1 if power consumption is currently at or
>>> + above hardware threshold2 (see 'power1_crit'), otherwise 0.
>>> +
>>> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_xeon_limit
>>> +Date: June 2019
>>> +KernelVersion: 5.3
>>> +Contact: Wu Hao <hao.wu@intel.com>
>>> +Description: Read-Only. It returns power limit for XEON in uW.
>>> +
>>> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_fpga_limit
>>> +Date: June 2019
>>> +KernelVersion: 5.3
>>> +Contact: Wu Hao <hao.wu@intel.com>
>>> +Description: Read-Only. It returns power limit for FPGA in uW.
>>> +
>>> +What: /sys/bus/platform/devices/dfl-fme.0/hwmon/hwmonX/power1_ltr
>>> +Date: June 2019
>>> +KernelVersion: 5.3
>>> +Contact: Wu Hao <hao.wu@intel.com>
>>> +Description: Read-only. Read this file to get current Latency Tolerance
>>> + Reporting (ltr) value. This ltr impacts the CPU low power
>>> + state in integrated solution.
>>
>> Does that attribute add any value without any kind of unit or an explanation
>> of its meaning ? What is userspace supposed to do with that information ?
>> Without context, it is just a meaningless number.
>
> I should add more description here, will fix it in the next version.
>
>>
>> Also, it appears that the information is supposed to be passed to power
>> management via the set_latency_tolerance() callback. If so, it would be
>> reported there. Would it possibly make more sense to use that interface ?
>
> If I remember correctly set_latency_tolerance is used to communicate a tolerance
> to device, but actually this is a read-only value, to indicate latency tolerance
> requirement for memory access from FPGA device, as you know FPGA could be
> programmed for different workloads, and different workloads may have different
> latency requirements, if workloads in FPGA don't have any need for immediate
> memory access, then it would be safe for deeper sleep state of system memory.
>
Hmm, you are correct. Yes, this attribute could definitely benefit from a more
detailed explanation.
Thanks,
Guenter
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2019-06-29 16:21 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-06-27 4:53 [PATCH v4 0/3] add thermal/power management features for FPGA DFL drivers Wu Hao
2019-06-27 4:53 ` [PATCH v4 1/3] Documentation: fpga: dfl: add descriptions for thermal/power management interfaces Wu Hao
2019-06-27 4:53 ` [PATCH v4 2/3] fpga: dfl: fme: add thermal management support Wu Hao
2019-06-28 17:35 ` Guenter Roeck
2019-06-27 4:53 ` [PATCH v4 3/3] fpga: dfl: fme: add power " Wu Hao
2019-06-28 17:55 ` Guenter Roeck
2019-06-29 0:33 ` Wu Hao
2019-06-29 16:21 ` Guenter Roeck
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).