1. 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
  2. 22 4月, 2006 2 次提交
    • O
      [PATCH] powerpc: Lack of ISA interrupts on XICS isn't dangerous · cc98f705
      Olof Johansson 提交于
      This isn't really a dangerous thing any more; most systems lack
      ISA interrupt controllers.
      Signed-off-by: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      cc98f705
    • H
      [PATCH] powerpc: clear IPIs on kdump · 81bbbe92
      Haren Myneni 提交于
      In some crash scenarios, the kexec CPU is not responding to an IPI sent by
      secondary CPU after init thread is forked, causing the system to drop into
      xmon during kdump boot.  This problem can be reproduced each time when the
      debugger is enabled and soft-reset is used to invoke kdump boot. The first
      CPU sends an IPI - setting the IPI priority for all secondary cpus
      (xics_cause_ipi()). But some CPUs will enter into the xmon via soft-reset,
      i.e, not executing xics_ipi_action(). Hence, IPI is not cleared. When
      exited from the debugger, one of these CPUs could become the primary kexec
      CPU. Since the IPI is not cleared, causing this issue in kdump boot. This
      patch clears and EOI IPI for kexec CPU as well before the kdump boot
      started.
      Signed-off-by: NHaren Myneni <haren@us.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      81bbbe92
  3. 01 4月, 2006 1 次提交
  4. 29 3月, 2006 1 次提交
  5. 27 3月, 2006 1 次提交
    • A
      [PATCH] powerpc: Allow non zero boot cpuids · 4df20460
      Anton Blanchard 提交于
      We currently have a hack to flip the boot cpu and its secondary thread
      to logical cpuid 0 and 1. This means the logical - physical mapping will
      differ depending on which cpu is boot cpu. This is most apparent on
      kexec, where we might kexec on any cpu and therefore change the mapping
      from boot to boot.
      
      The patch below does a first pass early on to work out the logical cpuid
      of the boot thread. We then fix up some paca structures to match.
      
      Ive also removed the boot_cpuid_phys variable for ppc64, to be
      consistent we use get_hard_smp_processor_id(boot_cpuid) everywhere.
      Signed-off-by: NAnton Blanchard <anton@samba.org>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      4df20460
  6. 22 3月, 2006 1 次提交
  7. 12 1月, 2006 1 次提交
  8. 09 1月, 2006 1 次提交
  9. 22 12月, 2005 1 次提交
    • P
      powerpc: Fix i8259 cascade on pSeries with XICS interrupt controller · 8b1af56b
      Paul Mackerras 提交于
      It turns out that commit f9bd170a
      broke the cascade from XICS to i8259 on pSeries machines; specifically
      we ended up not ever doing the EOI on the XICS for the cascade.  The
      result was that interrupts from the serial ports (and presumably any
      other devices using ISA interrupts) didn't get through.  This fixes
      it and also simplifies the code, by doing the EOI on the XICS in the
      xics_get_irq routine after reading and acking the interrupt on the
      i8259.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      8b1af56b
  10. 10 11月, 2005 1 次提交
  11. 09 11月, 2005 1 次提交
  12. 28 10月, 2005 2 次提交
  13. 12 9月, 2005 1 次提交
  14. 05 8月, 2005 1 次提交
  15. 26 6月, 2005 1 次提交
    • R
      [PATCH] ppc64: kexec support for ppc64 · fce0d574
      R Sharada 提交于
      This patch implements the kexec support for ppc64 platforms.
      
      A couple of notes:
      
      1)  We copy the pages in virtual mode, using the full base kernel
          and a statically allocated stack.   At kexec_prepare time we
          scan the pages and if any overlap our (0, _end[]) range we
          return -ETXTBSY.
      
          On PowerPC 64 systems running in LPAR (logical partitioning)
          mode, only a small region of memory, referred to as the RMO,
          can be accessed in real mode.  Since Linux runs with only one
          zone of memory in the memory allocator, and it can be orders of
          magnitude more memory than the RMO, looping until we allocate
          pages in the source region is not feasible.  Copying in virtual
          means we don't have to write a hash table generation and call
          hypervisor to insert translations, instead we rely on the pinned
          kernel linear mapping.  The kernel already has move to linked
          location built in, so there is no requirement to load it at 0.
      
          If we want to load something other than a kernel, then a stub
          can be written to copy a linear chunk in real mode.
      
      2)  The start entry point gets passed parameters from the kernel.
          Slaves are started at a fixed address after copying code from
          the entry point.
      
          All CPUs get passed their firmware assigned physical id in r3
          (most calling conventions use this register for the first
          argument).
      
          This is used to distinguish each CPU from all other CPUs.
          Since firmware is not around, there is no other way to obtain
          this information other than to pass it somewhere.
      
          A single CPU, referred to here as the master and the one executing
          the kexec call, branches to start with the address of start in r4.
          While this can be calculated, we have to load it through a gpr to
          branch to this point so defining the register this is contained
          in is free.  A stack of unspecified size is available at r1
          (also common calling convention).
      
          All remaining running CPUs are sent to start at absolute address
          0x60 after copying the first 0x100 bytes from start to address 0.
          This convention was chosen because it matches what the kernel
          has been doing itself.  (only gpr3 is defined).
      
          Note: This is not quite the convention of the kexec bootblock v2
          in the kernel.  A stub has been written to convert between them,
          and we may adjust the kernel in the future to allow this directly
          without any stub.
      
      3)  Destination pages can be placed anywhere, even where they
          would not be accessible in real mode.  This will allow us to
          place ram disks above the RMO if we choose.
      Signed-off-by: NMilton Miller <miltonm@bga.com>
      Signed-off-by: NR Sharada <sharada@in.ibm.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      fce0d574
  16. 06 5月, 2005 1 次提交
  17. 17 4月, 2005 1 次提交
    • 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