1. 26 6月, 2008 1 次提交
  2. 15 5月, 2008 1 次提交
  3. 29 4月, 2008 2 次提交
  4. 27 4月, 2008 1 次提交
  5. 23 4月, 2008 1 次提交
  6. 10 4月, 2008 1 次提交
  7. 05 3月, 2008 2 次提交
  8. 21 2月, 2008 1 次提交
    • H
      [IA64] VIRT_CPU_ACCOUNTING (accurate cpu time accounting) · b64f34cd
      Hidetoshi Seto 提交于
      This patch implements VIRT_CPU_ACCOUNTING for ia64,
      which enable us to use more accurate cpu time accounting.
      
      The VIRT_CPU_ACCOUNTING is an item of kernel config, which s390
      and powerpc arch have.  By turning this config on, these archs
      change the mechanism of cpu time accounting from tick-sampling
      based one to state-transition based one.
      
      The state-transition based accounting is done by checking time
      (cycle counter in processor) at every state-transition point,
      such as entrance/exit of kernel, interrupt, softirq etc.
      The difference between point to point is the actual time consumed
      during in the state. There is no doubt about that this value is
      more accurate than that of tick-sampling based accounting.
      Signed-off-by: NHidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      b64f34cd
  9. 12 2月, 2008 1 次提交
    • T
      [IA64] Fix build for sim_defconfig · 10d0aa3c
      Tony Luck 提交于
      Commit bdc80787 broke the build
      for this config because the sim_defconfig selects CONFIG_HZ=250
      but include/asm-ia64/param.h has an ifdef for the simulator to
      force HZ to 32.  So we ended up with a kernel/timeconst.h set
      for HZ=250 ... which then failed the check for the right HZ
      value and died with:
      
      Drop the #ifdef magic from param.h and make force CONFIG_HZ=32
      directly for the simulator.
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      10d0aa3c
  10. 09 2月, 2008 1 次提交
  11. 03 2月, 2008 4 次提交
    • A
      remove Documentation/smp.txt · 03502faa
      Adrian Bunk 提交于
      After seeing the filename I'd have expected something about the
      implementation of SMP in the Linux kernel - not some notes on kernel
      configuration and building trivialities noone would search at this
      place.
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Acked-by: NAlan Cox <alan@redhat.com>
      03502faa
    • 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
  12. 31 1月, 2008 1 次提交
    • T
      percpu: change Kconfig to HAVE_SETUP_PER_CPU_AREA · 988c388a
      travis@sgi.com 提交于
      Change:
      	config ARCH_SETS_UP_PER_CPU_AREA
      to:
      	config HAVE_SETUP_PER_CPU_AREA
      
      Cc: Andi Kleen <ak@suse.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: David Miller <davem@davemloft.net>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
      Cc: linuxppc-dev@ozlabs.org
      Cc: linux-ia64@vger.kernel.org
      Signed-off-by: NMike Travis <travis@sgi.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      988c388a
  13. 30 1月, 2008 2 次提交
  14. 20 10月, 2007 2 次提交
  15. 17 10月, 2007 4 次提交
  16. 13 10月, 2007 1 次提交
    • B
      [IA64] add driver for ACPI methods to call native firmware · 28eda5b8
      Bjorn Helgaas 提交于
      This driver for HPQ5001 devices installs a global ACPI OpRegion handler.
      AML methods can use this OpRegion to call native firmware entry points.
      
      ACPI does not define a mechanism for AML methods to call native firmware
      interfaces such as PAL or SAL.  This OpRegion handler adds such a mechanism.
      After the handler is installed, an AML method can call native firmware by
      storing the arguments and firmware entry point to specific offsets in the
      OpRegion.  When AML reads the "return value" offset from the OpRegion, this
      handler loads up the arguments, makes the firmware call, and returns the
      result.
      Signed-off-by: NBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      28eda5b8
  17. 14 8月, 2007 1 次提交
    • S
      [IA64] Include Kconfig.preempt · 0b0517a4
      Satyam Sharma 提交于
      arch/ia64/Kconfig failed to include kernel/Kconfig.preempt that meant it
      did not support PREEMPT_VOLUNTARY and PREEMPT_BKL (inadvertently).
      This was recently noticed when the newly-added PREEMPT_NOTIFIERS in
      Kconfig.preempt that was "select"ed from drivers/kvm/Kconfig (therefore)
      started giving bogus warnings ('select' used by config symbol 'KVM' refers
      to undefined symbol 'PREEMPT_NOTIFIERS') on ia64 builds.
      
      So let's remove the open-coded definition of CONFIG_PREEMPT in
      arch/ia64/Kconfig and replace it with just including Kconfig.preempt
      instead, like the other archs do.
      Signed-off-by: NSatyam Sharma <satyam@infradead.org>
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      0b0517a4
  18. 28 7月, 2007 1 次提交
    • T
      [IA64] Fix build failure in fs/quota.c · 7a6c8135
      Tony Luck 提交于
      b716395e added code to handle
      a compatability issue with 32bit quota tools, but the new compat
      routines are only needed when CONFIG_COMPAT=y (and with this set
      to 'n' there are compilation problems since some new typedefs are
      not visible).
      
      Reported by Doug Chapman.  Fix tuned by a cast of thousands (Andi,
      Andreas, Arthur, HPA, Willy)
      Signed-off-by: NTony Luck <tony.luck@intel.com>
      7a6c8135
  19. 21 7月, 2007 1 次提交
  20. 18 7月, 2007 1 次提交
  21. 12 7月, 2007 1 次提交
  22. 12 5月, 2007 1 次提交
  23. 09 5月, 2007 1 次提交
  24. 03 5月, 2007 1 次提交
  25. 20 3月, 2007 1 次提交
    • L
      ACPI: IA64: fix allnoconfig build · 8140a90e
      Len Brown 提交于
      The evils of Kconfig's select bite us once again...
      ia64/Kconfig selects ACPI, which depends on PM.
      But select ignores dependencies, allnoconfig
      chooses CONFIG_PM=n, and thus the menu of sub-options
      under ACPI vanish, which breaks the build.
      
      Manually select PM along with ACPI for now.
      Some day, we should delete them both, or fix select.
      
      Cc: Tony Luck <tony.luck@intel.com>
      Signed-off-by: NLen Brown <len.brown@intel.com>
      8140a90e
  26. 16 2月, 2007 1 次提交
  27. 12 2月, 2007 2 次提交
  28. 06 2月, 2007 2 次提交