s5p-mfc:gsc: increase IOMMU size from 256M to 512M

This is needed to run 4 instances of 1080p video.

BUG=None
TEST=Run 4 instances of mp4 files through browser on
separate windows. All 4 instances should continue playback.
Before:"[drm:exynos_gem_map_dma_buf] *ERROR* failed to map sgl with
iommu Error getting  dmabuf scatterlist"
After: 4 instances of video runs.

Change-Id: I01c8f4e9c0915752ea62ed96ad3f5b82172c8138
Signed-off-by: Kiran AVND <avnd.kiran@samsung.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/66185
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: kiran <kiran@chromium.org>
Tested-by: kiran <kiran@chromium.org>
UPSTREAM: ARM: tegra114: Reprogram GIC CPU interface to bypass IRQ on CPU PM entry

There is a difference between GICv1 and v2 when CPU in power management
mode (aka CPU power down on Tegra). For GICv1, IRQ/FIQ interrupt lines
going to CPU are same lines which are also used for wake-interrupt.
Therefore, we cannot disable the GIC CPU interface if we need to use same
interrupts for CPU wake purpose. This creates a race condition for CPU
power off entry. Also, in GICv1, disabling GICv1 CPU interface puts GICv1
into bypass mode such that incoming legacy IRQ/FIQ are sent to CPU, which
means disabling GIC CPU interface doesn't really disable IRQ/FIQ to CPU.

GICv2 provides a wake IRQ/FIQ (for wake-event purpose), which are not
disabled by GIC CPU interface. This is done by adding a bypass override
capability when the interrupts are disabled at the CPU interface. To
support this, there are four bits about IRQ/FIQ BypassDisable in CPU
interface Control Register. When the IRQ/FIQ not being driver by the
CPU interface, each interrupt output signal can be deasserted rather
than being driven by the legacy interrupt input.

So the wake-event can be used as wakeup signals to SoC (system power
controller).

To prevent race conditions and ensure proper interrupt routing on
Cortex-A15 CPUs when they are power-gated, add a CPU PM notifier
call-back to reprogram the GIC CPU interface on PM entry. The
GIC CPU interface will be reset back to its normal state by
the common GIC CPU PM exit callback when the CPU wakes up.

Based on the work by: Scott Williams <scwilliams@nvidia.com>

Signed-off-by: Joseph Lo <josephl@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
(cherry picked from commit 7e8b15dbc392cf3097f2d2e6dfbbf2e97318c553)
(cherry picked from
 git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git)

Conflicts:
	arch/arm/mach-tegra/irq.c

Change-Id: I04db856f9937188552c7dd7b85946005e347b0bd
Reviewed-on: https://gerrit.chromium.org/gerrit/64893
Tested-by: Joseph Lo <josephl@nvidia.com>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Olof Johansson <olofj@chromium.org>
UPSTREAM: ARM: tegra114: add low level support for CPU idle powered-down mode

The flow controller would take care the power sequence when CPU idle in
powered-down mode. It powered gate the CPU when CPU runs into WFI
instruction. And wake up the CPU when event be triggered.

The sequence is below.
* setting wfi bitmap for the CPU as the halt event in the
  FLOW_CTRL_CPU_HALT_REG to monitor the CPU running into WFI,then power
  gate it
* setting IRQ and FIQ as wake up event to wake up CPU when event triggered

Signed-off-by: Joseph Lo <josephl@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
(cherry picked from commit 1b9e6b2745621984b4aad49b0386814815fb15e7)
(cherry picked from
 git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git)

Change-Id: Ic041b072e4579cb6bbb1e0cc2f3d763921cba2ec
Reviewed-on: https://gerrit.chromium.org/gerrit/64894
Tested-by: Joseph Lo <josephl@nvidia.com>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Olof Johansson <olofj@chromium.org>
UPSTREAM: clk: exynos5250: Update cpufreq related clocks for EXYNOS5250

cpufreq driver for EXYNOS5250 is not a platform driver, hence we cannot
currently pass the clock names through a device tree node. Instead, we
need to make them available through a global alias.

cpufreq driver for EXYNOS5250 requires four clocks - 'armclk',
'mout_cpu', 'mout_mpll' and 'mout_apll'.

'armclk' has already been defined with an alias, 'mout_cpu', 'mout_mpll'
and 'mout_apll' are now defined with an alias.

Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>

BUG=chrome-os-partner:21952
TEST=boot on Spring, check in the kernel log that we no longer have
exynos_cpufreq initialization errors and see the CPU frequency going up
and down.

Change-Id: I397021e89059849f6ea605638b1c153f9651d535
Reviewed-on: https://gerrit.chromium.org/gerrit/65967
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
UPSTREAM: clk: exynos5250: Add sclk_mpll to the parent list of mout_cpu clock

'mout_mpll' is added the list of parent clocks for 'mout_cpu'.
'mout_mpll' is an alias to the clock 'sclk_mpll'. Hence 'sclk_mpll'
should be added to the list of parent clocks.

This results in an error when cpufreq driver for EXYNOS5250 tries to
set 'mout_mpll' as a parent for 'mout_cpu'.

clk_set_parent: clk sclk_mpll can not be parent of clk mout_cpu

Signed-off-by: Tushar Behera <tushar.behera@linaro.org>
Signed-off-by: Mike Turquette <mturquette@linaro.org>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>

BUG=chrome-os-partner:21952
TEST=boot on Spring, check in the kernel log that we no longer have
exynos_cpufreq initialization errors and see the CPU frequency going up
and down.

Change-Id: I803f99160948162c27f4b6954c4dfac89ab8dfb4
Reviewed-on: https://gerrit.chromium.org/gerrit/66225
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
CHROMIUM: clocksource: tegra: enable arch_timer

Architected timer is the local timer for Cortex-A15. Adding the support
for Tegra.

Note:
This patch was origianlly upstreamed for Kernel 3.8 but after talking
with "Rob Herring" who is moving the arch local timer to use CLKSRC_OF
init. That means we don't need this patch after Rob's patch is merged (It
was merged in Kernel 3.10). The link of the talking was below:
http://www.mail-archive.com/linux-tegra@vger.kernel.org/msg10034.html

BUG=none
TEST=checking the Architected local timer is running and system switching
     to timer-based delay loop

Change-Id: I94dbf9e62394f5fdce40cd91371515fd6111ec59
Signed-off-by: Joseph Lo <josephl@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/64161
Commit-Queue: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
UPSTREAM: ARM: tegra114: cpuidle: add powered-down state

This supports CPU core power down on each CPU when CPU idle. When CPU go
into this state, it saves it's context and needs a proper configuration
in flow controller to power gate the CPU when CPU runs into WFI
instruction. And the CPU also needs to set the IRQ as CPU power down idle
wake up event in flow controller.

Cc: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Joseph Lo <josephl@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
(cherry picked from commit 3045cb33eb6081a937d9a2873f5fb88d9fcb7900)
(cherry picked from
 git://git.kernel.org/pub/scm/linux/kernel/git/swarren/linux-tegra.git)

Conflicts:
	arch/arm/mach-tegra/cpuidle-tegra114.c

Change-Id: Ibd2545d370de1c66f2ac8a61be630a4af625a046
Reviewed-on: https://gerrit.chromium.org/gerrit/64895
Tested-by: Joseph Lo <josephl@nvidia.com>
Reviewed-by: Olof Johansson <olofj@chromium.org>
Commit-Queue: Olof Johansson <olofj@chromium.org>
CHROMIUM: dts: venice: venice: add cpu regulator node

Venice uses the TPS51632 as CPU regulator. The device is connected
on I2C5.

Add DT node for TPS51632.

Change-Id: If986ec8232f1d9b9fff5923b9bc33cab7d5dd516
Signed-off-by: Wei Ni <wni@nvidia.com>
Reviewed-on: https://gerrit.chromium.org/gerrit/66178
Commit-Queue: Olof Johansson <olofj@chromium.org>
Reviewed-by: Olof Johansson <olofj@chromium.org>
BACKPORT: drm/i915: Scale ring, rather than ia, frequency on Haswell

Haswell introduces a separate frequency domain for the ring (uncore). So
where we used to increase the CPU (IA) clock with GPU busyness, we now
need to scale the ring frequency directly instead. As the ring limits
our memory bandwidth, it is vital for performance that when the GPU is
busy, we increase the frequency of the ring to increase the available
memory bandwidth.

v2: Fix the algorithm to actually use the scaled gpu frequency for the ring.
v3: s/max_ring_freq/min_ring_freq/ as that is what it is

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jesse Barnes <jbarnes@virtuousgeek.org>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
[danvet: Add space checkpatch complained about.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
(cherry picked from commit 3ebecd07d382c022e93c560c56114eec1d6d2cdd)

BUG=None
TEST=This patch will boost graphical performance in Haswell, with the
     situation of memory intense high GPU usage and less of CPU.
     Because its hard to run heavy tests suite like phoronix
     in chrome-OS, the performance increase is validated by considering
     FPS as the test parameter on webgl experiment satisfying the
     above usage.

Change-Id: Ib8293aa92c9bed82246ecb2573b80dd279723933
Reviewed-on: https://gerrit.chromium.org/gerrit/63072
Tested-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Josh Triplett <josh@joshtriplett.org>
UPSTREAM: perf/arm: Fix armpmu_map_hw_event()

Fix constraint check in armpmu_map_hw_event().

Reported-and-tested-by: Vince Weaver <vincent.weaver@maine.edu>
Cc: <stable@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

BUG=chromium:275769
TEST=daisy build

Change-Id: I1e2a84c6019dff95d91734264c1e084ccca500b7
(cherry picked from commit b88a2595b6d8aedbd275c07dfa784657b4f757eb)
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66213
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
iio: isl29018: Add IR compensation for lux value

Since the isl29018 cannot sense much red on its lux channel, compensate by
adding in some of the IR channel value. This adds an iio channel for calibrating
what percentage of the IR value to add to the lux value when it's reported
through illuminance. When the new calibration channel
(in_illuminance1_calibscale) is equal to 0, there is no IR compensation.

BUG=chrome-os-partner:21723
TEST=manual on peach pit
	cd /sys/bus/iio/devices/iio\:device1/
	cat in_illuminance0_input ; cat illuminance0_input
	make sure values are the same
	echo 10 > in_illuminace1_calibscale
	cat in_illuminance0_input ; cat illuminance0_input
	make sure values are significantly larger than previous values

Change-Id: Ifbc99d2c394b3d83ed752ac42e8ff7308f72b078
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66035
Reviewed-by: YeongKu Cho <ykn.cho@samsung.com>
Commit-Queue: Bryan Freed <bfreed@chromium.org>
Reviewed-by: Bryan Freed <bfreed@chromium.org>
turbostat: Don't put unprocessed uapi headers in the include path

turbostat's Makefile puts arch/x86/include/uapi/ in the include path, so
that it can include <asm/msr.h> from it.  It isn't in general safe to
include even uapi headers directly from the kernel tree without
processing them through scripts/headers_install.sh, but asm/msr.h
happens to work.

However, that include path can break with some versions of system
headers, by overriding some system headers with the unprocessed versions
directly from the kernel source.  For instance:

In file included from /build/x86-generic/usr/include/bits/sigcontext.h:28:0,
                 from /build/x86-generic/usr/include/signal.h:339,
                 from /build/x86-generic/usr/include/sys/wait.h:31,
                 from turbostat.c:27:
../../../../arch/x86/include/uapi/asm/sigcontext.h:4:28: fatal error: linux/compiler.h: No such file or directory

This occurs because the system bits/sigcontext.h on that build system
includes <asm/sigcontext.h>, and asm/sigcontext.h in the kernel source
includes <linux/compiler.h>, which scripts/headers_install.sh would
filter out.

Since turbostat really only wants a single header, just include that one
header rather than putting an entire directory of kernel headers on the
include path.

In the process, switch from msr.h to msr-index.h, since turbostat just
wants the MSR numbers.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>

BUG=None
TEST=Together with the other patches in this series, successfully built
turbostat from this source tree in the ChromeOS build chroot.

LKML post: http://mid.gmane.org/20130810233627.GA8161@jtriplet-mobl1

Change-Id: I5848343a2d46053505f2e1cf4ac3fe87fbbfbc6c
Reviewed-on: https://gerrit.chromium.org/gerrit/66278
Tested-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Queue: Josh Triplett <josh@joshtriplett.org>
turbostat: Use GCC's CPUID functions to support PIC

turbostat uses inline assembly to call cpuid.  On 32-bit x86, on systems
that have certain security features enabled by default that make -fPIC
the default, this causes a build error:

turbostat.c: In function ‘check_cpuid’:
turbostat.c:1906:2: error: PIC register clobbered by ‘ebx’ in ‘asm’
  asm("cpuid" : "=a" (fms), "=c" (ecx), "=d" (edx) : "a" (1) : "ebx");
  ^

GCC provides a header cpuid.h, containing a __get_cpuid function that
works with both PIC and non-PIC.  (On PIC, it saves and restores ebx
around the cpuid instruction.)  Use that instead.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>

BUG=None
TEST=Together with the other patches in this series, successfully built
turbostat from this source tree in the ChromeOS build chroot.

LKML post: http://mid.gmane.org/20130811002546.GA10472@jtriplet-mobl1

Change-Id: I7823329826255b5d92efca1b40744de37745147e
Reviewed-on: https://gerrit.chromium.org/gerrit/66279
Tested-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Queue: Josh Triplett <josh@joshtriplett.org>
turbostat: Don't attempt to printf an off_t with %zx

turbostat uses the format %zx to print an off_t.  However, %zx wants a
size_t, not an off_t.  On 32-bit targets, those refer to different
types, potentially even with different sizes.  Use %llx and a cast
instead, since printf does not have a length modifier for off_t.

Without this patch, when compiling for a 32-bit target:

turbostat.c: In function 'get_msr':
turbostat.c:231:3: warning: format '%zx' expects argument of type 'size_t', but argument 4 has type 'off_t' [-Wformat]

Signed-off-by: Josh Triplett <josh@joshtriplett.org>

BUG=None
TEST=Together with the other patches in this series, successfully built
turbostat from this source tree in the ChromeOS build chroot.

LKML post: http://mid.gmane.org/20130810235518.GA9342@jtriplet-mobl1

Change-Id: Iee204b88b50d132c92325ce4e6d93fd84d6023a4
Reviewed-on: https://gerrit.chromium.org/gerrit/66280
Tested-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Reviewed-by: Mike Frysinger <vapier@chromium.org>
Commit-Queue: Josh Triplett <josh@joshtriplett.org>
turbostat: Check return value of fscanf

Some systems declare fscanf with the warn_unused_result attribute.  On
such systems, turbostat generates the following warnings:

turbostat.c: In function 'get_core_id':
turbostat.c:1203:8: warning: ignoring return value of 'fscanf', declared with attribute warn_unused_result [-Wunused-result]
turbostat.c: In function 'get_physical_package_id':
turbostat.c:1186:8: warning: ignoring return value of 'fscanf', declared with attribute warn_unused_result [-Wunused-result]
turbostat.c: In function 'cpu_is_first_core_in_package':
turbostat.c:1169:8: warning: ignoring return value of 'fscanf', declared with attribute warn_unused_result [-Wunused-result]
turbostat.c: In function 'cpu_is_first_sibling_in_core':
turbostat.c:1148:8: warning: ignoring return value of 'fscanf', declared with attribute warn_unused_result [-Wunused-result]

Fix these by checking the return value of those four calls to fscanf.

Signed-off-by: Josh Triplett <josh@joshtriplett.org>

BUG=None
TEST=Together with the other patches in this series, successfully built
turbostat from this source tree in the ChromeOS build chroot.

LKML post: http://mid.gmane.org/20130811003737.GA13053@jtriplet-mobl1

Change-Id: I033cfe67ca090e6fb11a45de38e21a434fdbd42d
Reviewed-on: https://gerrit.chromium.org/gerrit/66281
Tested-by: Josh Triplett <josh@joshtriplett.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Josh Triplett <josh@joshtriplett.org>
UPSTREAM: mm, sched: Drop voluntary schedule from might_fault()

might_fault() is called from functions like copy_to_user()
which most callers expect to be very fast, like a couple of
instructions.

So functions like memcpy_toiovec() call them many times in a loop.

But might_fault() calls might_sleep() and with CONFIG_PREEMPT_VOLUNTARY
this results in a function call.

Let's not do this - just call __might_sleep() that produces
a diagnostic for sleep within atomic, but drop
might_preempt().

Here's a test sending traffic between the VM and the host,
host is built with CONFIG_PREEMPT_VOLUNTARY:

 before:
	incoming: 7122.77   Mb/s
	outgoing: 8480.37   Mb/s

 after:
	incoming: 8619.24   Mb/s
	outgoing: 9455.42   Mb/s

As a side effect, this fixes an issue pointed
out by Ingo: might_fault might schedule differently
depending on PROVE_LOCKING. Now there's no
preemption point in both cases, so it's consistent.

Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1369577426-26721-10-git-send-email-mst@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
(cherry picked from commit 114276ac0a3beb9c391a410349bd770653e185ce)
Cherry picked from upstream's torvalds/linux.git/master

BUG=chrome-os-partner:21976
TEST=None (I guess some performance/responsiveness testing might be good?)

Change-Id: I8abf19bced3da42af28cc72c9bc736a2daa2d804
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66399
Reviewed-by: Doug Anderson <dianders@chromium.org>
ARM: dts: Avoid turning off the INT rail on rev3-5 of pit during S2R

There is an issue with some exynos5420 parts where turning off the INT
rail during S2R can cause issues.  Avoid doing it on rev 3, 4, and 5
boards where the SoCs haven't been screened to avoid the issue.

There may be some S3 power impact on rev3/rev4/rev5 boards, but there
seem to be enough boards that don't S2R at all that it's better to pay
the slight penalty.

BUG=chrome-os-partner:21228
BUG=chrome-os-partner:22082
TEST=Device that didn't suspend/resume now does
TEST=On rev 3.0 device, ran and saw '00 00 00 02' with:
  hexdump -C /proc/device-tree/*/*/*/BUCK3/regulator-op-mode

Change-Id: I9e01e3d44348e26831eea1a7f650da9485869b41
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66524
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: ARM: exynos: add pwm device to exynos5250

Change-Id: Id9fe9452a53300403e1bedb563701ee10882216d
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66421
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
CHROMIUM: ARM: exynos: snow: add backlight-pwm nodes

Also mark the PWM node as enabled.

Change-Id: I3e125be056cc1571c1ce82a2c8ae92d26e58c4e1
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/66422
Reviewed-by: Doug Anderson <dianders@chromium.org>
CHROMIUM: mwifiex: WARN when resetting card

When resetting the sdio card, log a warning using WARN_ON. This
will tell us which path triggered the warning (mwifiex_tx_timeout
vs. mwifiex_cmd_timeout_func). Additionally, it will enable us
to track the frequency of the issue using UMA stats and crash
reporting.

Signed-off-by: Mukesh Agrawal <quiche@chromium.org>
Signed-off-by: Paul Stewart <pstew@chromium.org>
Originally-reviewed-on: https://gerrit.chromium.org/gerrit/65639

BUG=chromium:270328
TEST=force reset (using gerrit.chromium.org/gerrit/38708), check dmesg

Change-Id: Ibcda3195383af5a63b55b359a55c171caed395ec
Reviewed-on: https://gerrit.chromium.org/gerrit/66569
Reviewed-by: Ashok Nagarajan <asnagarajan@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>