From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Badal Nilawar <badal.nilawar@intel.com>
Cc: linux-hwmon@vger.kernel.org, linux@roeck-us.net,
rodrigo.vivi@intel.com, intel-xe@lists.freedesktop.org
Subject: Re: [Intel-xe] [PATCH v6 1/5] drm/xe/hwmon: Expose power attributes
Date: Tue, 26 Sep 2023 21:45:43 -0700 [thread overview]
Message-ID: <875y3w1ax4.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <20230925081842.3566834-2-badal.nilawar@intel.com>
On Mon, 25 Sep 2023 01:18:38 -0700, Badal Nilawar wrote:
>
Hi Badal,
> +static int xe_hwmon_process_reg(struct xe_hwmon *hwmon, enum xe_hwmon_reg hwmon_reg,
Maybe xe_hwmon_read_write_reg? process_reg sounds bad. Basically we don't
process a register, we read or write it.
> + enum xe_hwmon_reg_operation operation, u32 *value,
> + u32 clr, u32 set)
> +{
> + struct xe_reg reg;
> +
> + reg.raw = xe_hwmon_get_reg(hwmon, hwmon_reg);
> +
> + if (!reg.raw)
> + return -EOPNOTSUPP;
> +
> + switch (operation) {
> + case REG_READ:
> + *value = xe_mmio_read32(hwmon->gt, reg);
> + return 0;
> + case REG_WRITE:
> + xe_mmio_write32(hwmon->gt, reg, *value);
> + return 0;
> + case REG_RMW:
> + *value = xe_mmio_rmw32(hwmon->gt, reg, clr, set);
> + return 0;
> + default:
> + drm_warn(>_to_xe(hwmon->gt)->drm, "Invalid xe hwmon reg operation: %d\n",
> + operation);
> + return -EOPNOTSUPP;
> + }
> +}
> +
> +int xe_hwmon_process_reg_read64(struct xe_hwmon *hwmon, enum xe_hwmon_reg hwmon_reg, u64 *value)
> +{
> + struct xe_reg reg;
> +
> + reg.raw = xe_hwmon_get_reg(hwmon, hwmon_reg);
> +
> + if (!reg.raw)
> + return -EOPNOTSUPP;
> +
> + *value = xe_mmio_read64_2x32(hwmon->gt, reg);
> +
> + return 0;
We can't make read64 part of enum xe_hwmon_reg_operation?
> +}
> +
> +#define PL1_DISABLE 0
> +
> +/*
> + * HW allows arbitrary PL1 limits to be set but silently clamps these values to
> + * "typical but not guaranteed" min/max values in REG_PKG_POWER_SKU. Follow the
> + * same pattern for sysfs, allow arbitrary PL1 limits to be set but display
> + * clamped values when read.
> + */
> +static int xe_hwmon_power_max_read(struct xe_hwmon *hwmon, long *value)
> +{
> + u32 reg_val;
> + u64 reg_val64, min, max;
> +
> + xe_hwmon_process_reg(hwmon, REG_PKG_RAPL_LIMIT, REG_READ, ®_val, 0, 0);
> + /* Check if PL1 limit is disabled */
> + if (!(reg_val & PKG_PWR_LIM_1_EN)) {
> + *value = PL1_DISABLE;
> + return 0;
> + }
> +
> + reg_val = REG_FIELD_GET(PKG_PWR_LIM_1, reg_val);
> + *value = mul_u64_u32_shr(reg_val, SF_POWER, hwmon->scl_shift_power);
> +
> + xe_hwmon_process_reg_read64(hwmon, REG_PKG_POWER_SKU, ®_val64);
> + min = REG_FIELD_GET(PKG_MIN_PWR, reg_val64);
> + min = mul_u64_u32_shr(min, SF_POWER, hwmon->scl_shift_power);
> + max = REG_FIELD_GET(PKG_MAX_PWR, reg_val64);
> + max = mul_u64_u32_shr(max, SF_POWER, hwmon->scl_shift_power);
> +
> + if (min && max)
> + *value = clamp_t(u64, *value, min, max);
Not exactly correct. Should be:
if (min)
clamp at min
if (max)
clamp at max
I was thinking of changing it for i915 but was lazy.
> +
> + return 0;
> +}
> +
> +static int xe_hwmon_power_max_write(struct xe_hwmon *hwmon, long value)
> +{
> + u32 reg_val;
> +
> + /* Disable PL1 limit and verify, as limit cannot be disabled on all platforms */
> + if (value == PL1_DISABLE) {
> + xe_hwmon_process_reg(hwmon, REG_PKG_RAPL_LIMIT, REG_RMW, ®_val,
> + PKG_PWR_LIM_1_EN, 0);
> + xe_hwmon_process_reg(hwmon, REG_PKG_RAPL_LIMIT, REG_READ, ®_val,
If we are not checking for return codes from these functions, why are they
not void?
Also, how about separate read/write/rmw functions as Andi was suggesting?
They would be clearer I think.
Thanks.
--
Ashutosh
WARNING: multiple messages have this Message-ID (diff)
From: "Dixit, Ashutosh" <ashutosh.dixit@intel.com>
To: Badal Nilawar <badal.nilawar@intel.com>
Cc: <intel-xe@lists.freedesktop.org>, <linux-hwmon@vger.kernel.org>,
<anshuman.gupta@intel.com>, <linux@roeck-us.net>,
<andi.shyti@linux.intel.com>, <riana.tauro@intel.com>,
<matthew.brost@intel.com>, <rodrigo.vivi@intel.com>
Subject: Re: [PATCH v6 1/5] drm/xe/hwmon: Expose power attributes
Date: Tue, 26 Sep 2023 21:45:43 -0700 [thread overview]
Message-ID: <875y3w1ax4.wl-ashutosh.dixit@intel.com> (raw)
In-Reply-To: <20230925081842.3566834-2-badal.nilawar@intel.com>
On Mon, 25 Sep 2023 01:18:38 -0700, Badal Nilawar wrote:
>
Hi Badal,
> +static int xe_hwmon_process_reg(struct xe_hwmon *hwmon, enum xe_hwmon_reg hwmon_reg,
Maybe xe_hwmon_read_write_reg? process_reg sounds bad. Basically we don't
process a register, we read or write it.
> + enum xe_hwmon_reg_operation operation, u32 *value,
> + u32 clr, u32 set)
> +{
> + struct xe_reg reg;
> +
> + reg.raw = xe_hwmon_get_reg(hwmon, hwmon_reg);
> +
> + if (!reg.raw)
> + return -EOPNOTSUPP;
> +
> + switch (operation) {
> + case REG_READ:
> + *value = xe_mmio_read32(hwmon->gt, reg);
> + return 0;
> + case REG_WRITE:
> + xe_mmio_write32(hwmon->gt, reg, *value);
> + return 0;
> + case REG_RMW:
> + *value = xe_mmio_rmw32(hwmon->gt, reg, clr, set);
> + return 0;
> + default:
> + drm_warn(>_to_xe(hwmon->gt)->drm, "Invalid xe hwmon reg operation: %d\n",
> + operation);
> + return -EOPNOTSUPP;
> + }
> +}
> +
> +int xe_hwmon_process_reg_read64(struct xe_hwmon *hwmon, enum xe_hwmon_reg hwmon_reg, u64 *value)
> +{
> + struct xe_reg reg;
> +
> + reg.raw = xe_hwmon_get_reg(hwmon, hwmon_reg);
> +
> + if (!reg.raw)
> + return -EOPNOTSUPP;
> +
> + *value = xe_mmio_read64_2x32(hwmon->gt, reg);
> +
> + return 0;
We can't make read64 part of enum xe_hwmon_reg_operation?
> +}
> +
> +#define PL1_DISABLE 0
> +
> +/*
> + * HW allows arbitrary PL1 limits to be set but silently clamps these values to
> + * "typical but not guaranteed" min/max values in REG_PKG_POWER_SKU. Follow the
> + * same pattern for sysfs, allow arbitrary PL1 limits to be set but display
> + * clamped values when read.
> + */
> +static int xe_hwmon_power_max_read(struct xe_hwmon *hwmon, long *value)
> +{
> + u32 reg_val;
> + u64 reg_val64, min, max;
> +
> + xe_hwmon_process_reg(hwmon, REG_PKG_RAPL_LIMIT, REG_READ, ®_val, 0, 0);
> + /* Check if PL1 limit is disabled */
> + if (!(reg_val & PKG_PWR_LIM_1_EN)) {
> + *value = PL1_DISABLE;
> + return 0;
> + }
> +
> + reg_val = REG_FIELD_GET(PKG_PWR_LIM_1, reg_val);
> + *value = mul_u64_u32_shr(reg_val, SF_POWER, hwmon->scl_shift_power);
> +
> + xe_hwmon_process_reg_read64(hwmon, REG_PKG_POWER_SKU, ®_val64);
> + min = REG_FIELD_GET(PKG_MIN_PWR, reg_val64);
> + min = mul_u64_u32_shr(min, SF_POWER, hwmon->scl_shift_power);
> + max = REG_FIELD_GET(PKG_MAX_PWR, reg_val64);
> + max = mul_u64_u32_shr(max, SF_POWER, hwmon->scl_shift_power);
> +
> + if (min && max)
> + *value = clamp_t(u64, *value, min, max);
Not exactly correct. Should be:
if (min)
clamp at min
if (max)
clamp at max
I was thinking of changing it for i915 but was lazy.
> +
> + return 0;
> +}
> +
> +static int xe_hwmon_power_max_write(struct xe_hwmon *hwmon, long value)
> +{
> + u32 reg_val;
> +
> + /* Disable PL1 limit and verify, as limit cannot be disabled on all platforms */
> + if (value == PL1_DISABLE) {
> + xe_hwmon_process_reg(hwmon, REG_PKG_RAPL_LIMIT, REG_RMW, ®_val,
> + PKG_PWR_LIM_1_EN, 0);
> + xe_hwmon_process_reg(hwmon, REG_PKG_RAPL_LIMIT, REG_READ, ®_val,
If we are not checking for return codes from these functions, why are they
not void?
Also, how about separate read/write/rmw functions as Andi was suggesting?
They would be clearer I think.
Thanks.
--
Ashutosh
next prev parent reply other threads:[~2023-09-27 4:55 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-25 8:18 [Intel-xe] [PATCH v6 0/5] Add HWMON support for DGFX Badal Nilawar
2023-09-25 8:18 ` Badal Nilawar
2023-09-25 8:18 ` [Intel-xe] [PATCH v6 1/5] drm/xe/hwmon: Expose power attributes Badal Nilawar
2023-09-25 8:18 ` Badal Nilawar
2023-09-25 8:58 ` [Intel-xe] " Andi Shyti
2023-09-25 8:58 ` Andi Shyti
2023-09-27 4:45 ` Dixit, Ashutosh [this message]
2023-09-27 4:45 ` Dixit, Ashutosh
2023-09-27 10:28 ` [Intel-xe] " Nilawar, Badal
2023-09-27 10:28 ` Nilawar, Badal
2023-09-28 4:54 ` [Intel-xe] " Dixit, Ashutosh
2023-09-28 4:54 ` Dixit, Ashutosh
2023-09-27 4:53 ` [Intel-xe] " Dixit, Ashutosh
2023-09-27 4:53 ` Dixit, Ashutosh
2023-09-27 8:39 ` [Intel-xe] " Nilawar, Badal
2023-09-27 8:39 ` Nilawar, Badal
2023-09-28 4:55 ` [Intel-xe] " Dixit, Ashutosh
2023-09-28 4:55 ` Dixit, Ashutosh
2023-09-29 6:37 ` [Intel-xe] " Nilawar, Badal
2023-09-29 6:37 ` Nilawar, Badal
2023-09-29 16:48 ` [Intel-xe] " Dixit, Ashutosh
2023-09-29 16:48 ` Dixit, Ashutosh
2023-09-29 21:41 ` [Intel-xe] " Dixit, Ashutosh
2023-09-29 21:41 ` Dixit, Ashutosh
2023-10-04 0:52 ` [Intel-xe] " Dixit, Ashutosh
2023-10-04 0:52 ` Dixit, Ashutosh
2023-10-04 6:43 ` Nilawar, Badal
2023-10-04 6:43 ` Nilawar, Badal
2023-10-04 15:56 ` Rodrigo Vivi
2023-10-04 15:56 ` Rodrigo Vivi
2023-10-04 16:11 ` Rodrigo Vivi
2023-10-04 16:11 ` Rodrigo Vivi
2023-10-04 10:18 ` Nilawar, Badal
2023-10-04 10:18 ` Nilawar, Badal
2023-09-28 4:55 ` [Intel-xe] " Dixit, Ashutosh
2023-09-28 4:55 ` Dixit, Ashutosh
2023-09-25 8:18 ` [Intel-xe] [PATCH v6 2/5] drm/xe/hwmon: Expose card reactive critical power Badal Nilawar
2023-09-25 8:18 ` Badal Nilawar
2023-09-25 9:03 ` [Intel-xe] " Andi Shyti
2023-09-25 9:03 ` Andi Shyti
2023-09-25 8:18 ` [Intel-xe] [PATCH v6 3/5] drm/xe/hwmon: Expose input voltage attribute Badal Nilawar
2023-09-25 8:18 ` Badal Nilawar
2023-09-25 9:04 ` [Intel-xe] " Andi Shyti
2023-09-25 9:04 ` Andi Shyti
2023-09-25 8:18 ` [Intel-xe] [PATCH v6 4/5] drm/xe/hwmon: Expose hwmon energy attribute Badal Nilawar
2023-09-25 8:18 ` Badal Nilawar
2023-09-25 11:49 ` [Intel-xe] " Andi Shyti
2023-09-25 11:49 ` Andi Shyti
2023-09-25 8:18 ` [Intel-xe] [PATCH v6 5/5] drm/xe/hwmon: Expose power1_max_interval Badal Nilawar
2023-09-25 8:18 ` Badal Nilawar
2023-09-25 11:56 ` [Intel-xe] " Andi Shyti
2023-09-25 11:56 ` Andi Shyti
[not found] ` <e5801f36-2f9a-6d24-7af2-1e7174f2e0b4@intel.com>
2023-09-26 8:01 ` [Intel-xe] " Andi Shyti
2023-09-26 8:01 ` Andi Shyti
2023-09-26 9:00 ` [Intel-xe] " Nilawar, Badal
2023-09-26 9:00 ` Nilawar, Badal
2023-09-26 21:01 ` [Intel-xe] " Andi Shyti
2023-09-26 21:01 ` Andi Shyti
2023-09-27 3:32 ` [Intel-xe] " Dixit, Ashutosh
2023-09-27 3:32 ` Dixit, Ashutosh
2023-09-27 9:04 ` [Intel-xe] " Nilawar, Badal
2023-09-27 9:04 ` Nilawar, Badal
2023-09-27 9:31 ` [Intel-xe] " Gupta, Anshuman
2023-09-27 9:31 ` Gupta, Anshuman
2023-09-25 8:20 ` [Intel-xe] ✓ CI.Patch_applied: success for Add HWMON support for DGFX (rev6) Patchwork
2023-09-25 8:20 ` [Intel-xe] ✗ CI.checkpatch: warning " Patchwork
2023-09-25 8:21 ` [Intel-xe] ✓ CI.KUnit: success " Patchwork
2023-09-25 8:28 ` [Intel-xe] ✓ CI.Build: " Patchwork
2023-09-25 8:28 ` [Intel-xe] ✗ CI.Hooks: failure " Patchwork
2023-09-25 8:30 ` [Intel-xe] ✓ CI.checksparse: success " Patchwork
2023-09-25 9:04 ` [Intel-xe] ✗ CI.BAT: failure " Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875y3w1ax4.wl-ashutosh.dixit@intel.com \
--to=ashutosh.dixit@intel.com \
--cc=badal.nilawar@intel.com \
--cc=intel-xe@lists.freedesktop.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=rodrigo.vivi@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.