diff mbox

[v2] acpi: Fix regression where _PPC is not read at boot even when ignore_ppc=0

Message ID 20090430095414.GA19462@srcf.ucam.org (mailing list archive)
State Accepted, archived
Headers show

Commit Message

Matthew Garrett April 30, 2009, 9:54 a.m. UTC 
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(-)

Comments

Ingo Molnar April 30, 2009, 11:10 a.m. UTC | #1 
* Matthew Garrett <mjg59@srcf.ucam.org> wrote:

> 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:

thanks - i've applied this and started testing it. I suspect 1-2 
days of test-time should be enough to see if it breaks this box in 
any way.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Matthew Garrett April 30, 2009, 11:13 a.m. UTC | #2 
On Thu, Apr 30, 2009 at 01:10:42PM +0200, Ingo Molnar wrote:

> thanks - i've applied this and started testing it. I suspect 1-2 
> days of test-time should be enough to see if it breaks this box in 
> any way.

My recollection was that you'd see the machine limited to 1GHz on every 
boot?
Darrick J. Wong May 15, 2009, 7:12 p.m. UTC | #3 
On Thu, Apr 30, 2009 at 12:13:38PM +0100, Matthew Garrett wrote:
> On Thu, Apr 30, 2009 at 01:10:42PM +0200, Ingo Molnar wrote:
> 
> > thanks - i've applied this and started testing it. I suspect 1-2 
> > days of test-time should be enough to see if it breaks this box in 
> > any way.
> 
> My recollection was that you'd see the machine limited to 1GHz on every 
> boot?

That seems accurate based on my reading of the old thread.

It's been a couple of weeks; has anyone seen any problems?

--D
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Darrick J. Wong June 2, 2009, 11:21 p.m. UTC | #4 
On Fri, May 15, 2009 at 12:12:19PM -0700, Darrick J. Wong wrote:
> On Thu, Apr 30, 2009 at 12:13:38PM +0100, Matthew Garrett wrote:
> > On Thu, Apr 30, 2009 at 01:10:42PM +0200, Ingo Molnar wrote:
> > 
> > > thanks - i've applied this and started testing it. I suspect 1-2 
> > > days of test-time should be enough to see if it breaks this box in 
> > > any way.
> > 
> > My recollection was that you'd see the machine limited to 1GHz on every 
> > boot?
> 
> That seems accurate based on my reading of the old thread.
> 
> It's been a couple of weeks; has anyone seen any problems?

Now it's been thirty days since I last heard from anyone.  Has the problem been
fixed by some other means?

--D
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

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