All of lore.kernel.org
 help / color / mirror / Atom feed
From: Len Brown <lenb@kernel.org>
To: trenn@suse.de
Cc: linux-acpi@vger.kernel.org, cpufreq@lists.linux.org.uk
Subject: Re: [PATCH] Workaround for _PPC (BIOS cpufreq limitations)
Date: Sat, 19 May 2007 00:55:58 -0400	[thread overview]
Message-ID: <200705190055.58626.lenb@kernel.org> (raw)
In-Reply-To: <1179543568.16465.35.camel@sublime.suse.de>

On Friday 18 May 2007 22:59, Thomas Renninger wrote:
> Len, can you apply this one, pls.
> 
> Workaround for _PPC (BIOS cpufreq limitations)
> 
> There have been fixes using _PPC, which seem to unhide a problem
> on HP nx6125 (double cpufreq switch freezes the machine for
> several seconds).
> This one should provide a workaround for the nx6125 and for
> possible other machines that show any weird _PPC behaviour.

I don't understand what the failure is, and why this workaround
is effective.  Is this a clue here to a real bug
that requires a real fix, rather than a workaround?

-Len

> Signed-off-by: Thomas Renninger <trenn@suse.de>
> 
> ---
>  drivers/acpi/processor_perflib.c |   16 +++++++++++++++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 
> Index: linux-2.6.21/drivers/acpi/processor_perflib.c
> ===================================================================
> --- linux-2.6.21.orig/drivers/acpi/processor_perflib.c
> +++ linux-2.6.21/drivers/acpi/processor_perflib.c
> @@ -60,6 +60,11 @@ static DEFINE_MUTEX(performance_mutex);
>   * policy is adjusted accordingly.
>   */
>  
> +static unsigned int ignore_ppc = 0;
> +module_param(ignore_ppc, uint, 0644);
> +MODULE_PARM_DESC(ignore_ppc, "If the frequency of your machine gets wrongly" \
> +		 "limited by BIOS, this should help");
> +
>  #define PPC_REGISTERED   1
>  #define PPC_IN_USE       2
>  
> @@ -72,6 +77,9 @@ static int acpi_processor_ppc_notifier(s
>  	struct acpi_processor *pr;
>  	unsigned int ppc = 0;
>  
> +	if (ignore_ppc)
> +		return 0;
> +
>  	mutex_lock(&performance_mutex);
>  
>  	if (event != CPUFREQ_INCOMPATIBLE)
> @@ -130,7 +138,13 @@ static int acpi_processor_get_platform_l
>  
>  int acpi_processor_ppc_has_changed(struct acpi_processor *pr)
>  {
> -	int ret = acpi_processor_get_platform_limit(pr);
> +	int ret;
> +
> +	if (ignore_ppc)
> +		return 0;
> +
> +	ret = acpi_processor_get_platform_limit(pr);
> +
>  	if (ret < 0)
>  		return (ret);
>  	else
> 
> 

  reply	other threads:[~2007-05-19  4:55 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-19  2:59 [PATCH] Workaround for _PPC (BIOS cpufreq limitations) Thomas Renninger
2007-05-19  4:55 ` Len Brown [this message]
2007-05-19 19:41   ` Thomas Renninger

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=200705190055.58626.lenb@kernel.org \
    --to=lenb@kernel.org \
    --cc=cpufreq@lists.linux.org.uk \
    --cc=linux-acpi@vger.kernel.org \
    --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.