Skip to content
  1. Feb 03, 2008
    • Mathieu Desnoyers's avatar
      Add HAVE_OPROFILE · 42d4b839
      Mathieu Desnoyers authored
      
      
      Linus:
      On the per-architecture side, I do think it would be better to *not* have
      internal architecture knowledge in a generic file, and as such a line like
      
              depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32
      
      really shouldn't exist in a file like kernel/Kconfig.instrumentation.
      
      It would be much better to do
      
              depends on ARCH_SUPPORTS_KPROBES
      
      in that generic file, and then architectures that do support it would just
      have a
      
              bool ARCH_SUPPORTS_KPROBES
                      default y
      
      in *their* architecture files. That would seem to be much more logical,
      and is readable both for arch maintainers *and* for people who have no
      clue - and don't care - about which architecture is supposed to support
      which interface...
      
      Changelog:
      
      Actually, I know I gave this as the magic incantation, but now that I see
      it, I realize that I should have told you to just use
      
              config ARCH_SUPPORTS_KPROBES
                      def_bool y
      
      instead, which is a bit denser.
      
      We seem to use both kinds of syntax for these things, but this is really
      what "def_bool" is there for...
      
      Changelog :
      
      - Moving to HAVE_*.
      - Add AVR32 oprofile.
      
      Signed-off-by: default avatarMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      42d4b839
  2. Jan 28, 2008
  3. Oct 19, 2007
  4. Oct 16, 2007
  5. Oct 02, 2007
  6. Sep 17, 2007
  7. Jul 11, 2007
  8. Feb 20, 2007
  9. Feb 11, 2007
    • Christoph Lameter's avatar
      [PATCH] Set CONFIG_ZONE_DMA for arches with GENERIC_ISA_DMA · 5ac6da66
      Christoph Lameter authored
      
      
      As Andi pointed out: CONFIG_GENERIC_ISA_DMA only disables the ISA DMA
      channel management.  Other functionality may still expect GFP_DMA to
      provide memory below 16M.  So we need to make sure that CONFIG_ZONE_DMA is
      set independent of CONFIG_GENERIC_ISA_DMA.  Undo the modifications to
      mm/Kconfig where we made ZONE_DMA dependent on GENERIC_ISA_DMA and set
      theses explicitly in each arches Kconfig.
      
      Reviews must occur for each arch in order to determine if ZONE_DMA can be
      switched off.  It can only be switched off if we know that all devices
      supported by a platform are capable of performing DMA transfers to all of
      memory (Some arches already support this: uml, avr32, sh sh64, parisc and
      IA64/Altix).
      
      In order to switch ZONE_DMA off conditionally, one would have to establish
      a scheme by which one can assure that no drivers are enabled that are only
      capable of doing I/O to a part of memory, or one needs to provide an
      alternate means of performing an allocation from a specific range of memory
      (like provided by alloc_pages_range()) and insure that all drivers use that
      call.  In that case the arches alloc_dma_coherent() may need to be modified
      to call alloc_pages_range() instead of relying on GFP_DMA.
      
      Signed-off-by: default avatarChristoph Lameter <clameter@sgi.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      5ac6da66
  10. Jan 24, 2007
  11. Dec 12, 2006
  12. Dec 08, 2006
    • David Howells's avatar
      [PATCH] LOG2: Implement a general integer log2 facility in the kernel · f0d1b0b3
      David Howells authored
      
      
      This facility provides three entry points:
      
      	ilog2()		Log base 2 of unsigned long
      	ilog2_u32()	Log base 2 of u32
      	ilog2_u64()	Log base 2 of u64
      
      These facilities can either be used inside functions on dynamic data:
      
      	int do_something(long q)
      	{
      		...;
      		y = ilog2(x)
      		...;
      	}
      
      Or can be used to statically initialise global variables with constant values:
      
      	unsigned n = ilog2(27);
      
      When performing static initialisation, the compiler will report "error:
      initializer element is not constant" if asked to take a log of zero or of
      something not reducible to a constant.  They treat negative numbers as
      unsigned.
      
      When not dealing with a constant, they fall back to using fls() which permits
      them to use arch-specific log calculation instructions - such as BSR on
      x86/x86_64 or SCAN on FRV - if available.
      
      [akpm@osdl.org: MMC fix]
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Herbert Xu <herbert@gondor.apana.org.au>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Wojtek Kaniewski <wojtekka@toxygen.net>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      f0d1b0b3
    • Judith Lebzelter's avatar
      [PATCH] use generic BUG for ppc · a8605aef
      Judith Lebzelter authored
      
      
      Switch ppc over to using the generic BUG implementation.
      
      Signed-off-by: default avatarJudith Lebzelter <judith@osdl.org>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Cc: Michael Ellerman <michael@ellerman.id.au>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      a8605aef
  13. Dec 04, 2006
  14. Nov 30, 2006
  15. Oct 03, 2006
    • Matt LaPlante's avatar
      Attack of "the the"s in arch · 4b3f686d
      Matt LaPlante authored
      
      
      The patch below corrects multiple occurances of "the the"
      typos across several files, both in source comments and KConfig files.
      There is no actual code changed, only text.  Note this only affects the /arch
      directory, and I believe I could find many more elsewhere. :)
      
      Signed-off-by: default avatarAdrian Bunk <bunk@stusta.de>
      4b3f686d
  16. Sep 27, 2006
  17. Sep 13, 2006
  18. Jun 29, 2006
  19. May 24, 2006
  20. Mar 27, 2006
  21. Mar 26, 2006
  22. Feb 07, 2006
  23. Jan 15, 2006
    • Paul Mackerras's avatar
      [PATCH] ppc: Remove powermac support from ARCH=ppc · a7fdd90b
      Paul Mackerras authored
      
      
      This makes it possible to build kernels for PReP and/or CHRP
      with ARCH=ppc by removing the (non-building) powermac support.
      It's now also possible to select PReP and CHRP independently.
      Powermac users should now build with ARCH=powerpc instead of
      ARCH=ppc.  (This does mean that it is no longer possible to
      build a 32-bit kernel for a G5.)
      
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      a7fdd90b
  24. Jan 11, 2006
  25. Jan 09, 2006
  26. Dec 05, 2005
    • Paul Mackerras's avatar
      ppc: Build in all three of powermac, PREP and CHRP support · b6d78157
      Paul Mackerras authored
      
      
      This reverts commit da0825fd, making
      it so that if you select CONFIG_PPC_MULTIPLATFORM you get support
      for PMAC, PREP and CHRP built in.
      
      The reason for not allowing PMAC, PREP and CHRP to be selected
      individually for ARCH=ppc is that there is too much interdependency
      between them in the platform support code.  For example, CHRP uses
      the PMAC nvram code.
      
      Configuring with ARCH=powerpc does allow you to select support for
      PMAC and CHRP separately.  Support for PREP is not there yet but
      should be there soon.
      
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      b6d78157
  27. Nov 07, 2005
  28. Oct 26, 2005
  29. Sep 21, 2005
  30. Sep 18, 2005
  31. Sep 15, 2005
    • David S. Miller's avatar
      [LIB]: Consolidate _atomic_dec_and_lock() · 4db2ce01
      David S. Miller authored
      
      
      Several implementations were essentialy a common piece of C code using
      the cmpxchg() macro.  Put the implementation in one spot that everyone
      can share, and convert sparc64 over to using this.
      
      Alpha is the lone arch-specific implementation, which codes up a
      special fast path for the common case in order to avoid GP reloading
      which a pure C version would require.
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4db2ce01
  32. Sep 10, 2005
    • Paul Mackerras's avatar
      [PATCH] ppc32: support hotplug cpu on powermacs · 31139971
      Paul Mackerras authored
      
      
      This allows cpus to be off-lined on 32-bit SMP powermacs.  When a cpu
      is off-lined, it is put into sleep mode with interrupts disabled.  It
      can be on-lined again by asserting its soft-reset pin, which is
      connected to a GPIO pin.
      
      With this I can off-line the second cpu in my dual G4 powermac, which
      means that I can then suspend the machine (the suspend/resume code
      refuses to suspend if more than one cpu is online, and making it cope
      with multiple cpus is surprisingly messy).
      
      Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      31139971
Loading