cpufreq: interactive: Move definition of cpufreq_gov_interactive downwards

This moves definition of cpufreq_gov_interactive towards the bottom of file, so
that we don't have to add prototype of cpufreq_governor_interactive() in the
beginning of file.

Change-Id: I04bd1004954eb36502c5cd7e35d3d7274cddaf95
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Git-commit: e50d640cacfe61e69f1b4fa92fa0174c688e919c
Git-Repo: https://android.googlesource.com/kernel/common.git
[junjiew@codeaurora.org: Resolve merge conflicts]
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
cpufreq: interactive: fix compiling warnings

The gcc warns like:

  cpufreq_interactive.c:745:6: warning: operation on 'ret' may be undefined [-Wsequence-point]

It was introduced by commit cf0fad49d17cb8273ce555dd5b7afab67d7923bf.

Since sprintf(...) just return 1 (one character) in this case, ret should not changed.
Just discarding the result of sprintf(...) leads to the result that
the committer of cf0fad49d17cb8273ce555dd5b7afab67d7923bf wants.

Change-Id: Ifed1cef6d6a31c3ed23dad03a567b3b9eddf3a57
Signed-off-by: Chih-Wei Huang <cwhuang@android-x86.org>
Git-commit: 0715d10b9e6c04327adb189e13ecd6a3c2df48ce
Git-Repo: https://android.googlesource.com/kernel/common.git
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
cpufreq: interactive: Honor changed minimum frequency

This saves a few cycles in the timer routine.

Change-Id: I4c0e89094a00a0b63eae6320e6c3bdbb2d4c307e
cpufreq: interactive: Revert timer start modification

commit f8b276565ce95bd788af0fc8d060f92632590a40
(cpufreq: Sync on thread migration optimizations)
introduced a change to cpufreq_interactive_timer_start() in order
to reschedule the timer differently based on whether min or max
is changed. A better way is to reschedule the timer only when
necessary.

Revert timer start modification in preparation for the final fix.

Change-Id: I13f3b75a6eee03ac6380c24db899806a9bfbc96a
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
cpufreq: interactive: restructure CPUFREQ_GOV_LIMITS

The cpufreq_interactive_timer gets cancelled and rescheduled
whenever the cpufreq_policy is changed. When the cpufreq policy is
changed at a rate faster than the sampling_rate of the interactive
governor, then the governor misses to change the target frequency
for long duration. The patch removes the need of cancelling the
timers when policy->min is changed.

Change-Id: Ibd98d151e1c73b8bd969484583ff98ee9f1135ef
Signed-off-by: Badhri Jagan Sridharan <Badhri@google.com>
Git-commit: 9b97d655a558607c5d46ef1f21365d695f8d1ee2
Git-Repo: https://android.googlesource.com/kernel/common.git
[junjiew@codeaurora.org: resolve merge conflicts]
Signed-off-by: Junjie Wu <junjiew@codeaurora.org>
cpufreq: interactive: Simplify frequency calculations

Previously, complicated calculations led to oscillating cpu
frequencies that ruined user experience even on high-end
devices. Revert to the classic calculations based on a
percentage of current max frequency.  This way, we're using
freqs more evenly and much more predictable.

Change-Id: Id7898618607f0e26b272e3c74932a92380e3db7a
cpufreq: interactive: Consider changed min limit a frequency boost

A changed policy->min can safely be considered a frequency boost.
Process this change analogous to the cpufreq_interactive_boost()
routine.

Change-Id: Ie4ca2be2dad0f5bd541c2b79afee3bad3a349d80
cpufreq: interactive: Honor boosted state in several timer calculations

Change-Id: If03da12c52d89a5293e32ac918db44a00ef34884
Makefile: remove the damn wrapper.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Sound Control: WCD9320: expose additional controls

Signed-off-by: Paul Reioux <reioux@gmail.com>
sound control 3.x: Initial GPL release for WCD9320 Audio Codec

This is first official GPL release based on my private implementation.

This release has been tested for xperia Z officially.  It may work
with other devices using the same WCD9320 Audio Codec as well, but not tested

Signed-off-by: Paul Reioux <reioux@gmail.com>
sound control: WCD9320: update speaker gain control for Z1

Signed-off-by: Paul Reioux <reioux@gmail.com>
Sound Control: (Optional) work around for Nexus 4/5 audio issues

(Use this only for devices with audio reset issues)

Also bump version to 3.1

Signed-off-by: Paul Reioux <reioux@gmail.com>

wcd9xxx-core: add register write without mutex protection

This is assuming the calling function will take care of the mutex.

Signed-off-by: Paul Reioux <reioux@gmail.com>
Sound Control: (OPTIONAL) add power amp registers access control as well

Signed-off-by: Paul Reioux <reioux@gmail.com>
fastcharge: initial Nexus 5 adaptation

added custom charge levels for better control over fastcharge

Signed-off-by: Paul Reioux <reioux@gmail.com>

Conflicts:
	arch/arm/mach-msm/Kconfig
	arch/arm/mach-msm/Makefile
	drivers/usb/dwc3/dwc3_otg.c

Change-Id: Ibfe2fa07d6c14cf02f1ac5ea343e7b49d10f3086
fastcharge: increase battery charging current to use higher input current

Signed-off-by: Paul Reioux <reioux@gmail.com>
block: fiops ioscheduler core

FIOPS (Fair IOPS) ioscheduler is IOPS based ioscheduler, so only targets
for drive without I/O seek. It's quite similar like CFQ, but the dispatch
decision is made according to IOPS instead of slice.

The algorithm is simple. Drive has a service tree, and each task lives in
the tree. The key into the tree is called vios (virtual I/O). Every request
has vios, which is calculated according to its ioprio, request size and so
on. Task's vios is the sum of vios of all requests it dispatches. FIOPS
always selects task with minimum vios in the service tree and let the task
dispatch request. The dispatched request's vios is then added to the task's
vios and the task is repositioned in the sevice tree.

Unlike CFQ, FIOPS doesn't have separate sync/async queues, because with I/O
less writeback, usually a task can only dispatch either sync or async requests.
Bias read or write request can still be done with read/write scale.

One issue is if workload iodepth is lower than drive queue_depth, IOPS
share of a task might not be strictly according to its priority, request
Bias read or write request can still be done with read/write scale.

One issue is if workload iodepth is lower than drive queue_depth, IOPS
share of a task might not be strictly according to its priority, request
size and so on. In this case, the drive is in idle actually. Solving the
problem need make drive idle, so impact performance. I believe CFQ isn't
completely fair between tasks in such case too.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>

Change-Id: I8de0406495ee3076df2d3de4285f84d4ec90dbfc
Signed-off-by: Paul Reioux <reioux@gmail.com>
block: fiops read/write request scale

read/write speed of Flash based storage usually is different. For example,
in my SSD maxium thoughput of read is about 3 times faster than that of
write. Add a scale to differenate read and write. Also add a tunable, so
user can assign different scale for read and write.

By default, the scale is 1:1, which means the scale is a noop.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops sync/async scale

CFQ gives 2.5 times more share to sync workload. This matches CFQ.

Note this is different with the read/write scale. We have 3 types of
requests:
1. read
2. sync write
3. write
CFQ doesn't differentitate type 1 and 2, but request cost of 1 and 2
are usually different for flash based storage. So we have both sync/async
and read/write scale here.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops add ioprio support

Add CFQ-like ioprio support. Priority A will get 20% more share than priority
A+1, which matches CFQ.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>