Revert "GPU: optimize build with -Ofast"

This reverts commit 40ce2e0ea294a41ee7a17fed07dd5fc31b04ee42.
Revert "makefile: build with -Ofast"

This reverts commit 30fbcf1182d07d73f62dd39f4f36257a25c36a81.
Revert "msm: mdss: Turn off backlight while power off"

This reverts commit 84692344583991d679c7c4e1f1bffe439f536bfe.
ARM: dts: msm: i2c: change clock rate to 19.2 MHz

For standard  requirement, I2C source
speed of 50MHz causes high power usage, hence
this patch change the clock rate to 19.2 MHz
to save power.

CRs-Fixed: 552956
Change-Id: Ifb17fb79062a390a19881d247a2ac0ca5cc55d80
Signed-off-by: Sana Venkat Raju <c_vsana@codeaurora.org>
Signed-off-by: flar2 <asegaert@gmail.com>
i2c-qup: Verify that mem resource exists prior to redirection

Redirection may cause a system crush in the case of a missing
memory resource specification. Now when reading a memory
resource from platform data, the return value is checked
before doing redirection on the resource.

Change-Id: Id4ef9c293f65935d6e3bd311720a1e66a2da8f35
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>
Signed-off-by: flar2 <asegaert@gmail.com>
qup_i2c: Handle scenario if runtime PM is disable

If  runtime PM is not supported, make sure
the I2C clock and GPIOs enabled at the start
of the transfer(RD/WR)
This is done by i2c_qup_pm_resume_runtime()

CRs-Fixed: 492194
Change-Id: Iaa901a0f0d0cd58318e3f6dd64e1db73c73b630f
Signed-off-by: Dilip Kota <c_dkota@codeaurora.org>
Signed-off-by: Sana Venkat Raju <c_vsana@codeaurora.org>
Signed-off-by: flar2 <asegaert@gmail.com>
i2c_qup: Improve implementation of PM callbacks

Refactor PM callbacks and remove redundant variable.
Add support for configuration of clockcontrol event.
Now the clock's state may be set by pm calls (as before)
or by a transfer's begining and ending.
Runtime-PM is still used in autosuspend configuration for
expensive NoC voting/unvoting since that may go to remote
processor.

CRs-Fixed: 592435
Change-Id: I54f7c67f768336f66765a04006b4c8e4734ac277
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>
Signed-off-by: Sagar Dharia <sdharia@codeaurora.org>
Signed-off-by: Sana Venkat Raju <c_vsana@codeaurora.org>

Conflicts:
	Documentation/devicetree/bindings/i2c/i2c-qup.txt
Signed-off-by: flar2 <asegaert@gmail.com>
qup_i2c: export qup_i2c_init_driver

Drivers like onsemi-ncp6335d and fan53555 are clients of i2c-qup driver.
In some targets, these clients have to initialize and probe early before
the i2c-qup driver is ready. Hence export qup_i2c_init_driver to make sure
i2c-qup driver is ready when its clients need to probe.

Change-Id: I0f866d1c4239f9c72f6753674c2283e97f3a3691
Signed-off-by: Ke Liu <keliu@codeaurora.org>
Signed-off-by: flar2 <asegaert@gmail.com>
i2c_qup: Fix for unhandled IRQ

I2C qup driver handle scenario where runtime
PM is not enabled and enables clocks explicitly.
But it checks runtime PM suspended state in ISR
routine before processing further which can lead to issue
of unhandled valid IRQ sometimes because I2C client
can initiate transaction very early after system
resume and runtime PM is not enabled.

Add atomic flag to synchronize between active transaction
request when clocks are enabled and ISR.

CRs-Fixed: 670480
Change-Id: I175bc29a7b5b6e713ab6ec28deb34b2b0d23fa8a
Signed-off-by: Sana Venkat Raju <c_vsana@codeaurora.org>
Signed-off-by: Alok Chauhan <alokc@codeaurora.org>
Signed-off-by: flar2 <asegaert@gmail.com>
qup_i2c: Initialize I2C resource before registering.

Due to mismatch in sequence of initializing the
I2C resources  and registering device,  issues seen
while probing clients. This patch corrects the sequence.

CRs-Fixed: 581007
Change-Id: I98f0e73ce1ed1213409d5700f7a78e722e451ec0
Signed-off-by: Sana Venkat Raju <c_vsana@codeaurora.org>

qup_i2c: Correct free memory call

Correct freeing of memory, which is allocated using
the devm prefixed API, to free it using devm_kfree rather
then kfree.

CRs-Fixed: 582597
Change-Id: If1aa9bcd86bb3a7d35adc5630ff19ad08bbdf762
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>

qup_i2c: dump gpio config on error

Dump the configuration of relevant GPIOs
on timeout error.

Change-Id: Iab5aa57befc146c232d12759990b0b8a23a68fe1
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>

qup_i2c: export qup_i2c_init_driver

Drivers like onsemi-ncp6335d and fan53555 are clients of i2c-qup driver.
In some targets, these clients have to initialize and probe early before
the i2c-qup driver is ready. Hence export qup_i2c_init_driver to make sure
i2c-qup driver is ready when its clients need to probe.

Change-Id: I0f866d1c4239f9c72f6753674c2283e97f3a3691
Signed-off-by: Ke Liu <keliu@codeaurora.org>

qup_i2c: improve PM functionality

Move system-PM functionality to noirq stage. Remove
the incorrect active-only clock path-voting setting.
Resolve synchronization of concurent transition of
system and runtime PM.

Change-Id: I2753557482da7a48a596e4b660165b4e2af0f854
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>

qup_i2c: support for configuarable noise rejection

allow to configure noise rejection value from device tree
which helps filter spikes in the i2c lines.

CRs-Fixed: 626250
Change-Id: If66132c8cc444294e4e6e275ece8b85108cf7abb
Signed-off-by: Ankit Gupta <ankgupta@codeaurora.org>

qup_i2c: Improve recovery from core and slave bad state

Unexpected noise, and/or unexpected behavior from a slave
may put the whole I2C bus in unworkable state. Clear I2C
bus state using HW command instead of bit-banging to avoid
assumption about GPIO recovery config.

Change-Id: I8d1d0002392f9ec9bc0db146aa0ce3e138334644
Signed-off-by: Gilad Avidov <gavidov@codeaurora.org>
Signed-off-by: flar2 <asegaert@gmail.com>
arm: hammerhead: gpiomux: Pull down the UART suspend gpio

This reduces leakage during use of bluetooth.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
ARM: bitops: prefetch the destination word for write prior to strex

The cost of changing a cacheline from shared to exclusive state can be
significant, especially when this is triggered by an exclusive store,
since it may result in having to retry the transaction.

This patch prefixes our atomic bitops implementation with prefetchw,
to try and grab the line in exclusive state from the start. The testop
macro is left alone, since the barrier semantics limit the usefulness
of prefetching data.

Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>

ARM: 7907/1: lib: delay-loop: Add align directive to fix BogoMIPS calculation

Currently mx53 (CortexA8) running at 1GHz reports:
Calibrating delay loop... 663.55 BogoMIPS (lpj=3317760)

Tom Evans verified that alignments of 0x0 and 0x8 run the two instructions of __loop_delay in one clock cycle (1 clock/loop), while alignments of 0x4 and 0xc take 3 clocks to run the loop twice. (1.5 clock/loop)

The original object code looks like this:

00000010 <__loop_const_udelay>:
  10:	e3e01000 	mvn	r1, #0
  14:	e51f201c 	ldr	r2, [pc, #-28]	; 0 <__loop_udelay-0x8>
  18:	e5922000 	ldr	r2, [r2]
  1c:	e0800921 	add	r0, r0, r1, lsr #18
  20:	e1a00720 	lsr	r0, r0, #14
  24:	e0822b21 	add	r2, r2, r1, lsr #22
  28:	e1a02522 	lsr	r2, r2, #10
  2c:	e0000092 	mul	r0, r2, r0
  30:	e0800d21 	add	r0, r0, r1, lsr #26
  34:	e1b00320 	lsrs	r0, r0, #6
  38:	01a0f00e 	moveq	pc, lr

0000003c <__loop_delay>:
  3c:	e2500001 	subs	r0, r0, #1
  40:	8afffffe 	bhi	3c <__loop_delay>
  44:	e1a0f00e 	mov	pc, lr

After adding the 'align 3' directive to __loop_delay (align to 8 bytes):

00000010 <__loop_const_udelay>:
  10:	e3e01000 	mvn	r1, #0
  14:	e51f201c 	ldr	r2, [pc, #-28]	; 0 <__loop_udelay-0x8>
  18:	e5922000 	ldr	r2, [r2]
  1c:	e0800921 	add	r0, r0, r1, lsr #18
  20:	e1a00720 	lsr	r0, r0, #14
  24:	e0822b21 	add	r2, r2, r1, lsr #22
  28:	e1a02522 	lsr	r2, r2, #10
  2c:	e0000092 	mul	r0, r2, r0
  30:	e0800d21 	add	r0, r0, r1, lsr #26
  34:	e1b00320 	lsrs	r0, r0, #6
  38:	01a0f00e 	moveq	pc, lr
  3c:	e320f000 	nop	{0}

00000040 <__loop_delay>:
  40:	e2500001 	subs	r0, r0, #1
  44:	8afffffe 	bhi	40 <__loop_delay>
  48:	e1a0f00e 	mov	pc, lr
  4c:	e320f000 	nop	{0}

, which now reports:
Calibrating delay loop... 996.14 BogoMIPS (lpj=4980736)

Some more test results:

On mx31 (ARM1136) running at 532 MHz, before the patch:
Calibrating delay loop... 351.43 BogoMIPS (lpj=1757184)

On mx31 (ARM1136) running at 532 MHz after the patch:
Calibrating delay loop... 528.79 BogoMIPS (lpj=2643968)

Also tested on mx6 (CortexA9) and on mx27 (ARM926), which shows the same
BogoMIPS value before and after this patch.

Reported-by: Tom Evans <tom_usenet@optusnet.com.au>
Suggested-by: Tom Evans <tom_usenet@optusnet.com.au>
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7404/1: cmpxchg64: use atomic64 and local64 routines for cmpxchg64

The cmpxchg64 routines for ARMv6+ CPUs replicate inline assembly that
already exists for atomic64 operations. Furthermore, the cmpxchg64 code
uses the "memory" constraint in the clobber list rather than identifying
the region of memory that is actually modified.

This patch replaces the ARMv6+ cmpxchg64 code with macros that expand to
the atomic64_ and local64_ variants, casting the pointer parameter to
the appropriate container type.

Cc: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7720/1: ARM v6/v7 cmpxchg64 shouldn't clear upper 32 bits of the old/new value

The implementation of cmpxchg64() for the ARM v6 and v7 architecture
casts parameter 2 and 3 (the old and new 64bit values) to an unsigned
long before calling the atomic_cmpxchg64() function. This clears
the top 32 bits of the old and new values, resulting in the wrong
values being compare-exchanged. Luckily, this only appears to be used
for 64-bit sched_clock, which we don't (yet) have on ARM.

This bug was introduced by commit 3e0f5a15f500 ("ARM: 7404/1: cmpxchg64:
use atomic64 and local64 routines for cmpxchg64").

Cc: <stable@vger.kernel.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Jaccon Bastiaansen <jaccon.bastiaansen@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7852/1: cmpxchg: implement barrier-less cmpxchg64_local

Our cmpxchg64 macros are wrappers around atomic64_cmpxchg. Whilst this is
great for code re-use, there is a case for barrier-less cmpxchg where it
is known to be safe (for example cmpxchg64_local and cmpxchg-based
lockrefs).

This patch introduces a 64-bit cmpxchg implementation specifically
for the cmpxchg64_* macros, so that it can be later used by the lockref
code.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7853/1: cmpxchg: implement cmpxchg64_relaxed

This patch introduces cmpxchg64_relaxed for arm, which performs a 64-bit
cmpxchg operation without barrier semantics. cmpxchg64_local is updated
to use the new operation.

Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

ARM: 7984/1: prefetch: add prefetchw invocations for barriered atomics

After a bunch of benchmarking on the interaction between dmb and pldw,
it turns out that issuing the pldw *after* the dmb instruction can
give modest performance gains (~3% atomic_add_return improvement on a
dual A15).

This patch adds prefetchw invocations to our barriered atomic operations
including cmpxchg, test_and_xxx and futexes.

Change-Id: Id6ebfe82ff9578c27e2b745e2cce167200112606
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
cpuidle: check for need_resched() after the idle entry trace event

trace_cpu_idle_rcuidle() can end up waking ksoftirqd under certain
conditions. Since there is no check for need_resched() following
this wake up, the cpu ends up going into an idle state despite there
being a runnable task on that runqueue. Furthermore, since the
resched flag is set, any sucessive waking up tasks on the idle cpu
will not result in an IPI being sent to that cpu. Consequently tasks
on that runqueue will starve until the cpu exits idle by itself. Fix
this problem by adding a need_resched() check after the idle entry
trace event.

A side effect of this change is that the idle trace entry and exit
event may be recorded for an extremely short duration even though
the cpu does not actually enter idle.

Change-Id: I370c39a1e39ecd829e44ac783b4888a00ab05eae
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
ARM: gic: use a private mapping for CPU target interfaces

The GIC interface numbering does not necessarily follow the logical
CPU numbering, especially for complex topologies such as multi-cluster
systems.

Fortunately we can easily probe the GIC to create a mapping as the
Interrupt Processor Targets Registers for the first 32 interrupts are
read-only, and each field returns a value that always corresponds to
the processor reading the register.

Initially all mappings target all CPUs in case an IPI is required to
boot secondary CPUs.  It is refined as those CPUs discover what their
actual mapping is.

Signed-off-by: Nicolas Pitre <nico@linaro.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
ARM: gic: Bring inline with upstream

Change-Id: Ic2cce8da16c81b9448e1f2ea8813ae05b48f1e31

ARM: gic: fix restore order of distributor registers in gic_cpu_restore()

Similar to gic_dist_restore(), the GIC config, priority and enable
registers should be restored in that order. Fix this in gic_cpu_restore()
which currently restores the enable registers before the configuration
registers.

Change-Id: Ib75640849bef81aa87a3b110fe1bd7ea4371d659
Signed-off-by: Osvaldo Banuelos <osvaldob@codeaurora.org>

ARM: GIC: fix GIC cpumask initialization

Punit Agrawal reports:
> I was trying to boot 3.8-rc5 on Realview EB 11MPCore using
> realview-smp_defconfig as a starting point but the kernel failed to
> progress past the log below (config attached).
>
> Pawel suggested I try reverting 384a290283f - "ARM: gic: use a private
> mapping for CPU target interfaces" that you've authored. With this
> commit reverted the kernel boots.
>
> I am not quite sure why the commit breaks 11MPCore but Pawel (cc'd)
> might be able to shed light on that.

Some early GIC implementations return zero for the first distributor
CPU routing register.  This means we can't rely on that telling us
which CPU interface we're connected to.  We know that these platforms
implement PPIs for IRQs 29-31 - but we shouldn't assume that these
will always be populated.

So, instead, scan for a non-zero CPU routing register in the first
32 IRQs and use that as our CPU mask.

Change-Id: I264edd7273353e300d7d1ef096709f9d87b9ec78
Reported-by: Punit Agrawal <punit.agrawal@arm.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

irqchip: gic: Perform the gic_secondary_init() call via CPU notifier

All the calls to gic_secondary_init() pass 0 as the first argument.
Since this function is called on each CPU when starting, it can be done
in a platform-independent way via a CPU notifier registered by the GIC
code.

Change-Id: I729e09097230eb2f93fb730f1d58a279c5ef51f8
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Acked-by: Rob Herring <rob.herring@calxeda.com>
Acked-by: Simon Horman <horms+renesas@verge.net.au>
Tested-by: Simon Horman <horms+renesas@verge.net.au>
Acked-by: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Tested-by: Dinh Nguyen <dinguyen@altera.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Marc Zyngier <marc.zyngier@arm.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: David Brown <davidb@codeaurora.org>
Cc: Bryan Huntsman <bryanh@codeaurora.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Shiraz Hashim <shiraz.hashim@st.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Barry Song <baohua.song@csr.com>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
ARM: fix user unalignment prefetch abort

Branching to an address in ARM state which is not
word aligned, where this is defined to be UNPREDICTABLE,
can cause one of the following two behaviours: 1. The
unaligned location is forced to be aligned. 2. Using
the unaligned address generates a Prefetch Abort on the
first instruction using the unaligned PC value.

To be consistant for the user space binaries, the
unaligned location is forced aligned with this config.

Change-Id: I30eb9e5ffd886b746a46ff0ba1b0279e578fc201
Signed-off-by: Maria Yu <aiquny@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
blu_plug: use input boost, __ref to lighten the driver, misc fixes