public inbox for intel-gfx@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Pandruvada, Srinivas" <srinivas.pandruvada@intel.com>
To: "ville.syrjala@linux.intel.com" <ville.syrjala@linux.intel.com>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>
Cc: "Zhang, Rui" <rui.zhang@intel.com>,
	"Wysocki, Rafael J" <rafael.j.wysocki@intel.com>,
	"intel-gfx@lists.freedesktop.org"
	<intel-gfx@lists.freedesktop.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [Intel-gfx] [PATCH] powercap: intel_rapl: Don't warn about BIOS locked limits during resume
Date: Wed, 4 Oct 2023 18:45:22 +0000	[thread overview]
Message-ID: <6d207eef73fb2ad32264921ae7d1a536b6b8da61.camel@intel.com> (raw)
In-Reply-To: <20231004183455.27797-1-ville.syrjala@linux.intel.com>

On Wed, 2023-10-04 at 21:34 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> 
> Restore enough of the original behaviour to stop spamming
> dmesg with warnings about BIOS locked limits when trying
> to restore them during resume.
> 
> This still doesn't 100% match the original behaviour
> as we no longer attempt to blindly restore the BIOS locked
> limits. No idea if that makes any difference in practice.
> 
I lost the context here. Why can't we simply change pr_warn to pr_debug
here?

Thanks,
Srinivas

> Cc: Zhang Rui <rui.zhang@intel.com>
> Cc: Wang Wendy <wendy.wang@intel.com>
> Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Cc: Srinivas Pandruvada <srinivas.pandruvada@intel.com>
> Fixes: 9050a9cd5e4c ("powercap: intel_rapl: Cleanup Power Limits
> support")
> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> ---
>  drivers/powercap/intel_rapl_common.c | 28 ++++++++++++++++++++------
> --
>  1 file changed, 20 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/powercap/intel_rapl_common.c
> b/drivers/powercap/intel_rapl_common.c
> index 40a2cc649c79..9a6a40c83f82 100644
> --- a/drivers/powercap/intel_rapl_common.c
> +++ b/drivers/powercap/intel_rapl_common.c
> @@ -882,22 +882,34 @@ static int rapl_read_pl_data(struct rapl_domain
> *rd, int pl,
>         return rapl_read_data_raw(rd, prim, xlate, data);
>  }
>  
> -static int rapl_write_pl_data(struct rapl_domain *rd, int pl,
> -                              enum pl_prims pl_prim,
> -                              unsigned long long value)
> +static int rapl_write_pl_data_nowarn(struct rapl_domain *rd, int pl,
> +                                    enum pl_prims pl_prim,
> +                                    unsigned long long value)
>  {
>         enum rapl_primitives prim = get_pl_prim(rd, pl, pl_prim);
>  
>         if (!is_pl_valid(rd, pl))
>                 return -EINVAL;
>  
> -       if (rd->rpl[pl].locked) {
> -               pr_warn("%s:%s:%s locked by BIOS\n", rd->rp->name,
> rd->name, pl_names[pl]);
> +       if (rd->rpl[pl].locked)
>                 return -EACCES;
> -       }
>  
>         return rapl_write_data_raw(rd, prim, value);
>  }
> +
> +static int rapl_write_pl_data(struct rapl_domain *rd, int pl,
> +                             enum pl_prims pl_prim,
> +                             unsigned long long value)
> +{
> +       int ret;
> +
> +       ret = rapl_write_pl_data_nowarn(rd, pl, pl_prim, value);
> +       if (ret == -EACCES)
> +               pr_warn("%s:%s:%s locked by BIOS\n", rd->rp->name,
> rd->name, pl_names[pl]);
> +
> +       return ret;
> +}
> +
>  /*
>   * Raw RAPL data stored in MSRs are in certain scales. We need to
>   * convert them into standard units based on the units reported in
> @@ -1634,8 +1646,8 @@ static void power_limit_state_restore(void)
>                 rd = power_zone_to_rapl_domain(rp->power_zone);
>                 for (i = POWER_LIMIT1; i < NR_POWER_LIMITS; i++)
>                         if (rd->rpl[i].last_power_limit)
> -                               rapl_write_pl_data(rd, i, PL_LIMIT,
> -                                              rd-
> >rpl[i].last_power_limit);
> +                               rapl_write_pl_data_nowarn(rd, i,
> PL_LIMIT,
> +                                                         rd-
> >rpl[i].last_power_limit);
>         }
>         cpus_read_unlock();
>  }


  reply	other threads:[~2023-10-04 18:45 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-04 18:34 [Intel-gfx] [PATCH] powercap: intel_rapl: Don't warn about BIOS locked limits during resume Ville Syrjala
2023-10-04 18:45 ` Pandruvada, Srinivas [this message]
2023-10-04 18:59   ` Ville Syrjälä
2023-10-24 17:11     ` Ville Syrjälä
2023-10-24 18:31       ` Rafael J. Wysocki
2023-10-24 18:48         ` Ville Syrjälä
2023-10-24 18:52           ` Rafael J. Wysocki
2023-10-05  0:47 ` [Intel-gfx] ✓ Fi.CI.BAT: success for " Patchwork
2023-10-05 12:02 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2023-10-24 19:17 ` [Intel-gfx] [PATCH v2] powercap: intel_rapl: Downgrade BIOS locked limits pr_warn() to pr_debug() Ville Syrjala
2023-10-24 20:08   ` Rafael J. Wysocki
2023-10-25  5:54 ` [Intel-gfx] ✓ Fi.CI.BAT: success for powercap: intel_rapl: Don't warn about BIOS locked limits during resume (rev2) Patchwork
2023-10-25 21:50 ` [Intel-gfx] ✗ Fi.CI.IGT: 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=6d207eef73fb2ad32264921ae7d1a536b6b8da61.camel@intel.com \
    --to=srinivas.pandruvada@intel.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rui.zhang@intel.com \
    --cc=ville.syrjala@linux.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox