1. 03 2月, 2008 3 次提交
    • M
      Move Kconfig.instrumentation to arch/Kconfig and init/Kconfig · 125e5645
      Mathieu Desnoyers 提交于
      Move the instrumentation Kconfig to
      
      arch/Kconfig for architecture dependent options
        - oprofile
        - kprobes
      
      and
      
      init/Kconfig for architecture independent options
        - profiling
        - markers
      
      Remove the "Instrumentation Support" menu. Everything moves to "General setup".
      Delete the kernel/Kconfig.instrumentation file.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      125e5645
    • M
      Add HAVE_KPROBES · 3f550096
      Mathieu Desnoyers 提交于
      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 KPROBES_SUPPORT
                      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...
      
      - Use HAVE_KPROBES
      - Use a select
      
      - Yet another update :
      Moving to HAVE_* now.
      
      - Update ARM for kprobes support.
      Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Jeff Dike <jdike@addtoit.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      3f550096
    • M
      Add HAVE_OPROFILE · 42d4b839
      Mathieu Desnoyers 提交于
      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: NMathieu 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: NSam Ravnborg <sam@ravnborg.org>
      42d4b839
  2. 28 1月, 2008 2 次提交
  3. 20 10月, 2007 1 次提交
  4. 17 10月, 2007 1 次提交
  5. 03 10月, 2007 2 次提交
  6. 17 9月, 2007 1 次提交
  7. 12 7月, 2007 1 次提交
  8. 21 2月, 2007 1 次提交
  9. 12 2月, 2007 1 次提交
    • C
      [PATCH] Set CONFIG_ZONE_DMA for arches with GENERIC_ISA_DMA · 5ac6da66
      Christoph Lameter 提交于
      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: NChristoph Lameter <clameter@sgi.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5ac6da66
  10. 24 1月, 2007 1 次提交
  11. 13 12月, 2006 1 次提交
  12. 09 12月, 2006 2 次提交
    • D
      [PATCH] LOG2: Implement a general integer log2 facility in the kernel · f0d1b0b3
      David Howells 提交于
      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: NDavid 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: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      f0d1b0b3
    • J
      [PATCH] use generic BUG for ppc · a8605aef
      Judith Lebzelter 提交于
      Switch ppc over to using the generic BUG implementation.
      Signed-off-by: NJudith 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: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      a8605aef
  13. 04 12月, 2006 1 次提交
  14. 30 11月, 2006 1 次提交
  15. 04 10月, 2006 1 次提交
    • M
      Attack of "the the"s in arch · 4b3f686d
      Matt LaPlante 提交于
      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: NAdrian Bunk <bunk@stusta.de>
      4b3f686d
  16. 27 9月, 2006 1 次提交
  17. 13 9月, 2006 1 次提交
  18. 30 6月, 2006 1 次提交
  19. 24 5月, 2006 1 次提交
  20. 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
  21. 27 3月, 2006 2 次提交
  22. 07 2月, 2006 1 次提交
  23. 15 1月, 2006 1 次提交
    • P
      [PATCH] ppc: Remove powermac support from ARCH=ppc · a7fdd90b
      Paul Mackerras 提交于
      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: NPaul Mackerras <paulus@samba.org>
      a7fdd90b
  24. 11 1月, 2006 1 次提交
  25. 09 1月, 2006 1 次提交
  26. 05 12月, 2005 1 次提交
    • P
      ppc: Build in all three of powermac, PREP and CHRP support · b6d78157
      Paul Mackerras 提交于
      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: NPaul Mackerras <paulus@samba.org>
      b6d78157
  27. 07 11月, 2005 2 次提交
  28. 26 10月, 2005 2 次提交
  29. 21 9月, 2005 3 次提交
  30. 19 9月, 2005 1 次提交