Received: by 2002:a05:7412:251c:b0:e2:908c:2ebd with SMTP id w28csp2033036rda; Tue, 24 Oct 2023 10:11:39 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFhjFhMQ8JqVzZPZvZFAgMME2QoNMTu55xjvcVktMIFoTP4ARYTKyG0kO/PBuEzI97NwdtS X-Received: by 2002:a17:90b:4c92:b0:27d:c499:14f3 with SMTP id my18-20020a17090b4c9200b0027dc49914f3mr10989172pjb.9.1698167498947; Tue, 24 Oct 2023 10:11:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1698167498; cv=none; d=google.com; s=arc-20160816; b=PrruYf5kLU9NK37eMfPVihiwpy1ssD18Z9tihD9Aweb2RXiREuhz0olH65QHSFiHxb 8db8Weh4a0adhzCi4gpkPU5r/F1REcAKq5Z9Zkgi11Mk/YFJ+glfGgGs1+tXcbEgIsfY Oz3uDwWHJUKcKKvccyEmVPRwojfHn01fIG9YXw68woxmm74292o30I+r21EsfTBqT8IY 74pS7K2TLBedWFQZudtE2EcMf55lLTHitVB1XIfmGDDTmXIgc41odlmDS0zhNVAuvDNG o1+3g9rXQhD5V0c9CPNsEduN/DV9fq+WkrcMhFdWH6gU+2+y5tRYzgQRtoRO/BIP3+xA 8fAQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=9DRok8UTRHhChh4aWwkcqmTk7wUvfKhv8iZ8FOj5f9w=; fh=1M3l/CZGZBIaoeQ1ponaozpXpY5aOaLMMTXwCn/UABk=; b=fZnFOeKLQlqbvy5Ka7/tQ0SOc9txeUnZ/OFw2Q/3fBpKo2Kyf0yJiCflQKf4ggfMVa TUNQcTgqY5A3Tvl3UyISZ291mLw8Df+oQswdCYIqniH+GXTTv6MhUPybpaekbZ4DFbte yH8ijWskpgETTX0XWrl6uUqkqcWtwK4V875+GQj9WTjj7Jc8Dkmpd1dh7s28K53t0DJw snrEvJ77mK+q7d3DVMkiXhfWbIdL2dSI4/civa65q3DlIenh2OOQmsdLyLMEe+1NdJgd G343OySQDXeS08GIwDqIuJYHilDdQe0twptTdUSG72uEksTFAC2PX5x87a891Yx/F0ja Wtuw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=C0KFcnBa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from fry.vger.email (fry.vger.email. [2620:137:e000::3:8]) by mx.google.com with ESMTPS id lr7-20020a17090b4b8700b0027ce7a59589si11793734pjb.142.2023.10.24.10.11.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 24 Oct 2023 10:11:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) client-ip=2620:137:e000::3:8; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=C0KFcnBa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:8 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by fry.vger.email (Postfix) with ESMTP id C58FD80707A7; Tue, 24 Oct 2023 10:11:24 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at fry.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1343846AbjJXRLP (ORCPT + 99 others); Tue, 24 Oct 2023 13:11:15 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44130 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234851AbjJXRLO (ORCPT ); Tue, 24 Oct 2023 13:11:14 -0400 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.9]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2D1FF133; Tue, 24 Oct 2023 10:11:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1698167473; x=1729703473; h=date:from:to:cc:subject:message-id:references: mime-version:content-transfer-encoding:in-reply-to; bh=gjg5VDG7lc3uq494hHNG5+JDII6JKPABQkbpXQHkNS8=; b=C0KFcnBaAMukxPHZjSht/er9PI8qNL7wHNwGvRVhCnO/bIrXxAPHsTbZ EOsuQgbmPvH6jxJgvCCsUibMaumT1mmTp7LC6iW7hdNmKFjtla6gXRId1 mZFY3LV6cDjsAIX9gK3SpDi0BHLvADnP2P0B1e/CIWNKpurvjAqUNIhuF Ipc7DO3bKPZWt6rAxHdVj0qBgDor0/frBrdtYIjAq9H1Bq1xrOqarf+9V QSMZXq0/d4uYokwnYTm1YaY44qoIo6icfiVcgDMs/aXEQtNhGsh8KRU/m 2nkSzH1BKjjHkbLROMpxKMgIU8Gljp+vR9yyTmlNNvXiZrZVtZBRiKiAW g==; X-IronPort-AV: E=McAfee;i="6600,9927,10873"; a="5741286" X-IronPort-AV: E=Sophos;i="6.03,248,1694761200"; d="scan'208";a="5741286" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orvoesa101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Oct 2023 10:11:12 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10873"; a="758547737" X-IronPort-AV: E=Sophos;i="6.03,248,1694761200"; d="scan'208";a="758547737" Received: from stinkpipe.fi.intel.com (HELO stinkbox) ([10.237.72.74]) by orsmga002.jf.intel.com with SMTP; 24 Oct 2023 10:11:08 -0700 Received: by stinkbox (sSMTP sendmail emulation); Tue, 24 Oct 2023 20:11:07 +0300 Date: Tue, 24 Oct 2023 20:11:07 +0300 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: "Pandruvada, Srinivas" Cc: "linux-pm@vger.kernel.org" , "intel-gfx@lists.freedesktop.org" , "Wysocki, Rafael J" , "linux-kernel@vger.kernel.org" , "Zhang, Rui" Subject: Re: [Intel-gfx] [PATCH] powercap: intel_rapl: Don't warn about BIOS locked limits during resume Message-ID: References: <20231004183455.27797-1-ville.syrjala@linux.intel.com> <6d207eef73fb2ad32264921ae7d1a536b6b8da61.camel@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Patchwork-Hint: comment X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on fry.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (fry.vger.email [0.0.0.0]); Tue, 24 Oct 2023 10:11:25 -0700 (PDT) On Wed, Oct 04, 2023 at 09:59:47PM +0300, Ville Syrj?l? wrote: > On Wed, Oct 04, 2023 at 06:45:22PM +0000, Pandruvada, Srinivas wrote: > > On Wed, 2023-10-04 at 21:34 +0300, Ville Syrjala wrote: > > > From: Ville Syrj?l? > > > > > > 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? > > I presume someone wanted to make it pr_warn() for a reason. > I don't mind either way. Ping. Can someone make a decision on how this should get fixed so we get this moving forward? > > > > > Thanks, > > Srinivas > > > > > Cc: Zhang Rui > > > Cc: Wang Wendy > > > Cc: Rafael J. Wysocki > > > Cc: Srinivas Pandruvada > > > Fixes: 9050a9cd5e4c ("powercap: intel_rapl: Cleanup Power Limits > > > support") > > > Signed-off-by: Ville Syrj?l? > > > --- > > > ?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(); > > > ?} > > > > -- > Ville Syrj?l? > Intel -- Ville Syrj?l? Intel