Received: by 2002:a25:f815:0:0:0:0:0 with SMTP id u21csp3570864ybd; Fri, 28 Jun 2019 10:55:44 -0700 (PDT) X-Google-Smtp-Source: APXvYqxM+Dn+gC2MHX/Np7JUANTWh6xRtVlH2Obx/wvzZGqlzA0lrYji9Mr0ZbCLaGGuqj//Z1FN X-Received: by 2002:a17:902:301:: with SMTP id 1mr5097667pld.323.1561744544005; Fri, 28 Jun 2019 10:55:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1561744543; cv=none; d=google.com; s=arc-20160816; b=FPBe2UJyvUhSPyc3z+5wiQ+Sfv/YuIZtycEeR1NW1dXlxHzCx4qCywCJXAj3QvLkjS BReK1F4Wb8fQQ7gw2XH+/wRbLvRqt1vq0bFMzfHigr2CvdYuztCCZnqq9YRVuqn7nDFm BaArpSxqV6MfQMsswL/Gle5ntfSGVm4ScJiyJFvRHWrB4u2SFQKqF6T3XOAlba5FD9AO 0yBKgnLLR7zLCNw7xEGjxoEKGfEid+fYyccx/a72lvSj0ByUjOP50omMt6TF6DHS3aPS iq5VHFbI9Qro/NzaYwFPu27zEuT7DiJfCdnTuwkB/xUPoT1brBgm561Kg4ewkt6HMNlt fgCw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=5mtqm2h2+VZjGMu4oNeQihR8XXbIQd/Um6Njm+TfFqE=; b=ORU6xHA4SyhPeWXoiTY1x5pBxoiTLu0/diKNjF27WYNCMuazUPzLF/ao06T71RPORJ Fd6YzmhVJfIoy52dRqQy5L6PsEvuWoDieYMQiumbozgKFAQrXBbPjtAsDQPb/1jjg8B3 8PjSwRKdy1ztjdQwhFdyWMAw+N+X/nfzzAWUDuReFljt/fWjJoDKaaoXR2o8lssK4K52 86x6kVoTZUhr7cqi029ldkECTVLSw38uBm1X+SAlK7d1YB20c9ghlwK8jw3gZEXXM/7T 5sorDfA/z09MKtrOVmLXzexVMCrD0/y+B4Kz3JHDHlChoN0T5whKAZEHDswD0odcjMwE NrIg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b="StjXNGZ/"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g2si2597660plp.1.2019.06.28.10.55.27; Fri, 28 Jun 2019 10:55:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b="StjXNGZ/"; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726702AbfF1RzS (ORCPT + 99 others); Fri, 28 Jun 2019 13:55:18 -0400 Received: from mail-pl1-f196.google.com ([209.85.214.196]:43199 "EHLO mail-pl1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726536AbfF1RzR (ORCPT ); Fri, 28 Jun 2019 13:55:17 -0400 Received: by mail-pl1-f196.google.com with SMTP id cl9so3632784plb.10; Fri, 28 Jun 2019 10:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=5mtqm2h2+VZjGMu4oNeQihR8XXbIQd/Um6Njm+TfFqE=; b=StjXNGZ/s4D3bTdmXhpfN87U7/h3E3RyIqSozsesMh3pnnpvEGarSjHtPiZS+tMarN BxmNj91PZHKoYPultodCES7tnpsD8pwZleUbMQk1yW0a9vxukMjs9NXNkJ8+OG4zwRxz l9l4wEEfmCxRqjlGU/0ncBrzYb9jrfv0vOnx75ORY9ORGH838OF8WejfzjVZG/SB+QjB uAykkOE4X07kSwlSHfRAt+AeYjAdAf8UzHQXqRnow0Usdf58Gu74i+7NS6q+g883mdf1 lkeTgIRQPntTJbRMOgKssMeIsRFqZ+8aE8h/h8VT8Ra+0MYUJPy1noRtGiu4kZ0VX5q+ hDCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=5mtqm2h2+VZjGMu4oNeQihR8XXbIQd/Um6Njm+TfFqE=; b=XMJSXVMCHqwiFnkJrMhRggWgrX12uNEg2RMpP2gHLdzN1x8ZJ8YD5C3bMOG784Qaa5 NXobIHt/5b/qySGcH9Jl4LYVntNcPYmZa3fvIFQQLopzns5Q4luiBl88j22olcX7v3XY kjcj/HzTFfFjTbdhPfNQXJIAqccKNYAnK6Puv1t3tOO4bB1gEjMyt8UtiVtq4GbOvXAS ZNRUEbztVU+hNcpDZc+2bVBtnx2YuLZ+VRV0FzosVb5cjNxJuXw5mvLrjo3mw1nvvOEC huy4+w6EDlavsIKltMLJNo5GFw/d/HXqmMMk4KYNGxFEViDIPuSxrWrW+CMQcXhldqKt Y46Q== X-Gm-Message-State: APjAAAX3Eb4BDPt7D1AOyvRq4urIL/7j443hR5RLyjW7HFv0BtS15spC VHMhQpXYlaz1Hvm/dopGP05Ke5Ic X-Received: by 2002:a17:902:54f:: with SMTP id 73mr12804287plf.246.1561744516155; Fri, 28 Jun 2019 10:55:16 -0700 (PDT) Received: from localhost ([2600:1700:e321:62f0:329c:23ff:fee3:9d7c]) by smtp.gmail.com with ESMTPSA id u21sm4091253pfm.70.2019.06.28.10.55.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Jun 2019 10:55:15 -0700 (PDT) Date: Fri, 28 Jun 2019 10:55:14 -0700 From: Guenter Roeck To: Wu Hao Cc: mdf@kernel.org, linux-fpga@vger.kernel.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, linux-hwmon@vger.kernel.org, jdelvare@suse.com, atull@kernel.org, gregkh@linuxfoundation.org, Luwei Kang , Xu Yilun Subject: Re: [PATCH v4 3/3] fpga: dfl: fme: add power management support Message-ID: <20190628175514.GB25890@roeck-us.net> References: <1561611218-5800-1-git-send-email-hao.wu@intel.com> <1561611218-5800-4-git-send-email-hao.wu@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1561611218-5800-4-git-send-email-hao.wu@intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > Signed-off-by: Xu Yilun > Signed-off-by: Wu Hao > --- > 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 > 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 > +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 > +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 > +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 > +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 > +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 > +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 > +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 > +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 >