1. 28 1月, 2008 1 次提交
  2. 25 1月, 2008 1 次提交
  3. 07 10月, 2006 1 次提交
  4. 03 7月, 2006 1 次提交
  5. 01 7月, 2006 1 次提交
  6. 30 6月, 2006 2 次提交
    • I
      [PATCH] genirq: cleanup: merge irq_affinity[] into irq_desc[] · a53da52f
      Ingo Molnar 提交于
      Consolidation: remove the irq_affinity[NR_IRQS] array and move it into the
      irq_desc[NR_IRQS].affinity field.
      
      [akpm@osdl.org: sparc64 build fix]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a53da52f
    • I
      [PATCH] genirq: rename desc->handler to desc->chip · d1bef4ed
      Ingo Molnar 提交于
      This patch-queue improves the generic IRQ layer to be truly generic, by adding
      various abstractions and features to it, without impacting existing
      functionality.
      
      While the queue can be best described as "fix and improve everything in the
      generic IRQ layer that we could think of", and thus it consists of many
      smaller features and lots of cleanups, the one feature that stands out most is
      the new 'irq chip' abstraction.
      
      The irq-chip abstraction is about describing and coding and IRQ controller
      driver by mapping its raw hardware capabilities [and quirks, if needed] in a
      straightforward way, without having to think about "IRQ flow"
      (level/edge/etc.) type of details.
      
      This stands in contrast with the current 'irq-type' model of genirq
      architectures, which 'mixes' raw hardware capabilities with 'flow' details.
      The patchset supports both types of irq controller designs at once, and
      converts i386 and x86_64 to the new irq-chip design.
      
      As a bonus side-effect of the irq-chip approach, chained interrupt controllers
      (master/slave PIC constructs, etc.) are now supported by design as well.
      
      The end result of this patchset intends to be simpler architecture-level code
      and more consolidation between architectures.
      
      We reused many bits of code and many concepts from Russell King's ARM IRQ
      layer, the merging of which was one of the motivations for this patchset.
      
      This patch:
      
      rename desc->handler to desc->chip.
      
      Originally i did not want to do this, because it's a big patch.  But having
      both "desc->handler", "desc->handle_irq" and "action->handler" caused a
      large degree of confusion and made the code appear alot less clean than it
      truly is.
      
      I have also attempted a dual approach as well by introducing a
      desc->chip alias - but that just wasnt robust enough and broke
      frequently.
      
      So lets get over with this quickly.  The conversion was done automatically
      via scripts and converts all the code in the kernel.
      
      This renaming patch is the first one amongst the patches, so that the
      remaining patches can stay flexible and can be merged and split up
      without having some big monolithic patch act as a merge barrier.
      
      [akpm@osdl.org: build fix]
      [akpm@osdl.org: another build fix]
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d1bef4ed
  7. 28 3月, 2006 1 次提交
    • P
      ppc: Remove CHRP, POWER3 and POWER4 support from arch/ppc · 0a26b136
      Paul Mackerras 提交于
      32-bit CHRP machines are now supported only in arch/powerpc, as are
      all 64-bit PowerPC processors.  This means that we don't use
      Open Firmware on any platform in arch/ppc any more.
      
      This makes PReP support a single-platform option like every other
      platform support option in arch/ppc now, thus CONFIG_PPC_MULTIPLATFORM
      is gone from arch/ppc.  CONFIG_PPC_PREP is the option that selects
      PReP support and is generally what has replaced
      CONFIG_PPC_MULTIPLATFORM within arch/ppc.
      
      _machine is all but dead now, being #defined to 0.
      
      Updated Makefiles, comments and Kconfig options generally to reflect
      these changes.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      0a26b136
  8. 10 2月, 2006 1 次提交
  9. 19 10月, 2005 1 次提交
  10. 11 10月, 2005 1 次提交
    • P
      ppc: Various minor compile fixes · fd582ec8
      Paul Mackerras 提交于
      This fixes up a variety of minor problems in compiling with ARCH=ppc
      arising from using the merged versions of various header files.
      A lot of the changes are just adding #include <asm/machdep.h> to
      files that use ppc_md or smp_ops_t.
      
      This also arranges for us to use semaphore.c, vecemu.c, vector.S and
      fpu.S from arch/powerpc/kernel when compiling with ARCH=ppc.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      fd582ec8
  11. 30 9月, 2005 1 次提交
  12. 05 9月, 2005 1 次提交
  13. 28 6月, 2005 1 次提交
    • B
      [PATCH] ppc32: Bump PMU interrupt priority · e4ee69c8
      Benjamin Herrenschmidt 提交于
      The Power Management Unit on PowerMacs is very sensitive to timeouts during
      async message exchanges.  It uses rather crude protocol based on a shift
      register with an interrupt and is almost continuously exchanging messages with
      the host CPU on laptops.
      
      This patch adds a routine to the open_pic driver to be able to select a PMU
      driver so that it bumps it's interrupt priority to above the normal level.
      
      This will allow PMU interrupts to occur while another interrupt is pending,
      and thus reduce the risk of machine beeing abruptly shutdown by the PMU due to
      a timeout in PMU communication caused by excessive interrupt latency.  The
      problem is very rare, and usually just doesn't happen, but it is still useful
      to make things even more robust.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      e4ee69c8
  14. 22 6月, 2005 1 次提交
  15. 29 5月, 2005 1 次提交
    • B
      [PATCH] ppc32: Fix cpufreq vs. sleep issue · b16eeb47
      Benjamin Herrenschmidt 提交于
      Recent kernels occasionally trigger a PMU timeout on some mac laptops,
      typically on wakeup from sleep.  This seem to be caused by either a too big
      latency caused by the cpufreq switch on wakeup from sleep or by an
      interrupt beeing lost due to the reset of the interrupt controller done
      during wakeup.
      
      This patch makes that code more robust by stopping PMU auto poll activity
      around cpufreq changes on machines that use the PMU for such changes (long
      latency switching involving a CPU hard reset and flush of all caches) and
      by removing the reset of the open pic interrupt controller on wakeup (that
      can cause the loss of an interrupt and Darwin doesn't do it, so it must not
      be necessary).
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      b16eeb47
  16. 20 5月, 2005 1 次提交
  17. 17 4月, 2005 2 次提交
    • B
      [PATCH] ppc32: Fix cpufreq problems · 7a648b9e
      Benjamin Herrenschmidt 提交于
      This patch updates the PowerMac cpufreq driver.  It depends on the addition
      of the suspend() method (my previous patch) and on the new flag I defined
      to silence some warnings that are normal for us.
      
      It fixes various issues related to cpufreq on pmac, including some crashes
      on some models when sleeping the machine while in low speed, proper voltage
      control on some newer machines, and adds voltage control on 750FX based G3
      laptops.
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      7a648b9e
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4