mogami: remove CONFIG_MMC_MSM_CARD_HW_DETECTION
msm_serial_hs: Don't configure gpios into UART Mode always

UARTDM device is used as interface to connect external devices through
GPIOs. Currently those GPIOs are configured in active mode once driver's
probe() is called and configured in suspend mode once its remove() is
called. Probe() is called once only and remove is not called until UARTDM
platform device is removed. With this current implementation, although
external device (ex. Bluetooth SoC) is not operational mode, used UARTDM
GPIOs are configured in active mode which is causing more leakage current
and more power consumption.

Hence configure those UARTDM GPIOs in active mode only when used UARTDM
device is opened and under used. Configure UARTDM GPIOs back to suspend
mode when UARTDM device is closed and under not used.

CRs-Fixed: 422217

Change-Id: I057a2da827f37687e5ea69bdca1533568be06eab
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
Signed-off-by: nobodyAtall <tsogkas@ceid.upatras.gr>
msm_serial_hs : handle uart_flush_buffer

Serial core allocates circular buffer for uart tx transfer.
Circular buffer head and tail is updated in serial core and
circular buffer tail is updated in uart driver.While uart
transfer is happening, uart client bluetooth hci_ldisc,calls
uart_flush_buffer in serial core and sets circular buffer
head and tail to zero.As uart driver does not know when
uart_flush_buffer is called in serial core by uart client,it
updates circular buffer tail for the previous ADM Tx completion.
This leads to queueing Tx command to ADM although no data is
there in circular buffer.Because of this,uart client is not
functional.

Hence adding msm_hs_flush_buffer api which notifies to uart driver
that uart_flush_buffer is called in serial core by uart client and
set tty_flush_receive flag to true.In uart interrupt handler ,do
not update circular buffer tail if uart_flush_buffer is already
called in serial core by uart client else update circular buffer
tail on ADM Tx completion.

(cherry picked from commit ce39410ad3db5b9fb446bf5da126585d58fa872a)

Change-Id: I9bce30da218f42739c175d9b3c283ae39b6b5c89
CRs-Fixed: 419054
Signed-off-by: Saket Saurabh <ssaurabh@codeaurora.org>
Signed-off-by: nobodyAtall <tsogkas@ceid.upatras.gr>
msm_serial_hs: Add support to handle Rx BREAK condition

Currently Rx Break Error condition is not checked using UART_DM_SR
register. Hence by default null-character is being inserted on
receiving Rx Error or Rx Break condition. Application sets termios
c_iflag if it needs any notification related to any Rx Error or
Break condition. Hence add support to handle Rx Break condition and
insert null-character conditionally based on termios.c_iflag.

CRs-Fixed: 412201
Change-Id: I7f496e42757b949f597d5dbe5c1f1ca88ee53c8c
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
Signed-off-by: nobodyAtall <tsogkas@ceid.upatras.gr>

Conflicts:
	drivers/tty/serial/msm_serial_hs.c
msm_serial_hs: consider flush buffer request only when DMA is in progress

TTY Core uses flush_buffer to clear out any output data before closing
port, whereas UART application can always request to do flush output data
before starting data transfer using tty supported ioctl().
receive_tty_flush is used to make decision on completion of any DMA Tx
data transfer. Using same approach when there is no DMA Tx transfer is
happening, it is breaking next DMA Tx transfer functionality. Hence
update receive_tty_flush only when there is any DMA TX transfer active.

(cherry picked from commit 53069734628ebce341cf1ef778c91dbcbbcf67db)

Change-Id: I26f4ceece422674e1f7647e5dfadb476cec1ef92
CRs-Fixed: 438057
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
Signed-off-by: nobodyAtall <tsogkas@ceid.upatras.gr>
msm_serial_hs: Wait for discard flush completion for UART Rx channel

Completion of requested flush command with ADM driver is having more
latency then previously. Hence now it is required to wait for discard
flush complete if there is more events expected with UART driver which
would go out of sync without it. Below are 2 instances where it is must
to wait for discard flush completion requested on UART Rx channel.

1. Changing Baud Rate of UART
UART application can send baud rate change request based on its requirement
of communication with connected device on remote uart. Serial core also
does set by default baud rate when application is opening the uart port. As
Rx command is queued always with ADM driver from UART driver, for above
events it is required to flush the same after setting the baud rate. Not
waiting for completion of Rx flush would allow application to send command
on Tx or any other ioctl which would reach to connected device but response
may not be received as Rx flush completion is not received to queue next Rx
command to ADM. Hence with this there are chances that received data with
UART wil be lost when Rx flush completion is not received in-time. Hence
wait for Rx flush completion from set_termios() with timeout as 300 jiffie.
Rx flush completion time is non-deterministic as it depends on number of
commands queued to ADM driver from ADM client drivers.

2. While going for UART clock off
UART clock off has multiple state machines and before going into last
state it makes sure that there are no pending data in UART Tx and Rx FIFO.
Although there would be one Rx command queued which is flushed before
moving to last state and going ahead with UART clock off. If UART clock is
turned off before Rx flush request is being executed and ADM tried to flush
Rx command, ADM encounters data bus error on UART Rx Channel. Hence with
waiting for Rx flush completion, and then doing UART clock off on receving
the same would resolve ADM data bus error issue on UART Rx channel.

CRs-Fixed: 457769
Change-Id: I9344277224a2dc3f28140a1f42aa3feed5411b97
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
Signed-off-by: nobodyAtall <tsogkas@ceid.upatras.gr>
msm_serial_hs_lite: Don't set UART clock to zero always

Setting UART clock rate to zero is causing multiple issues
and leading to more confusion with other stability issues.
Setting UART clock rate to zero is invalid operation on
recent platforms and throws multiple error messages. Hence
add platform data set_uart_clk_zero to enable setting uart
clock rate to zero operation on required platform for
specific use case.

Also set set_uart_clk_zero for GSBI9 shared between different
processor.

CRs-Fixed: 455466
Change-Id: Iba04d4cf094885b0eae6a9c49ed06f750bcc1024
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
Signed-off-by: nobodyAtall <tsogkas@ceid.upatras.gr>
defconfigs: disable CIFS for improving battery life
Fix coconut camera button

Signed-off-by: nobodyAtall <tsogkas@ceid.upatras.gr>
Add SIO I/O scheduler

Signed-off-by: nobodyAtall <tsogkas@ceid.upatras.gr>
Add Smartass2 / SmartassH3 / VDD interface

Conflicts:
	arch/arm/mach-msm/acpuclock-7x30.c
Fix build smartasses for kernel 3.4

Signed-off-by: nobodyAtall <tsogkas@ceid.upatras.gr>
drivers: cpufreq: Send a uevent when governor changes

* Useful so userspace tools can reconfigure.

Signed-off-by: nobodyAtall <tsogkas@ceid.upatras.gr>
cpufreq: Add a boostpulse interface to ondemand

For applications that require a one-shot increase in frequency,
the boostpulse interface would help to scale to max for the time
specified in boostime. This helps applications that currently
increases scaling_min_freq and resets later after a fixed duration.
Instead of changing scaling_min_freq applications can directly write
to boostpulse and governer resets during regular timer after the time
expires.

Change-Id: Ie5f490ff06b41364aa76dd468573433495da28a4
Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>
Signed-off-by: nobodyAtall <tsogkas@ceid.upatras.gr>
cpufreq: fix utilization statistics for sync cpus

If the cpus are using related_cpus policy, then the
current implementaion will overwrite the the calculated
load for every iteration in the for loop. Hence, mpdecision
will read incorrect value, if the cores are using related
cpus policy. With this change mpdecision will read the
sum of the loads of all cpu's, if related cpu policy is
used.

Change-Id: I242c8fe39fd75dc3e48750a5b78a5d218b536ddd
Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>
Signed-off-by: Shruthi Krishna <skrish@codeaurora.org>
Signed-off-by: nobodyAtall <tsogkas@ceid.upatras.gr>
cpufreq: notify avg load for short sampling_rate

If the sampling rate is less than 50ms reporting
the actual load may lead to poor decision making
at user space. So, for sampling rates less than 50ms
report the average of load across two samples.

Change-Id: I0d1cf00801732bee8e4380158d7e892758226594
Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>
Signed-off-by: nobodyAtall <tsogkas@ceid.upatras.gr>
cpufreq: boost the sampling rate on touch event

For better Ux responsiveness ondemand sampling rate
needs to be 20ms. But, a 20ms sampling rate increases power
consumption. So, boost the sampling rate to 20ms on every
touch event for 2.5 ms and later reset to default rate.
Also, change sampling down factor proportional to the
sampling rate.

Change-Id: I111b1cf3b8ed133347149afc34d329d0384ecfcb
Signed-off-by: Narayanan Gopalakrishnan <nargop@codeaurora.org>
Signed-off-by: nobodyAtall <tsogkas@ceid.upatras.gr>
cpufreq: ondemand: Fix the boostpulse interface

  * Boostpulse was not working because no default frequency was set.
  * We don't need an input handler to push the freq to max, userspace
    does a better job with the Power HAL.
  * Tweak boost time to 500ms

Change-Id: Ice8c26b758747d265976263296a2da3380b864f7

Signed-off-by: nobodyAtall <tsogkas@ceid.upatras.gr>
cpufreq: ondemand: Change boostfreq value

Signed-off-by: nobodyAtall <tsogkas@ceid.upatras.gr>
cpufreq: interactive: Sync with Google's 3.4 kernel

cpufreq: interactive: take idle notifications only when active

Register an idle notifier only when the governor is active.  Also
short-circuit work of idle end if the governor is not enabled.

Signed-off-by: Sam Leffler <sleffler@chromium.org>
Change-Id: I4cae36dd2e7389540d337d74745ffbaa0131870f

cpufreq: interactive: keep freezer happy when not current governor

Fix a problem where the hung task mechanism was deeming the interactive
clock boost thread as hung.  This was because the thread is created at
module init but never run/woken up until needed.  If the governor is not
being used this can be forever.  To workaround this explicitly wake up
the thread once all the necessary data structures are initialized.  The
latter required some minor code shuffle.

Signed-off-by: Sam Leffler <sleffler@chromium.org>
Change-Id: Ie2c058dd75dcb6460ea10e7ac997e46baf66b1fe

cpufreq: interactive: handle speed up and down in the realtime task

Not useful to have a separate, non-realtime workqueue for speed down
events, avoid priority inversion for speed up events.

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

cpufreq: interactive: remove input_boost handling

Now handled in userspace Power HAL instead.

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

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>

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>

cpufreq: interactive: pin timers to associated CPU

Helps avoid waking up other CPUs to react to activity on the local CPU.

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

cpufreq: interactive: use deferrable timer by default

Avoid wakeups only to handle the governor timer when the system is otherwise
idle.

For platforms where the power cost of remaining in idle at higher CPU
speed may outweigh the cost of a governor wakeup from idle to lower the speed,
set parameter cpufreq_interactive.governidle=1.

Change-Id: Id6c43eb35caecf9b0574fcdd5b769711bc7e6de6
Signed-off-by: LianWei WANG <a22439@motorola.com>
Signed-off-by: Todd Poynor <toddpoynor@google.com>

cpufreq: interactive: kick timer on idle exit past expiry

The deferrable timer list isn't checked on all idle exits, such as when
hi-res timers expire or ISRs schedule workers.  If the idle loop is
exited and it's past time to run the governor load polling timer,
run it immediately.  This ensures we handle load spikes caused by actvity
that does not run the normal timer list.

Rename the field that timestamps the "time_in_idle" value to be more
accurate.

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

cpufreq: interactive: trace actual speed in target speed decisions

Tracing adds actual speed since this is expected to be key to the
choice of target speed.

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

cpufreq: interactive: change speed according to current speed and target load

Add a target_load attribute that specifies how aggressively the governor is
to adjust speed to meet the observed load.  New target speed is calculated
as the current actual speed (may be higher than target speed on SMP) times
the CPU load (as a fraction) divided by target load (fraction).

cpufreq_frequency_table_target() call use CPUFREQ_RELATION_L to set
the next higher speed rather than next lower speed.

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

cpufreq: interactive: apply above_hispeed_delay to each step above hispeed

Apply above_hispeed_delay whenever increasing speed to a new speed above
hispeed (not just the first step above hispeed).

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

cpufreq: interactive: allow arbitrary speed / target load mappings

Accept a string of target loads and speeds at which to apply the
target loads, per the documentation update in this patch.  For example,
"85 1000000:90 1700000:99" targets CPU load 85% below speed 1GHz,  90%
at or above 1GHz, until 1.7GHz and above, at which load 99% is targeted.

Attempt to avoid oscillations by evaluating the current speed
weighted by current load against each new choice of speed, choosing a
higher speed if the current load requires a higher speed.

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

cpufreq: interactive: remove load since last speed change

The longer-term load since last speed change isn't terribly useful,
may delay recognition of dropping load, and would need forthcoming
changes to adjust load for changing CPU speeds.  Drop it.

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

cpufreq: interactive: adjust load for changes in speed

Add notifier for speed transitions.  Keep a count of CPU active
microseconds times current frequency, converted to a percentage relative
to the current frequency when load is evaluated.

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

cpufreq: interactive: specify duration of CPU speed boost pulse

Sysfs attribute boostpulse_duration specifies the duration of boosting CPU
speed in response to bootpulse events.  Duration is specified in usecs,
default 80ms.

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

cpufreq: interactive: add timer slack to limit idle at speed > min

Always use deferrable timer for load sampling.

Set a non-deferrable timer to an additional slack time to allow prior to
waking up from idle to drop speed when not at minimum speed.  Slack value
-1 avoids wakeups to drop speed.  Default is 80ms.

Remove the governidle module param and its timer management in idle.  For
platforms on which holding speed above mimum in idle costs power, use the
new timer slack to select how long to wait before waking up to drop speed.

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

cpufreq: interactive: fix boosting logic

35a84de cpufreq: interactive: apply above_hispeed_delay to each step above hispeed

caused the speed choice logic to osciallate between boosting and not boosting.
Add back code to ensure speed does not drop below boost frequency while
boosting.

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

cpufreq: interactive: fix racy timer stopping

When stopping the governor, del_timer_sync() can race against an
invocation of the idle notifier callback, which has the potential
to reactivate the timer.

To fix this issue, a read-write semaphore is used. Multiple readers are
allowed as long as pcpu->governor_enabled is true.  However it can be
moved to false only after taking a write semaphore which would wait for
any on-going asynchronous activities to complete and prevent any more of
those activities to be initiated.

[toddpoynor@google.com: cosmetic and commit text changes]
Change-Id: Ib51165a735d73dcf964a06754c48bdc1913e13d0
Signed-off-by: Nicolas Pitre <nicolas.pitre@linaro.org>

cpufreq: interactive: fix race on timer restart on governor start

Starting the governor, or restarting on a hotplugged-in CPU, can race
with the timer start in idle, triggering a BUG on timer already pending.
Start the timer before setting the enable flag, and use enable_sem to
protect the sequence (and ensure correct order of the update to the
enable flag).  Delete any existing timer for safety.

Change-Id: Ife77cf9fe099e8fd8543224cbf148c6722c2ffb0
Reported-by: Francisco Franco <francisco.franco@cloudcar.com>
Signed-off-by: Todd Poynor <toddpoynor@google.com>

cpufreq: interactive: default go_hispeed_load 99%, doc updates

Update default go_hispeed_load from 85% to 99%.  Recent changes to the
governor now use a default target_load of 90%.  go_hispeed_load should
not be lower than the target load for hispeed_freq, which could lead
to oscillating speed decisions.  Other recent changes reduce the need
to dampen speed jumps on load spikes, while input event boosts from
userspace are the preferred method for anticipating load spikes with
UI impacts.

General update to the documentation to reflect recent changes.

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

cpufreq: interactive: init default values at compile time

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

cpufreq: interactive: don't handle transition notification if not enabled

If multiple governors are in use then avoid processing frequency transition
notifications for CPUs on which the interactive governor is not enabled.

Change-Id: Ibd75255b921d887501a64774a8c4f62302f2d4e4
Reported-by: Francisco Franco <francisco.franco@cloudcar.com>
Signed-off-by: Todd Poynor <toddpoynor@google.com>

cpufreq: interactive: fix deadlock on spinlock in timer

Need to use irqsave/restore spinlock calls to avoid a deadlock in calls
from the timer.

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

cpufreq: interactive: fix race on governor start/stop

There is race condition when both two cpu do CPUFREQ_GOV_STOP and one cpu
do CPUFREQ_GOV_START soon. The sysfs_remove_group is not done yet on one
cpu, but sysfs_create_group is called on another cpu, which cause governor
start failed and then kernel panic in timer callback because the policy and
cpu mask are all kfree in cpufreq driver.

Replace atomic with mutex to lock the whole START/STOP sequence.

Change-Id: I3762b3d44315ae021b8275aca84f5ea9147cc540
Signed-off-by: Lianwei Wang <a22439@motorola.com>

cpufreq: interactive: allow arbitrary speed / delay mappings

Accept a string of delays and speeds at which to apply the delay before
raising each step above hispeed. For example, "80000 1300000:200000
1500000:40000" means that the delay at or above 1GHz, until 1.3GHz is 80 msecs,
the delay until 1.5GHz is 200 msecs and the delay at or above 1.5GHz is 40
msecs when hispeed_freq is 1GHz.

[toddpoynor@google.com: add documentation]
Change-Id: Ifeebede8b1acbdd0a53e5c6916bccbf764dc854f
Signed-off-by: Minsung Kim <ms925.kim@samsung.com>

cpufreq: interactive: add io_is_busy interface

Previously the idle time returned from get_cpu_idle_time_us included the
iowait time. So the iowait time was always calculated as idle time.

But now the idle time returned from get_cpu_idle_time_us does not include
the iowait time anymore because of below commit which cause the iowait time
always calculated as busy time:
    6beea0c nohz: Fix update_ts_time_stat idle accounting

Add the io_is_busy interface, as does the ondemand governor, and let the user
configure the iowait time as busy or idle through the io_is_busy sysfs
interface.

By default, io_is_busy is disabled.

[toddpoynor@google.com: minor updates]
Change-Id: If7d70ff864c43bc9c8d7fd7cfc66f930d339f9b4
Signed-off-by: Lianwei Wang <lian-wei.wang@motorola.com>
Signed-off-by: Todd Poynor <toddpoynor@google.com>

cpufreq: interactive: fix crash on error paths in get_tokenized_data

Use separate variable for error code, free proper pointer.

Change-Id: Ia83cccb195997789ac6afbf5b8761f7b278196d6
Reported-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Todd Poynor <toddpoynor@google.com>

cpufreq: interactive: base above_hispeed_delay on target freq, not current

Time to wait should be based on the intended target speed, not the
actual speed (which may be held high by another CPU).

Change-Id: Ifc5bb55d06adddb9a02af90af05398a78f282272
Reported-by: Arve Hjønnevåg <arve@android.com>
Signed-off-by: Todd Poynor <toddpoynor@google.com>

cpufreq: interactive: Fix uninitialized spinlock

Change-Id: I9959669e0f643ccd2bd1072fae440d8c20f1c9cc