public inbox for cpufreq@vger.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: cpufreq@vger.kernel.org
Subject: [Bug 60839] scaling_max_freq cannot be set to values larger than bios_limit
Date: Tue, 10 Sep 2013 08:28:55 +0000	[thread overview]
Message-ID: <bug-60839-12968-nF23raoEHG@https.bugzilla.kernel.org/> (raw)
In-Reply-To: <bug-60839-12968@https.bugzilla.kernel.org/>

https://bugzilla.kernel.org/show_bug.cgi?id=60839

Lan Tianyu <tianyu.lan@intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |tianyu.lan@intel.com

--- Comment #1 from Lan Tianyu <tianyu.lan@intel.com> ---
(In reply to Sven Köhler from comment #0)
> Background:
> 
> On my Dell Latitude E6410, the following happens if the power supply is
> plugged in or plugged out: The value of bios_limit drops for all CPUs to
> cpuinfo_min_freq. Within seconds, it is then gradually increased until
> bios_limit is equal to cpuinfo_max_freq. I assume, that this serves the
> purpose of detecting the type of attached power supply. The BIOS temporarely
> limits the CPU frequency in order to keep the power consumption low until it
> is determined that the power supply is the correct one.
> 
> Problem description:
> 
> Assume that nobody is writing to scaling_max_freq and that
> scaling_max_freq=cpuinfo_max_freq initially. Upon switching the power
> supply,  you observe that the value of scaling_max_freq decreases and then
> gradually increases along with bios_limit. From this I conclude that
> (a) internally, the value for scaling_max_freq can assume values larger than
> bios_limit. However, when reading scaling_max_freq through sysfs the value
> is clipped by bios_limit
> (b) there is no good reason, why the internal value of scaling_max_freq
> shouldn't be set to a value larger than bios_limit.
> 
> However, any write to scaling_max_freq through sysfs will also be clipped by
> bios_limit. In result, if the value of cpuinfo_max_freq is written to
> scaling_max_freq while bios_limit is low, then the internal value of
> scaling_max_freq will be set to whatever the value of bios_limit is.
> 
> In my case, this was causing the following problems:
> laptop-mode-tools would write to scaling_max_freq shortly after the power
> supply was plugged in / unplugged. As the bios_limit would be low at that
> point, the internal value of scaling_max_freq would be set to a low value.
> Hence, cpufreq would never raise the frequencies of my CPUs again even after
> bios_limit increased. I solved it my disabling the cpufreq related parts of
> laptop-mode-tools.

Hi:
     This sounds like a user space issue. Bios limit will rise after
plugging/unplugging AC and laptop-mode-tools also should update
scaling_max_freq. Cpufreq core schedules freq scope according user space
configuration. If user space tool doesn't extend the scope according bios limit
after plugging/unplugging AC, the scope will keep low cpufreq.


> 
> Also note, that it isn't currently possible to determine the true value of
> scaling_max_freq as the value returned through sysfs is clipped by
> bios_limit.

-- 
You are receiving this mail because:
You are the assignee for the bug.

  reply	other threads:[~2013-09-10  8:28 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-03 12:47 [Bug 60839] New: scaling_max_freq cannot be set to values larger than bios_limit bugzilla-daemon
2013-09-10  8:28 ` bugzilla-daemon [this message]
2013-09-10  8:36 ` [Bug 60839] " bugzilla-daemon
2013-09-10  9:46 ` bugzilla-daemon
2013-09-10 12:45 ` bugzilla-daemon
2013-09-10 13:15 ` bugzilla-daemon
2013-09-10 14:19 ` bugzilla-daemon
2013-09-11 19:49 ` bugzilla-daemon
2013-09-12 14:07 ` bugzilla-daemon
2013-09-12 14:49 ` bugzilla-daemon
2013-09-18  3:27 ` bugzilla-daemon
2013-10-14  7:58 ` bugzilla-daemon

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=bug-60839-12968-nF23raoEHG@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=cpufreq@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox