All of lore.kernel.org
 help / color / mirror / Atom feed
From: Matthew Garrett <mjg59@srcf.ucam.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: "Darrick J. Wong" <djwong@us.ibm.com>,
	Thomas Renninger <trenn@suse.de>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	cpufreq@vger.kernel.org, linux-acpi@vger.kernel.org
Subject: Re: [PATCH v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0
Date: Thu, 30 Apr 2009 10:54:14 +0100	[thread overview]
Message-ID: <20090430095414.GA19462@srcf.ucam.org> (raw)
In-Reply-To: <20090430072556.GD16737@elte.hu>

On Thu, Apr 30, 2009 at 09:25:56AM +0200, Ingo Molnar wrote:

> OTOH, if you rely on me figuring out which patch to revert and what 
> to do, it will take an indeterminate amount of time - together with 
> all the other items in my 'would be nice to hack on, given a bit of 
> free time' queue :)

Here's Darrick's patch:

Earlier, Ingo Molnar posted a patch to make it so that the kernel would avoid
reading _PPC on his broken T60.  Unfortunately, it seems that with Thomas
Renninger's patch last July to eliminate _PPC evaluations when the processor
driver loads, the kernel never actually reads _PPC at all!  This is problematic
if you happen to boot your non-T60 computer in a state where the BIOS _wants_
_PPC to be something other than zero.

So, put the _PPC evaluation back into acpi_processor_get_performance_info if
ignore_ppc isn't 1.

This second version restores the correct function call, which simplifies
the patch.  I apologize for the churn and the poor eyesight.

Signed-off-by: Darrick J. Wong <djwong@us.ibm.com>
---

 drivers/acpi/processor_perflib.c |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)


diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
index cafb410..85af717 100644
--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -348,7 +348,11 @@ static int acpi_processor_get_performance_info(struct acpi_processor *pr)
 	if (result)
 		goto update_bios;
 
-	return 0;
+	/* We need to call _PPC once when cpufreq starts */
+	if (ignore_ppc != 1)
+		result = acpi_processor_get_platform_limit(pr);
+
+	return result;
 
 	/*
 	 * Having _PPC but missing frequencies (_PSS, _PCT) is a very good hint that

-- 
Matthew Garrett | mjg59@srcf.ucam.org

  reply	other threads:[~2009-04-30  9:54 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-15 22:53 [PATCH] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0 Darrick J. Wong
2009-04-16  0:27 ` [PATCH v2] " Darrick J. Wong
2009-04-16 10:01   ` Thomas Renninger
2009-04-16 10:32     ` Ingo Molnar
2009-04-16 17:42     ` Darrick J. Wong
2009-04-16 18:49       ` Thomas Renninger
2009-04-16 22:45       ` Matthew Garrett
2009-04-20  5:13         ` Len Brown
2009-04-20  9:13           ` Thomas Renninger
2009-04-20 10:45             ` Ingo Molnar
2009-04-29 13:19               ` Thomas Renninger
2009-04-29 13:19                 ` Thomas Renninger
2009-04-29 14:48                 ` Ingo Molnar
2009-04-29 21:43                 ` Darrick J. Wong
2009-04-30  9:07                   ` Thomas Renninger
2009-04-30  9:17                     ` Ingo Molnar
2009-04-20 22:18             ` Henrique de Moraes Holschuh
2009-04-28 19:33         ` Darrick J. Wong
2009-04-28 19:53           ` Matthew Garrett
2009-04-28 20:24             ` Darrick J. Wong
2009-04-29 21:39             ` Darrick J. Wong
2009-04-29 22:00               ` Matthew Garrett
2009-04-30  7:25                 ` Ingo Molnar
2009-04-30  9:54                   ` Matthew Garrett [this message]
2009-04-30 11:10                     ` Ingo Molnar
2009-04-30 11:13                       ` Matthew Garrett
2009-05-15 19:12                         ` Darrick J. Wong
2009-06-02 23:21                           ` Darrick J. Wong
2009-06-07 10:05                             ` Ingo Molnar
2009-07-15  0:32                               ` Darrick J. Wong
2010-02-16 22:07                                 ` Matthew Garrett
2010-02-16 22:26                                   ` Darrick J. Wong
2010-02-18  9:02                                     ` Len Brown
2010-02-18 18:28                                       ` Darrick J. Wong
2010-02-19  6:12                                         ` Len Brown

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=20090430095414.GA19462@srcf.ucam.org \
    --to=mjg59@srcf.ucam.org \
    --cc=cpufreq@vger.kernel.org \
    --cc=djwong@us.ibm.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=trenn@suse.de \
    /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.