02 Apr, 2013

2 commits

  • cpufreq layer doesn't call cpufreq driver's callback for any offline
    CPU and so checking that isn't useful.

    Lets get rid of it.

    Signed-off-by: Viresh Kumar
    Acked-by: David S. Miller
    Signed-off-by: Rafael J. Wysocki

    Viresh Kumar
     
  • 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
     

02 Feb, 2013

2 commits


21 Nov, 2012

2 commits


01 Nov, 2012

1 commit


23 Oct, 2012

1 commit

  • Commit 6889125b8b4e09c5e53e6ecab3433bed1ce198c9
    (cpufreq/powernow-k8: workqueue user shouldn't migrate the kworker to another CPU)
    causes powernow-k8 to trigger a preempt warning, e.g.:

    BUG: using smp_processor_id() in preemptible [00000000] code: cpufreq/3776
    caller is powernowk8_target+0x20/0x49
    Pid: 3776, comm: cpufreq Not tainted 3.6.0 #9
    Call Trace:
    [] debug_smp_processor_id+0xc7/0xe0
    [] powernowk8_target+0x20/0x49
    [] __cpufreq_driver_target+0x82/0x8a
    [] cpufreq_governor_performance+0x4e/0x54
    [] __cpufreq_governor+0x8c/0xc9
    [] __cpufreq_set_policy+0x1a9/0x21e
    [] store_scaling_governor+0x16f/0x19b
    [] ? cpufreq_update_policy+0x124/0x124
    [] ? _raw_spin_unlock_irqrestore+0x2c/0x49
    [] store+0x60/0x88
    [] sysfs_write_file+0xf4/0x130
    [] vfs_write+0xb5/0x151
    [] sys_write+0x4a/0x71
    [] system_call_fastpath+0x16/0x1b

    Fix this by by always using work_on_cpu().

    Signed-off-by: Andreas Herrmann
    Cc: stable@vger.kernel.org
    Signed-off-by: Rafael J. Wysocki

    Andreas Herrmann
     

03 Oct, 2012

1 commit

  • Pull power management updates from Rafael J Wysocki:

    - Improved system suspend/resume and runtime PM handling for the SH
    TMU, CMT and MTU2 clock event devices (also used by ARM/shmobile).

    - Generic PM domains framework extensions related to cpuidle support
    and domain objects lookup using names.

    - ARM/shmobile power management updates including improved support for
    the SH7372's A4S power domain containing the CPU core.

    - cpufreq changes related to AMD CPUs support from Matthew Garrett,
    Andre Przywara and Borislav Petkov.

    - cpu0 cpufreq driver from Shawn Guo.

    - cpufreq governor fixes related to the relaxing of limit from Michal
    Pecio.

    - OMAP cpufreq updates from Axel Lin and Richard Zhao.

    - cpuidle ladder governor fixes related to the disabling of states from
    Carsten Emde and me.

    - Runtime PM core updates related to the interactions with the system
    suspend core from Alan Stern and Kevin Hilman.

    - Wakeup sources modification allowing more helper functions to be
    called from interrupt context from John Stultz and additional
    diagnostic code from Todd Poynor.

    - System suspend error code path fix from Feng Hong.

    Fixed up conflicts in cpufreq/powernow-k8 that stemmed from the
    workqueue fixes conflicting fairly badly with the removal of support for
    hardware P-state chips. The changes were independent but somewhat
    intertwined.

    * tag 'pm-for-3.7-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (76 commits)
    Revert "PM QoS: Use spinlock in the per-device PM QoS constraints code"
    PM / Runtime: let rpm_resume() succeed if RPM_ACTIVE, even when disabled, v2
    cpuidle: rename function name "__cpuidle_register_driver", v2
    cpufreq: OMAP: Check IS_ERR() instead of NULL for omap_device_get_by_hwmod_name
    cpuidle: remove some empty lines
    PM: Prevent runtime suspend during system resume
    PM QoS: Use spinlock in the per-device PM QoS constraints code
    PM / Sleep: use resume event when call dpm_resume_early
    cpuidle / ACPI : move cpuidle_device field out of the acpi_processor_power structure
    ACPI / processor: remove pointless variable initialization
    ACPI / processor: remove unused function parameter
    cpufreq: OMAP: remove loops_per_jiffy recalculate for smp
    sections: fix section conflicts in drivers/cpufreq
    cpufreq: conservative: update frequency when limits are relaxed
    cpufreq / ondemand: update frequency when limits are relaxed
    properly __init-annotate pm_sysrq_init()
    cpufreq: Add a generic cpufreq-cpu0 driver
    PM / OPP: Initialize OPP table from device tree
    ARM: add cpufreq transiton notifier to adjust loops_per_jiffy for smp
    cpufreq: Remove support for hardware P-state chips from powernow-k8
    ...

    Linus Torvalds
     

20 Sep, 2012

1 commit

  • powernowk8_target() runs off a per-cpu work item and if the
    cpufreq_policy->cpu is different from the current one, it migrates the
    kworker to the target CPU by manipulating current->cpus_allowed. The
    function migrates the kworker back to the original CPU but this is
    still broken. Workqueue concurrency management requires the kworkers
    to stay on the same CPU and powernowk8_target() ends up triggerring
    BUG_ON(rq != this_rq()) in try_to_wake_up_local() if it contends on
    fidvid_mutex and sleeps.

    It is unclear why this bug is being reported now. Duncan says it
    appeared to be a regression of 3.6-rc1 and couldn't reproduce it on
    3.5. Bisection seemed to point to 63d95a91 "workqueue: use @pool
    instead of @gcwq or @cpu where applicable" which is an non-functional
    change. Given that the reproduce case sometimes took upto days to
    trigger, it's easy to be misled while bisecting. Maybe something made
    contention on fidvid_mutex more likely? I don't know.

    This patch fixes the bug by using work_on_cpu() instead if @pol->cpu
    isn't the same as the current one. The code assumes that
    cpufreq_policy->cpu is kept online by the caller, which Rafael tells
    me is the case.

    stable: ed48ece27c ("workqueue: reimplement work_on_cpu() using
    system_wq") should be applied before this; otherwise, the
    behavior could be horrible.

    Signed-off-by: Tejun Heo
    Reported-by: Duncan
    Tested-by: Duncan
    Cc: Rafael J. Wysocki
    Cc: Andreas Herrmann
    Cc: stable@vger.kernel.org
    Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=47301

    Tejun Heo
     

10 Sep, 2012

3 commits

  • These chips are now supported by acpi-cpufreq, so we can delete all the
    code handling them.

    Andre: Tighten the deprecation warning message. Trigger load of
    acpi-cpufreq and let the load of the module finally fail.
    This avoids the problem of users ending up without any cpufreq support
    after the transition.

    Signed-off-by: Matthew Garrett
    Signed-off-by: Andre Przywara
    Signed-off-by: Rafael J. Wysocki

    Matthew Garrett
     
  • powernow-k8 is quite prematurely crying Hooray and outputs diagnostic
    messages, although the actual initialization can still fail.
    Since now we may have acpi-cpufreq already loaded, we move the
    messages at the end of the init routine to avoid confusing output
    if the loading of powernow-k8 should not succeed.

    Signed-off-by: Andre Przywara
    Signed-off-by: Rafael J. Wysocki

    Andre Przywara
     
  • cpufreq modules are often loaded from init scripts that assume that
    all recent AMD systems will use powernow-k8.
    To inform the user of the change of support and ease the transition
    to acpi-cpufreq, emit a warning message.

    Signed-off-by: Andre Przywara
    Signed-off-by: Rafael J. Wysocki

    Andre Przywara
     

05 Sep, 2012

1 commit


27 Jan, 2012

1 commit

  • This marks all the x86 cpuinfo tables to the CPU specific device drivers,
    to allow auto loading by udev. This should simplify the distribution
    startup scripts for this greatly.

    I didn't add MODULE_DEVICE_IDs to the centrino and p4-clockmod drivers,
    because those probably shouldn't be auto loaded and the acpi driver
    be used instead (not fully sure on that, would appreciate feedback)

    The old nforce drivers autoload based on the PCI ID.

    ACPI cpufreq is autoloaded in another patch.

    v3: Autoload gx based on PCI IDs only. Remove cpu check (Dave Jones)
    v4: Use newly introduce HW_PSTATE feature for powernow-k8 loading

    Cc: Dave Jones
    Cc: Kay Sievers
    Signed-off-by: Andi Kleen
    Signed-off-by: Thomas Renninger
    Acked-by: H. Peter Anvin
    Signed-off-by: Greg Kroah-Hartman

    Andi Kleen
     

06 Jan, 2012

3 commits


17 Jun, 2011

2 commits

  • This patch augments the pstate transition code to error out
    (instead of returning 0) when an incorrect pstate is provided.

    Suggested-by: Borislav Petkov
    CC: andre.przywara@amd.com
    CC: Mark.Langsdorf@amd.com
    Signed-off-by: Konrad Rzeszutek Wilk
    Signed-off-by: Dave Jones

    Konrad Rzeszutek Wilk
     
  • Before this patch if we failed the vid transition would still try to
    submit the "new" frequencies to cpufreq.
    That is incorrect - also we could submit a non-existing frequency value
    which would cause cpufreq to crash. The ultimate fix is in cpufreq
    to deal with incorrect values, but this patch improves the error
    recovery in the AMD powernowk8 driver.

    The failure that was reported was as follows:

    powernow-k8: Found 1 AMD Athlon(tm) 64 Processor 3700+ (1 cpu cores) (version 2.20.00)
    powernow-k8: fid 0x2 (1000 MHz), vid 0x12
    powernow-k8: fid 0xa (1800 MHz), vid 0xa
    powernow-k8: fid 0xc (2000 MHz), vid 0x8
    powernow-k8: fid 0xe (2200 MHz), vid 0x8
    Marking TSC unstable due to cpufreq changes
    powernow-k8: fid trans failed, fid 0x2, curr 0x0
    BUG: unable to handle kernel paging request at ffff880807e07b78
    IP: [] cpufreq_stats_update+0x46/0x5b
    ...

    And transition fails and data->currfid ends up with 0. Since
    the machine does not support 800Mhz value when the calculation is
    done ('find_khz_freq_from_fid(data->currfid);') it reports the
    new frequency as 800000 which is bogus. This patch fixes
    the issue during target setting.

    The patch however does not fix the issue in 'powernowk8_cpu_init'
    where the pol->cur can also be set with the 800000 value:

    pol->cur = find_khz_freq_from_fid(data->currfid);
    dprintk("policy current frequency %d kHz\n", pol->cur);

    /* min/max the cpu is capable of */
    if (cpufreq_frequency_table_cpuinfo(pol, data->powernow_table)) {

    The fix for that looks to update cpufreq_frequency_table_cpuinfo to
    check pol->cur.... but that would cause an regression in how the
    acpi-cpufreq driver works (it sets cpu->cur after calling
    cpufreq_frequency_table_cpuinfo). Instead the fix will be to let
    cpufreq gracefully handle bogus data (another patch).

    Acked-by: Borislav Petkov
    CC: andre.przywara@amd.com
    CC: Mark.Langsdorf@amd.com
    Reported-by: Tobias Diedrich
    Tested-by: Tobias Diedrich
    [v1: Rebased on v3.0-rc2, reduced patch to deal with vid case]
    Signed-off-by: Konrad Rzeszutek Wilk
    Signed-off-by: Dave Jones

    Konrad Rzeszutek Wilk
     

20 May, 2011

1 commit