[IA64] Add "model name" to /proc/cpuinfo

Linux ia64 port tried to decode the processor family number
to something human-readable, but Intel brandnames don't change
synchronously with updates to the family number.  Adopt a more
i386-like approach and just print the family number in decimal.
Add a new field "model name" that uses PAL_BRAND_INFO to find
the official name for the cpu, or on older systems, falls back
to using the well-known codenames (Merced, McKinley, Madison).

Signed-off-by: Tony Luck <tony.luck@intel.com>
[IA64] esi-support

Add support for making ESI calls [1].  ESI stands for "Extensible SAL
specification" and is basically a way for invoking firmware
subroutines which are identified by a GUID.  I don't know whether ESI
is used by vendors other than HP (if you do, please let me know) but
as firmware "backdoors" go, this seems one of the cleaner methods, so
it seems reasonable to support it, even though I'm not aware of any
publicly documented ESI calls.  I'd have liked to make the ESI module
completely stand-alone, but unfortunately that is not easily (or not
at all) possible because in order to make ESI calls in physical mode,
a small stub similar to the EFI stub is needed in the kernel proper.
I did try to create a stub that would work in user-level, but it
quickly got ugly beyond recognition (e.g., the stub had to make
assumptions about how the module-loader generated call-stubs work) and
I didn't even get it to work (that's probably fixable, but I didn't
bother because I concluded it was too ugly anyhow).  While it's not
terribly elegant to have kernel code which isn't actively used in the
kernel proper, I think it might be worth making an exception here for
two reasons: the code is trivially small (all that's really needed is
esi_stub.S) and by including it in the normal kernel distro, it might
encourage other OEMs to also use ESI, which I think would be far
better than each inventing their own firmware "backdoor".

The code was originally written by Alex.  I just massaged and packaged
it a bit (and perhaps messed up some things along the way...).

Changes since first version of patch that was posted to mailing list:
* Export ia64_esi_call and ia64_esi_call_phys() as GPL symbols.
* Disallow building esi.c as a module for now.  Building as a module
  would currently lead to an unresolved reference to "sal_lock" on SMP kernels
  because that symbol doesn't get exported.
* Export esi_call_phys() only if ESI is enabled.
* Remove internal stuff from esi.h and add a "proc_type" argument to
  ia64_esi_call() such that serialization-requirements can be expressed (ESI
  follows SAL here, where procedure calls may have to be serialized, are
  MP-safe, or MP-safe andr reentrant).

[1] h21007.www2.hp.com/dspp/tech/tech_TechDocumentDetailPage_IDX/1,1701,919,00.html

Signed-off-by: David Mosberger <David.Mosberger@acm.org>
Signed-off-by: Alex Williamson <alex.williamson@hp.com>
Signed-off-by: Tony Luck <tony.luck@intel.com>
[MMC] Convert mmci to use data->blksz rather than data->blksz_bits

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[MMC] Remove data->blksz_bits member

data->blksz_bits is unused now - remove it.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[MMC] Add multi block-write capability

Add a capability flag for drivers to set when they can perform multi-
block transfers to cards _and_ correctly report the number of bytes
transferred should an error occur.

The last point is very important - if a driver reports more bytes than
were actually accepted by the card and an error occurs, there is the
possibility for data loss.

Pierre Ossman provided the patch for wbsd and sdhci.

Signed-off-by: Pierre Ossman <drzeus@drzeus.cx>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ARM] Cleanup arch/arm/mm a little

Move top_pmd into arch/arm/mm/mm.h - nothing outside arch/arm/mm
references it.

Move the repeated definition of TOP_PTE into mm/mm.h, as well as
a few function prototypes.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ARM] Move mmu.c out of the way

Rename mmu.c to context.c - it's the ARMv6 ASID context handling
code rather than generic "mmu" handling code.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ARM] Add ARM irqtrace support

This adds support for irqtrace for lockdep on ARM.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ARM] Fix kernel/fork.c for lockdep on ARM

ARM has interrupts enabled over context switches (iow, has
__ARCH_WANT_INTERRUPTS_ON_CTXSW defined.)  The lockdep code in fork.c
 assumes that interrupts are always disabled.  Fix this wrong
assumption by making the initialisation of 'p->hardirqs_enabled'
depend on __ARCH_WANT_INTERRUPTS_ON_CTXSW.

Acked-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ARM] Optimise VFP thread notify function a little

The common case for the thread notifier is a context switch.  Tell
gcc that this is the most likely condition so it can optimise the
function for this case.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ARM] 3759/2: Remove uses of %?

Patch from Daniel Jacobowitz

The ARM kernel has several uses of asm("foo%?").  %? is a GCC internal
modifier used to output conditional execution predicates.  However, no
version of GCC supports conditionalizing asm statements.  GCC 4.2 will
correctly expand %? to the empty string in user asms.  Earlier versions may
reuse the condition from the previous instruction.  In 'if (foo) asm
("bar%?");' this is somewhat likely to be right... but not reliable.

So, the only safe thing to do is to remove the uses of %?.  I believe
the tlbflush.h occurances were supposed to be removed before, based
on the comment about %? not working at the top of that file.

Old versions of GCC could omit branches around user asms if the asm didn't
mark the condition codes as clobbered.  This problem hasn't been seen on any
recent (3.x or 4.x) GCC, but it could theoretically happen.  So, where
%? was removed a cc clobber was added.

Signed-off-by: Daniel Jacobowitz <dan@codesourcery.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ARM] nommu: create flat.h to support uClinux flat binaries

Create header with uClinux flat format binary support macros for ARM
platforms. Derived from the m68knommu flat.h.

Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[MMC] MMC_CAP_BYTEBLOCK flag for non-log2 block sizes capable hosts

Some MMC hosts can only handle log2 block sizes.  Unfortunately,
the MMC password support needs to be able to send non-log2 block
sizes.  Provide a capability so that the MMC password support can
decide whether it should use this support or not.

The unfortunate side effect of this host limitation is that any
MMC card protected by a password which is not a log2 block size
can not be accessed on a host which only allows a log2 block size.

This change just adds the flag.  The MMC password support code
needs updating to use it (if and when it is finally submitted.)

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[MMC] Don't check READY_FOR_DATA when reading

There's no point checking to see if the card is ready to accept
data when we're reading from it - sending the command only wastes
precious bus bandwidth.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ARM] 3795/1: S3C24XX: add base AC97 registers

Add base definitions for the AC97 register
definitions.

Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ARM] 3796/1: S3C24XX: Add per-cpu DMA channel mapper

Allow each CPU type in the S3C24XX range to
select the DMA channel mapping it supports.

We change the DMA registration to use an
virtual channel number that the DMA system
will allocate to a hardware channel at
request time.

Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ARM] 3797/1: S3C2410: DMA channel mappings

DMA channel mappings for the S3C2410

Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ARM] 3798/1: S3C2440: DMA channel mappings

S3C2440 DMA channel mappings

Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ARM] 3799/1: S3C2442: DMA channel mappings

DMA channel mappings for the S3C2442

Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
[ARM] 3801/1: S3C24XX: Move IRQ PM out of pm.c

Seperate the IRQ power management code out of
the pm.c file, and add it to the relevant
system class devices.

Also make the suspend and resume code take
notice of the fact these registers can be
moved by compile time code.

Add fix from Ilya Yanok to also save the
INTSUBMSK over sleep.

Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>