1. 22 Oct, 2008 4 commits
  2. 20 Oct, 2008 24 commits
    • Harvey Harrison's avatar
      misc: replace remaining __FUNCTION__ with __func__ · 653c0316
      Harvey Harrison authored
      
      
      __FUNCTION__ is gcc-specific, use __func__
      Signed-off-by: default avatarHarvey Harrison <harvey.harrison@gmail.com>
      Acked-by: default avatarRandy Dunlap <randy.dunlap@oracle.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      653c0316
    • Dave Jones's avatar
      Update email addresses. · f4432c5c
      Dave Jones authored
      
      
      Update assorted email addresses and related info to point
      to a single current, valid address.
      
      additionally
      - trivial CREDITS entry updates. (Not that this file means much any more)
      - remove arjans dead redhat.com address from powernow driver
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f4432c5c
    • Linus Torvalds's avatar
      Update .gitignore files for generated targets · db7a6d8d
      Linus Torvalds authored
      
      
      The generated 'capflags.c' file wasn't properly ignored, and the list of
      files in scripts/basic/ wasn't up-to-date.
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      db7a6d8d
    • Benjamin Herrenschmidt's avatar
      powerpc/PCI: Add legacy PCI access via sysfs · e9f82cb7
      Benjamin Herrenschmidt authored
      
      
      This patch adds support for legacy_io and legacy_mem files in
      bus class directories in sysfs for powerpc
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      e9f82cb7
    • Benjamin Herrenschmidt's avatar
      PCI: Add ability to mmap legacy_io on some platforms · f19aeb1f
      Benjamin Herrenschmidt authored
      
      
      This adds the ability to mmap legacy IO space to the legacy_io files
      in sysfs on platforms that support it. This will allow to clean up
      X to use this instead of /dev/mem for legacy IO accesses such as
      those performed by Int10.
      
      While at it I moved pci_create/remove_legacy_files() to pci-sysfs.c
      where I think they belong, thus making more things statis in there
      and cleaned up some spurrious prototypes in the ia64 pci.h file
      Signed-off-by: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      f19aeb1f
    • Seth Heasley's avatar
      x86/PCI: irq and pci_ids patch for Intel Ibex Peak DeviceIDs · 37a84ec6
      Seth Heasley authored
      
      
      This patch updates the Intel Ibex Peak (PCH) LPC and SMBus Controller
      DeviceIDs.
      
      The LPC Controller ID is set by Firmware within the range of
      0x3b00-3b1f.  This range is included in pci_ids.h using min and max
      values, and irq.c now has code to handle the range (in lieu of 32
      additions to a SWITCH statement).
      
      The SMBus Controller ID is a fixed-value and will not change.
      Signed-off-by: default avatarSeth Heasley <seth.heasley@intel.com>
      Acked-by: default avatarJean Delvare <khali@linux-fr.org>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      37a84ec6
    • Bjorn Helgaas's avatar
      x86/PCI: follow lspci device/vendor style · d768cb69
      Bjorn Helgaas authored
      
      
      Use "[%04x:%04x]" for PCI vendor/device IDs to follow the format
      used by lspci(8).
      Signed-off-by: default avatarBjorn Helgaas <bjorn.helgaas@hp.com>
      Signed-off-by: default avatarJesse Barnes <jbarnes@virtuousgeek.org>
      d768cb69
    • Adrian Bunk's avatar
      mn10300: use bcd2bin/bin2bcd · f6a2298c
      Adrian Bunk authored
      
      
      Change mn10300 to use the new bcd2bin/bin2bcd functions instead of the
      obsolete BCD_TO_BIN/BIN_TO_BCD macros.
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      Acked-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      f6a2298c
    • Adrian Bunk's avatar
      mips: use bcd2bin/bin2bcd · 02112dbc
      Adrian Bunk authored
      
      
      Changes mips to use the new bcd2bin/bin2bcd functions instead of the
      obsolete BCD_TO_BIN/BIN_TO_BCD/BCD2BIN/BIN2BCD macros.
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      02112dbc
    • Adrian Bunk's avatar
      rtc: use bcd2bin/bin2bcd · 357c6e63
      Adrian Bunk authored
      
      
      Change various rtc related code to use the new bcd2bin/bin2bcd functions
      instead of the obsolete BCD_TO_BIN/BIN_TO_BCD/BCD2BIN/BIN2BCD macros.
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      Acked-by: default avatarAlessandro Zummo <a.zummo@towertech.it>
      Cc: David Brownell <david-b@pacbell.net>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      357c6e63
    • Adrian Bunk's avatar
      cris: use bcd2bin/bin2bcd · 4110a0d6
      Adrian Bunk authored
      
      
      Change cris to use the new bcd2bin/bin2bcd functions instead of the
      obsolete BCD_TO_BIN/BIN_TO_BCD macros.
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      Cc: Chris Zankel <zankel@tensilica.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      4110a0d6
    • Adrian Bunk's avatar
      alpha: use bcd2bin/bin2bcd · 18b1bd05
      Adrian Bunk authored
      
      
      Change alpha to use the new bcd2bin/bin2bcd functions instead of the
      obsolete BCD_TO_BIN/BIN_TO_BCD macros.
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      18b1bd05
    • Simon Horman's avatar
      always reserve elfcore header memory in crash kernel · d9a9855d
      Simon Horman authored
      
      
      elfcore header memory needs to be reserved in a crash kernel.  This means
      that the relevant code should be protected by CONFIG_CRASH_DUMP rather
      than CONFIG_PROC_VMCORE.
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d9a9855d
    • Simon Horman's avatar
      kdump: add is_vmcore_usable() and vmcore_unusable() · 85a0ee34
      Simon Horman authored
      
      
      The usage of elfcorehdr_addr has changed recently such that being set to
      ELFCORE_ADDR_MAX is used by is_kdump_kernel() to indicate if the code is
      executing in a kernel executed as a crash kernel.
      
      However, arch/ia64/kernel/setup.c:reserve_elfcorehdr will rest
      elfcorehdr_addr to ELFCORE_ADDR_MAX on error, which means any subsequent
      calls to is_kdump_kernel() will return 0, even though they should return
      1.
      
      Ok, at this point in time there are no subsequent calls, but I think its
      fair to say that there is ample scope for error or at the very least
      confusion.
      
      This patch add an extra state, ELFCORE_ADDR_ERR, which indicates that
      elfcorehdr_addr was passed on the command line, and thus execution is
      taking place in a crashdump kernel, but vmcore can't be used for some
      reason.  This is tested for using is_vmcore_usable() and set using
      vmcore_unusable().  A subsequent patch makes use of this new code.
      
      To summarise, the states that elfcorehdr_addr can now be in are as follows:
      
      ELFCORE_ADDR_MAX: not a crashdump kernel
      ELFCORE_ADDR_ERR: crashdump kernel but vmcore is unusable
      any other value:  crash dump kernel and vmcore is usable
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      85a0ee34
    • Simon Horman's avatar
      kdump: use is_kdump_kernel() in sba_init() · 630bf207
      Simon Horman authored
      
      
      o Make use of is_kdump_kernel() rather than checking elfcorehdr_addr directly.
      
      o Remove CONFIG_CRASH_DUMP as is_kdump_kernel() is safe to call anywhere
      
      o Remove CONFIG_PROC_FS as it is bogus, the check
        should occur regardless of if CONFIG_PROC_FS is set or not.
      Signed-off-by: default avatarSimon Horman <horms@verge.net.au>
      Acked-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      630bf207
    • Vivek Goyal's avatar
      kdump: make elfcorehdr_addr independent of CONFIG_PROC_VMCORE · 57cac4d1
      Vivek Goyal authored
      
      
      o elfcorehdr_addr is used by not only the code under CONFIG_PROC_VMCORE
        but also by the code which is not inside CONFIG_PROC_VMCORE.  For
        example, is_kdump_kernel() is used by powerpc code to determine if
        kernel is booting after a panic then use previous kernel's TCE table.
        So even if CONFIG_PROC_VMCORE is not set in second kernel, one should be
        able to correctly determine that we are booting after a panic and setup
        calgary iommu accordingly.
      
      o So remove the assumption that elfcorehdr_addr is under
        CONFIG_PROC_VMCORE.
      
      o Move definition of elfcorehdr_addr to arch dependent crash files.
        (Unfortunately crash dump does not have an arch independent file
        otherwise that would have been the best place).
      
      o kexec.c is not the right place as one can Have CRASH_DUMP enabled in
        second kernel without KEXEC being enabled.
      
      o I don't see sh setup code parsing the command line for
        elfcorehdr_addr.  I am wondering how does vmcore interface work on sh.
        Anyway, I am atleast defining elfcoredhr_addr so that compilation is not
        broken on sh.
      Signed-off-by: default avatarVivek Goyal <vgoyal@redhat.com>
      Acked-by: default avatar"Eric W. Biederman" <ebiederm@xmission.com>
      Acked-by: default avatarSimon Horman <horms@verge.net.au>
      Acked-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      57cac4d1
    • WANG Cong's avatar
      uml: fix a compile error · 966c8079
      WANG Cong authored
      
      
      Fix
      
      arch/um/sys-i386/signal.c: In function 'copy_sc_from_user':
      arch/um/sys-i386/signal.c:182: warning: dereferencing 'void *' pointer
      arch/um/sys-i386/signal.c:182: error: request for member '_fxsr_env' in something not a structure or union
      Signed-off-by: default avatarWANG Cong <wangcong@zeuux.org>
      Cc: Jeff Dike <jdike@addtoit.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      966c8079
    • Huang Weiyi's avatar
      arch/m68k/bvme6000/rtc.c: remove duplicated include · d12a6f7f
      Huang Weiyi authored
      
      
      Removed duplicated include file <linux/smp_lock.h> in
      arch/m68k/bvme6000/rtc.c.
      Signed-off-by: default avatarHuang Weiyi <weiyi.huang@gmail.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      d12a6f7f
    • Matt Helsley's avatar
      container freezer: implement freezer cgroup subsystem · dc52ddc0
      Matt Helsley authored
      
      
      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: default avatarCedric Le Goater <clg@fr.ibm.com>
      Signed-off-by: default avatarMatt Helsley <matthltc@us.ibm.com>
      Acked-by: default avatarSerge E. Hallyn <serue@us.ibm.com>
      Tested-by: default avatarMatt Helsley <matthltc@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      dc52ddc0
    • Matt Helsley's avatar
      container freezer: add TIF_FREEZE flag to all architectures · 83224b08
      Matt Helsley authored
      
      
      This patch series introduces a cgroup subsystem that utilizes the swsusp
      freezer to freeze a group of tasks.  It's immediately useful for batch job
      management scripts.  It should also be useful in the future for
      implementing container checkpoint/restart.
      
      The freezer subsystem in the container filesystem defines a cgroup file
      named freezer.state.  Reading freezer.state will return the current state
      of the cgroup.  Writing "FROZEN" to the state file will freeze all tasks
      in the cgroup.  Subsequently writing "RUNNING" will unfreeze the tasks in
      the cgroup.
      
      * 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 patch:
      
      The first step in making the refrigerator() available to all
      architectures, even for those without power management.
      
      The purpose of such a change is to be able to use the refrigerator() in a
      new control group subsystem which will implement a control group freezer.
      
      [akpm@linux-foundation.org: fix sparc]
      Signed-off-by: default avatarCedric Le Goater <clg@fr.ibm.com>
      Signed-off-by: default avatarMatt Helsley <matthltc@us.ibm.com>
      Acked-by: default avatarPavel Machek <pavel@suse.cz>
      Acked-by: default avatarSerge E. Hallyn <serue@us.ibm.com>
      Acked-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: default avatarNigel Cunningham <nigel@tuxonice.net>
      Tested-by: default avatarMatt Helsley <matthltc@us.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      83224b08
    • Nick Piggin's avatar
      mm: rewrite vmap layer · db64fe02
      Nick Piggin authored
      
      
      Rewrite the vmap allocator to use rbtrees and lazy tlb flushing, and
      provide a fast, scalable percpu frontend for small vmaps (requires a
      slightly different API, though).
      
      The biggest problem with vmap is actually vunmap.  Presently this requires
      a global kernel TLB flush, which on most architectures is a broadcast IPI
      to all CPUs to flush the cache.  This is all done under a global lock.  As
      the number of CPUs increases, so will the number of vunmaps a scaled
      workload will want to perform, and so will the cost of a global TLB flush.
       This gives terrible quadratic scalability characteristics.
      
      Another problem is that the entire vmap subsystem works under a single
      lock.  It is a rwlock, but it is actually taken for write in all the fast
      paths, and the read locking would likely never be run concurrently anyway,
      so it's just pointless.
      
      This is a rewrite of vmap subsystem to solve those problems.  The existing
      vmalloc API is implemented on top of the rewritten subsystem.
      
      The TLB flushing problem is solved by using lazy TLB unmapping.  vmap
      addresses do not have to be flushed immediately when they are vunmapped,
      because the kernel will not reuse them again (would be a use-after-free)
      until they are reallocated.  So the addresses aren't allocated again until
      a subsequent TLB flush.  A single TLB flush then can flush multiple
      vunmaps from each CPU.
      
      XEN and PAT and such do not like deferred TLB flushing because they can't
      always handle multiple aliasing virtual addresses to a physical address.
      They now call vm_unmap_aliases() in order to flush any deferred mappings.
      That call is very expensive (well, actually not a lot more expensive than
      a single vunmap under the old scheme), however it should be OK if not
      called too often.
      
      The virtual memory extent information is stored in an rbtree rather than a
      linked list to improve the algorithmic scalability.
      
      There is a per-CPU allocator for small vmaps, which amortizes or avoids
      global locking.
      
      To use the per-CPU interface, the vm_map_ram / vm_unmap_ram interfaces
      must be used in place of vmap and vunmap.  Vmalloc does not use these
      interfaces at the moment, so it will not be quite so scalable (although it
      will use lazy TLB flushing).
      
      As a quick test of performance, I ran a test that loops in the kernel,
      linearly mapping then touching then unmapping 4 pages.  Different numbers
      of tests were run in parallel on an 4 core, 2 socket opteron.  Results are
      in nanoseconds per map+touch+unmap.
      
      threads           vanilla         vmap rewrite
      1                 14700           2900
      2                 33600           3000
      4                 49500           2800
      8                 70631           2900
      
      So with a 8 cores, the rewritten version is already 25x faster.
      
      In a slightly more realistic test (although with an older and less
      scalable version of the patch), I ripped the not-very-good vunmap batching
      code out of XFS, and implemented the large buffer mapping with vm_map_ram
      and vm_unmap_ram...  along with a couple of other tricks, I was able to
      speed up a large directory workload by 20x on a 64 CPU system.  I believe
      vmap/vunmap is actually sped up a lot more than 20x on such a system, but
      I'm running into other locks now.  vmap is pretty well blown off the
      profiles.
      
      Before:
      1352059 total                                      0.1401
      798784 _write_lock                              8320.6667 <- vmlist_lock
      529313 default_idle                             1181.5022
       15242 smp_call_function                         15.8771  <- vmap tlb flushing
        2472 __get_vm_area_node                         1.9312  <- vmap
        1762 remove_vm_area                             4.5885  <- vunmap
         316 map_vm_area                                0.2297  <- vmap
         312 kfree                                      0.1950
         300 _spin_lock                                 3.1250
         252 sn_send_IPI_phys                           0.4375  <- tlb flushing
         238 vmap                                       0.8264  <- vmap
         216 find_lock_page                             0.5192
         196 find_next_bit                              0.3603
         136 sn2_send_IPI                               0.2024
         130 pio_phys_write_mmr                         2.0312
         118 unmap_kernel_range                         0.1229
      
      After:
       78406 total                                      0.0081
       40053 default_idle                              89.4040
       33576 ia64_spinlock_contention                 349.7500
        1650 _spin_lock                                17.1875
         319 __reg_op                                   0.5538
         281 _atomic_dec_and_lock                       1.0977
         153 mutex_unlock                               1.5938
         123 iget_locked                                0.1671
         117 xfs_dir_lookup                             0.1662
         117 dput                                       0.1406
         114 xfs_iget_core                              0.0268
          92 xfs_da_hashname                            0.1917
          75 d_alloc                                    0.0670
          68 vmap_page_range                            0.0462 <- vmap
          58 kmem_cache_alloc                           0.0604
          57 memset                                     0.0540
          52 rb_next                                    0.1625
          50 __copy_user                                0.0208
          49 bitmap_find_free_region                    0.2188 <- vmap
          46 ia64_sn_udelay                             0.1106
          45 find_inode_fast                            0.1406
          42 memcmp                                     0.2188
          42 finish_task_switch                         0.1094
          42 __d_lookup                                 0.0410
          40 radix_tree_lookup_slot                     0.1250
          37 _spin_unlock_irqrestore                    0.3854
          36 xfs_bmapi                                  0.0050
          36 kmem_cache_free                            0.0256
          35 xfs_vn_getattr                             0.0322
          34 radix_tree_lookup                          0.1062
          33 __link_path_walk                           0.0035
          31 xfs_da_do_buf                              0.0091
          30 _xfs_buf_find                              0.0204
          28 find_get_page                              0.0875
          27 xfs_iread                                  0.0241
          27 __strncpy_from_user                        0.2812
          26 _xfs_buf_initialize                        0.0406
          24 _xfs_buf_lookup_pages                      0.0179
          24 vunmap_page_range                          0.0250 <- vunmap
          23 find_lock_page                             0.0799
          22 vm_map_ram                                 0.0087 <- vmap
          20 kfree                                      0.0125
          19 put_page                                   0.0330
          18 __kmalloc                                  0.0176
          17 xfs_da_node_lookup_int                     0.0086
          17 _read_lock                                 0.0885
          17 page_waitqueue                             0.0664
      
      vmap has gone from being the top 5 on the profiles and flushing the crap
      out of all TLBs, to using less than 1% of kernel time.
      
      [akpm@linux-foundation.org: cleanups, section fix]
      [akpm@linux-foundation.org: fix build on alpha]
      Signed-off-by: default avatarNick Piggin <npiggin@suse.de>
      Cc: Jeremy Fitzhardinge <jeremy@goop.org>
      Cc: Krzysztof Helt <krzysztof.h1@poczta.fm>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      db64fe02
    • Badari Pulavarty's avatar
      mm: cleanup to make remove_memory() arch-neutral · 71088785
      Badari Pulavarty authored
      
      
      There is nothing architecture specific about remove_memory().
      remove_memory() function is common for all architectures which support
      hotplug memory remove.  Instead of duplicating it in every architecture,
      collapse them into arch neutral function.
      
      [akpm@linux-foundation.org: fix the export]
      Signed-off-by: default avatarBadari Pulavarty <pbadari@us.ibm.com>
      Cc: Yasunori Goto <y-goto@jp.fujitsu.com>
      Cc: Gary Hade <garyhade@us.ibm.com>
      Cc: Mel Gorman <mel@csn.ul.ie>
      Cc: Yasunori Goto <y-goto@jp.fujitsu.com>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      71088785
    • Takashi Iwai's avatar
      ps3: Add passthru support for non-audio streams · 64931a4b
      Takashi Iwai authored
      
      
      Add support for the channel status bit setting so that non-PCM
      data stream can be sent (i.e. pass-through) via SPDIF/HDMI.
      Signed-off-by: default avatarMasakazu Mokuno <mokuno@sm.sony.co.jp>
      Acked-by: default avatarGeert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      64931a4b
    • Masakazu Mokuno's avatar
      ps3: Add ps3av_audio_mute_analog() · 756ba83e
      Masakazu Mokuno authored
      
      
      Add support for muting the analog output so that it does not
      play noises while non-PCM data is played.
      Signed-off-by: default avatarMasakazu Mokuno <mokuno@sm.sony.co.jp>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      756ba83e
  3. 19 Oct, 2008 12 commits