04 Aug, 2010

1 commit


10 Apr, 2010

1 commit

  • Multiple modules used to define those which are with identical
    functionality and were needlessly replicated among the different cpufreq
    drivers. Push them into the header and remove duplication.

    Signed-off-by: Borislav Petkov
    LKML-Reference:
    Reviewed-by: Thomas Renninger
    Signed-off-by: H. Peter Anvin

    Borislav Petkov
     

25 Nov, 2009

1 commit

  • 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
     

29 Oct, 2009

1 commit

  • When CONFIG_CPU_FREQ is disabled, cpufreq_get() needs a stub. Used by kvm
    (although it looks like a bit of the kvm code could be omitted when
    CONFIG_CPU_FREQ is disabled).

    arch/x86/built-in.o: In function `kvm_arch_init':
    (.text+0x10de7): undefined reference to `cpufreq_get'

    (Needed in linux-next's KVM tree, but it's correct in 2.6.32).

    Signed-off-by: Randy Dunlap
    Tested-by: Eric Paris
    Cc: Jiri Slaby
    Cc: Avi Kivity
    Cc: Marcelo Tosatti
    Cc: Dave Jones
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Randy Dunlap
     

02 Sep, 2009

1 commit

  • Currently everything in the cpufreq layer is per core based.
    This does not reflect reality, for example ondemand on conservative
    governors have global sysfs variables.

    Introduce a global cpufreq directory and add the kobject to the governor
    struct, so that governors can easily access it.
    The directory is initialized in the cpufreq_core_init initcall and thus will
    always be created if cpufreq is compiled in, even if no cpufreq driver is
    active later.

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

    Thomas Renninger
     

10 Mar, 2009

1 commit

  • This reverts commit e088e4c9cdb618675874becb91b2fd581ee707e6.

    Removing the sysfs interface for p4-clockmod was flagged as a
    regression in bug 12826.

    Course of action:
    - Find out the remaining causes of overheating, and fix them
    if possible. ACPI should be doing the right thing automatically.
    If it isn't, we need to fix that.
    - mark p4-clockmod ui as deprecated
    - try again with the removal in six months.

    It's not really feasible to printk about the deprecation, because
    it needs to happen at all the sysfs entry points, which means adding
    a lot of strcmp("p4-clockmod".. calls to the core, which.. bleuch.

    Signed-off-by: Dave Jones

    Dave Jones
     

06 Jan, 2009

1 commit

  • Impact: use new cpumask API to reduce memory usage

    This is part of an effort to reduce structure sizes for machines
    configured with large NR_CPUS. cpumask_t gets replaced by
    cpumask_var_t, which is either struct cpumask[1] (small NR_CPUS) or
    struct cpumask * (large NR_CPUS).

    Signed-off-by: Rusty Russell
    Signed-off-by: Mike Travis
    Acked-by: Dave Jones
    Signed-off-by: Ingo Molnar

    Rusty Russell
     

06 Dec, 2008

1 commit

  • p4-clockmod has a long history of abuse. It pretends to be a CPU
    frequency scaling driver, even though it doesn't actually change
    the CPU frequency, but instead just modulates the frequency with
    wait-states.
    The biggest misconception is that when running at the lower 'frequency'
    p4-clockmod is saving power. This isn't the case, as workloads running
    slower take longer to complete, preventing the CPU from entering deep C states.

    However p4-clockmod does have a purpose. It can prevent overheating.
    Having it hooked up to the cpufreq interfaces is the wrong way to achieve
    cooling however. It should instead be hooked up to ACPI.

    This diff introduces a means for a cpufreq driver to register with the
    cpufreq core, but not present a sysfs interface.

    Signed-off-by: Matthew Garrett
    Signed-off-by: Dave Jones

    Matthew Garrett
     

10 Oct, 2008

1 commit


31 Jul, 2008

1 commit

  • Ingo Molnar provided a fix to not call _PPC at processor driver
    initialization time in "[PATCH] ACPI: fix cpufreq regression" (git
    commit e4233dec749a3519069d9390561b5636a75c7579)

    But it can still happen that _PPC is called at processor driver
    initialization time.

    This patch should make sure that this is not possible anymore.

    Signed-off-by: Thomas Renninger
    Cc: Andi Kleen
    Cc: Len Brown
    Cc: Dave Jones
    Cc: Ingo Molnar
    Cc: Venkatesh Pallipadi
    Cc:
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Thomas Renninger
     

20 May, 2008

1 commit


29 Apr, 2008

2 commits

  • Allow use of the powersave cpufreq governor as the default one for EMBEDDED
    configs.

    Signed-off-by: Alessandro Guido
    Signed-off-by: Andrew Morton
    Signed-off-by: Dave Jones

    Alessandro Guido
     
  • Currently, affected_cpus shows which CPUs need to have their frequency
    coordinated in software. When hardware coordination is in use, the contents
    of this file appear the same as when no coordination is required. This can
    lead to some confusion among user-space programs, for example, that do not
    know that extra coordination is required to force a CPU core to a particular
    speed to control power consumption.

    To fix this, create a "related_cpus" attribute that always displays the
    coordination map regardless of whatever coordination strategy the cpufreq
    driver uses (sw or hw). If the cpufreq driver does not provide a value, fall
    back to policy->cpus.

    Signed-off-by: Darrick J. Wong
    Signed-off-by: Andrew Morton
    Signed-off-by: Dave Jones

    Darrick J. Wong
     

07 Feb, 2008

1 commit

  • Eliminate cpufreq_userspace scaling_setspeed deadlock.

    Luming Yu recently uncovered yet another cpufreq related deadlock.
    One thread that continuously switches the governors and the other thread that
    repeatedly cats the contents of cpufreq directory causes both these threads to
    go into a deadlock.

    Detailed examination of the deadlock showed the exact flow before the deadlock
    as:

    Thread 1 Thread 2
    ________ ________
    cats files under /sys/devices/.../cpufreq/
    Set governor to userspace
    Adds a new sysfs entry for
    scaling_setspeed
    cats files under /sys/devices/.../cpufreq/

    Set governor to performance
    Holds cpufreq_rw_sem in write
    mode
    Sends a STOP notify to
    userspace governor
    cat /sys/devices/.../cpufreq/scaling_setspeed
    Gets a handle on the above sysfs entry with
    sysfs_get_active
    Blocks while trying to get cpufreq_rw_sem
    in read mode
    Remove a sysfs entry for
    scaling_setspeed
    Blocks on sysfs_deactivate
    while waiting for earlier
    get_active (on other thread)
    to drain

    At this point both threads go into deadlock and any other thread that tries to
    do anything with sysfs cpufreq will also block.

    There seems to be no easy way to avoid this deadlock as long as
    cpufreq_userspace adds/removes the sysfs entry under same kobject as cpufreq.
    Below patch moves scaling_setspeed to cpufreq.c, keeping it always and calling
    back the governor on read/write. This is the cleanest fix I could think of,
    even though adding two callbacks in governor structure just for this seems
    unnecessary.

    Note that the change makes scaling_setspeed under /sys/.../cpufreq permanent
    and returns when governor is not userspace.

    Signed-off-by: Venkatesh Pallipadi
    Signed-off-by: Dave Jones

    Venki Pallipadi
     

05 Oct, 2007

3 commits

  • Callsites such as arch/powerpc/oprofile/op_model_cell.c are having to
    open-code #ifdef CONFIG_CPU_FREQ only to be able to get at the full definition
    of cpufreq_unregister_notifier(), because no empty stub is available for the
    !CONFIG_CPU_FREQ case. Let's provide one, to be able to remove such #ifdef's
    from the rest of the kernel tree -- those will come in a subsequent patch.

    Signed-off-by: Satyam Sharma
    Signed-off-by: Andrew Morton
    Signed-off-by: Dave Jones

    Satyam Sharma
     
  • Cc: Adrian Bunk
    Signed-off-by: Andrew Morton
    Signed-off-by: Dave Jones

    Thomas Renninger
     
  • Depending on the transition latency of the HW for cpufreq switches, the
    ondemand or conservative governor cannot be used with certain cpufreq
    drivers. Still the ondemand should be the default governor on a wide range
    of systems. This patch allows this and lets the governor fallback to the
    performance governor at cpufreq driver load time, if the driver does not
    support fast enough frequency switching.

    Main benefit is that on e.g. installation or other systems without
    userspace support a working dynamic cpufreq support can be achieved on most
    systems by simply loading the cpufreq driver. This is especially essential
    for recent x86(_64) laptop hardware which may rely on working dynamic
    cpufreq OS support.

    Signed-off-by: Thomas Renninger
    Signed-off-by: Venkatesh Pallipadi
    Cc: Russell King
    Cc: Bryan Wu
    Cc: Andi Kleen
    Cc: "Luck, Tony"
    Cc: Paul Mackerras
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mundt
    Cc: "David S. Miller"
    Signed-off-by: Andrew Morton
    Signed-off-by: Dave Jones

    Thomas Renninger
     

27 Sep, 2007

1 commit

  • This reverts commit 184c44d2049c4db7ef6ec65794546954da2c6a0e.

    As noted by Dave Jones:
    "Linus, please revert the above cset. It doesn't seem to be
    necessary (it was added to fix a miscompile in 'make allnoconfig'
    which doesn't seem to be repeatable with it reverted) and actively
    breaks the ARM SA1100 framebuffer driver."

    Requested-by: Dave Jones
    Cc: Russell King
    Cc: Andrew Morton
    Cc: Andi Kleen
    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

06 May, 2007

1 commit

  • * 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6: (231 commits)
    [PATCH] i386: Don't delete cpu_devs data to identify different x86 types in late_initcall
    [PATCH] i386: type may be unused
    [PATCH] i386: Some additional chipset register values validation.
    [PATCH] i386: Add missing !X86_PAE dependincy to the 2G/2G split.
    [PATCH] x86-64: Don't exclude asm-offsets.c in Documentation/dontdiff
    [PATCH] i386: avoid redundant preempt_disable in __unlazy_fpu
    [PATCH] i386: white space fixes in i387.h
    [PATCH] i386: Drop noisy e820 debugging printks
    [PATCH] x86-64: Fix allnoconfig error in genapic_flat.c
    [PATCH] x86-64: Shut up warnings for vfat compat ioctls on other file systems
    [PATCH] x86-64: Share identical video.S between i386 and x86-64
    [PATCH] x86-64: Remove CONFIG_REORDER
    [PATCH] x86-64: Print type and size correctly for unknown compat ioctls
    [PATCH] i386: Remove copy_*_user BUG_ONs for (size < 0)
    [PATCH] i386: Little cleanups in smpboot.c
    [PATCH] x86-64: Don't enable NUMA for a single node in K8 NUMA scanning
    [PATCH] x86: Use RDTSCP for synchronous get_cycles if possible
    [PATCH] i386: Add X86_FEATURE_RDTSCP
    [PATCH] i386: Implement X86_FEATURE_SYNC_RDTSC on i386
    [PATCH] i386: Implement alternative_io for i386
    ...

    Fix up trivial conflict in include/linux/highmem.h manually.

    Signed-off-by: Linus Torvalds

    Linus Torvalds
     

03 May, 2007

1 commit


27 Apr, 2007

1 commit


27 Feb, 2007

1 commit


23 Feb, 2007

1 commit


11 Feb, 2007

1 commit

  • Yet another attempt to resolve cpufreq and hotplug locking issues.

    Patchset has 3 patches:
    * Rewrite the lock infrastructure of cpufreq using a per cpu rwsem.
    * Minor restructuring of work callback in ondemand driver.
    * Use the new cpufreq rwsem infrastructure in ondemand work.

    This patch:

    Convert policy->lock to rwsem and move it to per_cpu area.
    This rwsem will protect against both changing/accessing policy
    related parameters and CPU hot plug/unplug.

    [malattia@linux.it: fix oops in kref_put()]
    Cc: Gautham R Shenoy
    Signed-off-by: Venkatesh Pallipadi
    Cc: Gautham R Shenoy
    Signed-off-by: Mattia Dongili
    Signed-off-by: Andrew Morton
    Signed-off-by: Dave Jones

    Venkatesh Pallipadi
     

16 Oct, 2006

1 commit

  • Enable ondemand governor and acpi-cpufreq to use IA32_APERF and IA32_MPERF MSR
    to get active frequency feedback for the last sampling interval. This will
    make ondemand take right frequency decisions when hardware coordination of
    frequency is going on.

    Without APERF/MPERF, ondemand can take wrong decision at times due
    to underlying hardware coordination or TM2.
    Example:
    * CPU 0 and CPU 1 are hardware cooridnated.
    * CPU 1 running at highest frequency.
    * CPU 0 was running at highest freq. Now ondemand reduces it to
    some intermediate frequency based on utilization.
    * Due to underlying hardware coordination with other CPU 1, CPU 0 continues to
    run at highest frequency (as long as other CPU is at highest).
    * When ondemand samples CPU 0 again next time, without actual frequency
    feedback from APERF/MPERF, it will think that previous frequency change
    was successful and can go to wrong target frequency. This is because it
    thinks that utilization it has got this sampling interval is when running at
    intermediate frequency, rather than actual highest frequency.

    More information about IA32_APERF IA32_MPERF MSR:
    Refer to IA-32 Intel® Architecture Software Developer's Manual at
    http://developer.intel.com

    Signed-off-by: Venkatesh Pallipadi
    Signed-off-by: Dave Jones

    Venkatesh Pallipadi
     

26 Jul, 2006

1 commit

  • The patch below moves the cpu hotplugging higher up in the cpufreq
    layering; this is needed to avoid recursive taking of the cpu hotplug
    lock and to otherwise detangle the mess.

    The new rules are:
    1. you must do lock_cpu_hotplug() around the following functions:
    __cpufreq_driver_target
    __cpufreq_governor (for CPUFREQ_GOV_LIMITS operation only)
    __cpufreq_set_policy
    2. governer methods (.governer) must NOT take the lock_cpu_hotplug()
    lock in any way; they are called with the lock taken already
    3. if your governer spawns a thread that does things, like calling
    __cpufreq_driver_target, your thread must honor rule #1.
    4. the policy lock and other cpufreq internal locks nest within
    the lock_cpu_hotplug() lock.

    I'm not entirely happy about how the __cpufreq_governor rule ended up
    (conditional locking rule depending on the argument) but basically all
    callers pass this as a constant so it's not too horrible.

    The patch also removes the cpufreq_governor() function since during the
    locking audit it turned out to be entirely unused (so no need to fix it)

    The patch works on my testbox, but it could use more testing
    (otoh... it can't be much worse than the current code)

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Linus Torvalds

    Arjan van de Ven
     

26 Jun, 2006

1 commit


23 Jun, 2006

1 commit

  • * 'release' of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6: (65 commits)
    ACPI: suppress power button event on S3 resume
    ACPI: resolve merge conflict between sem2mutex and processor_perflib.c
    ACPI: use for_each_possible_cpu() instead of for_each_cpu()
    ACPI: delete newly added debugging macros in processor_perflib.c
    ACPI: UP build fix for bugzilla-5737
    Enable P-state software coordination via _PDC
    P-state software coordination for speedstep-centrino
    P-state software coordination for acpi-cpufreq
    P-state software coordination for ACPI core
    ACPI: create acpi_thermal_resume()
    ACPI: create acpi_fan_suspend()/acpi_fan_resume()
    ACPI: pass pm_message_t from acpi_device_suspend() to root_suspend()
    ACPI: create acpi_device_suspend()/acpi_device_resume()
    ACPI: replace spin_lock_irq with mutex for ec poll mode
    ACPI: Allow a WAN module enable/disable on a Thinkpad X60.
    sem2mutex: acpi, acpi_link_lock
    ACPI: delete unused acpi_bus_drivers_lock
    sem2mutex: drivers/acpi/processor_perflib.c
    ACPI add ia64 exports to build acpi_memhotplug as a module
    ACPI: asus_acpi_init(): propagate correct return value
    ...

    Manual resolve of conflicts in:

    arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
    arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c
    include/acpi/processor.h

    Linus Torvalds
     

26 Apr, 2006

1 commit


09 Feb, 2006

1 commit


19 Jan, 2006

1 commit

  • This one fell through the automation at first because it initializes the
    semaphore to locked, but that's easily remedied

    Signed-off-by: Arjan van de Ven
    Signed-off-by: Dave Jones

    drivers/cpufreq/cpufreq.c | 37 +++++++++++++++++++------------------
    include/linux/cpufreq.h | 3 ++-
    2 files changed, 21 insertions(+), 19 deletions(-)

    Arjan van de Ven
     

07 Dec, 2005

1 commit

  • What is the value shown in "cpu MHz" of /proc/cpuinfo when CPUs are capable of
    changing frequency?

    Today the answer is: It depends.
    On i386:
    SMP kernel - It is always the boot frequency
    UP kernel - Scales with the frequency change and shows that was last set.

    On x86_64:
    There is one single variable cpu_khz that gets written by all the CPUs. So,
    the frequency set by last CPU will be seen on /proc/cpuinfo of all the
    CPUs in the system. What you see also depends on whether you have constant_tsc
    capable CPU or not.

    On ia64:
    It is always boot time frequency of a particular CPU that gets displayed.

    The patch below changes this to:
    Show the last known frequency of the particular CPU, when cpufreq is present. If
    cpu doesnot support changing of frequency through cpufreq, then boot frequency
    will be shown. The patch affects i386, x86_64 and ia64 architectures.

    Signed-off-by: Venkatesh Pallipadi
    Signed-off-by: Dave Jones

    Venkatesh Pallipadi
     

31 Oct, 2005

1 commit

  • I recently picked up my older work to remove unnecessary #includes of
    sched.h, starting from a patch by Dave Jones to not include sched.h
    from module.h. This reduces the number of indirect includes of sched.h
    by ~300. Another ~400 pointless direct includes can be removed after
    this disentangling (patch to follow later).
    However, quite a few indirect includes need to be fixed up for this.

    In order to feed the patches through -mm with as little disturbance as
    possible, I've split out the fixes I accumulated up to now (complete for
    i386 and x86_64, more archs to follow later) and post them before the real
    patch. This way this large part of the patch is kept simple with only
    adding #includes, and all hunks are independent of each other. So if any
    hunk rejects or gets in the way of other patches, just drop it. My scripts
    will pick it up again in the next round.

    Signed-off-by: Tim Schmielau
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Tim Schmielau
     

08 Jul, 2005

1 commit


01 Jun, 2005

1 commit


29 Apr, 2005

1 commit

  • In order to properly fix some issues with cpufreq vs. sleep on
    PowerBooks, I had to add a suspend callback to the pmac_cpufreq driver.
    I must force a switch to full speed before sleep and I switch back to
    previous speed on resume.

    I also added a driver flag to disable the warnings in suspend/resume
    since it is expected in this case to have different speed (and I want it
    to fixup the jiffies properly).

    Signed-off-by: Benjamin Herrenschmidt
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Benjamin Herrenschmidt
     

17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds