summaryrefslogtreecommitdiffstats
path: root/Documentation/cpu-freq
Commit message (Collapse)AuthorAgeFilesLines
* Documentation: cpufreq: intel_pstate: fix typoFelipe Franciosi2016-02-181-1/+1
| | | | | | | This just swaps a colon for a quote in the intel_pstate documentation. Signed-off-by: Felipe Franciosi <felipe@nutanix.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Documentation: cpufreq: intel_pstate: enhance documentationSrinivas Pandruvada2016-01-051-42/+199
| | | | | | | | | This is an attempt to make documentation more user friendly. Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> Reviewed-by: Doug Smythies <dsmythies@telus.net> Reviewed-by: Chen, Yu C <yu.c.chen@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: pcc-cpufreq: update default value of cpuinfo_transition_latencyJacob Tanenbaum2015-12-101-2/+2
| | | | | | | | | | | | | | | | | The cpufreq documentation specifies policy->cpuinfo.transition_latency the time it takes on this CPU to switch between two frequencies in nanoseconds (if appropriate, else specify CPUFREQ_ETERNAL) currently pcc-cpufreq does not expose the value and sets it to zero. I changed the pcc-cpufreq driver and it's documentation to conform to the default value specified in Documentation/cpu-freq/cpu-drivers.txt Signed-off-by: Jacob Tanenbaum <jtanenba@redhat.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: remove redundant CPUFREQ_INCOMPATIBLE notifier eventViresh Kumar2015-09-011-5/+2Star
| | | | | | | | | | | | | What's being done from CPUFREQ_INCOMPATIBLE, can also be done with CPUFREQ_ADJUST. There is nothing special with CPUFREQ_INCOMPATIBLE notifier. Kill CPUFREQ_INCOMPATIBLE and fix its usage sites. This also updates the numbering of notifier events to remove holes. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge tag 'docs-for-linus' of git://git.lwn.net/linux-2.6Linus Torvalds2015-06-252-11/+12
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Pull documentation updates from Jonathan Corbet: "The main thing here is Ingo's big subdirectory documenting feature support for each architecture. Beyond that, it's the usual pile of fixes, tweaks, and small additions" * tag 'docs-for-linus' of git://git.lwn.net/linux-2.6: (79 commits) doc:md: fix typo in md.txt. Documentation/mic/mpssd: don't build x86 userspace when cross compiling Documentation/prctl: don't build tsc tests when cross compiling Documentation/vDSO: don't build tests when cross compiling Doc:ABI/testing: Fix typo in sysfs-bus-fcoe Doc: Docbook: Change wikipedia's URL from http to https in scsi.tmpl Doc: Change wikipedia's URL from http to https Documentation/kernel-parameters: add missing pciserial to the earlyprintk Doc:pps: Fix typo in pps.txt kbuild : Fix documentation of INSTALL_HDR_PATH Documentation: filesystems: updated struct file_operations documentation in vfs.txt kbuild: edit explanation of clean-files variable Doc: ja_JP: Fix typo in HOWTO Move freefall program from Documentation/ to tools/ Documentation: ARM: EXYNOS: Describe boot loaders interface Doc:nfc: Fix typo in nfc-hci.txt vfs: Minor documentation fix Doc: networking: txtimestamp: fix printf format warning Documentation, intel_pstate: Improve legacy mode internal governors description Documentation: extend use case for EXPORT_SYMBOL_GPL() ...
| * Documentation, intel_pstate: Improve legacy mode internal governors descriptionPrarit Bhargava2015-06-052-11/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current documentation is incomplete wrt the intel_pstate legacy internal governors. The confusion comes from the general cpufreq governors which also use the names performance and powersave. This patch better differentiates between the two sets of governors and gives an explanation of how the internal P-state governors behave differently from one another. Also fix two minor typos. Cc: Prarit Bhargava <prarit@redhat.com> Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com> Cc: Kristen Carlson Accardi <kristen@linux.intel.com> Cc: Dirk Brandewie <dirk.j.brandewie@intel.com> Cc: x86@kernel.org Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Prarit Bhargava <prarit@redhat.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
* | Documentation: cpufreq: delete duplicate description of sysfs interface ↵Wang Long2015-05-051-2/+0Star
|/ | | | | | | | | | | | | | | | | | | | | 'scaling_driver' The file 'Documentation/cpu-freq/user-guide.txt' has duplicate description of sysfs interface 'scaling_driver'. [first] scaling_driver : this file shows what cpufreq driver is used to set the frequency on this CPU [second] scaling_driver : Hardware driver for cpufreq. Although this does not affect anything, I think we should only have one. so delete the second one because the first one is described in more detail. Signed-off-by: Wang Long <long.wanglong@huawei.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* intel_pstate: Add num_pstates to sysfsKristen Carlson Accardi2015-01-301-0/+4
| | | | | | | | | Add a sysfs interface to display the total number of supported pstates. This value is independent of whether turbo has been enabled or disabled. Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* intel_pstate: expose turbo range to sysfsKristen Carlson Accardi2015-01-301-0/+4
| | | | | | | | | | This patch adds "turbo_pct" to the intel_pstate sysfs interface. turbo_pct will display the percentage of the total supported pstates that are in the turbo range. This value is independent of whether turbo has been disabled or not. Signed-off-by: Kristen Carlson Accardi <kristen@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* intel_pstate: Add support for HWPDirk Brandewie2014-11-121-12/+25
| | | | | | | | | | | | | | | | | | Add support of Hardware Managed Performance States (HWP) described in Volume 3 section 14.4 of the SDM. With HWP enbaled intel_pstate will no longer be responsible for selecting P states for the processor. intel_pstate will continue to register to the cpufreq core as the scaling driver for CPUs implementing HWP. In HWP mode intel_pstate provides three functions reporting frequency to the cpufreq core, support for the set_policy() interface from the core and maintaining the intel_pstate sysfs interface in /sys/devices/system/cpu/intel_pstate. User preferences expressed via the set_policy() interface or the sysfs interface are forwared to the CPU via the HWP MSR interface. Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* intel_pstate: Update documentation of {max,min}_perf_pct sysfs filesDirk Brandewie2014-07-071-2/+5
| | | | | | | | | Update documentation to make the interpretation of the values clearer Link: https://bugzilla.kernel.org/show_bug.cgi?id=64251 Cc: 3.13+ <stable@vger.kernel.org> # 3.13+ Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: add support for intermediate (stable) frequenciesViresh Kumar2014-06-051-2/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Douglas Anderson, recently pointed out an interesting problem due to which udelay() was expiring earlier than it should. While transitioning between frequencies few platforms may temporarily switch to a stable frequency, waiting for the main PLL to stabilize. For example: When we transition between very low frequencies on exynos, like between 200MHz and 300MHz, we may temporarily switch to a PLL running at 800MHz. No CPUFREQ notification is sent for that. That means there's a period of time when we're running at 800MHz but loops_per_jiffy is calibrated at between 200MHz and 300MHz. And so udelay behaves badly. To get this fixed in a generic way, introduce another set of callbacks get_intermediate() and target_intermediate(), only for drivers with target_index() and CPUFREQ_ASYNC_NOTIFICATION unset. get_intermediate() should return a stable intermediate frequency platform wants to switch to, and target_intermediate() should set CPU to that frequency, before jumping to the frequency corresponding to 'index'. Core will take care of sending notifications and driver doesn't have to handle them in target_intermediate() or target_index(). NOTE: ->target_index() should restore to policy->restore_freq in case of failures as core would send notifications for that. Tested-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Doug Anderson <dianders@chromium.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* PM / OPP: Move cpufreq specific OPP functions out of generic OPP libraryNishanth Menon2014-05-071-0/+29
| | | | | | | | | | | | | | | | CPUFreq specific helper functions for OPP (Operating Performance Points) now use generic OPP functions that allow CPUFreq to be be moved back into CPUFreq framework. This allows for independent modifications or future enhancements as needed isolated to just CPUFreq framework alone. Here, we just move relevant code and documentation to make this part of CPUFreq infrastructure. Cc: Kevin Hilman <khilman@deeprootsystems.com> Signed-off-by: Nishanth Menon <nm@ti.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Make linux-pm@vger.kernel.org official mailing listViresh Kumar2014-05-011-2/+2
| | | | | | | | | | | | | | | | There has been confusion all the time about which mailing list to follow for cpufreq activities, linux-pm@vger.kernel.org or cpufreq@vger.kernel.org. Since patches sent to cpufreq@vger.kernel.org don't go to Patchwork which is a maintenance workflow problem, make linux-pm@vger.kernel.org the official mailing list for cpufreq stuff and remove all references of cpufreq@vger.kernel.org from kernel source. Later, we can request that the list be dropped entirely. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Introduce macros for cpufreq_frequency_table iterationStratos Karafotis2014-04-301-0/+19
| | | | | | | | | | | | | | | | | | | Many cpufreq drivers need to iterate over the cpufreq_frequency_table for various tasks. This patch introduces two macros which can be used for iteration over cpufreq_frequency_table keeping a common coding style across drivers: - cpufreq_for_each_entry: iterate over each entry of the table - cpufreq_for_each_valid_entry: iterate over each entry that contains a valid frequency. It should have no functional changes. Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Acked-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Add stop CPU callback to cpufreq_driver interfaceDirk Brandewie2014-03-201-1/+7
| | | | | | | | | | | | | | This callback allows the driver to do clean up before the CPU is completely down and its state cannot be modified. This is used by the intel_pstate driver to reduce the requested P state prior to the core going away. This is required because the requested P state of the offline core is used to select the package P state. This effectively sets the floor package P state to the requested P state on the offline core. Signed-off-by: Dirk Brandewie <dirk.j.brandewie@intel.com> [rjw: Minor modifications] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: remove unused notifier: CPUFREQ_{SUSPENDCHANGE|RESUMECHANGE}Viresh Kumar2014-03-191-4/+0Star
| | | | | | | | | | Two cpufreq notifiers CPUFREQ_RESUMECHANGE and CPUFREQ_SUSPENDCHANGE have not been used for some time, so remove them to clean up code a bit. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com> [rjw: Changelog] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Documentation: cpufreq / boost: Update BOOST documentationLukasz Majewski2014-01-171-13/+13
| | | | | | | | | | Since the support for software and hardware controlled boosting has been added, update the corresponding documentation. Signed-off-by: Lukasz Majewski <l.majewski@samsung.com> Signed-off-by: Myungjoo Ham <myungjoo.ham@samsung.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Documentation / cpufreq: add intel-pstate.txtRamkumar Ramachandra2014-01-061-0/+40
| | | | | | | | | | The Intel P-state driver is currently undocumented. Add some documentation based on the cover-letter sent with the original series. Cc: Dirk Brandewie <dirk.brandewie@gmail.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Ramkumar Ramachandra <artagnon@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Implement light weight ->target_index() routineViresh Kumar2013-10-252-11/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the prototype of cpufreq_drivers target routines is: int target(struct cpufreq_policy *policy, unsigned int target_freq, unsigned int relation); And most of the drivers call cpufreq_frequency_table_target() to get a valid index of their frequency table which is closest to the target_freq. And they don't use target_freq and relation after that. So, it makes sense to just do this work in cpufreq core before calling cpufreq_frequency_table_target() and simply pass index instead. But this can be done only with drivers which expose their frequency table with cpufreq core. For others we need to stick with the old prototype of target() until those drivers are converted to expose frequency tables. This patch implements the new light weight prototype for target_index() routine. It looks like this: int target_index(struct cpufreq_policy *policy, unsigned int index); CPUFreq core will call cpufreq_frequency_table_target() before calling this routine and pass index to it. Because CPUFreq core now requires to call routines present in freq_table.c CONFIG_CPU_FREQ_TABLE must be enabled all the time. This also marks target() interface as deprecated. So, that new drivers avoid using it. And Documentation is updated accordingly. It also converts existing .target() to newly defined light weight .target_index() routine for many driver. Acked-by: Hans-Christian Egtvedt <egtvedt@samfundet.no> Acked-by: Jesper Nilsson <jesper.nilsson@axis.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Russell King <linux@arm.linux.org.uk> Acked-by: David S. Miller <davem@davemloft.net> Tested-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rjw@rjwysocki.net>
* cpufreq: Drop the owner field from struct cpufreq_driverViresh Kumar2013-08-101-2/+0Star
| | | | | | | | | | We don't need to set .owner = THIS_MODULE any more in cpufreq drivers as this field isn't used any more by the cpufreq core. This patch removes it and updates all dependent drivers accordingly. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: rename index as driver_data in cpufreq_frequency_tableViresh Kumar2013-06-041-8/+2Star
| | | | | | | | | | | | | | | | | The "index" field of struct cpufreq_frequency_table was never an index and isn't used at all by the cpufreq core. It only is useful for cpufreq drivers for their internal purposes. Many people nowadays blindly set it in ascending order with the assumption that the core will use it, which is a mistake. Rename it to "driver_data" as that's what its purpose is. All of its users are updated accordingly. [rjw: Changelog] Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Simon Horman <horms+renesas@verge.net.au> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* Merge branch 'timers-nohz-for-linus' of ↵Linus Torvalds2013-05-051-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull 'full dynticks' support from Ingo Molnar: "This tree from Frederic Weisbecker adds a new, (exciting! :-) core kernel feature to the timer and scheduler subsystems: 'full dynticks', or CONFIG_NO_HZ_FULL=y. This feature extends the nohz variable-size timer tick feature from idle to busy CPUs (running at most one task) as well, potentially reducing the number of timer interrupts significantly. This feature got motivated by real-time folks and the -rt tree, but the general utility and motivation of full-dynticks runs wider than that: - HPC workloads get faster: CPUs running a single task should be able to utilize a maximum amount of CPU power. A periodic timer tick at HZ=1000 can cause a constant overhead of up to 1.0%. This feature removes that overhead - and speeds up the system by 0.5%-1.0% on typical distro configs even on modern systems. - Real-time workload latency reduction: CPUs running critical tasks should experience as little jitter as possible. The last remaining source of kernel-related jitter was the periodic timer tick. - A single task executing on a CPU is a pretty common situation, especially with an increasing number of cores/CPUs, so this feature helps desktop and mobile workloads as well. The cost of the feature is mainly related to increased timer reprogramming overhead when a CPU switches its tick period, and thus slightly longer to-idle and from-idle latency. Configuration-wise a third mode of operation is added to the existing two NOHZ kconfig modes: - CONFIG_HZ_PERIODIC: [formerly !CONFIG_NO_HZ], now explicitly named as a config option. This is the traditional Linux periodic tick design: there's a HZ tick going on all the time, regardless of whether a CPU is idle or not. - CONFIG_NO_HZ_IDLE: [formerly CONFIG_NO_HZ=y], this turns off the periodic tick when a CPU enters idle mode. - CONFIG_NO_HZ_FULL: this new mode, in addition to turning off the tick when a CPU is idle, also slows the tick down to 1 Hz (one timer interrupt per second) when only a single task is running on a CPU. The .config behavior is compatible: existing !CONFIG_NO_HZ and CONFIG_NO_HZ=y settings get translated to the new values, without the user having to configure anything. CONFIG_NO_HZ_FULL is turned off by default. This feature is based on a lot of infrastructure work that has been steadily going upstream in the last 2-3 cycles: related RCU support and non-periodic cputime support in particular is upstream already. This tree adds the final pieces and activates the feature. The pull request is marked RFC because: - it's marked 64-bit only at the moment - the 32-bit support patch is small but did not get ready in time. - it has a number of fresh commits that came in after the merge window. The overwhelming majority of commits are from before the merge window, but still some aspects of the tree are fresh and so I marked it RFC. - it's a pretty wide-reaching feature with lots of effects - and while the components have been in testing for some time, the full combination is still not very widely used. That it's default-off should reduce its regression abilities and obviously there are no known regressions with CONFIG_NO_HZ_FULL=y enabled either. - the feature is not completely idempotent: there is no 100% equivalent replacement for a periodic scheduler/timer tick. In particular there's ongoing work to map out and reduce its effects on scheduler load-balancing and statistics. This should not impact correctness though, there are no known regressions related to this feature at this point. - it's a pretty ambitious feature that with time will likely be enabled by most Linux distros, and we'd like you to make input on its design/implementation, if you dislike some aspect we missed. Without flaming us to crisp! :-) Future plans: - there's ongoing work to reduce 1Hz to 0Hz, to essentially shut off the periodic tick altogether when there's a single busy task on a CPU. We'd first like 1 Hz to be exposed more widely before we go for the 0 Hz target though. - once we reach 0 Hz we can remove the periodic tick assumption from nr_running>=2 as well, by essentially interrupting busy tasks only as frequently as the sched_latency constraints require us to do - once every 4-40 msecs, depending on nr_running. I am personally leaning towards biting the bullet and doing this in v3.10, like the -rt tree this effort has been going on for too long - but the final word is up to you as usual. More technical details can be found in Documentation/timers/NO_HZ.txt" * 'timers-nohz-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (39 commits) sched: Keep at least 1 tick per second for active dynticks tasks rcu: Fix full dynticks' dependency on wide RCU nocb mode nohz: Protect smp_processor_id() in tick_nohz_task_switch() nohz_full: Add documentation. cputime_nsecs: use math64.h for nsec resolution conversion helpers nohz: Select VIRT_CPU_ACCOUNTING_GEN from full dynticks config nohz: Reduce overhead under high-freq idling patterns nohz: Remove full dynticks' superfluous dependency on RCU tree nohz: Fix unavailable tick_stop tracepoint in dynticks idle nohz: Add basic tracing nohz: Select wide RCU nocb for full dynticks nohz: Disable the tick when irq resume in full dynticks CPU nohz: Re-evaluate the tick for the new task after a context switch nohz: Prepare to stop the tick on irq exit nohz: Implement full dynticks kick nohz: Re-evaluate the tick from the scheduler IPI sched: New helper to prevent from stopping the tick in full dynticks sched: Kick full dynticks CPU that have more than one task enqueued. perf: New helper to prevent full dynticks CPUs from stopping tick perf: Kick full dynticks CPU if events rotation is needed ...
| * nohz: Rename CONFIG_NO_HZ to CONFIG_NO_HZ_COMMONFrederic Weisbecker2013-04-031-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We are planning to convert the dynticks Kconfig options layout into a choice menu. The user must be able to easily pick any of the following implementations: constant periodic tick, idle dynticks, full dynticks. As this implies a mutual exclusion, the two dynticks implementions need to converge on the selection of a common Kconfig option in order to ease the sharing of a common infrastructure. It would thus seem pretty natural to reuse CONFIG_NO_HZ to that end. It already implements all the idle dynticks code and the full dynticks depends on all that code for now. So ideally the choice menu would propose CONFIG_NO_HZ_IDLE and CONFIG_NO_HZ_EXTENDED then both would select CONFIG_NO_HZ. On the other hand we want to stay backward compatible: if CONFIG_NO_HZ is set in an older config file, we want to enable CONFIG_NO_HZ_IDLE by default. But we can't afford both at the same time or we run into a circular dependency: 1) CONFIG_NO_HZ_IDLE and CONFIG_NO_HZ_EXTENDED both select CONFIG_NO_HZ 2) If CONFIG_NO_HZ is set, we default to CONFIG_NO_HZ_IDLE We might be able to support that from Kconfig/Kbuild but it may not be wise to introduce such a confusing behaviour. So to solve this, create a new CONFIG_NO_HZ_COMMON option which gathers the common code between idle and full dynticks (that common code for now is simply the idle dynticks code) and select it from their referring Kconfig. Then we'll later create CONFIG_NO_HZ_IDLE and map CONFIG_NO_HZ to it for backward compatibility. Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Chris Metcalf <cmetcalf@tilera.com> Cc: Christoph Lameter <cl@linux.com> Cc: Geoff Levand <geoff@infradead.org> Cc: Gilad Ben Yossef <gilad@benyossef.com> Cc: Hakan Akkan <hakanakkan@gmail.com> Cc: Ingo Molnar <mingo@kernel.org> Cc: Kevin Hilman <khilman@linaro.org> Cc: Li Zhong <zhong@linux.vnet.ibm.com> Cc: Namhyung Kim <namhyung.kim@lge.com> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Cc: Paul Gortmaker <paul.gortmaker@windriver.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Steven Rostedt <rostedt@goodmis.org> Cc: Thomas Gleixner <tglx@linutronix.de>
* | cpufreq: AMD "frequency sensitivity feedback" powersave bias for ondemand ↵Jacob Shin2013-04-101-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | governor Future AMD processors, starting with Family 16h, can provide software with feedback on how the workload may respond to frequency change -- memory-bound workloads will not benefit from higher frequency, where as compute-bound workloads will. This patch enables this "frequency sensitivity feedback" to aid the ondemand governor to make better frequency change decisions by hooking into the powersave bias. Signed-off-by: Jacob Shin <jacob.shin@amd.com> Acked-by: Thomas Renninger <trenn@suse.de> Acked-by: Borislav Petkov <bp@suse.de> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | cpufreq: drivers: Remove unnecessary assignments of policy-> membersViresh Kumar2013-04-021-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Some assignments of policy-> min/max/cur/cpuinfo.min_freq/cpuinfo.max_freq aren't required as part of it is done by cpufreq driver or cpufreq core. Remove them. At some places we merge multiple lines together too. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Acked-by: Sekhar Nori <nsekhar@ti.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | cpufreq: Documentation: Fix cpufreq_frequency_table nameViresh Kumar2013-04-021-2/+2
| | | | | | | | | | | | | | | | At few places in documentation cpufreq_frequency_table is written as cpufreq_freq_table. Fix these. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* | cpufreq: conservative: Fix sampling_down_factor functionalityStratos Karafotis2013-04-011-0/+6
|/ | | | | | | | | | | | sampling_down_factor tunable is unused since commit 8e677ce83bf41ba9c74e5b6d9ee60b07d4e5ed93 (4 years ago). This patch restores the original functionality and documents the tunable. Signed-off-by: Stratos Karafotis <stratosk@semaphore.gr> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* cpufreq: Update Documentation for cpus and related_cpusViresh Kumar2013-02-022-4/+10
| | | | | | | | | Documentation related to cpus and related_cpus is confusing and not very clear. Over that CPUFreq core has seen much changes recently. Lets update documentation and comments for cpus and related_cpus. Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
* acpi-cpufreq: Add support for disabling dynamic overclockingAndre Przywara2012-09-091-0/+93
| | | | | | | | | | | | | | | | | | | | | | | One feature present in powernow-k8 that isn't present in acpi-cpufreq is support for enabling or disabling AMD's core performance boost technology. This patch adds support to acpi-cpufreq, but also includes support for Intel's dynamic acceleration. The original boost disabling sysfs file was per CPU, but acted globally. Also the naming (cpb) was at least not intuitive. So lets introduce a single file simply called "boost", which sits once in /sys/devices/system/cpu/cpufreq. This should be the only way of using this feature, so add documentation about the rationale and the usage. A following patch will re-introduce the cpb knob for compatibility reasons on AMD CPUs. Per-CPU boost switching is possible, but not trivial and is thus postponed to a later patch series. Signed-off-by: Andre Przywara <andre.przywara@amd.com> Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
* Doc: cpufreq: Fix typo and outdated linePaul Bolle2011-11-081-3/+1Star
| | | | | | | | | | 'sampling_rate_max' was removed with commit ef598549 ("[...] Remove deprecated sysfs file sampling_rate_max"), so its line can be dropped from governors.txt. And 'show_sampling_rate_min' is a typo: the sysfs file is called 'sampling_rate_min'. Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* Fix documentation and comment typo 'no_hz'Paul Bolle2011-08-081-1/+1
| | | | | | Signed-off-by: Paul Bolle <pebolle@tiscali.nl> Acked-by: Len Brown <len.brown@intel.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* doc: fix wrong arch/i386 referencesWanlong Gao2011-06-131-1/+1
| | | | | | | | | | | | Change all "arch/i386" to "arch/x86" in Documentaion/, since the directory has changed. Also update the files which have changed their filename in the meantime accordingly. Signed-off-by: Wanlong Gao <wanlong.gao@gmail.com> [jkosina@suse.cz: reword changelog] Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* [CPUFREQ] Add documentation for sampling_down_factorVishwanath BS2011-03-161-0/+11
| | | | | | | | Update cpufreq governor documentation for sampling_down_factor tunable parameter. Signed-off-by: Vishwanath BS <vishwanath.bs@ti.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Processor Clocking Control interface driverNaga Chumbalkar2010-01-131-0/+207
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Processor Clocking Control (PCC) is an interface between the BIOS and OSPM. Based on the server workload, OSPM can request what frequency it expects from a logical CPU, and the BIOS will achieve that frequency transparently. This patch introduces driver support for PCC. OSPM uses the PCC driver to communicate with the BIOS via the PCC interface. There is a Documentation file that provides a link to the PCC Specification, and also provides a summary of the PCC interface. Currently, certain HP ProLiant platforms implement the PCC interface. However, any platform whose BIOS implements the PCC Specification, can utilize this driver. V2 --> V1 changes (based on Dominik's suggestions): - Removed the dependency on CPU_FREQ_TABLE - "cpufreq_stats" will no longer PANIC. Actually, it will not load anymore because it is not applicable. - Removed the sanity check for target frequency in the ->target routine. NOTE: A patch to sanitize the target frequency requested by "ondemand" is needed to ensure that the target freq < policy->min. Can this driver be queued up for the 2.6.33 tree? Signed-off-by: Naga Chumbalkar <nagananda.chumbalkar@hp.com> Signed-off-by: Matthew Garrett <mjg@redhat.com> Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] fix default value for ondemand governorMike Frysinger2010-01-131-2/+2
| | | | | Signed-off-by: Mike Frysinger <vapier@gentoo.org> Signed-off-by: Dave Jones <davej@redhat.com>
* [ACPI/CPUFREQ] Introduce bios_limit per cpu cpufreq sysfs interfaceThomas Renninger2009-11-241-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This interface is mainly intended (and implemented) for ACPI _PPC BIOS frequency limitations, but other cpufreq drivers can also use it for similar use-cases. Why is this needed: Currently it's not obvious why cpufreq got limited. People see cpufreq/scaling_max_freq reduced, but this could have happened by: - any userspace prog writing to scaling_max_freq - thermal limitations - hardware (_PPC in ACPI case) limitiations Therefore export bios_limit (in kHz) to: - Point the user that it's the BIOS (broken or intended) which limits frequency - Export it as a sysfs interface for userspace progs. While this was a rarely used feature on laptops, there will appear more and more server implemenations providing "Green IT" features like allowing the service processor to limit the frequency. People want to know about HW/BIOS frequency limitations. All ACPI P-state driven cpufreq drivers are covered with this patch: - powernow-k8 - powernow-k7 - acpi-cpufreq Tested with a patched DSDT which limits the first two cores (_PPC returns 1) via _PPC, exposed by bios_limit: # echo 2200000 >cpu2/cpufreq/scaling_max_freq # cat cpu*/cpufreq/scaling_max_freq 2600000 2600000 2200000 2200000 # #scaling_max_freq shows general user/thermal/BIOS limitations # cat cpu*/cpufreq/bios_limit 2600000 2600000 2800000 2800000 # #bios_limit only shows the HW/BIOS limitation CC: Pallipadi Venkatesh <venkatesh.pallipadi@intel.com> CC: Len Brown <lenb@kernel.org> CC: davej@codemonkey.org.uk CC: linux@dominikbrodowski.net Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Document units for transition latencyMark Brown2009-11-241-3/+3
| | | | | | | They're documented in the header but not in Documentation. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] update Doc for cpuinfo_cur_freq and scaling_cur_freqNaga Chumbalkar2009-09-011-2/+7
| | | | | | | | | | | | | | | | | | | | | | | I think the way "cpuinfo_cur_info" and "scaling_cur_info" are defined under ./Documentation/cpu-freq/user-guide.txt can be enhanced. Currently, they are both defined the same way: "Current speed/frequency" of the CPU, in KHz". Below is a patch that distinguishes one from the other. Regards, - naga - ----------------------------------------- Update description for "cpuinfo_cur_freq" and "scaling_cur_freq". Some of the wording is drawn from comments found in ./drivers/cpufreq/cpufreq.c: cpufreq_out_of_sync(): * @old_freq: CPU frequency the kernel thinks the CPU runs at * @new_freq: CPU frequency the CPU actually runs at Signed-off-by: Naga Chumbalkar <nagananda.chumbalkar@hp.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] minor correction to cpu-freq documentationChumbalkar Nagananda2009-06-152-2/+1Star
| | | | | | | | I have been reading the documentation for cpufreq closely. Found a couple of minor errors in the Documentation. Signed-off-by: Naga Chumbalkar <nagananda.chumbalkar@hp.com> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Only set sampling_rate_max deprecated, sampling_rate_min is usefulThomas Renninger2009-06-151-12/+14
| | | | | | | | Update the documentation accordingly. Cleanup and use printk_once. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] ondemand/conservative: sanitize sampling_rate restrictionsThomas Renninger2009-02-251-1/+13
| | | | | | | | Limit sampling rate to transition_latency * 100 or kernel limits. If sampling_rate is tried to be set too low, set the lowest allowed value. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] ondemand/conservative: deprecate sampling_rate{min,max}Thomas Renninger2009-02-251-2/+8
| | | | | | | The same info can be obtained via the transition_latency sysfs file Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] Introduce ↵Thomas Renninger2009-02-251-0/+12
| | | | | | | | | | | | | | | /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_transition_latency It's not only useful for the ondemand and conservative governors, but also for userspace daemons to know about the HW transition latency of the CPU. It is especially useful for userspace to know about this value when the ondemand or conservative governors are run. The sampling rate control value depends on it and for userspace being able to set sane tuning values there it has to know about the transition latency. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Dave Jones <davej@redhat.com>
* ACPI: cpufreq: Remove deprecated /proc/acpi/processor/../performance proc ↵Thomas Renninger2009-02-041-16/+0Star
| | | | | | | | | | | | | entries They were long enough set deprecated... Update Documentation/cpu-freq/users-guide.txt: The deprecated files listed there seen not to exist for some time anymore already. Signed-off-by: Thomas Renninger <trenn@suse.de> Signed-off-by: Len Brown <len.brown@intel.com>
* doc: Update sh cpufreq documentation.Paul Mundt2008-12-221-4/+2Star
| | | | | | | The sh cpufreq driver is no longer limited to just the SH-3 and SH-4, update the documentation to reflect this fact accordingly. Signed-off-by: Paul Mundt <lethal@linux-sh.org>
* [CPUFREQ] Documentation: Add Blackfin to list of supported processorsRobin Getz2008-11-251-0/+12
| | | | | | Signed-off-by: Robin Getz <rgetz@blackfin.uclinux.org> Signed-off-by: Bryan Wu <cooloney@kernel.org> Signed-off-by: Dave Jones <davej@redhat.com>
* [CPUFREQ] correct broken links and email addressesNémeth Márton2008-10-091-6/+4Star
| | | | | | | | Replace the no longer working links and email address in the documentation and in source code. Signed-off-by: Márton Németh <nm127@freemail.hu> Signed-off-by: Dave Jones <davej@redhat.com>
* Documentation cleanup: trivial misspelling, punctuation, and grammar ↵Matt LaPlante2008-07-261-1/+1
| | | | | | | | corrections. Cc: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* [CPUFREQ] Remove documentation of removed ondemand tunable.Dave Jones2008-05-211-8/+0Star
| | | | | | | sampling_down_factor was removed in ccb2fe209dac9ff67f6351e783e610073afaaeaf back in June 2006. Signed-off-by: Dave Jones <davej@redhat.com>
generated by cgit v1.2.3-55-g7522 (git 2.39.0) at 2024-11-01 15:41:37 +0100