1. 12 Feb, 2003 8 commits
    • Linus Torvalds's avatar
      Merge bk://linux-dj.bkbits.net/cpufreq · 7cc3ef9a
      Linus Torvalds authored
      into penguin.transmeta.com:/home/penguin/torvalds/repositories/kernel/linux
      7cc3ef9a
    • Dave Jones's avatar
      [CPUFREQ] fix longrun min/max confusion. · ce2d3f00
      Dave Jones authored
      ce2d3f00
    • Dave Jones's avatar
      [CPUFREQ] add support for cpufreq governors. · 2e585809
      Dave Jones authored
      More bits from Dominik.
      
      Most cpufreq drivers (in fact, all except one, longrun) or even most
      cpu frequency scaling algorithms only offer the CPU to be set to one
      frequency. In order to offer dynamic frequency scaling, the cpufreq
      core must be able to tell these drivers of a "target frequency". So
      these specific drivers will be transformed to offer a "->target"
      call instead of the existing "->setpolicy" call. For "longrun", all
      stays the same, though.
      
      How to decide what frequency within the CPUfreq policy should be used?
      That's done using "cpufreq governors". Two are already in this patch
      -- they're the already existing "powersave" and "performance" which
      set the frequency statically to the lowest or highest frequency,
      respectively. At least two more such governors will be ready for
      addition in the near future, but likely many more as there are various
      different theories and models about dynamic frequency scaling
      around. Using such a generic interface as cpufreq offers to scaling
      governors, these can be tested extensively, and the best one can be
      selected for each specific use.
      
      Basically, it's the following flow graph:
      
      CPU can be set to switch independetly    |         CPU can only be set
            within specific "limits"           |       to specific frequencies
      
                                       "CPUfreq policy"
                      consists of frequency limits (policy->{min,max})
                           and CPUfreq governor to be used
                               /                    \
                              /                      \
                             /                       the cpufreq governor decides
                            /                        (dynamically or statically)
                           /                         what target_freq to set within
                          /                          the limits of policy->{min,max}
                         /                                \
                        /                                  \
              Using the ->setpolicy call,              Using the ->target call,
                  the limits and the                    the frequency closest
                   "policy" is set.                     to target_freq is set.
                                                        It is assured that it
                                                        is within policy->{min,max}
      2e585809
    • Dave Jones's avatar
      [CPUFREQ] Properly set memory allocated by x86 cpufreq drivers to zero. · b846cb81
      Dave Jones authored
      From Dominik Brodowski
      b846cb81
    • Pavel Machek's avatar
      [PATCH] Fix stack handling in acpi_wakeup.S · 26a97bb1
      Pavel Machek authored
      This fixes stack handling in acpi_wakeup.S, and makes stack smaller so
      that wakeup code actually fits inside memory allocated for it. Plus
      someone renamed .L1432 to something meaningful.
      26a97bb1
    • Linus Torvalds's avatar
    • Ivan Kokshaysky's avatar
      [PATCH] alpha: Add missing sighand bits · fcb96784
      Ivan Kokshaysky authored
      fcb96784
    • Tomas Szepe's avatar
      [PATCH] export allow_signal() · 0cbea0df
      Tomas Szepe authored
      Export allow_signal().  It's needed by lockd, sunrpc and other modules.
      0cbea0df
  2. 11 Feb, 2003 27 commits
  3. 10 Feb, 2003 5 commits