Hi,
be careful, this could break the T60 again.
Can you and Ingo place acpidump of your machines somewhere, please.
On Thursday 16 April 2009 02:27:12 Darrick J. Wong wrote:
> 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 wrong. _PPC is only evaluated when a cpufreq driver got registered.
> 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.
Your machine should suffer from that since Ingo's T60 patch?
Reading the _PPC part of the ACPI spec again:
---
In order to support dynamic changes of _PPC object, Notify events on
the processor object. Notify events of type 0x80 will cause OSPM to
reevaluate any _PPC objects residing under the particular processor object
notified.
---
The *reevaluate* implies that the _PPC value has been evaluated/initialized
by the OS already and Ingo's patch would be wrong then.
I'd like to have a look at the T60's ACPI parts and find out what exactly
(or if at all) makes _PPC to return sane values, I expect it's _PDC.
Hmm, I could also imagine that Ingo's T60 patch is not needed anymore since
Yakui's patch (0ac3c571315a53c14d2733564f14ebdb911fe903).
This one could make sure that _PDC is evaluated first making the internal
ACPI _PPC state initialize and makes sure _PPC gets only called afterwards.
If this patch does not break Ingo's T60, I think this should go in.
Due to Yakui's reordering/cleanup of ACPI function calls, I think also
the notifier chain I introduced is not needed anymore and I can clean this
up if I find some time.
> 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@xxxxxxxxxx>
> ---
>
> 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
You are more or less reverting Ingo's patch (e4233dec749a3519069d9390561b5636a75c7579):
diff --git a/drivers/acpi/processor_perflib.c b/drivers/acpi/processor_perflib.c
index 5207f9e..cbb6f08 100644
--- a/drivers/acpi/processor_perflib.c
+++ b/drivers/acpi/processor_perflib.c
@@ -322,10 +322,6 @@ static int acpi_processor_get_performance_info(struct acpi_processor *pr)
if (result)
return result;
- result = acpi_processor_get_platform_limit(pr);
- if (result)
- return result;
-
return 0;
}
Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
