This adds basic perf support for ARC700 cores. Most PERF_COUNT_HW* events
are supported now.
Signed-off-by: NMischa Jonker <mjonker@synopsys.com>
Acked-by: NPeter Zijlstra <peterz@infradead.org>
Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Signed-off-by: NVineet Gupta <vgupta@synopsys.com>

Add a header file for Nokia SDRAM functions. Based on patches by Juha
Keski-Saari.
Signed-off-by: NAaro Koskinen <aaro.koskinen@nokia.com>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Commit 7c63984b (ARM: do not define VMALLOC_END relative to PAGE_OFFSET)
changed VMALLOC_END to be an explicit value. Before this, it was
relative to PAGE_OFFSET and therefore converted to unsigned long
as PAGE_OFFSET is an unsigned long. This introduced the following
build warning. Fix this by changing the explicit defines of
VMALLOC_END to be unsigned long.

  CC      arch/arm/mm/init.o
arch/arm/mm/init.c: In function 'mem_init':
arch/arm/mm/init.c:606: warning: format '%08lx' expects type 'long unsigned int', but argument 12 has type 'unsigned int'
Signed-off-by: NAnand Gadiyar <gadiyar@ti.com>
Acked-by: NUwe Kleine-K <u.kleine-koenig@pengutronix.dee>
Acked-by: NNicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

VMALLOC_END is supposed to be an absolute value, while PAGE_OFFSET may
vary depending on the selected user:kernel memory split mode through
CONFIG_VMSPLIT_*.  In fact, the goal of moving PAGE_OFFSET down is to
accommodate more directly addressed RAM by the kernel below the vmalloc
area, and having VMALLOC_END move along PAGE_OFFSET is rather against
the very reason why PAGE_OFFSET can be moved in the first place.
Signed-off-by: NNicolas Pitre <nicolas.pitre@linaro.org>

This just leaves include/asm-arm/plat-* to deal with.
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

VMALLOC_START and VMALLOC_OFFSET are common between all ARM
machine classes.  Move them into include/asm-arm/pgtable.h,
but allow a machine class to override them if required.
Signed-off-by: NRussell King <rmk@arm.linux.org.uk>

Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!