msm: mdss: avoid clocks on if panel is not on for command mode

There are cases where vsync enable may happen before panel has been
turned on. In this case MDP clocks and specially DSI clocks shouldn't
get turned on if the panel is not ready yet. Add a check to ensure
clocks are not turned on and wait for panel to be turned on later on,
vsync events will be enabled then.

Change-Id: I522a1ecafc3949582e049d247a443725672d2d47
Signed-off-by: Adrian Salido-Moreno <adrianm@codeaurora.org>
msm: mdss: cleanup MDP3 driver compilation

Enable MDP3 driver compilation only on chip-sets where MDP3 core is
present. This helps reduce the size of kernel binary where MDP3 is
not present.

Change-Id: I357ff73f91e7ee1654a8666a78efebf68a2a8290
Signed-off-by: Ujwal Patel <ujwalp@codeaurora.org>
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>
block: fiops preserve vios key for deep queue depth workload

If the task has running request, even it's added into service tree newly,
we preserve its vios key, so it will not lost its share. This should work
for task driving big queue depth. For single depth task, there is no approach
to preserve its vios key.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
block: fiops bias sync workload

If there are async requests running, delay async workload. Otherwise
async workload (usually very deep iodepth) will use all queue iodepth
and later sync requests will get long delayed. The idea is from CFQ.

Signed-off-by: Shaohua Li <shaohua.li@intel.com>
msm: pm: Notify secure code of L2 power mode from last core only

Notify secure code L2 low power mode only if the current core is the
last core down. In certain scenarios, its possible that Linux and
secure code have different views of what a last core and could result in
secure code not invalidating a cache when the L2 was placed in a
non-retention mode.

Consider a two core scenario where Core 1 is power collapsed and Core 0
is the last core down setting L2 to be invalidated. Before Core 0 makes
the scm call, its possible that is interrupted to process a secure
interrupt. If the Core 1 wakes up in this time and decides to vote a
different L2 mode, this mode wouldn't be consistent with what Core 0
passes down to secure code when resuming from interrupt handling. In
these cases, the secure code could end up incorrectly invalidating the L2
on warmboot.

Also, the secure code and Linux should have a consistent view of what
last core down is to flush and invalidate L2. To ensure this, acquire a
remote (hardware) spinlock to serialize the last portion of the
power-collapse sequence. The remote spinlock will be released by the
secure code after it acquires its own lock to serialize the power
collapse sequence.

Change-Id: Ib5e2f360fddce558d22ce094dd7755c395c45a8c
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
msm: pm: Acquire scm_handoff_lock conditionally

Acquisition of the scm_handoff_lock requires a TrustZone software
image that will release the lock. Without this, a deadlock will
occur since the lock will remain held forever.

Since this lock is only really needed if the qcom,allow-synced-levels
property is specified for the lpm-levels device, conditionally acquire
the lock based on this property. This avoid the TrustZone software
dependency when qcom,allow-synced-levels is not specified.

Change-Id: I8f8f1e4f9bdab6e70ef2a5484faba4e8ce8ac20c
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
msm: remote_spinlock: Add support for remote_spin_lock_rlock_id()

remote_spin_lock_rlock_id() and remote_spin_unlock_rlock() are
added to acquire/release a raw remote lock (without a local
spinlock). This is useful when ownership of a lock must transfer
between different execution environments, such as when a lock is
used to guarantee atomicity of a set of actions spread across
different execution environments.

Specifically, these APIs are added to support a new lock which
must be acquired in Linux but released by TrustZone software.

Because no local spinlock is acquired, each thread must use a
different ID so that only one thread can proceed through the
lock at a time.

Support for these new APIs is presently implemented only for
SFPB locks.

Change-Id: Ifc5b1f552090051d2e975107e56e21e22df08924
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
update defconfig

Change-Id: I9009ac0ffd987c8a26343d6ae91eaa50542e68e7