28 Sep, 2017

1 commit

  • Commit 33fc30b47098 (cpufreq: intel_pstate: Document the current
    behavior and user interface) dropped the intel-pstate.txt file
    from Documentation/cpu-freq/, but it did not update the index.txt
    file in there accordingly, so do that now.

    Fixes: 33fc30b47098 (cpufreq: intel_pstate: Document the current behavior and user interface)
    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

14 May, 2017

1 commit


14 Mar, 2017

1 commit

  • The user/admin documentation of cpufreq is badly outdated. It
    conains stale and/or inaccurate information along with things
    that are not particularly useful. Also, some of the important
    pieces are missing from it.

    For this reason, add a new user/admin document for cpufreq
    containing current information to admin-guide and drop the old
    outdated .txt documents it is replacing.

    Since there will be more PM documents in admin-guide going forward,
    create a separate directory for them and put the cpufreq document
    in there right away.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Viresh Kumar
    Signed-off-by: Jonathan Corbet

    Rafael J. Wysocki
     

09 Mar, 2017

1 commit


23 Feb, 2017

1 commit

  • Pull documentation updates from Jonathan Corbet:
    "A slightly quieter cycle for documentation this time around.

    Three more DocBook template files have been converted to RST; only 21
    to go. There are various build improvements and the usual array of
    documentation improvements and fixes"

    * tag 'docs-4.11' of git://git.lwn.net/linux: (44 commits)
    docs / driver-api: Fix structure references in device_link.rst
    PM / docs: Fix structure references in device.rst
    Add a target to check broken external links in the Documentation
    Documentation: Fix linux-api list typo
    Documentation: DocBook/Makefile comment typo
    Improve sparse documentation
    Documentation: make Makefile.sphinx no-ops quieter
    Documentation: DMA-ISA-LPC.txt
    Documentation: input: fix path to input code definitions
    docs: Remove the copyright year from conf.py
    docs: Fix a warning in the Korean HOWTO.rst translation
    PM / sleep / docs: Convert PM notifiers document to reST
    PM / core / docs: Convert sleep states API document to reST
    PM / core: Update kerneldoc comments in pm.h
    doc-rst: Fix recursive make invocation from macros
    doc-rst: Delete output of failed dot-SVG conversion
    doc-rst: Break shell command sequences on failure
    Documentation/sphinx: make targets independent of Sphinx work for HAVE_SPHINX=0
    doc-rst: fixed cleandoc target when used with O=dir
    Documentation/sphinx: prevent generation of .pyc files in the source tree
    ...

    Linus Torvalds
     

04 Feb, 2017

3 commits

  • Make it possible to change the operation mode of intel_pstate with
    the help of a new sysfs attribute called "status".

    There are three possible configurations that can be selected using
    this attribute:

    "off" - The driver is not in use at this time.
    "active" - The driver works as a P-state governor (default).
    "passive" - The driver works as a regular cpufreq one and collaborates
    with the generic cpufreq governors (it sets P-states as
    requested by those governors). [This is the same mode
    the driver can be started in by passing intel_pstate=passive
    in the kernel command line.]

    The current setting is returned by reads from this attribute. Writing
    one of the above strings to it changes the operation mode as indicated
    by that string, if possible.

    If HW-managed P-states (HWP) feature is enabled, it is not possible
    to change the driver's operation mode and attempts to write to this
    attribute will fail.

    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     
  • The cpufreq core has gone though lots of updates in recent times, but on
    many occasions the documentation wasn't updated along with the code.
    This patch tries to catchup the documentation with the code.

    Also add Rafael and Viresh as the contributors to the documentation.

    Based on a patch from Claudio Scordino.

    Signed-off-by: Claudio Scordino
    Signed-off-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     
  • This patch doesn't change the content of the documentation, but rather
    reformat it to make it more readable.

    Signed-off-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

05 Jan, 2017

1 commit


08 Dec, 2016

1 commit


11 Nov, 2016

1 commit


01 Nov, 2016

1 commit


22 Oct, 2016

1 commit


09 Sep, 2016

1 commit

  • The cpufreq-stats code can no longer be built as a module, so it now
    appears with square brackets in menuconfig.

    Signed-off-by: Jean Delvare
    Fixes: 1aefc75b2449 (cpufreq: stats: Make the stats code non-modular)
    Acked-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Jean Delvare
     

23 Jul, 2016

1 commit

  • This reverts commit 790d849bf811a8ab5d4cd2cce0f6fda92f6aebf2.

    Using a v4.7-rc7 kernel on a HP ProLiant triggered following messages

    pcc-cpufreq: (v1.10.00) driver loaded with frequency limits: 1200 MHz, 2800 MHz
    cpufreq: ondemand governor failed, too long transition latency of HW, fallback to performance governor

    The last line was shown for each CPU in the system.
    Testing v4.5 (where commit 790d849b was integrated) triggered
    similar messages. Same behaviour on a 2nd HP Proliant system.

    So commit 790d849bf (cpufreq: pcc-cpufreq: update default value of
    cpuinfo_transition_latency) causes the system to use performance
    governor which, I guess, was not the intention of the patch.

    Enabling debug output in pcc-cpufreq provides following verbose output:

    pcc-cpufreq: (v1.10.00) driver loaded with frequency limits: 1200 MHz, 2800 MHz
    pcc_get_offset: for CPU 0: pcc_cpu_data input_offset: 0x44, pcc_cpu_data output_offset: 0x48
    init: policy->max is 2800000, policy->min is 1200000
    get: get_freq for CPU 0
    get: SUCCESS: (virtual) output_offset for cpu 0 is 0xffffc9000d7c0048, contains a value of: 0xff06. Speed is: 168000 MHz
    cpufreq: ondemand governor failed, too long transition latency of HW, fallback to performance governor
    target: CPU 0 should go to target freq: 2800000 (virtual) input_offset is 0xffffc9000d7c0044
    target: was SUCCESSFUL for cpu 0

    I am asking to revert 790d849bf to re-enable usage of ondemand
    governor with pcc-cpufreq.

    Fixes: 790d849bf (cpufreq: pcc-cpufreq: update default value of cpuinfo_transition_latency)
    CC: # 4.5+
    Signed-off-by: Andreas Herrmann
    Signed-off-by: Rafael J. Wysocki

    Andreas Herrmann
     

09 Jun, 2016

2 commits


03 Jun, 2016

1 commit

  • All cpufreq drivers with a freq-table are migrated to use
    cpufreq_table_validate_and_show() long back and the routine
    cpufreq_frequency_table_cpuinfo() isn't used outside of cpufreq core
    now.

    Unexport it and update Documentation as well.

    Signed-off-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

19 Feb, 2016

1 commit


05 Jan, 2016

1 commit


10 Dec, 2015

1 commit

  • 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
    Acked-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Jacob Tanenbaum
     

01 Sep, 2015

1 commit


25 Jun, 2015

1 commit

  • 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()
    ...

    Linus Torvalds
     

05 Jun, 2015

1 commit

  • 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
    Cc: "Rafael J. Wysocki"
    Cc: Kristen Carlson Accardi
    Cc: Dirk Brandewie
    Cc: x86@kernel.org
    Acked-by: Viresh Kumar
    Signed-off-by: Prarit Bhargava
    Signed-off-by: Jonathan Corbet

    Prarit Bhargava
     

06 May, 2015

1 commit

  • 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
    Signed-off-by: Rafael J. Wysocki

    Wang Long
     

30 Jan, 2015

2 commits


12 Nov, 2014

1 commit

  • 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
    Signed-off-by: Rafael J. Wysocki

    Dirk Brandewie
     

07 Jul, 2014

1 commit


06 Jun, 2014

1 commit

  • 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
    Signed-off-by: Viresh Kumar
    Reviewed-by: Doug Anderson
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

07 May, 2014

1 commit

  • 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
    Signed-off-by: Nishanth Menon
    Acked-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Nishanth Menon
     

01 May, 2014

1 commit

  • 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
    [rjw: Changelog]
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

30 Apr, 2014

1 commit

  • 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
    Acked-by: Lad, Prabhakar
    Acked-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Stratos Karafotis
     

20 Mar, 2014

1 commit

  • 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
    [rjw: Minor modifications]
    Signed-off-by: Rafael J. Wysocki

    Dirk Brandewie
     

19 Mar, 2014

1 commit


17 Jan, 2014

1 commit


06 Jan, 2014

1 commit


26 Oct, 2013

1 commit

  • 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
    Acked-by: Jesper Nilsson
    Acked-by: Linus Walleij
    Acked-by: Russell King
    Acked-by: David S. Miller
    Tested-by: Andrew Lunn
    Signed-off-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

10 Aug, 2013

1 commit


04 Jun, 2013

1 commit

  • 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
    Acked-by: Simon Horman
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar