ENGR00267090 mx6sl: System is running at minimum operating voltages

VDD_ARM_IN, VDD_SOC_IN and VDD_PU_IN are at minimum operating voltages of
i.MX6SL when running. Raise these power rails by 25mV for all CPU working
points to compensate the output tolerance from external regulators.

Signed-off-by: Peter Chan <B18700@freescale.com>
ENGR00279566: ARM: i.MX6: Enable L2 cache I/D prefetch function

This patch enable the L2 cache I/D prefetch function on the i.MX6 family.
Based on Android test result, it has the performance improvement:

Before the change:
JB4.3 RC1:
Browser Vellamo scores See The Sun Canvas: 51.16
Browser Vellamo scores Deep Sea Canvas: 65.41
Browser Vellamo scores Aquarium Canvas: 50.23

After the change:
Browser Vellamo scores See The Sun Canvas: 70.28
Browser Vellamo scores Deep Sea Canvas: 78.57
Browser Vellamo scores Aquarium Canvas: 53.73

Signed-off-by: Jason Liu <r64343@freescale.com>
ENGR00267271-1 mx6sl: minimize the VDDHIGH_IN current in deep sleep mode

Minimize the VDDHIGH_IN current by
- Some pads are either have external pullup or may idle at HIGH state. Enable
  internal pulldown will increase leakage current. Do not enable internal
  pulldown to the following pads when suspend: PAD_I2C1_SCL, PAD_I2C1_SDA,
  PAD_I2C2_SCL, PAD_I2C2_SDA, PAD_SD1_CLK, PAD_SD1_CMD, PAD_SD1_DAT0,
  PAD_SD1_DAT1, PAD_SD1_DAT2, PAD_SD1_DAT3, PAD_SD1_DAT4, PAD_SD1_DAT5,
  PAD_SD1_DAT6, PAD_SD1_DAT7, PAD_SD2_CLK, PAD_SD2_CMD, PAD_SD2_DAT0,
  PAD_SD2_DAT1, PAD_SD2_DAT2, PAD_SD2_DAT3, PAD_SD2_DAT4, PAD_SD2_DAT5,
  PAD_SD3_CLK, PAD_SD3_CMD, PAD_SD3_DAT0, PAD_SD3_DAT1, PAD_SD3_DAT2,
  PAD_SD3_DAT3, PAD_FEC_MDIO, PAD_ECSPI1_SS0, PAD_EPDC_PWRCTRL2, PAD_KEY_COL4,
  PAD_KEY_ROW5, PAD_KEY_COL6, PAD_FEC_TX_CLK, PAD_SD2_DAT6, PAD_SD2_DAT7,
  PAD_KEY_ROW7, PAD_KEY_COL7, PAD_REF_CLK_32K
- The pin configurations of SD card detect and write protect should not be
  changed when suspend, remove PAD_SD2_DAT4, PAD_SD2_DAT5 and PAD_KEY_COL7 from
  suspend_enter_pads[]
- LCDIF pins should be configured as GPIO when suspend, add PAD_LCD_ENABLE,
  PAD_LCD_HSYNC, PAD_LCD_VSYNC, PAD_LCD_RESET, PAD_LCD_DAT6, PAD_LCD_DAT7,
  PAD_LCD_DAT8, PAD_LCD_DAT9 to suspend_enter_pads[]
- PAD_WDOG_B is used as a software ON/OFF button detect on EVK. Remove
  MX6SL_PAD_WDOG_B__WDOG1_WDOG_B from mx6sl_brd_pads[]
- PAD_SD1_DAT0 is used by SD1 port, remove MX6SL_PAD_SD1_DAT0__GPIO_5_11
  from mx6sl_uart4_pads[]
- Configure PAD_JTAG_MOD, PAD_JTAG_TCK, PAD_JTAG_TDI, PAD_JTAG_TDO,
  PAD_JTAG_TMS, PAD_JTAG_TRSTB for JTAG function

Signed-off-by: Peter Chan <B18700@freescale.com>
ENGR00267271-2 mx6sl: minimize the VDDHIGH_IN current in deep sleep mode

Minimize the VDDHIGH_IN current by
- Use 100K pullup for SD card detect, write protect and charger signals.
  Use 100K internal pullup for PAD_KEY_COL7, PAD_KEY_ROW7, PAD_REF_CLK_32K,
  PAD_SD2_DAT6, PAD_SD2_DAT7, PAD_ECSPI2_MISO, PAD_ECSPI2_MOSI, PAD_ECSPI2_SS0
- Some pads have external pullup resistors. When suspend, disable pull/keeper
  for MX6SL_PAD_FEC_MDIO__GPIO_4_20, MX6SL_PAD_I2C1_SCL__GPIO_3_12,
  MX6SL_PAD_I2C1_SDA__GPIO_3_13, MX6SL_PAD_I2C2_SCL__GPIO_3_14,
  MX6SL_PAD_I2C2_SDA__GPIO_3_15
- Some function pads have external pull resistors. Disable internal pull for
  MX6SL_PAD_JTAG_MOD__SJC_MOD, MX6SL_PAD_JTAG_TCK__SJC_TCK

Signed-off-by: Peter Chan <B18700@freescale.com>
ENGR00283031 [GPU]Integrate 4.6.9p13 release kernel driver

Integrate GPU 4.6.9p13 release kernel driver for Android.

Signed-off-by: Xianzhong <b07117@freescale.com>
Acked-by: Jason Liu
mtd: gpmi: fix kernel BUG due to racing DMA operations

[1] The gpmi uses the nand_command_lp to issue the commands to NAND chips.
    The gpmi issues a DMA operation with gpmi_cmd_ctrl when it handles
    a NAND_CMD_NONE control command. So when we read a page(NAND_CMD_READ0)
    from the NAND, we may send two DMA operations back-to-back.

    If we do not serialize the two DMA operations, we will meet a bug when

    1.1) we enable CONFIG_DMA_API_DEBUG, CONFIG_DMADEVICES_DEBUG,
         and CONFIG_DEBUG_SG.

    1.2) Use the following commands in an UART console and a SSH console:
         cmd 1: while true;do dd if=/dev/mtd0 of=/dev/null;done
         cmd 1: while true;do dd if=/dev/mmcblk0 of=/dev/null;done

    The kernel log shows below:
    -----------------------------------------------------------------
    kernel BUG at lib/scatterlist.c:28!
    Unable to handle kernel NULL pointer dereference at virtual address 00000000
      .........................
    [<80044a0c>] (__bug+0x18/0x24) from [<80249b74>] (sg_next+0x48/0x4c)
    [<80249b74>] (sg_next+0x48/0x4c) from [<80255398>] (debug_dma_unmap_sg+0x170/0x1a4)
    [<80255398>] (debug_dma_unmap_sg+0x170/0x1a4) from [<8004af58>] (dma_unmap_sg+0x14/0x6c)
    [<8004af58>] (dma_unmap_sg+0x14/0x6c) from [<8027e594>] (mxs_dma_tasklet+0x18/0x1c)
    [<8027e594>] (mxs_dma_tasklet+0x18/0x1c) from [<8007d444>] (tasklet_action+0x114/0x164)
    -----------------------------------------------------------------

    1.3) Assume the two DMA operations is X (first) and Y (second).

         The root cause of the bug:
	   Assume process P issues DMA X, and sleep on the completion
	 @this->dma_done. X's tasklet callback is dma_irq_callback. It firstly
	 wake up the process sleeping on the completion @this->dma_done,
	 and then trid to unmap the scatterlist S. The waked process P will
	 issue Y in another ARM core. Y initializes S->sg_magic to zero
	 with sg_init_one(), while dma_irq_callback is unmapping S at the same
	 time.

	 See the diagram:

                   ARM core 0              |         ARM core 1
	 -------------------------------------------------------------
         (P issues DMA X, then sleep)  --> |
                                           |
         (X's tasklet wakes P)         --> |
                                           |
                                           | <-- (P begin to issue DMA Y)
                                           |
         (X's tasklet unmap the            |
      scatterlist S with dma_unmap_sg) --> | <-- (Y calls sg_init_one() to init
                                           |      scatterlist S)
                                           |

[2] This patch serialize both the X and Y in the following way:
     Unmap the DMA scatterlist S firstly, and wake up the process at the end
     of the DMA callback, in such a way, Y will be executed after X.

     After this patch:

                   ARM core 0              |         ARM core 1
	 -------------------------------------------------------------
         (P issues DMA X, then sleep)  --> |
                                           |
         (X's tasklet unmap the            |
      scatterlist S with dma_unmap_sg) --> |
                                           |
         (X's tasklet wakes P)         --> |
                                           |
                                           | <-- (P begin to issue DMA Y)
                                           |
                                           | <-- (Y calls sg_init_one() to init
                                           |     scatterlist S)
                                           |

Cc: stable@vger.kernel.org # 3.2
Signed-off-by: Huang Shijie <b32955@freescale.com>
Signed-off-by: Brian Norris <computersforpeace@gmail.com>
workqueue: convert BUG_ON()s in __queue_delayed_work() to WARN_ON_ONCE()s

commit fc4b514f2727f74a4587c31db87e0e93465518c3 upstream.

8852aac25e ("workqueue: mod_delayed_work_on() shouldn't queue timer on
0 delay") unexpectedly uncovered a very nasty abuse of delayed_work in
megaraid - it allocated work_struct, casted it to delayed_work and
then pass that into queue_delayed_work().

Previously, this was okay because 0 @delay short-circuited to
queue_work() before doing anything with delayed_work.  8852aac25e
moved 0 @delay test into __queue_delayed_work() after sanity check on
delayed_work making megaraid trigger BUG_ON().

Although megaraid is already fixed by c1d390d8e6 ("megaraid: fix
BUG_ON() from incorrect use of delayed work"), this patch converts
BUG_ON()s in __queue_delayed_work() to WARN_ON_ONCE()s so that such
abusers, if there are more, trigger warning but don't crash the
machine.

Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Xiaotian Feng <xtfeng@gmail.com>
Signed-off-by: Shuah Khan <shuah.khan@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

(cherry picked from commit 3ff0aeceb49aca3f99c37189e949bf43bfd393a0)
workqueue: convert BUG_ON()s in __queue_delayed_work() to WARN_ON_ONCE()s

commit fc4b514f2727f74a4587c31db87e0e93465518c3 upstream.

8852aac25e ("workqueue: mod_delayed_work_on() shouldn't queue timer on
0 delay") unexpectedly uncovered a very nasty abuse of delayed_work in
megaraid - it allocated work_struct, casted it to delayed_work and
then pass that into queue_delayed_work().

Previously, this was okay because 0 @delay short-circuited to
queue_work() before doing anything with delayed_work.  8852aac25e
moved 0 @delay test into __queue_delayed_work() after sanity check on
delayed_work making megaraid trigger BUG_ON().

Although megaraid is already fixed by c1d390d8e6 ("megaraid: fix
BUG_ON() from incorrect use of delayed work"), this patch converts
BUG_ON()s in __queue_delayed_work() to WARN_ON_ONCE()s so that such
abusers, if there are more, trigger warning but don't crash the
machine.

Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Xiaotian Feng <xtfeng@gmail.com>
Signed-off-by: Shuah Khan <shuah.khan@hp.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

(cherry picked from commit 3ff0aeceb49aca3f99c37189e949bf43bfd393a0)
(cherry picked from commit 5721c2db080cd0f9f7370a5eee6704ea71a5c7a4)
ENGR00288588 fixed system reboot when run webGL test

this is a fake recovery to cause system reboot, when run
http://people.mozilla.org/~sicking/webgl/ray.html

the fix is to disable GPU recovery in Chrome browser,

Signed-off-by: Xianzhong <b07117@freescale.com>
Acked-by: Jason Liu
ENGR00289999 fixed gc880 invalid command state message

gpu kernel dump the error message when enable DEBUG mode:

gckCONTEXT_Update(1493): State 0x0518 is not mapped.
gckCONTEXT_Update(1493): State 0x0520 is not mapped.
gckCONTEXT_Update(1493): State 0x0518 is not mapped.
gckCONTEXT_Update(1493): State 0x0520 is not mapped.

align gpu kernel driver to fix the error message

Signed-off-by: Xianzhong <b07117@freescale.com>
Acked-by: Jason Liu
ENGR00283031 [GPU]Integrate 4.6.9p13 release kernel driver

Integrate GPU 4.6.9p13 release kernel driver for Android.

Signed-off-by: Xianzhong <b07117@freescale.com>
Acked-by: Jason Liu
ENGR00288588 fixed system reboot when run webGL test

this is a fake recovery to cause system reboot, when run
http://people.mozilla.org/~sicking/webgl/ray.html

the fix is to disable GPU recovery in Chrome browser,

Signed-off-by: Xianzhong <b07117@freescale.com>
Acked-by: Jason Liu
ENGR00289999 fixed gc880 invalid command state message

gpu kernel dump the error message when enable DEBUG mode:

gckCONTEXT_Update(1493): State 0x0518 is not mapped.
gckCONTEXT_Update(1493): State 0x0520 is not mapped.
gckCONTEXT_Update(1493): State 0x0518 is not mapped.
gckCONTEXT_Update(1493): State 0x0520 is not mapped.

align gpu kernel driver to fix the error message

Signed-off-by: Xianzhong <b07117@freescale.com>
Acked-by: Jason Liu
ENGR00215174 HDMI video: use default video mode when HDMI cable plug.

In original implement, HDMI driver will use the last video mode
when cable plugin. Change the mechanism, use default video mode
seting in bootargs.

Signed-off-by: Liu Xiaowen <b37945@freescale.com>
ENGR00290444: Need to update CAAM driver with SM patches from STC

These patches came from Steve Cornelius of STC and are to fix SM in
CAAM driver. His comments:
    Original implementation assumed that physical base of Secure
    Memory (SM) region could be back-derived from the virtual
    address. Since the kernel doesn't normally know anything about the
    existence of SM (it is clearly not "general purpose" memory), then
    the normal means of address translation would not work,
    necessitating specific computation of physical addresses for SM
    pages.

    Last spin of this driver accounted for this, but did not extract
    the physical base address of SM from a property; instead, it used
    a constant as a shortcut. This change restores correct use of the
    device property to extract the physical base value.

Signed-off-by Jay Monkman <jay.monkman@freescale.com>
ENGR00290448: Double instantiation of RNG in CAAM Driver

These patches came from Steve Cornelius of STC and are to fix the RNG
instantiation problem in the CAAM driver. His comments:
    Add code to enable the "caam_probe" function to detect if the RNG
    has been instantiated and to skip the instantiation process if
    already completed.

Signed-off-by Jay Monkman <jay.monkman@freescale.com>
ENGR00290449: Cannot build CAAM as a loadable module

These patches come from Winston Hudson of STC and allow building CAAM
as a kernel module. His comments:
    This patch enables the CAAM driver to be built as a single LKM
    (Loadable Kernel Module). Individual components of the CAAM driver
    may be selected from the kernel configuration options, but a
    single monolithic "caam.ko" module is created. Adding or removing
    individual CAAM driver components requires that the module be
    recompiled, unloaded (rmmod caam.ko) then reloaded (insmod
    caam.ko), before the changes take affect. The option to build CAAM
    as part of the kernel is still available, but a kernel recompile
    and reboot is required before the changes take affect. The patch
    was created for the 3.0.x kernel.

    This patch also fixes an issue with the CAAM driver crashing with
    a kernel "opps" during driver initialization. The problem occurs
    when the CAAM RNG initialization fails and the "caam_remove()"
    function called. The driver attemps to release resources that have
    not been allocated. Checks have been added to ensure that resource
    allocation has occurred before attempting to release those
    resources.

Signed-off-by Jay Monkman <jay.monkman@freescale.com>
ENGR00286181 ARM: i.MX6: add more chip revision support

With the new tap-out of i.MX6DQ(TO1.5) and i.MX6DL/SOLO(TO1.2), we need add
more chip revision support in order to report the chip revision correctly.

Signed-off-by: Jason Liu <r64343@freescale.com>
ARM: 7668/1: fix memset-related crashes caused by recent GCC (4.7.2) optimizations

Recent GCC versions (e.g. GCC-4.7.2) perform optimizations based on
assumptions about the implementation of memset and similar functions.
The current ARM optimized memset code does not return the value of
its first argument, as is usually expected from standard implementations.

For instance in the following function:

void debug_mutex_lock_common(struct mutex *lock, struct mutex_waiter *waiter)
{
	memset(waiter, MUTEX_DEBUG_INIT, sizeof(*waiter));
	waiter->magic = waiter;
	INIT_LIST_HEAD(&waiter->list);
}

compiled as:

800554d0 <debug_mutex_lock_common>:
800554d0:       e92d4008        push    {r3, lr}
800554d4:       e1a00001        mov     r0, r1
800554d8:       e3a02010        mov     r2, #16 ; 0x10
800554dc:       e3a01011        mov     r1, #17 ; 0x11
800554e0:       eb04426e        bl      80165ea0 <memset>
800554e4:       e1a03000        mov     r3, r0
800554e8:       e583000c        str     r0, [r3, #12]
800554ec:       e5830000        str     r0, [r3]
800554f0:       e5830004        str     r0, [r3, #4]
800554f4:       e8bd8008        pop     {r3, pc}

GCC assumes memset returns the value of pointer 'waiter' in register r0; causing
register/memory corruptions.

This patch fixes the return value of the assembly version of memset.
It adds a 'mov' instruction and merges an additional load+store into
existing load/store instructions.
For ease of review, here is a breakdown of the patch into 4 simple steps:

Step 1
======
Perform the following substitutions:
ip -> r8, then
r0 -> ip,
and insert 'mov ip, r0' as the first statement of the function.
At this point, we have a memset() implementation returning the proper result,
but corrupting r8 on some paths (the ones that were using ip).

Step 2
======
Make sure r8 is saved and restored when (! CALGN(1)+0) == 1:

save r8:
-       str     lr, [sp, #-4]!
+       stmfd   sp!, {r8, lr}

and restore r8 on both exit paths:
-       ldmeqfd sp!, {pc}               @ Now <64 bytes to go.
+       ldmeqfd sp!, {r8, pc}           @ Now <64 bytes to go.
(...)
        tst     r2, #16
        stmneia ip!, {r1, r3, r8, lr}
-       ldr     lr, [sp], #4
+       ldmfd   sp!, {r8, lr}

Step 3
======
Make sure r8 is saved and restored when (! CALGN(1)+0) == 0:

save r8:
-       stmfd   sp!, {r4-r7, lr}
+       stmfd   sp!, {r4-r8, lr}

and restore r8 on both exit paths:
        bgt     3b
-       ldmeqfd sp!, {r4-r7, pc}
+       ldmeqfd sp!, {r4-r8, pc}
(...)
        tst     r2, #16
        stmneia ip!, {r4-r7}
-       ldmfd   sp!, {r4-r7, lr}
+       ldmfd   sp!, {r4-r8, lr}

Step 4
======
Rewrite register list "r4-r7, r8" as "r4-r8".

Signed-off-by: Ivan Djelic <ivan.djelic@parrot.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
(cherry picked from commit 455bd4c430b0c0a361f38e8658a0d6cb469942b5)
ARM: 7670/1: fix the memset fix

Commit 455bd4c430b0 ("ARM: 7668/1: fix memset-related crashes caused by
recent GCC (4.7.2) optimizations") attempted to fix a compliance issue
with the memset return value.  However the memset itself became broken
by that patch for misaligned pointers.

This fixes the above by branching over the entry code from the
misaligned fixup code to avoid reloading the original pointer.

Also, because the function entry alignment is wrong in the Thumb mode
compilation, that fixup code is moved to the end.

While at it, the entry instructions are slightly reworked to help dual
issue pipelines.

Signed-off-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Alexander Holler <holler@ahsoftware.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
(cherry picked from commit 418df63adac56841ef6b0f1fcf435bc64d4ed177)