platform-driver-x86.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: Joe Perches <joe@perches.com>
Cc: Cesar Eduardo Barros <cesarb@cesarb.net>,
	Matthew Garrett <mjg@redhat.com>,
	platform-driver-x86@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] intel_ips: quieten "power or thermal limit exceeded" messages
Date: Thu, 23 Sep 2010 13:31:32 -0700	[thread overview]
Message-ID: <20100923133132.3faae5b3@jbarnes-desktop> (raw)
In-Reply-To: <1282962104.1946.179.camel@Joe-Laptop>

On Fri, 27 Aug 2010 19:21:44 -0700
Joe Perches <joe@perches.com> wrote:

> On Fri, 2010-08-27 at 20:12 -0300, Cesar Eduardo Barros wrote:
> > Em 27-08-2010 04:39, Joe Perches escreveu:
> > > On Thu, 2010-08-26 at 22:38 -0300, Cesar Eduardo Barros wrote:
> > >> - The first "MCP power limit exceeded" seems very bogus.
> > >> - What do you mean, core_power_limit is zero?
> > > I added a logging message whenever the turbo limits change
> > > and logging messages for power/temp on MCH for completeness.
> > > Maybe this will show something useful like when/how
> > > CPU power limit gets set to 0.
> 
> > Running with it right now, did not help much:
> > 
> > $ dmesg | fgrep 'intel ips'
> > intel ips 0000:00:1f.6: Warning: CPU TDP doesn't match expected value 
> > (found 25, expected 35)
> > intel ips 0000:00:1f.6: PCI INT C -> GSI 18 (level, low) -> IRQ 18
> > intel ips 0000:00:1f.6: IPS driver initialized, MCP temp limit 65535
> > intel ips 0000:00:1f.6: MCP power limit 65535 exceeded: cpu:8058 + 
> > mch:23392829
> > intel ips 0000:00:1f.6: CPU power limit 0 exceeded: 5675
> > intel ips 0000:00:1f.6: CPU power limit 0 exceeded: 6369
> 
> I believe all these limits should always have non-zero values.
> So I still think you've hardware problems, but I suppose it
> could be the driver not reading the right registers or some
> such.  It seems odd that the driver never printed a logging
> message for either of the polling or irq methods to read the
> device cpu and thermal limits.
> 
> Jesse or any Intel folk, can you verify or suggest anything
> better?
> 
> If cpu_power_limit, or any _limit, is not set perhaps changing
> the test style to verify limit and adding a printed_once alert
> for each 0 value limit.  At least that'd shut up the continuous
> logging but at least give a notification message.
> 
> if (limit) {
> 	if (measured_val > limit)
> 		dev_info(foo)
> } else
> 	dev_alert_once()
> 
> Maybe something like this:
> 
>  drivers/platform/x86/intel_ips.c |  160 +++++++++++++++++++++++++++++++++-----
>  1 files changed, 140 insertions(+), 20 deletions(-)

Yes, we do need something like this.  It turns out the BIOS can
optionally program several of these values, and we need to sanity check
them.  If they're not valid (e.g. a core power limit of 0 or MCP temp
limit of 0xffff) we need to use the default values in the limit structs.

I think the programmed limits are valid if they're nonzero and less
than one of the available default limits.  If they're not valid, we
should just use the default values.  I was thinking something like the
below for MCP, but Joe you may want to just update your patch instead
since it's more complete.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center

diff --git a/drivers/platform/x86/intel_ips.c b/drivers/platform/x86/intel_ips.c
index 9024480..ec72e80 100644
--- a/drivers/platform/x86/intel_ips.c
+++ b/drivers/platform/x86/intel_ips.c
@@ -662,6 +662,17 @@ static bool mch_exceeded(struct ips_driver *ips)
 	return ret;
 }
 
+static void clamp_mcp_temp_limit(struct ips_driver *ips)
+{
+	/*
+	 * BIOS may or may not program an MCP limit.  Clamp it to the
+	 * lowest available value.
+	 */
+	if (ips->mcp_temp_limit < ips->core_temp_limit ||
+	    ips->mcp_temp_limit < ips->mch_temp_limit)
+		ips->mcp_temp_limit = min(ips->core_temp_limit, ips->mch_temp_limit);
+}
+
 /**
  * update_turbo_limits - get various limits & settings from regs
  * @ips: IPS driver struct
@@ -686,6 +697,7 @@ static void update_turbo_limits(struct ips_driver *ips)
 	ips->mcp_temp_limit = thm_readw(THM_PTL);
 	ips->mcp_power_limit = thm_readw(THM_MPPC);
 
+	clamp_mcp_temp_limit(ips);
 	/* Ignore BIOS CPU vs GPU pref */
 }
 
@@ -1155,6 +1167,7 @@ static irqreturn_t ips_irq_handler(int irq, void *arg)
 				STS_PTL_SHIFT;
 			ips->mcp_power_limit = (tc1 & STS_PPL_MASK) >>
 				STS_PPL_SHIFT;
+			clamp_mcp_temp_limit(ips);
 			spin_unlock(&ips->turbo_status_lock);
 
 			thm_writeb(THM_SEC, SEC_ACK);

  parent reply	other threads:[~2010-09-23 20:31 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-25  0:48 intel ips: CPU TDP doesn't match expected value Cesar Eduardo Barros
2010-08-25  1:37 ` Jesse Barnes
2010-08-26 23:29 ` [PATCH] intel_ips: quieten "power or thermal limit exceeded" messages Cesar Eduardo Barros
2010-08-26 23:33   ` Joe Perches
2010-08-27  0:11     ` Cesar Eduardo Barros
2010-08-27  0:41       ` Joe Perches
2010-08-27  1:38         ` Cesar Eduardo Barros
2010-08-27  7:39           ` Joe Perches
2010-08-27 23:12             ` Cesar Eduardo Barros
2010-08-28  2:21               ` Joe Perches
2010-08-28 10:46                 ` Cesar Eduardo Barros
     [not found]                   ` <1282994116.1946.226.camel@Joe-Laptop>
2010-08-28 12:52                     ` Cesar Eduardo Barros
2010-08-28 13:01                       ` Cesar Eduardo Barros
2010-08-28 13:29                       ` Joe Perches
2010-08-28 14:18                         ` Cesar Eduardo Barros
2010-08-28 15:23                           ` Henrique de Moraes Holschuh
2010-08-28 19:07                             ` Cesar Eduardo Barros
2010-08-30 16:29                               ` Jesse Barnes
2010-08-30 21:42                                 ` Cesar Eduardo Barros
2010-09-23 20:31                 ` Jesse Barnes [this message]
2010-09-23 20:47                   ` Joe Perches
2010-09-23 20:50                     ` Jesse Barnes
2010-08-27  0:18   ` Alan Cox
2010-08-27  0:22     ` Cesar Eduardo Barros
2010-08-27  1:42   ` Matthew Garrett

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=20100923133132.3faae5b3@jbarnes-desktop \
    --to=jbarnes@virtuousgeek.org \
    --cc=cesarb@cesarb.net \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg@redhat.com \
    --cc=platform-driver-x86@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).