All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Poosa, Karthik" <karthik.poosa@intel.com>
To: "Nilawar, Badal" <badal.nilawar@intel.com>,
	<intel-xe@lists.freedesktop.org>
Cc: <anshuman.gupta@intel.com>, <riana.tauro@intel.com>,
	<rodrigo.vivi@intel.com>
Subject: Re: [PATCH v2] drm/xe/hwmon: Add SW clamp for power limits writes
Date: Thu, 7 Aug 2025 17:20:54 +0530	[thread overview]
Message-ID: <0e2bc35d-34a8-46fb-bf59-e8b32412b35d@intel.com> (raw)
In-Reply-To: <bbbc9ff9-3547-4e5c-a491-3768cbbdb820@intel.com>

[-- Attachment #1: Type: text/plain, Size: 4690 bytes --]


On 07-08-2025 16:52, Nilawar, Badal wrote:
>
>
> On 07-08-2025 16:39, Poosa, Karthik wrote:
>>
>> On 07-08-2025 16:03, Nilawar, Badal wrote:
>>>
>>> On 06-08-2025 22:56, Karthik Poosa wrote:
>>>> Clamp writes to power limits powerX_crit/currX_crit, powerX_cap,
>>>> powerX_max, to the maximum supported by the pcode mailbox
>>>> when sysfs-provided values exceed this limit.
>>>> Although the pcode already performs clamping, values beyond the pcode
>>>> mailbox's supported range get truncated, leading to incorrect
>>>> critical power settings.
>>>> This patch ensures proper clamping to prevent such truncation.
>>>>
>>>> v2:
>>>>   - Address below review comments. (Riana)
>>>>   - Split comments into multiple sentences.
>>>>   - Use local variables for readability.
>>>>   - Add a debug log.
>>>>   - Use u64 instead of unsigned long.
>>>>
>>>> Signed-off-by: Karthik Poosa <karthik.poosa@intel.com>
>>>> Fixes: 92d44a422d0d ("drm/xe/hwmon: Expose card reactive critical 
>>>> power")
>>>> Fixes: fb1b70607f73 ("drm/xe/hwmon: Expose power attributes")
>>>> ---
>>>>   drivers/gpu/drm/xe/xe_hwmon.c | 29 +++++++++++++++++++++++++++++
>>>>   1 file changed, 29 insertions(+)
>>>>
>>>> diff --git a/drivers/gpu/drm/xe/xe_hwmon.c 
>>>> b/drivers/gpu/drm/xe/xe_hwmon.c
>>>> index f08fc4377d25..768a942ab0e7 100644
>>>> --- a/drivers/gpu/drm/xe/xe_hwmon.c
>>>> +++ b/drivers/gpu/drm/xe/xe_hwmon.c
>>>> @@ -332,6 +332,7 @@ static int xe_hwmon_power_max_write(struct 
>>>> xe_hwmon *hwmon, u32 attr, int channe
>>>>       int ret = 0;
>>>>       u32 reg_val, max;
>>>>       struct xe_reg rapl_limit;
>>>> +    u64 max_mbx_power_limit = 0;
>>>>         mutex_lock(&hwmon->hwmon_lock);
>>>>   @@ -356,6 +357,20 @@ static int xe_hwmon_power_max_write(struct 
>>>> xe_hwmon *hwmon, u32 attr, int channe
>>>>           goto unlock;
>>>>       }
>>>>   +    /*
>>>> +     * If the sysfs value exceeds the pcode mailbox cmd 
>>>> WRITE_PSYSGPU/PACKAGE_POWER_LIMIT
>>>> +     * max supported value, clamp it to the command's max (U12.3 
>>>> format).
>>>> +     * This is to avoid truncation during reg_val calculation 
>>>> below and ensure the valid
>>>> +     * power limit is sent for pcode which would clamp it to 
>>>> card-supported value.
>>>> +     */
>>>> +    max_mbx_power_limit = ((PWR_LIM_VAL) >> 
>>>> hwmon->scl_shift_power) * SF_POWER;
>>>> +    if (value > max_mbx_power_limit) {
>>>> +        value = max_mbx_power_limit;
>>>> +        drm_dbg(&hwmon->xe->drm,
>>>> +            "Sysfs value for ch %d %s exceeds limit; clamped to 
>>>> supported maximum\n",
>>>> +            channel, PWR_ATTR_TO_STR(attr));
>>> Is this debug message still needed?
>>
>> Having this debug message helps to identify clamping from driver due 
>> to oversized sysfs input. I think we can keep it.
>
> If the intention is to surface clamping behavior to users or 
> developers, then this message seems more appropriate as a 
> |drm_info|rather than |drm_dbg|.
>
okay, I shall change to drm_info.
>
> Regards,
> Badal
>
>>
>>>> +    }
>>>> +
>>>>       /* Computation in 64-bits to avoid overflow. Round to 
>>>> nearest. */
>>>>       reg_val = DIV_ROUND_CLOSEST_ULL((u64)value << 
>>>> hwmon->scl_shift_power, SF_POWER);
>>>>   @@ -739,9 +754,23 @@ static int 
>>>> xe_hwmon_power_curr_crit_write(struct xe_hwmon *hwmon, int channel,
>>>>   {
>>>>       int ret;
>>>>       u32 uval;
>>>> +    u64 max_crit_power_curr = 0;
>>>>         mutex_lock(&hwmon->hwmon_lock);
>>>>   +    /*
>>>> +     * If the sysfs value exceeds the pcode mailbox cmd 
>>>> POWER_SETUP_SUBCOMMAND_WRITE_I1
>>>> +     * max supported value, clamp it to the command's max (U10.6 
>>>> format).
>>>> +     * This is to avoid truncation during uval calculation below 
>>>> and ensure the valid power
>>>> +     * limit is sent for pcode which would clamp it to 
>>>> card-supported value.
>>>> +     */
>>>> +    max_crit_power_curr = (POWER_SETUP_I1_DATA_MASK >> 
>>>> POWER_SETUP_I1_SHIFT) * scale_factor;
>>>> +    if (value > max_crit_power_curr) {
>>>> +        value = max_crit_power_curr;
>>>> +        drm_dbg(&hwmon->xe->drm,
>>>> +            "Sysfs value for ch %d exceeds limit; clamped to 
>>>> supported maximum\n",
>>>> +            channel);
>>>
>>> Same question here?
>> same reply as above
>>>
>>> Regards,
>>> Badal
>>>
>>>> +    }
>>>>       uval = DIV_ROUND_CLOSEST_ULL(value << POWER_SETUP_I1_SHIFT, 
>>>> scale_factor);
>>>>       ret = xe_hwmon_pcode_write_i1(hwmon, uval);

[-- Attachment #2: Type: text/html, Size: 8334 bytes --]

      reply	other threads:[~2025-08-07 11:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-06 17:26 [PATCH v2] drm/xe/hwmon: Add SW clamp for power limits writes Karthik Poosa
2025-08-06 18:15 ` ✓ CI.KUnit: success for drm/xe/hwmon: Add SW clamp for power limits writes (rev2) Patchwork
2025-08-06 19:30 ` ✓ Xe.CI.BAT: " Patchwork
2025-08-06 20:39 ` ✓ Xe.CI.Full: " Patchwork
2025-08-07 10:33 ` [PATCH v2] drm/xe/hwmon: Add SW clamp for power limits writes Nilawar, Badal
2025-08-07 11:09   ` Poosa, Karthik
2025-08-07 11:22     ` Nilawar, Badal
2025-08-07 11:50       ` Poosa, Karthik [this message]

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=0e2bc35d-34a8-46fb-bf59-e8b32412b35d@intel.com \
    --to=karthik.poosa@intel.com \
    --cc=anshuman.gupta@intel.com \
    --cc=badal.nilawar@intel.com \
    --cc=intel-xe@lists.freedesktop.org \
    --cc=riana.tauro@intel.com \
    --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.