1. 12 Feb, 2003 11 commits
    • Andrew Morton's avatar
      [PATCH] kill some ppc64 warnings in knfsd · ebca3272
      Andrew Morton authored
      Don't assume that dev_t is an unsigned.  Cast it.
      ebca3272
    • Andrew Morton's avatar
      [PATCH] kill warning in vmscan.c · 8b7ee204
      Andrew Morton authored
      Make the "duplicate const" warning go away.  Arguably a compiler bug...
      8b7ee204
    • Andrew Morton's avatar
      [PATCH] genhd warnings fix · d89ff79e
      Andrew Morton authored
      I have a whole bunch of silly compile warning fixes here, arising from
      building the kernel for a 64-bit target.  Some are trivial, some are genuine
      printk bugs.
      
      assuming dev_t is unsigned generates a warning on ppc64.  Cast it.
      d89ff79e
    • 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 2 commits
    • David S. Miller's avatar
      Merge nuts.ninka.net:/home/davem/src/BK/sparcwork-2.5 · 7aaaac17
      David S. Miller authored
      into nuts.ninka.net:/home/davem/src/BK/sparc-2.5
      7aaaac17
    • David S. Miller's avatar
      [SIGNAL]: Allow more platforms to use generic get_signal_to_deliver. · b6f7756d
      David S. Miller authored
      The few platforms that cannot use the generic
      get_signal_to_deliver implementation cannot do
      so because they do special things for ptraced
      children.  This can be easily avoided and thus
      all of the signal handling code duplication can
      be eliminated.
      
      This is the first part, which adds a platform hook
      right before the parent of the ptraced child is woken.
      Data can be passed in via a cookie argument.
      
      The next part will be dealing with platforms
      that need to muck with breakpoints in the child
      in this same code block.
      b6f7756d