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