Eric Lee / smarc-ti-linux-kernel

20 Mar, 2014

1 commit

  • 367dc4aa9   cpufreq: Add stop CPU callback to cpufreq_driver interface ... Browse Code »
    26

    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

  • 9c0ebcf78   cpufreq: Implement light weight ->target_index() routine ... Browse Code »

    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

  • 507015880   cpufreq: rename index as driver_data in cpufreq_frequency_table ... Browse Code »

    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
     

06 May, 2013

1 commit

  • 534c97b09   Merge branch 'timers-nohz-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip ... Browse Code »

    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
    ...

    Linus Torvalds
     

10 Apr, 2013

1 commit

  • 9c5320c8e   cpufreq: AMD "frequency sensitivity feedback" powersave bias for ondemand governor ... Browse Code »

    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
    Acked-by: Thomas Renninger
    Acked-by: Borislav Petkov
    Acked-by: Viresh Kumar
    Signed-off-by: Rafael J. Wysocki

    Jacob Shin
     

03 Apr, 2013

1 commit

  • 3451d0243   nohz: Rename CONFIG_NO_HZ to CONFIG_NO_HZ_COMMON ... Browse Code »

    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
    Cc: Andrew Morton
    Cc: Chris Metcalf
    Cc: Christoph Lameter
    Cc: Geoff Levand
    Cc: Gilad Ben Yossef
    Cc: Hakan Akkan
    Cc: Ingo Molnar
    Cc: Kevin Hilman
    Cc: Li Zhong
    Cc: Namhyung Kim
    Cc: Paul E. McKenney
    Cc: Paul Gortmaker
    Cc: Peter Zijlstra
    Cc: Steven Rostedt
    Cc: Thomas Gleixner

    Frederic Weisbecker
     

02 Apr, 2013

2 commits

01 Apr, 2013

1 commit

02 Feb, 2013

1 commit

10 Sep, 2012

1 commit

  • 615b73007   acpi-cpufreq: Add support for disabling dynamic overclocking ... Browse Code »

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

    Andre Przywara
     

08 Nov, 2011

1 commit

  • e7cbb5b56   Doc: cpufreq: Fix typo and outdated line ... Browse Code »

    '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
    Signed-off-by: Jiri Kosina

    Paul Bolle
     

09 Aug, 2011

1 commit

13 Jun, 2011

1 commit

  • 25eb650a6   doc: fix wrong arch/i386 references ... Browse Code »

    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
    [jkosina@suse.cz: reword changelog]
    Signed-off-by: Jiri Kosina

    Wanlong Gao
     

17 Mar, 2011

1 commit

13 Jan, 2010

2 commits

  • 0f1d683fb   [CPUFREQ] Processor Clocking Control interface driver ... Browse Code »

    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
    Signed-off-by: Matthew Garrett
    Signed-off-by: Thomas Renninger
    Signed-off-by: Dave Jones

    Naga Chumbalkar
     
  • 292e0041c   [CPUFREQ] fix default value for ondemand governor ... Browse Code »

    Signed-off-by: Mike Frysinger
    Signed-off-by: Dave Jones

    Mike Frysinger
     

25 Nov, 2009

2 commits

  • e2f74f355   [ACPI/CPUFREQ] Introduce bios_limit per cpu cpufreq sysfs interface ... Browse Code »

    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
    CC: Len Brown
    CC: davej@codemonkey.org.uk
    CC: linux@dominikbrodowski.net

    Signed-off-by: Thomas Renninger
    Signed-off-by: Dave Jones

    Thomas Renninger
     
  • bbe237aaf   [CPUFREQ] Document units for transition latency ... Browse Code »

    They're documented in the header but not in Documentation.

    Signed-off-by: Mark Brown
    Signed-off-by: Dave Jones

    Mark Brown
     

02 Sep, 2009

1 commit

  • da470db16   [CPUFREQ] update Doc for cpuinfo_cur_freq and scaling_cur_freq ... Browse Code »

    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
    Signed-off-by: Dave Jones

    Naga Chumbalkar
     

15 Jun, 2009

2 commits

25 Feb, 2009

3 commits

04 Feb, 2009

1 commit

22 Dec, 2008

1 commit

26 Nov, 2008

1 commit

10 Oct, 2008

1 commit

27 Jul, 2008

1 commit

21 May, 2008

1 commit

29 Apr, 2008

1 commit

26 Jan, 2008

1 commit

09 May, 2007

1 commit

13 Dec, 2006

1 commit

30 Nov, 2006

1 commit