net: wireless: bcmdhd: Enable 5 GHz support

Update wiphy (wireless hardware description) to
support 5 GHz scan.

Bug 1000888

Change-Id: I1a7a99f97f69dd8f1790f81ee0fb21e209e8d10e
Signed-off-by: Nitin Bindal <nbindal@nvidia.com>
Reviewed-on: http://git-master/r/109556
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Rakesh Kumar <krakesh@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
bluetooth: enable sleep only if chip supports

Some bt chips e.g TI wl12xx, do not support external wake using GPIO.
If bluesleep platform data does not contain external wake GPIO information,
bluesleep driver assumes, bt chip does not support external wake and disables
bluetooth chip power management.

Bluesleep driver is also modified to start and stop on HCI_DEV_UP and
HCI_DEV_DOWN events respectively.

bug 1006864

Signed-off-by: Nagarjuna Kristam <nkristam@nvidia.com>
Change-Id: I64c34f5816bd824da1c720175f9e93c16847299b
Reviewed-on: http://git-master/r/108498
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
Reviewed-by: Automatic_Commit_Validation_User
ARM: tegra: clock: Increase boost_up_threshold for AVP clock

Increase the boost_up_threshold to 85 for ULP audio

bug 1009849

Change-Id: I4b1b746f445f5c2804befa52ae95c69b6b467083
Signed-off-by: Vandana Salve <vsalve@nvidia.com>
Reviewed-on: http://git-master/r/114620
Reviewed-by: Automatic_Commit_Validation_User
GVS: Gerrit_Virtual_Submit
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
Reviewed-by: Aleksandr Frid <afrid@nvidia.com>
video: tegra: dc: support disp mode override via boot args

Allows overidding the default disp mode without having to recompile
the kernel. Boot args can be specified in the following format:

disp_params=<rgb|hdmi|dsi>:pclk,h_active,v_active,h_ref_to_sync,
v_ref_to_sync,h_sync_width,v_sync_width,h_back_porch,v_back_porch,
h_front_porch,v_front_porch;<rgb|hdmi|dsi>:pclk,h_active,...

Bug 969088

Change-Id: Id0acf608de145493f6749d5b799d4bbb8162ba72
Signed-off-by: Nirav Patel <nipatel@nvidia.com>
Reviewed-on: http://git-master/r/104604
Reviewed-by: Rohan Somvanshi <rsomvanshi@nvidia.com>
Tested-by: Rohan Somvanshi <rsomvanshi@nvidia.com>
ARM: tegra: dvfs: Update Tegra3 dsi dvfs tables

Updated entries in Tegra3 dsi dvfs tables with recent characterization results.

Bug 985671.
Bug 1006163.

Change-Id: Ife87f3ccfd9d6147d4aa5b57c1a5750bbabc7e6b
Signed-off-by: Rakesh Iyer <riyer@nvidia.com>
Reviewed-on: http://git-master/r/112805
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>
GVS: Gerrit_Virtual_Submit
Reviewed-by: Peter Zu <pzu@nvidia.com>
modified for N7 kernel by faux123
cpufreq: mid-range frequency bias

Restrict go_maxspeed_load and max_boost at mid-range frequencies.

Change-Id: I9e3c59bbe708b428e12ce4dbef2144be09751d5a
Signed-off-by: satya popuri <spopuri@nvidia.com>
Reviewed-on: http://git-master/r/111754
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Karthikeyan Samynathan <ksamynathan@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
Reviewed-by: Aleksandr Frid <afrid@nvidia.com>
Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>
adapted for Nexus Grouper kernel from NV reference by faux123
cpufreq: interactive: add duration to boostpulse

baseded on:
From: Narayanan Gopalakrishnan <nargop@codeaurora.org>
Date: Thu, 4 Oct 2012 03:09:29 -0500
Subject: [PATCH] cpufreq: interactive: add boostpulse duration

This makes up for the portions missing that would've been written
by Narayanan Gopalakrishnan but they were missing (duration, and boost
time) and also adds the ability to set duration (which was originally
created by cyanogen)

Change-Id: I50ab2340080a1a21d051925300737058ed4a622d
lowmemorykiller: Compact memory when killing processes

* Memory compaction is never invoked on Android because we avoid swap
   and don't allocate huge pages. Fix it by invoking compaction from the LMK when
   a process is killed to reduce memory fragmentation.

Change-Id: I2bda790c2093e65fd6f43d52ea5149d6b57cb1e9

Conflicts:

	drivers/staging/android/lowmemorykiller.c

Conflicts:
	drivers/staging/android/lowmemorykiller.c
lowmemorykiller: Use asynchronous compaction

Change-Id: I6a65d06fc30b88fcedaaf1abf1855fdd19e3c912
drivers: staging: android: lmk compile fixup

Signed-off-by: Dennis Rassmann <showp1984@gmail.com>
lowmemorykiller: fix compile warning

Change-Id: If7965053444f8a6ee1b0e000642ffc89926f2655
cpufreq: interactive: remove input_boost handling

Now handled in userspace Power HAL instead.

Change-Id: I78a4a2fd471308bfcd785bbefcc65fede27314cf
Signed-off-by: Todd Poynor <toddpoynor@google.com>

Conflicts:
	drivers/cpufreq/cpufreq_interactive.c
config: grouper: set interactive as default

Change-Id: I23929d78e7840cf805269f04a70b332a0253f025
cpufreq: interactive: remove depreciated go_maxspeed_load

this /should/ have been replaced by go_hispeed_load
also rename midrange_maxspeed to midrange_hispeed for clarity

Change-Id: I50f9d91b85808b5ce81963cb6af67163faece832
cpufreq: interactive: run at fraction of hispeed_freq when load is low

When load is below go_hispeed_load, apply the percentage of CPU load to
a max frequency of hispeed_freq instead of the max speed.  This avoids
jumping too quickly to hispeed_freq when it is a relatively low
percentage of max speed.  This also allows go_hispeed_load to be set to
a high percentage relative to hispeed_freq (as a percentage of max speed,
again useful when hispeed_freq is a low fraction of max speed), to cap
larger loads at hispeed_freq.  For example, a load of 60% will typically
move to 60% of hispeed_freq, not 60% of max speed.  This causes the
governor to apply two different speed caps, depending on whether load is
below or above go_hispeed_load.

Also fix the type of hispeed_freq, which was u64, to match other
speed data types (and avoid overhead and allow division).

Change-Id: Ie2d0668be161c074aaad77db2037505431457b3a
Signed-off-by: Todd Poynor <toddpoynor@google.com>

Conflicts:
	drivers/cpufreq/cpufreq_interactive.c
cpufreq: interactive: always limit initial speed bump to hispeed

First bump speed up to hispeed_freq whenever the current speed is below
hispeed_freq, instead of only when the current speed is the minimum speed.
The previous code made it too difficult to use hispeed_freq as a common
intermediate speed on systems that frequently run at speeds between
minimum and hispeed_freq.

Change-Id: I04ec30bafabf5741e267ff289209b8c2d846824b
Signed-off-by: Todd Poynor <toddpoynor@google.com>

Conflicts:
	drivers/cpufreq/cpufreq_interactive.c