From: Anton Blanchard <anton@samba.org>

PPC64 32/64-bit emulation for AIO.

Very early initialization (core_initcall) needs to have the cdev
initialization done.  So make it part of the pre-initcall sequence, the
same way the bdev caches were done.

This addresses a futex related SMP scalability problem of
glibc. A number of regressions have been reported to the NTPL mailing list
when going to many CPUs, for applications that use condition variables and
the pthread_cond_broadcast() API call. Using this functionality, testcode
shows a slowdown from 0.12 seconds runtime to over 237 seconds (!)
runtime, on 4-CPU systems.

pthread condition variables use two futex-backed mutex-alike locks: an
internal one for the glibc CV state itself, and a user-supplied mutex
which the API guarantees to take in certain codepaths. (Unfortunately the
user-supplied mutex cannot be used to protect the CV state, so we've got
to deal with two locks.)

The cause of the slowdown is a 'swarm effect': if lots of threads are
blocked on a condition variable, and pthread_cond_broadcast() is done,
then glibc first does a FUTEX_WAKE on the cv-internal mutex, then down a
mutex_down() on the user-supplied mutex. Ie. a swarm of threads is created
which all race to serialize on the user-supplied mutex. The more threads
are used, the more likely it becomes that the scheduler will balance them
over to other CPUs - where they just schedule, try to lock the mutex, and
go to sleep. This 'swarm effect' is purely technical, a side-effect of
glibc's use of futexes, and the imperfect coupling of the two locks.

the solution to this problem is to not wake up the swarm of threads, but
'requeue' them from the CV-internal mutex to the user-supplied mutex. The
attached patch adds the FUTEX_REQUEUE feature FUTEX_REQUEUE requeues N
threads from futex address A to futex address B.

This way glibc can wake up a single thread (which will take the
user-mutex), and can requeue the rest, with a single system-call.

Ulrich Drepper has implemented FUTEX_REQUEUE support in glibc, and a
number of people have tested it over the past couple of weeks. Here are
the measurements done by Saurabh Desai:

System: 4xPIII 700MHz

 ./cond-perf -r 100 -n 200:        1p       2p         4p
 Default NPTL:                 0.120s   0.211s   237.407s
 requeue NPTL:                 0.124s   0.156s     0.040s

 ./cond-perf -r 1000 -n 100:
 Default NPTL:                 0.276s   0.412s     0.530s
 requeue NPTL:                 0.349s   0.503s     0.550s

 ./pp -v -n 128 -i 1000 -S 32768:
 Default NPTL: 128 games in    1.111s   1.270s    16.894s
 requeue NPTL: 128 games in    1.111s   1.959s     2.426s

 ./pp -v -n 1024 -i 10 -S 32768:
 Default NPTL: 1024 games in   0.181s   0.394s     incompleted 2m+
 requeue NPTL: 1024 games in   0.166s   0.254s     0.341s

the speedup with increasing number of threads is quite significant, in the
128 threads, case it's more than 8 times. In the cond-perf test, on 4 CPUs
it's almost infinitely faster than the 'swarm of threads' catastrophy
triggered by the old code.

new fields in struct inode - i_cdev and i_cindex.  When we do open() on
a character device we cache result of cdev lookup in inode and put the
inode on a cyclic list anchored in cdev.  If we already have that done,
we don't bother with any lookups.  When inode disappears it's removed
from the list.  When cdev gets unregistered we remove all cached
references to it (and remove such inodes from the list).  cdev is held
until final fput() now.

New object: struct cdev.  It contains a kobject, a pointer to
file_operations and a pointer to owner module.  These guys have a search
structure of the same sort as gendisks and chrdev_open() picks
file_operations from them.

Intended use: embed such animal in driver-owned structure (e.g.
tty_driver) and register it as associated with given range of device
numbers.  Generic code will do lookup for such object and use it for the
rest.

The behaviour of register_chrdev() is _not_ changed - it allocates
struct cdev and registers it; any old driver will work as if nothing had
changed.

On that stage we only use it during chrdev_open() to find
file_operations.  Later it will be cached in inode->i_cdev (and index in
range - in inode->i_cindex) so that ->open() could get whatever objects
it wants directly without any special-cased lookups, etc.

code responsible for gendisk lookups taken out in drivers/base and
generalized - now it allows to have a range-based mapping from numbers
to kobjects for given struct subsystem.

register_chrdev_region() sanitized, code in tty_io.c that dealt with it
cleaned up.

preparation to cdev-cidr - the lookup mechanism for gendisks is switched
to dealing with disk->kobj instead of disk.

pt.c fed through Lindent

Remove cpp abuses - same as had been done for pd/pf/pcd.

Remove the rest of cpp abuse in pg.c

pg.c fed through Lindent

This removes cpp abuses - same as had been done for pd/pf/pcd.

This restores the special-case behaviour of open() on the minor 0;
cpqarray allows to open that guy for ioctls even if nothing is
configured.  That got broken when gendisk patches went in.  Patch
restores the old behaviour by keeping gendisk for the first disk on
controller always registered; instead of unregistering it we set size to
0.

This fixes the TIOCCONS race; it's the same as the 2.4 patch except for
a fix for a brown-paperbag bug in it.

Forgot to remove include/asm-ppc/linux_logo.h when integrating the new logo
code.

Atafb bug in #if 0 code (from 2.4.x)

Use new wd33c93_{abort,host_reset}() routines introduced in 2.5.67 in the m68k
wd33c93-based SCSI host adapter drivers:
  - Amiga A2091 SCSI
  - Amiga A3000 SCSI
  - Amiga GVP Series II SCSI
  - MVME147 SCSI

These drivers still have to implement their own adapter-specific bus_reset()
routines!

Kill warning about unused static functions if HAVE_ARCH_GET_SIGNAL_TO_DELIVER
is defined.

Q40/Q60 IDE: Use the standard IDE operations, which are always MMIO on m68k,
but make sure IDE shows up in /proc/ioports (from Richard Zidlicky).

M68k raw I/O updates:
  - Convert raw I/O access macros to inline functions:
      o raw_{in,out}s[bw]()
      o raw_{in,out}sw_swapw()
  - Add raw_{in,out}sl() (needed for IDE)
  - Update isa_[im]t_[bw]() for stricter type checking of inline functions

Amifb: Updates for fbdev changes in 2.5.66 and 2.5.68:
  - Last parameter of fb_{fillrect,copyarea,imageblit}() became const

IDE I/O operations clean ups:
  - Kill warning about void return type not being ignored
  - Fix comment: Q40/Q60 also has a byte-swapped IDE interface

M68k IDE:
  - Update for new-style low-level IDE operations. Since so far no single
    m68k platform uses ISA/PCI I/O space for IDE, we always use the `raw' MMIO
    versions.
  - ATA_ARCH_LOCK was renamed to IDE_ARCH_LOCK
  - Define ide_ack_intr() and set IDE_ARCH_ACK_INTR

Resurrect dmasound:
  - Re-add dmasound to the build process
  - Update dmasound.h, which got missed in the dmasound update in 2.5.15
  - Compile fixes for core, Atari, Amiga Paula, and Q40:
      o Update for s/MINOR/minor/g changes
      o Add missing <linux/interrupt.h>
      o Fix spinlock typo

M68k: Use ptrace_check_attach instead of doing the checks ourselves (from
Andreas Schwab).

M68k: Fix sys_ipc() to return ENOSYS instead of EINVAL as appropriate.

SCSI: hosts.c uses CONFIG_*, hence it needs to include <linux/config.h>

M68k: Add pte_file() for Motorola MMUs (from Roman Zippel):
  - Add support for file file offsets in pte's (recycle unused _PAGE_COW bit)
  - Move swap macros into the mmu specific header
  - Fix swap macros (lowest two bits must be cleared)

M68k IDE: kill ide_ioreg_t and q40ide_ioreg_t

AFS and RXRPC: times must be unsigned long

Atyfb fixes for Atari (got reversed in 2.5.69):
  - Add missing allocation of default_par
  - Kill warnings in assignments

Ataflop: fix breakage after recent cleanups

M68k fbdev drivers: Update to the new irq API (from Roman Zippel and me) [20/20]

M68k SCSI drivers: Update to the new irq API (from Roman Zippel and me) [19/20]

M68k parport drivers: Update to the new irq API (from Roman Zippel and me) [18/20]

M68k net drivers: Update to the new irq API (from Roman Zippel and me) [17/20]

M68k mac drivers: Update to the new irq API (from Roman Zippel and me) [16/20]

M68k input drivers: Update to the new irq API (from Roman Zippel and me) [15/20]