ARM: Speed up page list initialization during boot

During boot, we populate the page lists by using the page freeing
mechanism on every individual page.  Unfortunately, this is very
inefficient because the memory manager spends a lot of time coalescing
pairs of adjacent free pages into bigger blocks.

Rather than adding a single page at a time, we can take advantage of the
fact that we know that all the pages are available and free up big
blocks of pages at a time instead.

This reduces boot time by 260ms on pit and 560ms on pi.

BUG=chrome-os-partner:25476
TEST=platform_BootPerf

Change-Id: Ib12bf17b66f18677b41d215e527aa0cd2e1f60be
Signed-off-by: Chirantan Ekbote <chirantan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188971
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
exynos5420: devfreq: Make INT voltage constant for all levels

DVFS version 3.50 recommends fixed INT voltage(of 400MHz level)
to be applied for all levels.
This patch locks voltage of all levels at the L2(400MHz) level
of that particular ASV group, instead of having to populate the
table with same values.

BUG=chrome-os-partner:26681
TEST=Boot on Pit and see INT voltage remain constant while
switching levels.
TEST=Boot on Pi and see no effect of this CL.

Change-Id: I5bddeac13d8361991f9063c4108be894c06e560a
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/188700
exynos542x: ASV: Add DVFS version 2.60 values

Adds DVFS table v2.60 values for exynos5422.
Changes in this version:
 * Decrease of 25mv on ASV group 9 and above
 * Makes MIF and MIFS voltage as 1V across ASV group
 * Change ABB set (RBB -> BYPASS) for ASV 9+ groups.

This also update DVFS table version 3.4 for exynos5420.
Changes in this version:
 * Makes MIF and MIFS voltage as 1V across ASV group

BUG=chrome-os-partner:26684
TEST=build and booted on pit/pi, run s2r, no side effect.
     * Also as the changes are for ASV9+ group, and we dont
       have any board with ASV9+, so not varified on ASV9 groups.
     * And we do not change the MIF voltage in kernel, so the
       second change should not harm.
     * /wo CL:188470
     localhost ~ # cat /sys/class/regulator/regulator.37/microvolts
     1000000
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>

Change-Id: I7f8ae6c622631ccee1cd171d3b1bd2eae7136342
Reviewed-on: https://chromium-review.googlesource.com/189025
Reviewed-by: Abhilash Kesavan <a.kesavan@samsung.com>
Tested-by: Alim Akhtar <alim.akhtar@samsung.com>
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
CHROMIUM: dts: exynos542x: Add world-wide txpwrlimit table for Marvell SD8897

This tx power table is downloaded to firmware during driver
initialization.

BUG=chrome-os-partner:26358
TEST=measure 11b/g/a tx power on different channels and matches
the txpwrlimit table

Change-Id: I76bffbe24328594f3d0582ce37c48e5a62d0aecb
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Reviewed-on: https://chromium-review.googlesource.com/189452
Reviewed-by: hyuckjoo lee <hyuckjoolee345@gmail.com>
Tested-by: hyuckjoo lee <hyuckjoolee345@gmail.com>
Reviewed-by: Paul Stewart <pstew@chromium.org>
drm/exynos: export the DDC i2c for hdmi

This is useful for debugging, and also for poking the DDC.

BUG=chromium:349356
TEST=boot on daisy, check for the presence of /sys/class/drm/card0-HDMI-1/i2c-* adapter

Change-Id: I0e6b7ba62d10fcbcebf9bf6fbee141b5a96ebee9
Reviewed-on: https://chromium-review.googlesource.com/189501
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
drm/exynos: get rid of flush_work() in dp poweroff

there is a deadlock between waiting for the
mode_config mutex and waiting for a synchronous
flush_work. Since all the worker ever does here
is return true, that doesn't really require
synchronous flushing, removing it reolves the
deadlock.

BUG=chrome-os-partner:26340
TEST= Boot, Login with/without hdmi connected,
      # set_short_timeouts
        wait for the system to suspend(led blinking or red)
        resume the system by pressing any key.
TEST= suspend_stress_test
TEST= hotplugging

Change-Id: Id78256c19ab71410576a750c3ac3fee335bb84d3
Signed-off-by: Shirish S <s.shirish@samsung.com>
Signed-off-by: Prathyush K <prathyush.k@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/189215
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
drm: Remove part of the HDTV hack

It breaks a toshiba TV here.

BUG=chrome-os-partner:25675
TEST=on zako with the toshiba TV, test that 1360x765 now works

Change-Id: Ia754cd8e0b5d051a52b7eb2eb4f50b5664d9605c
Reviewed-on: https://chromium-review.googlesource.com/189246
Tested-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Commit-Queue: Stéphane Marchesin <marcheu@chromium.org>
UPSTREAM: brcmfmac: Update driver to support 802.11AC device

This is a collection of patches including but not limited
to the following:

brcmfmac: Give priority to 5GHz band in selecting target BSS
brcmfmac: Improve scanning settings for connect
brcmfmac: revamp nl80211 testmode callback
brcmfmac: reset suspend flag upon sdio suspend failure
brcmfmac: assure active clock request upon entering SLEEP state
brcmfmac: Protect tx seq number for data and control
brcmfmac: use pre-allocated scatter-gather table for txglomming
brcmfmac: Correct mcs index report
brcmfmac: Put frame sdio tx error handling in sub function
brcmfmac: Use atomic functions for intstatus update
brcmfmac: Small cleanup of redundant code
brcmfmac: Remove immediate sleep support from SDIO
brcmfmac: Minimize SDIO dpc scheduling
brcmfmac: de-init driver layers in correct order
brcmfmac: ... ...

Signed-off-by: Daniel Kim <dekim@broadcom.com>
BUG=chrome-os-partner:26293
TEST=autotest (network_WiFi tests)

Change-Id: I6068093aa551f77bdba6217db0265f39c85d9edb
Reviewed-on: https://chromium-review.googlesource.com/188197
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Daniel Kim <dekim@broadcom.com>
Commit-Queue: Daniel Kim <dekim@broadcom.com>
CHROMIUM: s5p-mfc: Don't leak when allocating on top of old private buffers

Don't leak memory when allocating private buffers if they have previously
been allocated and somehow not freed. This may, for example, happen, if
the watchdog kicks in and we reinit the device. At this point we leak
the device context buffer.

Guard against such situations by checking if the buffer has already been
allocated and freeing that memory before reallocation.

Signed-off-by: Pawel Osciak <posciak@chromium.org>

BUG=chrome-os-partner:26491
TEST=decode/encode tests

Change-Id: Id195920585201f3dc5b27ca806a918c1eaa5db27
Reviewed-on: https://chromium-review.googlesource.com/189562
Reviewed-by: Wu-Cheng Li <wuchengli@chromium.org>
Reviewed-by: John Sheu <sheu@chromium.org>
Commit-Queue: Pawel Osciak <posciak@chromium.org>
Tested-by: Pawel Osciak <posciak@chromium.org>
CHROMIUM: s5p-mfc: Fix private buffer allocation error cases.

Don't ignore init_enc_buffers error return values.
Also, free previously-allocated context buffer in error path of instance
buffer allocation.
And finally, don't succeed instance buffers allocation on unrecognized
codec type.

Signed-off-by: Pawel Osciak <posciak@chromium.org>

BUG=chrome-os-partner:26491
TEST=decode/encode tests

Change-Id: I9d82887bd7676132f0e535d02f7bde65622cd730
Reviewed-on: https://chromium-review.googlesource.com/189563
Reviewed-by: John Sheu <sheu@chromium.org>
Commit-Queue: Pawel Osciak <posciak@chromium.org>
Tested-by: Pawel Osciak <posciak@chromium.org>
CHROMIUM: s5p-mfc: Don't crash the kernel if the watchdog kicks in.

If the software watchdog kicks in, the watchdog worker is not synchronized
with hardware interrupts and does not block other instances. It's possible
for it to clear the hw_lock, making other instances trigger a BUG() on
hw_lock checks. Since it's not fatal to clear the hw_lock to zero twice,
just WARN in those cases for now. We should not explode, as firmware will
return errors as needed for other instances after it's reloaded, or they
will time out.

A clean fix should involve killing other instances when watchdog kicks in,
but requires a major redesign of locking in the driver.

Signed-off-by: Pawel Osciak <posciak@chromium.org>

BUG=chrome-os-partner:26491
TEST=video encode/decode tests

Change-Id: I2dfbf19426965971cd08505371452496c287b72b
Reviewed-on: https://chromium-review.googlesource.com/189564
Reviewed-by: Pawel Osciak <posciak@chromium.org>
Commit-Queue: Pawel Osciak <posciak@chromium.org>
Tested-by: Pawel Osciak <posciak@chromium.org>
CHROMIUM: gpu: mali: Mark mapped pages ~VM_MAY* as well as VM_*

Unmask VM_MAY* for the permissions that are removed, so that mprotect() can't
be used later to upgrade them.

BUG=chromium:351855
TEST=regular kernel regression testing

Change-Id: I720fdb2fd59f7ba07a760f5b9dae3dce1d8c565e
Signed-off-by: Olof Johansson <olofj@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189686
Reviewed-by: Jorge Lucangeli Obes <jorgelo@chromium.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
CHROMIUM: init: Don't decrease loops_per_jiffy when a CPU comes up

The loops_per_jiffy count continues to be updated as each CPU is
brought up.  This causes problems when we've got an HMP system and
different CPUs have different loops per jiffy.  On exynos 542x
systems, for instance, the A7s will have significantly lower loops per
jiffy than their big brothers.

We should always set the loops_per_jiffy the first time through, then
use the max.

One could argue that complex HMP systems should really be completely
ignoring the global loops_per_jiffy variable anyway.  That's probably
why nobody has fixed this before.  With that argument you could say
that while this change isn't incorrect, it's a bit misguided.  Because
of that upstream probably won't want it.  There's no need for us to
revert it, but if/when we get ARCH timer-based udelay() we won't
really care about this patch.

BUG=chrome-os-partner:26000
TEST=See that loops_per_jiffy at boot is now propery for A15.

Change-Id: I6f17ccc6eaece4ef54b7ab70b0841b917942d6af
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189725
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
ARM: Don't ever downscale loops_per_jiffy in SMP systems

Downscaling loops_per_jiffy on SMP ARM systems really doesn't work.
You could really only do this if:

* Each CPU is has independent frequency changes (changing one CPU
  doesn't affect another).
* We change the generic ARM udelay() code to actually look at percpu
  loops_per_jiffy.

I don't know of any ARM CPUs that are totally independent that don't
just use a timer-based delay anyway.  For those that don't have a
timer-based delay, we should be conservative and overestimate
loops_per_jiffy.

Note that on snow you sometimes see (in the extreme case when we're
all the way downclocked) a udelay(100) become a udelay(1000) now.
That's no worse than we were in kernel-3.4.  On pit/pi we don't
downscale our A7s as much so we see worse case more like 100=>300.

BUG=chrome-os-partner:26000
TEST=No more SPI transfer timeouts with the EC (with next CL, too).
TEST=See I656b3ec5810920c57e17fe32930d35926e3cc314 (on snow, pit, pi)

Change-Id: I33fbfc59a93deaeec096408b1ef46295de56f495
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189885
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
cpufreq: exynos-iks: Remove loops_per_jiffy adjustment

Adjusting loops_per_jiffy is a flawed concept.  See
I656b3ec5810920c57e17fe32930d35926e3cc314.  Remove scaling of
loops_per_jiffy for IKS.

BUG=chrome-os-partner:26000
TEST=No more SPI transfer timeouts with the EC.
TEST=See I656b3ec5810920c57e17fe32930d35926e3cc314.

Change-Id: If403f702fd809543e92c736dd3bf12647c141633
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189728
Reviewed-by: Olof Johansson <olofj@chromium.org>
Reviewed-by: Sonny Rao <sonnyrao@chromium.org>
UPSTREAM: mwifiex: skipping pending commands after unload

We skip downloading other commands after FUNC_SHUTDOWN is queued
during driver unload. Main thread should be woken up each time
after freeing skipped command so that FUNC_SHUTDOWN gets served
in case if there are other pending commands before FUNC_SHUTDOWN.
Also, call mwifiex_complete_cmd() only for synchronous commands.

Reported-by: Avery Pennarun <apenwarr@gmail.com>
Signed-off-by: Amitkumar Karwar <akarwar@marvell.com>
Signed-off-by: Maithili Hinge <maithili@marvell.com>
Signed-off-by: Bing Zhao <bzhao@marvell.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>

BUG=chrome-os-partner:26626
TEST=run "./reload_network_device.sh mlan0; sleep 30" in a loop
for 50 times.

Change-Id: I9104f4f3dc814f19c8c98cc9ab4e09941ec45ac9
Reviewed-on: https://chromium-review.googlesource.com/189678
Reviewed-by: Paul Stewart <pstew@chromium.org>
Tested-by: Bing Zhao <bzhao@marvell.com>
Commit-Queue: Bing Zhao <bzhao@marvell.com>
UPSTREAM: nl80211: Update nl80211_attrs to 3.10

Update the nl80211_attrs to contain values from 3.10.
This also re-aligns NL80211_ATTR_CRIT_PROT_ID and
NL80211_ATTR_MAX_CRIT_PROT_DURATION so they attain the
correct values from the upstream kernels.

Signed-off-by: Paul Stewart <pstew@chromium.org>

BUG=chromium:352260
TEST=Rebuild chromeos-kernel-next

Change-Id: I6775cfaa347a54661810d0d1d95ed0332b1d2baf
Reviewed-on: https://chromium-review.googlesource.com/189844
Reviewed-by: Paul Stewart <pstew@chromium.org>
Commit-Queue: Paul Stewart <pstew@chromium.org>
Tested-by: Paul Stewart <pstew@chromium.org>
cpufreq: exynos5422: Set A15 max freq to 2.0 and A7 to 1.3

Restrict A15 max frequency to 2.0GHz and set min freq to
700MHz.
Restrict A7 max frequency to 1.3GHz.

BUG=chrome-os-partner:26776
TEST=Boot and see frequency of A15 and A7 being set as:
dmesg |grep -i merge
[    4.061194] merged_table index: 0 freq: -1
[    4.065074] merged_table index: 1 freq: 2000000
...
[    4.131521] merged_table index: 14 freq: 700000
[    4.136032] merged_table index: 15 freq: -1
...
[    4.161016] merged_table index: 21 freq: -1
[    4.165178] merged_table index: 22 freq: 650000
CQ-DEPEND=CL:*156839
CQ-DEPEND=CL:189644

Change-Id: I582552ce75a762f721d4433d0f5ef78ddcdf8646
Signed-off-by: Arjun.K.V <arjun.kv@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/189545
Reviewed-by: Doug Anderson <dianders@chromium.org>
Commit-Queue: Doug Anderson <dianders@chromium.org>
Tested-by: Doug Anderson <dianders@chromium.org>
drm/exynos: Remove 119MHz phy clock

It's unstable and causing the following hdmi failure when setting 1680x1050 mode.

The error:
[drm:hdmi_4212_mode_apply] *ERROR* hdmiphy's pll could not reach steady state.

BUG=chromium:352795
TEST=Tested on snow 1680x1050 mode no longer appears

Change-Id: If67987404b447bf136efe83111bf2e2f9c8de10c
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/190029
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
drm/anx7808: Implement debugfs file for register dumping

If debugfs is enabled there will be a file anx7808/regs which allows
the current register state of the anx7808 to be acceesed.

BUG=None
TEST=Tested on spring

Change-Id: I20d188f0df0e8cf9e306a972d36e4c0a4a6084a0
Signed-off-by: David Riley <davidriley@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189066