ARM: dts: Disable FIMD dithering for peach-pi variants

Peach-pi boards have eDP panels which support RGB6(+FRC data driver),
and hence we need not enable FIMD dithering.

This patch removes FIMD DT properties related to dithering
from exynos542x.dtsi and distributes it across peach-pit dtsi,
but not for peach-pi since we don't need dithering on peach-pi.

BUG=chrome-os-partner:25532
TEST=Boot on all peach boards. Ensure no color bands
     are observed while viewing a gradient image.
     armio 14400170 = 0, on peach-pi(Dithering disabled)
     armio 14400170 = 0x2B, on peach-pit(RGB666 Dithering enabled)

Change-Id: I01ce4f559ee390c1b67920617459660dac983048
Signed-off-by: Ajay Kumar <ajaykumar.rs@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/185164
Reviewed-by: Jaehoon Kim <jh228.kim@samsung.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Dominik Behr <dbehr@chromium.org>
Tested-by: Jaehoon Kim <jh228.kim@samsung.com>
Commit-Queue: Jaehoon Kim <jh228.kim@samsung.com>
cpufreq: exynos5420: Increase max A15 frequency from EVT2 sample

exynos5420 EVT2 samples can support 1.9Ghz as A15 MAX frequency.
In case of EVT0 and EVT1 samples, just over 90% of the samples will
work properly at 1.9GHz.
Hence we increase A15 MAX frequency from EVT2 sample onwards.

BUG=chrome-os-partner:25473
TEST=Run on exynos 5420 EVT1 and EVT2 and see A15 frequency increasing
     up to 1.8GHz and 1.9GHz respectively.

Change-Id: I9b3faa38f63e4efc8e4e3620a51c9565f16a78fd
Signed-off-by: Jaehoon Kim <jh228.kim@samsung.com>
Signed-off-by: Arjun.K.V <arjun.kv@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/184821
Reviewed-by: Doug Anderson <dianders@chromium.org>
Tested-by: Wonjoon Lee <woojoo.lee@samsung.com>
UPSTREAM: eCryptfs: Use the ablkcipher crypto API

Make the switch from the blkcipher kernel crypto interface to the
ablkcipher interface.

encrypt_scatterlist() and decrypt_scatterlist() now use the ablkcipher
interface but, from the eCryptfs standpoint, still treat the crypto
operation as a synchronous operation. They submit the async request and
then wait until the operation is finished before they return. Most of
the changes are contained inside those two functions.

Despite waiting for the completion of the crypto operation, the
ablkcipher interface provides performance increases in most cases when
used on AES-NI capable hardware.

BUG=chrome-os-partner:23189, chrome-os-partner:25419
TEST=booted on peach_pit. login to see the /home/chronos/user/Downloads
being created. We should able to cp, rm, dd on to
/home/chronos/user/Downloads.

Signed-off-by: Tyler Hicks <tyhicks@canonical.com>
Acked-by: Colin King <colin.king@canonical.com>
Reviewed-by: Zeev Zilberman <zeev@annapurnaLabs.com>
Cc: Dustin Kirkland <dustin.kirkland@gazzang.com>
Cc: Tim Chen <tim.c.chen@intel.com>
Cc: Ying Huang <ying.huang@intel.com>
Cc: Thieu Le <thieule@google.com>
Cc: Li Wang <dragonylffly@163.com>
Cc: Jarkko Sakkinen <jarkko.sakkinen@iki.fi>
(cherry picked from commit 4dfea4f0d7f13309d2ee112a2584210cae4320c6)

Signed-off-by: Naveen Krishna Ch <ch.naveen@samsung.com>

Conflicts:
	fs/ecryptfs/crypto.c

Change-Id: I0a9c1978f0f91180b7dd091643d2c74ac3575943
Reviewed-on: https://chromium-review.googlesource.com/184350
Reviewed-by: naveen krishna <naveen@chromium.org>
Commit-Queue: naveen krishna <naveen@chromium.org>
Tested-by: naveen krishna <naveen@chromium.org>
arm: dts: exynos542x: add mfc device tree node

MFC is changes between 5420 and 5422, 5420 is using MFCv7.2
and 5422 uses MFCv8.0, this patch refactor mfc node to be
used by 5422 and 5420 SoCs.

BUG=chrome-os-partner:24687
TEST=build and booted on pit and pi, /w other CLs can play video

Change-Id: Ie46521ea235d772011158ca55a37da01d3bd2e5a
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/182123
Reviewed-by: Pawel Osciak <posciak@chromium.org>
UPSTREAM: mmc: core: move the cache disabling operation to mmc_suspend

Cache control is an eMMC feature and in therefore should be
part of MMC's bus resume operations, performed in mmc_suspend,
rather than in the generic mmc_suspend_host().

BUG=chrome-os-partner:25299
TEST=build and booted on pit/pi, /w other CLs in this serise, cache_ctrl
     does work well.
TEST=suspend_stree_test multiple time

Signed-off-by: Maya Erez <merez@codeaurora.org>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
(cherry picked from commit 881d926d9d0bd2eb50f8f90c993bc403853382ce)

Change-Id: Ib8e991d96b99eb85522a32305c25a740317103e1
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/185655
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
BACKPORT: mmc: core: Use mmc_flush_cache() during mmc suspend

Earlier we disabled the cache during suspend, which meant a flush was
internally at the eMMC performed as well.

To simplify code we can make use of the mmc_flush_cache(), during mmc
suspend, which makes the mmc_cache_ctrl() redundant so then we can
remove it.

BUG=chrome-os-partner:25299
TEST=build and booted on pit/pi
     /w this patch emmc write perormance in as below:
     ~ # time dd if=/dev/zero of=/usr/local/100 bs=1M count=100
     conv=fdatasy
     100+0 records in
     100+0 records out
     104857600 bytes (105 MB) copied, 2.16756 s, 48.4 MB/s
     real    0m2.279s
     user    0m0.000s
     sys     0m0.685s
     /wo this CLs, the performace is a below:
     ~ # time dd if=/dev/zero of=/usr/local/100 bs=1M count=100
     conv=fdatasync
     100+0 records in
     100+0 records out
     104857600 bytes (105 MB) copied, 2.87583 s, 36.5 MB/s
TEST= ran mmc_test, all passed except 38 and 42
TEST= ran suspend_stree_test

Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Seungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Change-Id: I5fc75aa6d8b393067b57e46edb37ed71c329ac96
Reviewed-on: https://chromium-review.googlesource.com/183921
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
CHROMIUM: mmc: core: Enable MMC_CAP2_CACHE_CTRL as default

There are no reason to why the use of a non-volatile internal eMMC
cache should be controlled by a host cap. Instead let's just enable it
if the eMMC card supports it.

BUG=chrome-os-partner:25299
TEST=build and booted on pit/pi
     /w this patch emmc write perormance in as below:
     ~ # time dd if=/dev/zero of=/usr/local/100 bs=1M count=100
     conv=fdatasy
     100+0 records in
     100+0 records out
     104857600 bytes (105 MB) copied, 2.16756 s, 48.4 MB/s
     real    0m2.279s
     user    0m0.000s
     sys     0m0.685s
     /wo this CLs, the performace is a below:
     ~ # time dd if=/dev/zero of=/usr/local/100 bs=1M count=100
     conv=fdatasync
     100+0 records in
     100+0 records out
     104857600 bytes (105 MB) copied, 2.87583 s, 36.5 MB/s

TEST= Ran mmc_test, all passed, except 38 and 42.
TEST= Ran suspend_stress_test

Change-Id: Ide9c6157a9e21cb33ba56f59d22d5707f1013843
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
Acked-by: Seungwon Jeon <tgih.jun@samsung.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/183922
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Grant Grundler <grundler@chromium.org>
ARM: dts: exynos542x: enable SDR104 for wifi cards

Pit/pi wifi can support SDR104 mode operations, let enable the same.
This also change the drv-strength of clk/cmd/data line to 2x from
current setting of 1x. 2x drive strength is need to support high speed
operations.

BUG=chrome-os-partner:25364
TEST=build and boot on pi
     can see card is detcted as SDR104 SDIO card.
     	localhost ~ # cat /sys/kernel/debug/mmc1/ios
	clock:          200000000 Hz
	vdd:            20 (3.2 ~ 3.3 V)
	bus mode:       2 (push-pull)
	chip select:    0 (don't care)
	power mode:     2 (on)
	bus width:      2 (4 bits)
	timing spec:    6 (sd uhs SDR104)
	signal voltage: 0 (1.80 V)

Signed-off-by: Yuvaraj Kumar CD <yuvaraj.cd@samsung.com>
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>

Change-Id: Id037a31859772e8f0eb3e87bb228e805b0f7d1c0
Reviewed-on: https://chromium-review.googlesource.com/184120
Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
Commit-Queue: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
clock: exynos542x: Fix aclk400_wcore clock hierarchy

Exynos5422 does not have sclk_bpll as a source to dout_aclk400_core
unlike 5420. Fix this.

BUG=chrome-os-partner:25272
TEST=Build and boot on peach_pit/pi
On peach_pit:
$ cat /sys/kernel/debug/clk/clk_summary | grep wcore

mout_aclk400_wcore      0	0	666000000
mout_aclk400_wcore_bpll 0	0	666000000
dout_aclk400_wcore      0	0	83250000
mout_sw_aclk400_wcore   0	0	83250000
mout_user_aclk400_wcore 0	0	83250000

On peach_pi:
$ cat /sys/kernel/debug/clk/clk_summary | grep wcore

mout_aclk400_wcore      0	0	666000000
dout_aclk400_wcore      0	0	333000000
mout_sw_aclk400_wcore   0	0	333000000
mout_sw_aclk400_wcore   0	0	333000000

Change-Id: If3b47b6ebb288196a88e30032db54ba1b7168e4c
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/184652
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
clock: exynos542x: Add CAM block clocks

This patch adds missing clocks for CAM block, this is a new block added
in 5422. We are adding this so that we can clock gate this block when
not in use.

BUG=chrome-os-partner:24687
TEST=build and booted on pi, /w this patch can see cam block is clock
	gated
	localhost ~ # armio 0x10020700
	10020700:80fededf

	/wo this patch, clock to CAM block is ON
	localhost ~ # armio 0x10020700
	10020700:8ffededf

Change-Id: Ifb18a478cfe8c037b8627ef42ffd63553e3c6014
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/184792
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
UPSTREAM: ARM: add permission annotations to MT_MEMORY* mapping types

Document the permissions which the various MT_MEMORY* mapping types
will provide.

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

BUG=chromium:341583
TEST=daisy_spring build/boot

Change-Id: Ida5b07e9657557f1863a44079b3ae7191dcac029
(cherry picked from commit 2e2c9de207be043ee80161971c814d740759d3bc)
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185483
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: David James <davidjames@chromium.org>
UPSTREAM: ARM: implement basic NX support for kernel lowmem mappings

Add basic NX support for kernel lowmem mappings.  We mark any section
which does not overlap kernel text as non-executable, preventing it
from being used to write code and then execute directly from there.

This does not change the alignment of the sections, so the kernel
image doesn't grow significantly via this change, so we can do this
without needing a config option.

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

BUG=chromium:341583
TEST=daisy_spring build/boot

Change-Id: I16b3ac1a070f041757582f233a6978f7e1ac5bf9
(cherry picked from commit ebd4922ecc38e31e662cd641dd04099a9652c9b3)
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185484
Reviewed-by: Olof Johansson <olofj@chromium.org>
UPSTREAM: ARM: add definitions for pte_mkexec/pte_mknexec

Other architectures define pte_mkexec to mark a pte as executable.
Add pte_mkexec for ARM to get the same functionality. Although no
other architectures currently define it, also add pte_mknexec to
explicitly allow a pte to be marked as non executable.

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

BUG=chromium:341583
TEST=daisy_spring build/boot

Change-Id: Ib03d7f310b25271f02b0ab99a2667a48567a650f
(cherry picked from commit 27ec8da4ace46900a71b8462157aa2bc88ff5d2c)
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185485
Reviewed-by: Olof Johansson <olofj@chromium.org>
UPSTREAM: ARM: mm: Define set_memory_* functions for ARM

Other architectures define various set_memory functions to allow
attributes to be changed (e.g. set_memory_x, set_memory_rw, etc.)
Currently, these functions are missing on ARM. Define these in an
appropriate manner for ARM.

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

BUG=chromium:341583
TEST=daisy_spring build/boot

Change-Id: Id73c11e2434b35674baa76fc459f1fc980105c53
(cherry picked from commit 75374ad47c6465de6c098d7b913fe02d6131195c)
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185486
Reviewed-by: Olof Johansson <olofj@chromium.org>
UPSTREAM: ARM: add DEBUG_SET_MODULE_RONX option to Kconfig

Now that all the page setting infrastructure is in place,
Add the DEBUG_SET_MODULE_RONX to the ARM debugging Kconfig.
When turned on, data sections for modules will be marked as NX
and read only sections will be marked as such.

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

BUG=chromium:341583
TEST=daisy_spring build/boot

Change-Id: I80a8ef0ca3f85d0042b4222059e857765a5c373c
(cherry picked from commit dca9aa92fc7caa3620b31ced1535968f4aeeb967)
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185487
Reviewed-by: Olof Johansson <olofj@chromium.org>
UPSTREAM: ARM: fix executability of CMA mappings

The CMA region was being marked executable:

0xdc04e000-0xdc050000           8K     RW x      MEM/CACHED/WBRA
0xdc060000-0xdc100000         640K     RW x      MEM/CACHED/WBRA
0xdc4f5000-0xdc500000          44K     RW x      MEM/CACHED/WBRA
0xdcce9000-0xe0000000       52316K     RW x      MEM/CACHED/WBRA

This is mainly due to the badly worded MT_MEMORY_DMA_READY symbol, but
there are also a few other places in dma-mapping which should be
corrected to use the right constant.  Fix all these places:

0xdc04e000-0xdc050000           8K     RW NX     MEM/CACHED/WBRA
0xdc060000-0xdc100000         640K     RW NX     MEM/CACHED/WBRA
0xdc280000-0xdc300000         512K     RW NX     MEM/CACHED/WBRA
0xdc6fc000-0xe0000000       58384K     RW NX     MEM/CACHED/WBRA

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

BUG=chromium:341583
TEST=daisy_spring build/boot

Change-Id: I02066618a872dde9877a808cfda5fe3880e8cb03
(cherry picked from commit 71b55663c5d0a6f8473045db1c8b376803780191)
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185488
Reviewed-by: Olof Johansson <olofj@chromium.org>
MALI: platform/chromebook: exynos5422: Add 543MHz support

Add support for 543MHz on Exynos5422. We were not using 533 MHz
on 5420 even though it was available because we were not hitting this
level for most benchmarks. The existent 5420 support can be re-used
without any changes for 5422 as the only difference between the two
is 533->543 but for now I have added a new table for 5422.

BUG=chrome-os-partner:25272
TEST=Build and boot on peach_pi. With a u-boot patch setting the
default rate to 420MHz do the follwing:

$ cd /sys
$ cat ./bus/platform/drivers/mali/11800000.mali/asv
asv group:4 mp6
543000000:975000
543000000:975000
480000000:925000
420000000:887500
350000000:862500
266000000:837500
177000000:775000
100000000:775000

$ cat ./bus/platform/drivers/mali/11800000.mali/clock
100000000

$ cat ./bus/platform/drivers/mali/11800000.mali/vol
Current operating voltage for mali t6xx = 775000

$ echo off > /sys/bus/platform/drivers/mali/11800000.mali/dvfs
G3D DVFS is disabled

$ cat /sys/bus/platform/drivers/mali/11800000.mali/clock
420000000

$ cat /sys/class/regulator/regulator.40/microvolts
887500

Change-Id: Ifc86d87a26b3d0597f3d493982eb43d0bf36f1a4
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/183415
Reviewed-by: Doug Anderson <dianders@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
devfreq: exynos5420: Fix clock transitions when the PLL changes

Clock transitions when the source PLL changed were totally broken.
Overall there was a lot of confusion in the file about which clock was
the parent clock and which parent was the child clock.  Fix this by
renaming the clocks to "div_clk" and "mux_clk".  After doing this, fix
a number of issues around transition.

Quick summary of fixes:

* Handle parenting properly by setting the "mux" clock.  Don't try to
  set the parent of the div clock and don't try to set the div to be
  the parent of the mux (it's the opposite).
* Avoid ever over-clocking even for a short period of time.  With a
  future 5420 table fix, the old code was found to make the following
  transitions when switching aclk266 from DPLL to MPLL:
  85714285=>150000000=>200000000=>160000000.  We now transition like:
  85714285=>120000000=>160000000
* Fix the "SW_MUX" clock source handling.  Really this was just
  setting the source PLL to "SPLL", but the old code was skipping all
  the code to adjust dividers.  There's nothing magical about SPLL
  that makes setting the divider unnecessary, so remove that old
  special case code and rename "SW_MUX" to "SPLL".  Note that all
  devfreq levels that use this are currently disabled, so the old code
  wasn't a huge problem.
* Avoid including the (incorrect) <plat/clock.h>, which is the
  pre-common-clock header file.  By removing this header you can
  define the proper concrete "struct clk" temporarily while debugging.

BUG=chrome-os-partner:25272
TEST=(With other patches in this series), boot on Pit and Pi:
- See devfreq working.
- Verify the clock values and the parent set and see new
  changes taking effect on Pit.
- Run V8, Video, WebGL and S2R without issues.

Change-Id: I42c93f16375194679d733be9f3424c55ee8fee70
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185932
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Arjun K V <arjun.kv@samsung.com>
devfreq: exynos5420: Correct clock values for aclk266, aclk100_noc, aclk400_isp

While adding the recent 3.30 version of DVFS, we found few values in the devfreq
clock values which missed being updated from the previous 2.50 DVFS release.
So, correct the clock values and change the parent as required
for these clocks.
aclk266
aclk100_noc
aclk400_isp

BUG=chrome-os-partner:25272
TEST=Boot on Pit and Pi. See devfreq working.
Verify the clock values and the parent set and see new
changes taking effect on Pit.
Run V8, Video, WebGL and S2R without issues.

Change-Id: I04c913360cfcabecd89a89d8380d9ff0a4922fee
Signed-off-by: Arjun.K.V <arjun.kv@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/185649
Commit-Queue: Abhilash Kesavan <a.kesavan@samsung.com>
exynos542x: devfreq: Add support for Exynos5422

The current devfreq table has support till 420MHz for UHD. We
are restricting support till 400MHz in line with 2GHz ARM support.
500 and 600MHz levels have been added for backward compatibility
with 5420. The 500MHz level added actually holds the values needed
to run the bus at 420MHz.
We are removing 222MHz support till we have locking for MMC which
requires INT@333MHz.

BUG=chrome-os-partner:25272
TEST=Verify that 333 and 400MHz are being exercised.
$ cat /sys/class/devfreq/exynos5420-devfreq-int/available_frequencies
333000 400000

$ cat /sys/class/devfreq/exynos5420-devfreq-int/cur_freq
333000

$ cat /sys/class/devfreq/exynos5420-devfreq-int/time_in_state/int_time_in_state
600000 0
500000 0
400000 56
333000 2451
222000 0
111000 0
83000 0

Change-Id: Ib2c75ddf3b7c35d2cb0240fa5ccf35d69ce6fd76
Signed-off-by: Abhilash Kesavan <a.kesavan@samsung.com>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/183417
Reviewed-by: Andrew Bresticker <abrestic@chromium.org>