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. 15 1月, 2011 2 次提交
  3. 14 1月, 2011 3 次提交
    • A
      x86: OLPC: convert olpc-xo1 driver from pci device to platform device · 419cdc54
      Andres Salomon 提交于
      The cs5535-mfd driver now takes care of the PCI BAR handling; this
      means the olpc-xo1 driver shouldn't be touching the PCI device at all.
      
      This patch uses both cs5535-acpi and cs5535-pms platform devices rather
      than a single platform device because the cs5535-mfd driver may be used
      by other CS5535 platform-specific drivers; OLPC doesn't get to dictate
      that ACPI and PMS will always be used together.
      Signed-off-by: NAndres Salomon <dilinger@queued.net>
      Acked-by: NH. Peter Anvin <hpa@zytor.com>
      Signed-off-by: NSamuel Ortiz <sameo@linux.intel.com>
      419cdc54
    • L
      x86: support XZ-compressed kernel · 30314804
      Lasse Collin 提交于
      This integrates the XZ decompression code to the x86 pre-boot code.
      
      mkpiggy.c is updated to reserve about 32 KiB more buffer safety margin for
      kernel decompression.  It is done unconditionally for all decompressors to
      keep the code simpler.
      
      The XZ decompressor needs around 30 KiB of heap, so the heap size is
      increased to 32 KiB on both x86-32 and x86-64.
      
      Documentation/x86/boot.txt is updated to list the XZ magic number.
      
      With the x86 BCJ filter in XZ, XZ-compressed x86 kernel tends to be a few
      percent smaller than the equivalent LZMA-compressed kernel.
      Signed-off-by: NLasse Collin <lasse.collin@tukaani.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Alain Knaff <alain@knaff.lu>
      Cc: Albin Tonnerre <albin.tonnerre@free-electrons.com>
      Cc: Phillip Lougher <phillip@lougher.demon.co.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      30314804
    • A
      kernel: clean up USE_GENERIC_SMP_HELPERS · 351f8f8e
      Amerigo Wang 提交于
      For arch which needs USE_GENERIC_SMP_HELPERS, it has to select
      USE_GENERIC_SMP_HELPERS, rather than leaving a choice to user, since they
      don't provide their own implementions.
      
      Also, move on_each_cpu() to kernel/smp.c, it is strange to put it in
      kernel/softirq.c.
      
      For arch which doesn't use USE_GENERIC_SMP_HELPERS, e.g.  blackfin, only
      on_each_cpu() is compiled.
      Signed-off-by: NAmerigo Wang <amwang@redhat.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      351f8f8e
  4. 16 12月, 2010 1 次提交
    • A
      x86, olpc: Add OLPC device-tree support · c10d1e26
      Andres Salomon 提交于
      Make use of PROC_DEVICETREE to export the tree, and sparc's PROMTREE code to
      call into OLPC's Open Firmware to build the tree.
      
      v5: fix buglet with root node check (introduced in v4)
      
      v4: address some minor style issues pointed out by Grant, and explicitly cast
          negative phandle checks to s32.
      
      v3: rename olpc_prom to olpc_dt
        - rework Kconfig entries
        - drop devtree build hook from proc, instead adding a call to x86's
          paging_init (similarly to how sparc64 does it)
        - switch allocation from using slab to alloc_bootmem.  this allows
          the DT to be built earlier during boot (during setup_arch); the
          downside is that there are some 1200 bootmem reservations that are
          done during boot.  Not ideal..
        - add a helper olpc_ofw_is_installed function to test for the
          existence and successful detection of OLPC's OFW.
      Signed-off-by: NAndres Salomon <dilinger@queued.net>
      LKML-Reference: <20101116220952.26526a80@queued.net>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      c10d1e26
  5. 26 11月, 2010 1 次提交
  6. 18 11月, 2010 2 次提交
  7. 17 11月, 2010 2 次提交
  8. 12 11月, 2010 2 次提交
  9. 09 11月, 2010 1 次提交
    • F
      x86/mrst: Add SFI platform device parsing code · 1da4b1c6
      Feng Tang 提交于
      SFI provides a series of tables. These describe the platform devices present
      including SPI and I²C devices, as well as various sensors, keypads and other
      glue as well as interfaces provided via the SCU IPC mechanism (intel_scu_ipc.c)
      
      This patch is a merge of the core elements and relevant fixes from the
      Intel development code by Feng, Alek, myself into a single coherent patch
      for upstream submission.
      
      It provides the needed infrastructure to register I2C, SPI and platform devices
      described by the tables, as well as handlers for some of the hardware already
      supported in kernel. The 0.8 firmware also provides GPIO tables.
      
      Devices are created at boot time or if they are SCU dependant at the point an
      SCU is discovered. The existing Linux device mechanisms will then handle the
      device binding. At an abstract level this is an SFI to Linux device translator.
      
      Device/platform specific setup/glue is in this file. This is done so that the
      drivers for the generic I²C and SPI bus devices remain cross platform as they
      should.
      
      (Updated from RFC version to correct the emc1403 name used by the firmware
       and a wrongly used #define)
      Signed-off-by: NAlek Du <alek.du@linux.intel.com>
      LKML-Reference: <20101109112158.20013.6158.stgit@localhost.localdomain>
      [Clean ups, removal of 0.7 support]
      Signed-off-by: NFeng Tang <feng.tang@linux.intel.com>
      [Clean ups]
      Signed-off-by: NAlan Cox <alan@linux.intel.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      1da4b1c6
  10. 21 10月, 2010 1 次提交
  11. 19 10月, 2010 2 次提交
  12. 18 10月, 2010 1 次提交
  13. 16 10月, 2010 1 次提交
  14. 15 10月, 2010 3 次提交
    • R
      x86, olpc: XO-1 uses/depends on PCI · 9e9006e9
      Randy Dunlap 提交于
      olpc-xo1 uses pci_*() interfaces so it should depend on PCI.
      
      Otherwise we get build failure like:
      
       arch/x86/kernel/olpc-xo1.c:65: error: implicit declaration of function 'pci_enable_device_io'
       arch/x86/kernel/olpc-xo1.c:71: error: implicit declaration of function 'pci_request_region'
       arch/x86/kernel/olpc-xo1.c:80: error: implicit declaration of function 'pci_release_region'
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Acked-by: NDaniel Drake <dsd@laptop.org>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      LKML-Reference: <20101014101313.adf7eb2a.randy.dunlap@oracle.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9e9006e9
    • S
      ftrace: Rename config option HAVE_C_MCOUNT_RECORD to HAVE_C_RECORDMCOUNT · cf4db259
      Steven Rostedt 提交于
      The config option used by archs to let the build system know that
      the C version of the recordmcount works for said arch is currently
      called HAVE_C_MCOUNT_RECORD which enables BUILD_C_RECORDMCOUNT. To
      be more consistent with the name that all archs may use, it has been
      renamed to HAVE_C_RECORDMCOUNT. This will be less confusing since
      we are building a C recordmcount and not a mcount_record.
      Suggested-by: NIngo Molnar <mingo@elte.hu>
      Cc: <linux-arch@vger.kernel.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: linux-kbuild@vger.kernel.org
      Cc: John Reiser <jreiser@bitwagon.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      cf4db259
    • S
      ftrace/x86: Add support for C version of recordmcount · 72441cb1
      Steven Rostedt 提交于
      This patch adds the support for the C version of recordmcount and
      compile times show ~ 12% improvement.
      
      After verifying this works, other archs can add:
      
       HAVE_C_MCOUNT_RECORD
      
      in its Kconfig and it will use the C version of recordmcount
      instead of the perl version.
      
      Cc: <linux-arch@vger.kernel.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: linux-kbuild@vger.kernel.org
      Cc: John Reiser <jreiser@bitwagon.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      72441cb1
  15. 14 10月, 2010 2 次提交
  16. 13 10月, 2010 1 次提交
    • D
      x86, olpc: Add XO-1 poweroff support · bf1ebf00
      Daniel Drake 提交于
      Add a pm_power_off handler for the OLPC XO-1 laptop.
      
      The driver can be built modular and follows the behaviour of the
      APM driver, setting pm_power_off to NULL on unload. However, the
      ability to unload the module will probably be removed (with a simple
      __module_get(THIS_MODULE)) if/when XO-1 suspend/resume support is
      added to this file at a later date.
      Signed-off-by: NDaniel Drake <dsd@laptop.org>
      LKML-Reference: <20101010094032.9AE669D401B@zog.reactivated.net>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      bf1ebf00
  17. 12 10月, 2010 1 次提交
  18. 04 10月, 2010 1 次提交
  19. 24 9月, 2010 2 次提交
  20. 23 9月, 2010 2 次提交
  21. 21 9月, 2010 1 次提交
  22. 20 9月, 2010 1 次提交
  23. 28 8月, 2010 2 次提交
    • Y
      x86: Remove old bootmem code · 774ea0bc
      Yinghai Lu 提交于
      Requested by Ingo, Thomas and HPA.
      
      The old bootmem code is no longer necessary, and the transition is
      complete.  Remove it.
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      774ea0bc
    • Y
      x86: Use memblock to replace early_res · 72d7c3b3
      Yinghai Lu 提交于
      1. replace find_e820_area with memblock_find_in_range
      2. replace reserve_early with memblock_x86_reserve_range
      3. replace free_early with memblock_x86_free_range.
      4. NO_BOOTMEM will switch to use memblock too.
      5. use _e820, _early wrap in the patch, in following patch, will
         replace them all
      6. because memblock_x86_free_range support partial free, we can remove some special care
      7. Need to make sure that memblock_find_in_range() is called after memblock_x86_fill()
         so adjust some calling later in setup.c::setup_arch()
         -- corruption_check and mptable_update
      
      -v2: Move reserve_brk() early
          Before fill_memblock_area, to avoid overlap between brk and memblock_find_in_range()
          that could happen We have more then 128 RAM entry in E820 tables, and
          memblock_x86_fill() could use memblock_find_in_range() to find a new place for
          memblock.memory.region array.
          and We don't need to use extend_brk() after fill_memblock_area()
          So move reserve_brk() early before fill_memblock_area().
      -v3: Move find_smp_config early
          To make sure memblock_find_in_range not find wrong place, if BIOS doesn't put mptable
          in right place.
      -v4: Treat RESERVED_KERN as RAM in memblock.memory. and they are already in
          memblock.reserved already..
          use __NOT_KEEP_MEMBLOCK to make sure memblock related code could be freed later.
      -v5: Generic version __memblock_find_in_range() is going from high to low, and for 32bit
          active_region for 32bit does include high pages
          need to replace the limit with memblock.default_alloc_limit, aka get_max_mapped()
      -v6: Use current_limit instead
      -v7: check with MEMBLOCK_ERROR instead of -1ULL or -1L
      -v8: Set memblock_can_resize early to handle EFI with more RAM entries
      -v9: update after kmemleak changes in mainline
      Suggested-by: NDavid S. Miller <davem@davemloft.net>
      Suggested-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Suggested-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      72d7c3b3
  24. 26 8月, 2010 1 次提交
  25. 25 8月, 2010 1 次提交
  26. 24 8月, 2010 1 次提交
    • A
      x86, vmware: Remove deprecated VMI kernel support · 9863c90f
      Alok Kataria 提交于
      With the recent innovations in CPU hardware acceleration technologies
      from Intel and AMD, VMware ran a few experiments to compare these
      techniques to guest paravirtualization technique on VMware's platform.
      These hardware assisted virtualization techniques have outperformed the
      performance benefits provided by VMI in most of the workloads. VMware
      expects that these hardware features will be ubiquitous in a couple of
      years, as a result, VMware has started a phased retirement of this
      feature from the hypervisor.
      
      Please note that VMI has always been an optimization and non-VMI kernels
      still work fine on VMware's platform.
      Latest versions of VMware's product which support VMI are,
      Workstation 7.0 and VSphere 4.0 on ESX side, future maintainence
      releases for these products will continue supporting VMI.
      
      For more details about VMI retirement take a look at this,
      http://blogs.vmware.com/guestosguide/2009/09/vmi-retirement.html
      
      This feature removal was scheduled for 2.6.37 back in September 2009.
      Signed-off-by: NAlok N Kataria <akataria@vmware.com>
      LKML-Reference: <1282600151.19396.22.camel@ank32.eng.vmware.com>
      Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      9863c90f
  27. 22 8月, 2010 1 次提交