All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Renninger <mail@renninger.de>
To: cpufreq@lists.linux.org.uk
Cc: Dominik Brodowski <linux@dominikbrodowski.de>
Subject: DELL 600/800 - PPC frequency change issues
Date: Thu, 19 Jan 2006 18:59:22 +0100	[thread overview]
Message-ID: <43CFD37A.1040402@renninger.de> (raw)

When unplugging the AC adapter on these machines
following happens in BIOS:

- ACPI processor event fired, frequencies get limited
  to the lowest one(600 MHz) and BIOS already sets lowest freq.
- when waiting about 10 seconds another ACPI processor 
  event is fired, and all frequencies are available again,
  highest freq(1700 MHz) is set.
- when plugging in ac adapter before waiting 10 seconds
  ACPI processor event is happening immediately and all
  frequencies are available again, highest freq(1700 MHz) is set.


I found these bugs in kernel:

- speedstep centrino driver does not recognise that BIOS
  changed the frequency behind it's back.
  It tells you that 600 MHz are already set, and does not invoke
  PRE/POST transition validation. 
  On next frequency settings, the frequency is "out_of_sync" and
  the validater assumes 600 MHz and the frequency stays there.
  Not sure, maybe it stayed on 600 because of next bug or both, still
  the "out_of_sync" is valid and should be handled gracefully:

  Patch [1/2]
  
- userspace governor is using its own cpufreq_policy struct and
  forgets to set max_frequency there in 
  cpufreq_governor_userspace(CPUFREQ_GOV_LIMITS)
  That results in scaling_setspeed staying high in sysfs even the
  frequency has been lowered on _PPC change.
  When _PPC allows all frequencies again, the userspace governor
  uses it's own policy_struct with the old max value again (now the
  low one) and the frequency still stays at lowest frequency.

  Patch [2/2]

I tested with ondemand and userspace governor on a speedstep-centrino
system, both governors had problems with but should work fine with _PPC
changes whether the BIOS prechanges the freq or not.

Could someone please review.

Thanks,

      Thomas

                 reply	other threads:[~2006-01-19 17:59 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=43CFD37A.1040402@renninger.de \
    --to=mail@renninger.de \
    --cc=cpufreq@lists.linux.org.uk \
    --cc=linux@dominikbrodowski.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.