kgsl: update to latest ics_chocolate revision

Latest as of commit: c19588a1dcc60eb10b661ea0edd1e5b26e797b18

Completely untouched - build fixes for 2.6.35 kernel will be in
separate commit.

Change-Id: I1b925e82b3124206d74e7589336db341b66be652
(cherry picked from commit 2f3d191b4d0b916364a99c71bc81e5238b2cf589)
kgsl: build fixes for 2.6.35 kernel

Build fixes for ics_chocolate kgsl driver

Change-Id: I9083e685cc1a848540195681c833060e43bdc2ed
(cherry picked from commit f6b7316540e7f31512600586731f9b45e3584658)
msm: kgsl: Optimize page_alloc allocations

User memory needs to be zeroed out before it is sent to the user.
To do this, the kernel maps the page, memsets it to zero and then
unmaps it.  By virtue of mapping it, this forces us to flush the
dcache to ensure cache coherency between kernel and user mappings.
Originally, the page_alloc loop was using GFP_ZERO (which does a
map, memset, and unmap for each individual page) and then we were
additionally calling flush_dcache_page() for each page killing us
on performance.  It is far more efficient, especially for large
allocations (> 1MB), to allocate the pages without GFP_ZERO and
then to vmap the entire allocation, memset it to zero, flush the
cache and then unmap. This process is slightly slower for very
small allocations, but only by a few microseconds, and is well
within the margin of acceptability. In all, the new scheme is
faster than the default for all sizes greater than 16k, and is
almost 4X faster for 2MB and 4MB allocations which are common for
textures and very large buffer objects.

The downside is that if there isn't enough vmalloc room for the
allocation that we are forced to fallback to a slow page by
page memset/flush, but this should happen rarely (if at all) and
is only included for completeness.

CRs-Fixed: 372638
Change-Id: Ia3984581a01fb888c45471d25aa622900edd839d
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
(cherry picked from commit b2f163021cb8bc42cb9aca71c34112bc251ab533)
backport lowmemorykiller from CAF msm-3.4

this improves low memory behaviour greatly due to accounting for
lowmem_reserve as well as shmem pages.

Change-Id: I351dda49be388a98edfe6cc31ae4f2667c77429c
(cherry picked from commit a64a14050e32fa79905903cf76c62be5b360c8eb)
fix kgsl for beni/tass split boards

Change-Id: Icc175997d1084a4e32c3795a6401012ebaf94a2f
(cherry picked from commit edec543086c162c514484c784d37bd426f9e96b2)
mmc: update to latest gingerbread_rel revision

The Samsung source is based on CodeAurora tag M76XXTSNCJNLYA6140,
which is missing several important updates to the MMC drivers
required for wifi stability.

Taken from revision: 7b8b192bb2cee24d4c932d5fc1a386e7da6ce435

Note: completely untouched (i.e. Samsung hacks removed). Separate
commit will re-add needed code to improve ar6003 compatibility.

Change-Id: Iadff5c4551507a5389803de12f0e02c356601158
(cherry picked from commit e18149f0e5168893fc2e21f8c21922c81398a13c)
Improve ar6003 wifi compatibility for MMC driver

Change-Id: Ie24560d5882990f3c160dcf843f6ee7d06bba581
(cherry picked from commit 9a8b7914d57eaeeb21114601b6f328d30448e668)
Refresh configs

* MMC: update config for new MMC drivers
* MMC: add AR6003 driver workaround config (disabled for ath6kl)
* MMC: enable paranoid SD init,
* MMC: disable block bounce buffers (not needed on MSM7x27)
* KGSL: remove old config.
* Misc: update configs to reflect latest reference Android
  configs (base & recommended)

Change-Id: I883f15e2c4786804e5280e762c766d8122637c5b
(cherry picked from commit 5f2de756681dfbe8ce7834d22ddf4c25a479d637)
This is a combination of 36 commits.

ARM: zImage: don't hard code the stack size twice

Acked-by: Eric Miao <eric.miao@canonical.com>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
(cherry picked from commit bd6e732de8cf2510ac4389feb7269009eee5ee9a)

ARM: zImage: some comments for __armv3_mpu_cache_on

__armv3_mpu_cache_on seems broken.  As there is noone around who knows
about these machines just keep the code as is but point out the strange
things.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
(cherry picked from commit d8430e24332704fad02240120b116bc5d2c4346e)

ARM: zImage: __armv3_mpu_cache_flush: respect should-be-zero specification

Probably the register content for cache operations is "don't care" in
practice, but as r1 is explicitly zeroed, use that one.

Acked-by: Eric Miao <eric.miao@canonical.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

ARM: zImage: annotate debug functions about corrupted registers

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

ARM: remove bit-rotten STANDALONE_DEBUG for decompressor

I tried to get this running to debug the regression introduced by
e7db7b4 without success.  But this has several problems that make it
hard to fix:

  - lib/decompress_inflate.c includes in-kernel headers that make
    it difficult to compile for user space.
  - the binary formats changed both in kernel and user space and
    at least for the kernel side there isn't only a single
    variant.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>

ARM: zImage: don't define unused symbol initrd_phys

The only user of initrd_phys is arch/arm/boot/bootp/init.S which still
gets the value passed to.

Acked-by: Eric Miao <eric.miao@canonical.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

ARM: Remove unused PARAMS_PHYS from arch/arm/boot/compressed

The only reference in arch/arm/boot/compressed to PARAMS_PHYS is
params() in head.S, which can be directly converted to the exact
address as specified by arch/arm/mach-rpc/Makefile.boot.

Signed-off-by: Eric Miao <eric.miao@canonical.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

ARM: Auto calculate ZRELADDR and provide option for exceptions

As long as the zImage is placed within the 128MB range from the start of
memory, ZRELADDR (Address where the decompressed kernel will be placed,
usually == PHYS_OFFSET + TEXT_OFFSET) can be determined at run-time by
masking PC with 0xf80000000.

Running through all the Makefile.boot, all those zreladdr-y
addresses == 0x[0-f][08]00_0000 + TEXT_OFFSET can be determined at
run-time.

Option CONFIG_AUTO_ZRELADDR and CONFIG_ZRELADDR are introduced,
CONFIG_ZRELADDR _must_ be explicitly specified if:

- ((zreladdr-y - TEXT_OFFSET) & ~0xf8000000) != 0, which means
  masking PC with 0xf8000000 will result in an incorrect address.
  Currently this is only a problem on u300.

- or the assumption of the zImage being loaded by the bootloader within
  the first 128MB of RAM is incorrect

- or when ZBOOT_ROM is used, where the above assumption is usually wrong.

[ukleinek: changed mask from 0xf0000000 to 0xf8000000 for mx1 and shark
+ some review fixes from the mailing list]

Original-Idea-and-Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Eric Miao <eric.miao@canonical.com>
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>

ARM: 6286/1: fix Thumb-2 decompressor broken by "Auto calculate ZRELADDR"

"ARM: Auto calculate ZRELADDR and provide option for exceptions" broke
the Thumb-2 decompressor because it removed an entry in the LC0 table
but didn't adjust the offset the Thumb-2 code uses to load the SP from
that table.

Fix it, and also change the ARM code to use the separate SP-load since
ARM instructions that include the SP in the LDM register list are
deprecated.

Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: Fix build error when using KCONFIG_CONFIG

Jonathan Cameron reports that when using the environment
variable KCONFIG_CONFIG, he encounters this error:

make[2]: *** No rule to make target `.config', needed by `arch/arm/boot/compressed/vmlinux.lds'

Reported-by: Jonathan Cameron <jic23@cam.ac.uk>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: Partially revert "Auto calculate ZRELADDR and provide option for exceptions"

Partially revert e69edc7, which introduced automatic zreladdr
support.  The change in the way the manual definition is defined
seems to be error and conflict prone.  Go back to the original way
we were handling this for the time being, while keeping the automatic
zreladdr facility.

Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Conflicts:

	arch/arm/Kconfig

ARM: avoid marking decompressor .stack section as having contents

The .stack section doesn't contain any contents, and doesn't require
initialization either.  Rather than marking the output section with
'NOLOAD' but still having it exist in the object files, mark it with
%nobits which avoids the assembler marking the section with 'CONTENTS'.

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

ARM: 6499/1: Thumb-2: Correct data alignment for CONFIG_THUMB2_KERNEL in bootp/init.S

Directives such as .long and .word do not magically cause the
assembler location counter to become aligned in gas.  As a result,
using these directives in code sections can result in misaligned
data words when building a Thumb-2 kernel (CONFIG_THUMB2_KERNEL).

This is a Bad Thing, since the ABI permits the compiler to assume
that fundamental types of word size or above are word- aligned when
accessing them from C.  If the data is not really word-aligned,
this can cause impaired performance and stray alignment faults in
some circumstances.

In general, the following rules should be applied when using data
word declaration directives inside code sections:

    * .quad and .double:
         .align 3

    * .long, .word, .single, .float:
         .align (or .align 2)

    * .short:
        No explicit alignment required, since Thumb-2
        instructions are always 2 or 4 bytes in size.
        immediately after an instruction.

Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 6502/1: Thumb-2: Fix CONFIG_THUMB2_KERNEL breakage in compressed/head.S

Some instruction operand combinations are used here which are nor
permitted in Thumb-2.

In particular, most uses of pc as an operand are disallowed in
Thumb-2, and deprecated in ARM from ARMv7 onwards.

The modified code introduced by this patch should be compatible
with all architecture versions >= v3, with or without
CONFIG_THUMB2_KERNEL.

Reviewed-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 6750/1: improvements to compressed/head.S

In the case of a conflict between the memory used by the compressed
kernel with its decompressor code and the memory used for the
decompressed kernel, we currently store the later after the former and
relocate it afterwards.

This would be more efficient to do this the other way around i.e.
relocate the compressed data up front instead, resulting in a smaller
copy.  That also has the advantage of making the code smaller and more
straight forward.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Conflicts:

	arch/arm/boot/compressed/head.S

ARM: 6503/1: Thumb-2: Restore sensible zImage header layout for CONFIG_THUMB2_KERNEL

The code which makes up the zImage header intends to leave a
32-byte gap followed by a branch to the real entry point, a magic
number, and a word containing the absolute entry point address.

This gets messed up with with CONFIG_THUMB2_KERNEL, because the
size of the initial padding NOPs changes.

Instead, the header can be made fully compatible by restoring it to
ARM.

In the Thumb-2 case, we can replace the initial NOPs with a
sequence which switches to Thumb and jumps to the real entry point.

As a consequence, the zImage entry point is now always ARM, so no
special magic is needed any more for the uImage rules in the
Thumb-2 case.

Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 6739/1: update .gitignore for boot/compressed

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Conflicts:
	arch/arm/boot/compressed/.gitignore

Change-Id: I03de4cf2368311d4cbf64f335723beff7b2e812f

ARM: 6746/1: remove the 4x expansion presumption while decompressing the kernel

We currently presume a 4x expansion to guess the decompressed kernel size
in order to determine if the decompressed kernel is in conflict with
the location where zImage is loaded.  This guess may cause many issues
by overestimating the final kernel image size:

- This may force a needless relocation if the location of zImage was
  fine, wasting some precious microseconds of boot time.

- The relocation may be located way too far, possibly overwriting the
  initrd image in RAM.

- If the kernel image includes a large already-compressed initramfs image
  then the problem is even more exacerbated.

And if by some strange means the 4x guess is too low then we may overwrite
ourselves with the decompressed image.

So let's use the exact decompressed kernel image size instead.  For that
we need to rely on the stat command, but this is hardly a new build
dependency as the kernel already depends on many external commands
to be built provided by the coreutils package where stat is found.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 6778/1: compressed/head.S: make LDFLAGS_vmlinux into a recursively expanded variable

The simply expanded variable may be evaluated before the target file for
the stat command is up to date or even exists.  Switching to a recursively
expanded variable move the execution of the stat command to the location
where LDFLAGS_vmlinux is actually used, fixing the dependency issue
introduced by patch #6746/1.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

arm: change to new flag variables

Replace EXTRA_CFLAGS with ccflags-y and EXTRA_AFLAGS with asflags-y.

Signed-off-by: matt mooney <mfm@muteddisk.com>
Acked-by: WANG Cong <xiyou.wangcong@gmail.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>

ARM: zImage: make sure the stack is 64-bit aligned

With ARMv5+ and EABI, the compiler expects a 64-bit aligned stack so
instructions like STRD and LDRD can be used.  Without this, mysterious
boot failures were seen semi randomly with the LZMA decompressor.

While at it, let's align .bss as well.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Tony Lindgren <tony@atomide.com>
CC: stable@kernel.org

ARM: zImage: Fix bad SP address after relocating kernel

Otherwise cache_clean_flush can overwrite some of the relocated
area depending on where the kernel image gets loaded. This fixes
booting on n900 after commit 6d7d0ae51574943bf571d269da3243257a2d15db
(ARM: 6750/1: improvements to compressed/head.S).

Thanks to Aaro Koskinen <aaro.koskinen@nokia.com> for debugging
the address of the relocated area that gets corrupted, and to
Nicolas Pitre <nicolas.pitre@linaro.org> for the other uncompress
related fixes.

Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>

ARM: zImage: make sure not to relocate on top of the relocation code

If the zImage load address is slightly below the relocation address,
there is a risk for the copied data to overwrite the copy loop or
cache flush code that the relocation process requires.  Always
bump the relocation address by the size of that code to avoid this
issue.

Noticed by Tony Lindgren <tony@atomide.com>.

While at it, let's start the copy from the restart symbol which makes
the above code size computation possible by the assembler directly
(same sections), given that we don't need to preserve the code before
that point anyway. And therefore we don't need to carry the _start
pointer in r5 anymore.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Tony Lindgren <tony@atomide.com>

ARM: zImage: the page table memory must be considered before relocation

For correctness, the initial page table located right before the
decompressed kernel should be considered when determining if relocation
is required.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Acked-by: Tony Lindgren <tony@atomide.com>

ARM: zImage: no need to get the decompressed size from the filesystem

In commit d239b1dc093d the hardcoded 4x estimate for the decompressed
kernel size was replaced by the exact Image file size and passed to
the linker as a symbol value.  Turns out that this is unneeded as the
size is already included at the end of the compressed piggy data.
For those compressed formats that don't include this data, the build
system already takes care of appending it using size_append in
scripts/Makefile.lib.  So let's use that instead.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Tony Lindgren <tony@atomide.com>

ARM: zImage: simplify decompress_kernel()

The return value for decompress_kernel() is no longer used.  Furthermore,
this was obtained and stored in a variable called output_ptr which is
a complete misnomer for what is actually the size of the decompressed
kernel image.  Let's get rid of it.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Tony Lindgren <tony@atomide.com>

ARM: zImage: don't ignore error returned from decompress()

If decompress() returns an error without calling error(), we must
not attempt to boot the resulting kernel.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Tony Lindgren <tony@atomide.com>

ARM: zImage: make sure no GOTOFF relocs are used with .bss symbols

To be able to relocate the .bss section at run time independently from
the rest of the code, we must make sure that no GOTOFF relocations are
used with .bss symbols.  This usually means that no global variables can
be marked static unless they're also const.

To enforce this, suffice to fail the build whenever a private symbol
is allocated to .bss and list those symbols for convenience.

The user_stack and user_stack_end labels in head.S were converted into
non exported symbols to remove false positives.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Tony Lindgren <tony@atomide.com>

ARM: 6859/1: Add writethrough dcache support for ARM926EJS processor

The ARM kernel supports writethrough data cache via the
CONFIG_CPU_DCACHE_WRITETHROUGH option.  However, that
functionality wasn't implemented in the arch/arm/boot/compressed
code.  It is now necessary due to a new ARM926EJS processor
that has an issue with writeback data cache.

Signed-off-by: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 6954/1: zImage: fix Thumb2 breakage

Commit af3e4fd37a "ARM: 6859/1: Add writethrough dcache support for
ARM926EJS processor" broke Thumb2 compilation by omitting to maintain
the wide encoding for the added branch instructions which made the
ARM926EJ-S record smaller than expected, breaking the record walk code.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Mark A. Greer <mgreer@mvista.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 6961/1: zImage: Add build-time check for correctly-sized proc_type entries

It is easy to mis-maintain the proc_types table such that the
entries become wrongly-sized and misaligned when the kernel is
built in Thumb-2.

This patch adds an assembly-time check which will turn most common
size/alignment mistakes in this table into build failures, to avoid
having to debug the boot-time kernel hang which would happen if the
resulting kernel were actually booted.

Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: decompressor: use better output sections

Place read-only data in a .rodata output section, and the compressed
piggy data in .piggydata.  Place the .got.plt section before the .got
section as is standard ELF practise.

This allows the piggydata to be more easily extracted from the
compressed vmlinux file for verification purposes.

Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 6999/1: head, zImage: Always Enter the kernel in ARM state

Currently, the documented kernel entry requirements are not
explicit about whether the kernel should be entered in ARM or
Thumb, leading to an ambiguitity about how to enter Thumb-2
kernels.  As a result, the kernel is reliant on the zImage
decompressor to enter the kernel proper in the correct instruction
set state.

This patch changes the boot entry protocol for head.S and Image to
be the same as for zImage: in all cases, the kernel is now entered
in ARM.

Documentation/arm/Booting is updated to reflect this new policy.

A different rule will be needed for Cortex-M class CPUs as and when
support for those lands in mainline, since these CPUs don't support
the ARM instruction set at all: a note is added to the effect that
the kernel must be entered in Thumb on such systems.

Signed-off-by: Dave Martin <dave.martin@linaro.org>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: zImage: ensure it is always a multiple of 64 bits in size

This is needed for proper alignment when the DTB appending feature
is used.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Acked-by: Tony Lindgren <tony@atomide.com>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Dave Martin <dave.martin@linaro.org>
Tested-by: Thomas Abraham <thomas.abraham@linaro.org>

ARM: zImage: gather some string functions into string.c

This is a small subset of string functions needed by commits to come.
Except for memcpy() which is unchanged from its original location, their
implementation is meant to be small, and -Os is enforced to prevent gcc
from doing pointless loop unrolling.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Dave Martin <dave.martin@linaro.org>
Tested-by: Thomas Abraham <thomas.abraham@linaro.org>

ARM: zImage: prevent constant copy+rebuild of lib1funcs.S

The rule to copy this file doesn't have to be forced.  However
lib1funcs.[So] have to be listed amongst the targets.

This prevents zImage from being recreated needlessly.

Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>
Tested-by: Shawn Guo <shawn.guo@linaro.org>
Tested-by: Dave Martin <dave.martin@linaro.org>
Tested-by: Thomas Abraham <thomas.abraham@linaro.org>
(cherry picked from commit ca58d43565dd10cbf9b8f5e10eceabbd3dbdac57)

Change-Id: If8b27225424766f39fedb67338b5a3bfde20bd42
Add support for XZ compressed kernel

Change-Id: I42b2912b83d7af374497785820182e8b5e61d12a
(cherry picked from commit 216c04bf448190278f7388944dd765a53e69af70)
Samsung msm7x27: Use XZ compression to minimize kernel size

Change-Id: I936edc21fabb81733080346907b8f97a359117ed
(cherry picked from commit 8ab48679804efb0469fe9c00feb279de8d4acd74)