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
     

14 Nov, 2014

1 commit

  • The pcc-cpufreq driver is not automatically loaded on systems where
    the platform's power management setting requires this driver.
    Instead, on those systems no CPU frequency driver is registered and
    active.

    Make the autoloading matching criteria for loading the pcc-cpufreq
    driver the same as done in acpi-cpufreq by commit c655affbd524d01
    ("ACPI / cpufreq: Add ACPI processor device IDs to acpi-cpufreq").

    x86 CPU frequency drivers are now typically autoloaded by specifying
    MODULE_DEVICE_TABLE entries and x86cpu model specific matching.
    But pcc-cpufreq was omitted when acpi-cpufreq and other drivers were
    changed to use this approach.

    Both acpi-cpufreq and pcc-cpufreq depend on a distinct and mutually
    exclusive set of ACPI methods which are not directly tied to specific
    processor model numbers. Both of these drivers have init routines
    which look for their required ACPI methods. As a result, only the
    appropriate driver registers as the cpu frequency driver and the other
    one ends up being unloaded.

    Tested on various systems where acpi-cpufreq, intel_pstate, and
    pcc-cpufreq are the expected cpu frequency drivers.

    Signed-off-by: Lenny Szubowicz
    Signed-off-by: Joseph Szczypek
    Reported-by: Trinh Dao
    Signed-off-by: Rafael J. Wysocki

    Lenny Szubowicz
     

29 Sep, 2014

1 commit

  • Fix the following bug introduced by commit 8fec051eea73 (cpufreq:
    Convert existing drivers to use cpufreq_freq_transition_{begin|end})
    that forgot to move the spin_lock() in pcc_cpufreq_target() past
    cpufreq_freq_transition_begin() which calls wait_event():

    BUG: sleeping function called from invalid context at drivers/cpufreq/cpufreq.c:370
    in_atomic(): 1, irqs_disabled(): 0, pid: 2636, name: modprobe
    Preemption disabled at:[] pcc_cpufreq_target+0x27/0x200 [pcc_cpufreq]
    [ 51.025044]
    CPU: 57 PID: 2636 Comm: modprobe Tainted: G E 3.17.0-default #7
    Hardware name: Hewlett-Packard ProLiant DL980 G7, BIOS P66 07/07/2010
    00000000ffffffff ffff88026c46b828 ffffffff81589dbd 0000000000000000
    ffff880037978090 ffff88026c46b848 ffffffff8108e1df ffff880037978090
    0000000000000000 ffff88026c46b878 ffffffff8108e298 ffff88026d73ec00
    Call Trace:
    [] dump_stack+0x4d/0x90
    [] ___might_sleep+0x10f/0x180
    [] __might_sleep+0x48/0xd0
    [] cpufreq_freq_transition_begin+0x75/0x140 drivers/cpufreq/cpufreq.c:370 wait_event(policy->transition_wait, !policy->transition_ongoing);
    [] ? preempt_count_add+0xb9/0xc0
    [] pcc_cpufreq_target+0x63/0x200 [pcc_cpufreq] drivers/cpufreq/pcc-cpufreq.c:207 spin_lock(&pcc_lock);
    [] ? update_ts_time_stats+0x7f/0xb0
    [] __cpufreq_driver_target+0x85/0x170
    [] od_check_cpu+0xa8/0xb0
    [] dbs_check_cpu+0x180/0x1d0
    [] cpufreq_governor_dbs+0x3b0/0x720
    [] od_cpufreq_governor_dbs+0x33/0xe0
    [] __cpufreq_governor+0xa9/0x210
    [] cpufreq_set_policy+0x1e2/0x2e0
    [] cpufreq_init_policy+0x8c/0x110
    [] ? cpufreq_update_policy+0x1b0/0x1b0
    [] ? preempt_count_sub+0xb9/0x100
    [] __cpufreq_add_dev+0x596/0x6b0
    [] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq]
    [] cpufreq_add_dev+0xe/0x10
    [] subsys_interface_register+0xc1/0xf0
    [] ? preempt_count_sub+0xb9/0x100
    [] cpufreq_register_driver+0x117/0x2a0
    [] pcc_cpufreq_init+0x55/0x9f8 [pcc_cpufreq]
    [] ? pcc_cpufreq_probe+0x4b4/0x4b4 [pcc_cpufreq]
    [] do_one_initcall+0xc8/0x1f0
    [] ? __vunmap+0x9d/0x100
    [] do_init_module+0x30/0x1b0
    [] load_module+0x686/0x710
    [] ? do_init_module+0x1b0/0x1b0
    [] SyS_init_module+0x9b/0xc0
    [] system_call_fastpath+0x16/0x1b

    Fixes: 8fec051eea73 (cpufreq: Convert existing drivers to use cpufreq_freq_transition_{begin|end})
    Reported-and-tested-by: Mike Galbraith
    Cc: 3.15+ # 3.15+
    Signed-off-by: Rafael J. Wysocki

    Rafael J. Wysocki
     

26 Mar, 2014

1 commit


06 Jan, 2014

1 commit

  • In the current code, if we fail during a frequency transition, we
    simply send the POSTCHANGE notification with the old frequency. This
    isn't enough.

    One of the core users of these notifications is the code responsible
    for keeping loops_per_jiffy aligned with frequency changes. And mostly
    it is written as:

    if ((val == CPUFREQ_PRECHANGE && freq->old < freq->new) ||
    (val == CPUFREQ_POSTCHANGE && freq->old > freq->new)) {
    update-loops-per-jiffy...
    }

    So, suppose we are changing to a higher frequency and failed during
    transition, then following will happen:
    - CPUFREQ_PRECHANGE notification with freq-new > freq-old
    - CPUFREQ_POSTCHANGE notification with freq-new == freq-old

    The first one will update loops_per_jiffy and second one will do
    nothing. Even if we send the 2nd notification by exchanging values of
    freq-new and old, some users of these notifications might get
    unstable.

    This can be fixed by simply calling cpufreq_notify_post_transition()
    with error code and this routine will take care of sending
    notifications in the correct order.

    Signed-off-by: Viresh Kumar
    [rjw: Folded 3 patches into one, rebased unicore2 changes]
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

28 Oct, 2013

1 commit

  • * pm-cpufreq: (167 commits)
    cpufreq: create per policy rwsem instead of per CPU cpu_policy_rwsem
    intel_pstate: Add Baytrail support
    intel_pstate: Refactor driver to support CPUs with different MSR layouts
    cpufreq: Implement light weight ->target_index() routine
    PM / OPP: rename header to linux/pm_opp.h
    PM / OPP: rename data structures to dev_pm equivalents
    PM / OPP: rename functions to dev_pm_opp*
    cpufreq / governor: Remove fossil comment
    cpufreq: exynos4210: Use the common clock framework to set APLL clock rate
    cpufreq: exynos4x12: Use the common clock framework to set APLL clock rate
    cpufreq: Detect spurious invocations of update_policy_cpu()
    cpufreq: pmac64: enable cpufreq on iMac G5 (iSight) model
    cpufreq: pmac64: provide cpufreq transition latency for older G5 models
    cpufreq: pmac64: speed up frequency switch
    cpufreq: highbank-cpufreq: Enable Midway/ECX-2000
    exynos-cpufreq: fix false return check from "regulator_set_voltage"
    speedstep-centrino: Remove unnecessary braces
    acpi-cpufreq: Add comment under ACPI_ADR_SPACE_SYSTEM_IO case
    cpufreq: arm-big-little: use clk_get instead of clk_get_sys
    cpufreq: exynos: Show a list of available frequencies
    ...

    Conflicts:
    drivers/devfreq/exynos/exynos5_bus.c

    Rafael J. Wysocki
     

16 Oct, 2013

2 commits

  • Many common initializations of struct policy are moved to core now and hence
    this driver doesn't need to do it. This patch removes such code.

    Most recent of those changes is to call ->get() in the core after calling
    ->init().

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

    Viresh Kumar
     
  • Most of the users of cpufreq_verify_within_limits() calls it for
    limiting with min/max from policy->cpuinfo. We can make that code
    simple by introducing another routine which will do this for them
    automatically.

    This patch adds another routine cpufreq_verify_within_cpu_limits()
    and updates others to use it.

    Signed-off-by: Viresh Kumar
    Acked-by: Dirk Brandewie
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

24 Sep, 2013

1 commit

  • acpi_has_method() is a new ACPI API introduced to check
    the existence of an ACPI control method.

    It can be used to replace acpi_get_handle() in the case that
    1. the calling function doesn't need the ACPI handle of the control method.
    and
    2. the calling function doesn't care the reason why the method is unavailable.

    Convert acpi_get_handle() to acpi_has_method()
    in drivers/cpufreq/pcc_freq.c in this patch.

    Signed-off-by: Zhang Rui
    Signed-off-by: Rafael J. Wysocki

    Zhang Rui
     

10 Aug, 2013

1 commit


24 Jun, 2013

1 commit

  • PRECHANGE and POSTCHANGE notifiers must be called in groups, i.e
    either both should be called or both shouldn't be.

    In case we have started PRECHANGE notifier and found an error, we
    must call POSTCHANGE notifier with freqs.new = freqs.old to guarantee
    that the sequence of calling notifiers is complete.

    This patch fixes it.

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

    Viresh Kumar
     

02 Apr, 2013

1 commit

  • policy->cpus contains all online cpus that have single shared clock line. And
    their frequencies are always updated together.

    Many SMP system's cpufreq drivers take care of this in individual drivers but
    the best place for this code is in cpufreq core.

    This patch modifies cpufreq_notify_transition() to notify frequency change for
    all cpus in policy->cpus and hence updates all users of this API.

    Signed-off-by: Viresh Kumar
    Acked-by: Stephen Warren
    Tested-by: Stephen Warren
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     

09 Aug, 2012

1 commit

  • Convert a 0 error return code to a negative one, as returned elsewhere in the
    function.

    A simplified version of the semantic match that finds this problem is as
    follows: (http://coccinelle.lip6.fr/)

    //
    @@
    identifier ret;
    expression e,e1,e2,e3,e4,x;
    @@

    (
    if (\(ret != 0\|ret < 0\) || ...) { ... return ...; }
    |
    ret = 0
    )
    ... when != ret = e1
    *x = \(kmalloc\|kzalloc\|kcalloc\|devm_kzalloc\|ioremap\|ioremap_nocache\|devm_ioremap\|devm_ioremap_nocache\)(...);
    ... when != x = e2
    when != ret = e3
    *if (x == NULL || ...)
    {
    ... when != ret = e4
    * return ret;
    }
    //

    Signed-off-by: Julia Lawall
    Signed-off-by: Rafael J. Wysocki

    Julia Lawall
     

15 Sep, 2011

1 commit

  • per_cpu(processors, n) can be NULL, resulting in:

    Loading CPUFreq modules[ 437.661360] BUG: unable to handle kernel NULL pointer dereference at (null)
    IP: [] pcc_cpufreq_cpu_init+0x74/0x220 [pcc_cpufreq]

    It's better to avoid the oops by failing the driver, and allowing the
    system to boot.

    Signed-off-by: Naga Chumbalkar
    Cc: Dave Jones
    Cc: Len Brown
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Naga Chumbalkar
     

20 May, 2011

1 commit