This also removes the mach/s3c2400 version which was probably never used
due to the fact that we have this line in arch/arm/Makefile:

machine-$(CONFIG_ARCH_S3C2410)          := s3c2410 s3c2400 [...]

This is later used to construct the search path for:

The compiler would be looking into mach-s3c2410 and picking up this
version first.  Any config that was actually expecting the mach-s3c2400
version was therefore producing a broken kernel binary.  Not relying on
any of them anymore would fix that issue.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>

Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>

Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: NTony Lindgren <tony@atomide.com>

Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: NTony Lindgren <tony@atomide.com>

Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>

Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>

Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>

When the CONFIG_NO_MACH_MEMORY_H symbol is selected by a particular
machine class, the machine specific memory.h include file is no longer
used and can be removed.  In that case the equivalent information can
be obtained dynamically at runtime by enabling CONFIG_ARM_PATCH_PHYS_VIRT
or by specifying the physical memory address at kernel configuration time.

If/when all instances of mach/memory.h are removed then this symbol could
be removed.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>

This achieves two goals:

1) Get rid of davinci_uart_v2p() and davinci_uart_p2v() which were the
   last users of PLAT_PHYS_OFFSET.

2) Remove the probing of the M bit in the CP15 control reg and make
   the access to the .data variables completely position independent.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>

This is the first step to remove PLAT_PHYS_OFFSET usage from the debug
UART code.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Reviewed-by: NKevin Hilman <khilman@ti.com>
Tested-by: NKevin Hilman <khilman@ti.com>

This achieves two goals:

1) Get rid of omap_uart_v2p() and omap_uart_p2v() which were the last users
   of PLAT_PHYS_OFFSET.

2) Remove the probing of the M bit in the CP15 control reg and make
   the access to the .data variables completely position independent.

There is a catch though: the busyuart macro needs to know where the LSR
register is which might be at a different offset depending on the hardware.
Given that this macro is given only two registers and that one of them
must be preserved, the trick is to always pass the LSR register address
around, and deduce the base address for the THR register by masking out
the LSR offset in senduart instead.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>

This achieves two goals:

1) Get rid of omap_uart_v2p() and omap_uart_p2v() which were the last users
   of PLAT_PHYS_OFFSET.

2) Remove the probing of the M bit in the CP15 control reg and make
   the access to the .data variables completely position independent.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>

This is the first step to remove PLAT_PHYS_OFFSET usage from the debug
UART code.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: NTony Lindgren <tony@atomide.com>
Reviewed-by: NKevin Hilman <khilman@ti.com>

Some platforms (like OMAP not to name it) are doing rather complicated
hacks just to determine the base UART address to use.  Let's give their
addruart macro some slack by providing an extra work register which will
allow for much needed cleanups.

This is basically a no-op as this commit is only adding the extra argument
to the macro but no one is using it yet.
Signed-off-by: Nnicolas Pitre <nicolas.pitre@linaro.org>
Reviewed-by: NKevin Hilman <khilman@ti.com>

Nothing actually requires that <mach/hardware.h>, <mach/memory.h> nor
<asm/mach-types.h> be included here.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: NFelipe Balbi <balbi@ti.com>

Original comment:

  Restrict DMA-able region to workaround silicon limitation.
  The limitation restricts buffers available for DMA to SD/MMC
  hardware to be below 256MB.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>

Conflicts:
	arch/arm/mach-msm/board-msm7x30.c

Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
  perf tools: Add group event scheduling option to perf record/stat
  MAINTAINERS: Fix list of perf events source files
  perf tools: Fix build against newer glibc
  perf tools: Fix error handling of unknown events
  perf evlist: Fix missing event name init for default event
  perf list: Fix exit value

* 'stable/bug.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen:
  xen/tracing: Fix tracing config option properly
  xen: Do not enable PV IPIs when vector callback not present
  xen/x86: replace order-based range checking of M2P table by linear one
  xen: xen-selfballoon.c needs more header files

Steven Rostedt says we should use CONFIG_EVENT_TRACING.

Cc:Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

Fix regression for HVM case on older (<4.1.1) hypervisors caused by

  commit 99bbb3a8
  Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
  Date:   Thu Dec 2 17:55:10 2010 +0000

    xen: PV on HVM: support PV spinlocks and IPIs

This change replaced the SMP operations with event based handlers without
taking into account that this only works when the hypervisor supports
callback vectors. This causes unexplainable hangs early on boot for
HVM guests with more than one CPU.

BugLink: http://bugs.launchpad.net/bugs/791850

CC: stable@kernel.org
Signed-off-by: NStefan Bader <stefan.bader@canonical.com>
Signed-off-by: NStefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-and-Reported-by: NStefan Bader <stefan.bader@canonical.com>
Signed-off-by: NKonrad Rzeszutek Wilk <konrad.wilk@oracle.com>

There are now no platforms which set this macro.
Signed-off-by: NJon Medhurst <tixy@yxit.co.uk>

Signed-off-by: NJon Medhurst <tixy@yxit.co.uk>
CC: Paul Mundt <lethal@linux-sh.org>
CC: Magnus Damm <magnus.damm@gmail.com>

Signed-off-by: NJon Medhurst <tixy@yxit.co.uk>
CC: Jiandong Zheng <jdzheng@broadcom.com>
CC: Scott Branden <sbranden@broadcom.com>

Signed-off-by: NJon Medhurst <tixy@yxit.co.uk>
Acked-by: Nicolas Ferre<nicolas.ferre@atmel.com>

Signed-off-by: NJon Medhurst <tixy@yxit.co.uk>
Acked-by: NLinus Walleij <linus.walleij@stericsson.com>

Signed-off-by: NJon Medhurst <tixy@yxit.co.uk>
CC: Sekhar Nori <nsekhar@ti.com>
CC: Kevin Hilman <khilman@ti.com>

All in-tree MX boards using video use memblock_* functions to get their
coherent dma space for the camera. So there is no need to increase
CONSISTENT_DMA_SIZE beyond the default 2MB and we can simply remove the
defines which do this.
Signed-off-by: NJon Medhurst <tixy@yxit.co.uk>
Acked-by: NSascha Hauer <s.hauer@pengutronix.de>

Signed-off-by: NJon Medhurst <tixy@yxit.co.uk>
CC: Kukjin Kim <kgene.kim@samsung.com>

Signed-off-by: NJon Medhurst <tixy@yxit.co.uk>
CC: Kukjin Kim <kgene.kim@samsung.com>

Signed-off-by: NJon Medhurst <tixy@yxit.co.uk>
CC: Ben Dooks <ben-linux@fluff.org>

Signed-off-by: NJon Medhurst <tixy@yxit.co.uk>
CC: Tony Lindgren <tony@atomide.com>

This function can be called during boot to increase the size of the consistent
DMA region above it's default value of 2MB. It must be called before the memory
allocator is initialised, i.e. before any core_initcall.
Signed-off-by: NJon Medhurst <tixy@yxit.co.uk>
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>

* 'fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6:
  firewire: core: handle ack_busy when fetching the Config ROM

Now that there is no more users, we can remove it from the kernel.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: NArnd Bergmann <arnd@arndb.de>

Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: NArnd Bergmann <arnd@arndb.de>