1. 21 1月, 2011 1 次提交
    • D
      kconfig: rename CONFIG_EMBEDDED to CONFIG_EXPERT · 6a108a14
      David Rientjes 提交于
      The meaning of CONFIG_EMBEDDED has long since been obsoleted; the option
      is used to configure any non-standard kernel with a much larger scope than
      only small devices.
      
      This patch renames the option to CONFIG_EXPERT in init/Kconfig and fixes
      references to the option throughout the kernel.  A new CONFIG_EMBEDDED
      option is added that automatically selects CONFIG_EXPERT when enabled and
      can be used in the future to isolate options that should only be
      considered for embedded systems (RISC architectures, SLOB, etc).
      
      Calling the option "EXPERT" more accurately represents its intention: only
      expert users who understand the impact of the configuration changes they
      are making should enable it.
      Reviewed-by: NIngo Molnar <mingo@elte.hu>
      Acked-by: NDavid Woodhouse <david.woodhouse@intel.com>
      Signed-off-by: NDavid Rientjes <rientjes@google.com>
      Cc: Greg KH <gregkh@suse.de>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Robin Holt <holt@sgi.com>
      Cc: <linux-arch@vger.kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6a108a14
  2. 18 10月, 2010 1 次提交
  3. 08 10月, 2010 1 次提交
  4. 20 9月, 2010 1 次提交
  5. 27 7月, 2010 1 次提交
  6. 15 12月, 2009 1 次提交
  7. 16 11月, 2009 1 次提交
  8. 30 3月, 2009 1 次提交
  9. 27 3月, 2009 1 次提交
  10. 24 2月, 2009 1 次提交
    • T
      bootmem: clean up arch-specific bootmem wrapping · c1329375
      Tejun Heo 提交于
      Impact: cleaner and consistent bootmem wrapping
      
      By setting CONFIG_HAVE_ARCH_BOOTMEM_NODE, archs can define
      arch-specific wrappers for bootmem allocation.  However, this is done
      a bit strangely in that only the high level convenience macros can be
      changed while lower level, but still exported, interface functions
      can't be wrapped.  This not only is messy but also leads to strange
      situation where alloc_bootmem() does what the arch wants it to do but
      the equivalent __alloc_bootmem() call doesn't although they should be
      able to be used interchangeably.
      
      This patch updates bootmem such that archs can override / wrap the
      backend function - alloc_bootmem_core() instead of the highlevel
      interface functions to allow simpler and consistent wrapping.  Also,
      HAVE_ARCH_BOOTMEM_NODE is renamed to HAVE_ARCH_BOOTMEM.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Cc: Johannes Weiner <hannes@saeurebad.de>
      c1329375
  11. 05 1月, 2009 1 次提交
    • A
      avr32: Hammerhead board support · dd5e1339
      Alex Raimondi 提交于
      The Hammerhead platform is built around a AVR32 32-bit microcontroller
      from Atmel.  It offers versatile peripherals, such as ethernet, usb
      device, usb host etc.
      
      The board also incooperates a power supply and is a Power over Ethernet
      (PoE) Powered Device (PD).
      
      Additonally, a Cyclone III FPGA from Altera is integrated on the board.
      The FPGA is mapped into the 32-bit AVR memory bus. The FPGA offers two
      DDR2 SDRAM interfaces, which will cover even the most exceptional need
      of memory bandwidth. Together with the onboard video decoder the board
      is ready for video processing.
      
      This patch does include the basic support for the fpga device driver,
      but not the device driver itself.
      Signed-off-by: NAlex Raimondi <mailinglist@miromico.ch>
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      dd5e1339
  12. 20 10月, 2008 1 次提交
    • M
      container freezer: implement freezer cgroup subsystem · dc52ddc0
      Matt Helsley 提交于
      This patch implements a new freezer subsystem in the control groups
      framework.  It provides a way to stop and resume execution of all tasks in
      a cgroup by writing in the cgroup filesystem.
      
      The freezer subsystem in the container filesystem defines a file named
      freezer.state.  Writing "FROZEN" to the state file will freeze all tasks
      in the cgroup.  Subsequently writing "RUNNING" will unfreeze the tasks in
      the cgroup.  Reading will return the current state.
      
      * Examples of usage :
      
         # mkdir /containers/freezer
         # mount -t cgroup -ofreezer freezer  /containers
         # mkdir /containers/0
         # echo $some_pid > /containers/0/tasks
      
      to get status of the freezer subsystem :
      
         # cat /containers/0/freezer.state
         RUNNING
      
      to freeze all tasks in the container :
      
         # echo FROZEN > /containers/0/freezer.state
         # cat /containers/0/freezer.state
         FREEZING
         # cat /containers/0/freezer.state
         FROZEN
      
      to unfreeze all tasks in the container :
      
         # echo RUNNING > /containers/0/freezer.state
         # cat /containers/0/freezer.state
         RUNNING
      
      This is the basic mechanism which should do the right thing for user space
      task in a simple scenario.
      
      It's important to note that freezing can be incomplete.  In that case we
      return EBUSY.  This means that some tasks in the cgroup are busy doing
      something that prevents us from completely freezing the cgroup at this
      time.  After EBUSY, the cgroup will remain partially frozen -- reflected
      by freezer.state reporting "FREEZING" when read.  The state will remain
      "FREEZING" until one of these things happens:
      
      	1) Userspace cancels the freezing operation by writing "RUNNING" to
      		the freezer.state file
      	2) Userspace retries the freezing operation by writing "FROZEN" to
      		the freezer.state file (writing "FREEZING" is not legal
      		and returns EIO)
      	3) The tasks that blocked the cgroup from entering the "FROZEN"
      		state disappear from the cgroup's set of tasks.
      
      [akpm@linux-foundation.org: coding-style fixes]
      [akpm@linux-foundation.org: export thaw_process]
      Signed-off-by: NCedric Le Goater <clg@fr.ibm.com>
      Signed-off-by: NMatt Helsley <matthltc@us.ibm.com>
      Acked-by: NSerge E. Hallyn <serue@us.ibm.com>
      Tested-by: NMatt Helsley <matthltc@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dc52ddc0
  13. 13 10月, 2008 4 次提交
  14. 26 7月, 2008 1 次提交
    • M
      gpiolib: allow user-selection · 7444a72e
      Michael Buesch 提交于
      This patch adds functionality to the gpio-lib subsystem to make it
      possible to enable the gpio-lib code even if the architecture code didn't
      request to get it built in.
      
      The archtitecture code does still need to implement the gpiolib accessor
      functions in its asm/gpio.h file.  This patch adds the implementations for
      x86 and PPC.
      
      With these changes it is possible to run generic GPIO expansion cards on
      every architecture that implements the trivial wrapper functions.  Support
      for more architectures can easily be added.
      Signed-off-by: NMichael Buesch <mb@bu3sch.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: David Brownell <david-b@pacbell.net>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: Samuel Ortiz <sameo@openedhand.com>
      Cc: Kumar Gala <galak@gate.crashing.org>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Adrian Bunk <bunk@stusta.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      7444a72e
  15. 25 7月, 2008 1 次提交
  16. 02 7月, 2008 3 次提交
    • H
      avr32: Power Management support ("standby" and "mem" modes) · 02a00cf6
      Haavard Skinnemoen 提交于
      Implement Standby support. In this mode, we'll suspend all drivers,
      put the SDRAM in self-refresh mode and switch off the HSB bus
      ("frozen" mode.)
      
      Implement Suspend-to-mem support. In this mode, we suspend all
      drivers, put the SDRAM into self-refresh mode and switch off all
      internal clocks except the 32 kHz oscillator ("stop" mode.)
      
      The lowest-level suspend code runs from a small portion of SRAM
      allocated at startup time. This gets rid of a small potential race
      with the SDRAM where we might try to enter self-refresh mode in the
      middle of an icache burst. We also relocate all interrupt and
      exception handlers to SRAM during the small window when we enter and
      exit the low-power modes.
      
      We don't need to do any special tricks to start and stop the PLL. The
      main clock is automatically gated by hardware until the PLL is stable.
      Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
      02a00cf6
    • H
      avr32: Add simple SRAM allocator · b83d6ee1
      Haavard Skinnemoen 提交于
      Add SRAM allocator for avr32, which is just a thin wrapper around
      genalloc.
      Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
      b83d6ee1
    • H
      avr32: Use a quicklist for PGD allocation · 5a4d5292
      Haavard Skinnemoen 提交于
      Use a quicklist to allocate process PGDs. This is expected to be
      slightly faster since we need to copy entries from swapper_pg_dir,
      which can stay around for pages on the PGD quick list.
      Signed-off-by: NHaavard Skinnemoen <haavard.skinnemoen@atmel.com>
      5a4d5292
  17. 20 4月, 2008 1 次提交
    • D
      avr32: Generic clockevents support · e723ff66
      David Brownell 提交于
      This combines three patches from David Brownell:
        * avr32: tclib support
        * avr32: simplify clocksources
        * avr32: Turn count/compare into a oneshot clockevent device
      
      Register both TC blocks (instead of just the first one) so that
      the AT32/AT91 tclib code will pick them up (instead of just the
      avr32-only PIT-style clocksource).
      
      Rename the first one and its resources appropriately.
      
      More cleanups to the cycle counter clocksource code
      
       - Disable all the weak symbol magic; remove the AVR32-only TCB-based
         clocksource code (source and header).
      
       - Mark the __init code properly.
      
       - Don't forget to report IRQF_TIMER.
      
       - Make the system work properly with this clocksource, by preventing
         use of the CPU "idle" sleep state in the idle loop when it's used.
      
      Package the avr32 count/compare timekeeping support as a oneshot
      clockevent device, so it supports NO_HZ and high res timers.
      This means it also supports plugging in other clockevent devices
      and clocksources.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
      e723ff66
  18. 17 4月, 2008 1 次提交
    • A
      avr32 mustn't select HAVE_IDE · 71fc4c0c
      Adrian Bunk 提交于
      There's a libata based PATA driver for avr32, but no support for 
      drivers/ide/ on avr32.
      
      This patch fixes the following compile error:
      
      <--  snip  -->
      
      ...
        CC [M]  drivers/ide/ide-cd.o
      In file included from /home/bunk/linux/kernel-2.6/git/linux-2.6/drivers/ide/ide-cd.c:37:
      /home/bunk/linux/kernel-2.6/git/linux-2.6/include/linux/ide.h:209:21: error: asm/ide.h: No such file or directory
      make[3]: *** [drivers/ide/ide-cd.o] Error 1
      
      <--  snip  -->
      Signed-off-by: NAdrian Bunk <bunk@kernel.org>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Acked-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
      71fc4c0c
  19. 09 2月, 2008 1 次提交
  20. 06 2月, 2008 1 次提交
    • D
      gpiolib: avr32 at32ap platform support · b98348bd
      David Brownell 提交于
      Teach AVR32 to use the "GPIO Library" when exposing its GPIOs, so that signals
      on external chips (like GPIO expanders) can easily be used.
      
      This mostly reorganizes some existing logic, with two minor changes in
      behavior:
      
       - The PSR registers are used instead of the previous "gpio_mask" values,
         matching AT91 behavior and removing some duplication between that role
         and that of "pinmux_mask".
      
       - NR_IRQs grew to acommodate a bank of external GPIOs.  Eventually this
         number should probably become a board-specific config option.
      
      There's a debugfs dump of status for the built-in GPIOs, showing which pins
      have deglitching, pullups, or open drain drive enabled, as well as the ID
      string used when requesting each IRQ.
      Signed-off-by: NDavid Brownell <dbrownell@users.sourceforge.net>
      Acked-by: NHaavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: Jean Delvare <khali@linux-fr.org>
      Cc: Eric Miao <eric.miao@marvell.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Philipp Zabel <philipp.zabel@gmail.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ben Gardner <bgardner@wabtec.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b98348bd
  21. 04 2月, 2008 1 次提交
  22. 03 2月, 2008 2 次提交
    • 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
  23. 25 1月, 2008 6 次提交
  24. 07 12月, 2007 3 次提交
  25. 15 11月, 2007 1 次提交
  26. 20 10月, 2007 1 次提交
  27. 19 7月, 2007 1 次提交