PM QoS: Add max online cpus as PM QoS parameter

Bug 894200

Change-Id: Ieb009a13c6ef9bca2388e234eb973d65a4e3a58b
Signed-off-by: Alex Frid <afrid@nvidia.com>
Reviewed-on: http://git-master/r/71034
Reviewed-by: Rohan Somvanshi <rsomvanshi@nvidia.com>
Tested-by: Rohan Somvanshi <rsomvanshi@nvidia.com>

Rebase-Id: R5791d3cb0bb66f3b8079f5a8af5fa758fb3c6705
PM QoS: Add CPU frequency min/max as PM QoS params

Add minimum and maximum CPU frequency as PM QoS parameters.

Bug 888312

Change-Id: I18abddded35a044a6ad8365035e31d1a2213a329
Reviewed-on: http://git-master/r/72206
Signed-off-by: Antti P Miettinen <amiettinen@nvidia.com>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Reviewed-on: http://git-master/r/75883
Reviewed-by: Automatic_Commit_Validation_User

Rebase-Id: R1007bbef60489ecc81a9acd0ce3b0abfa9a05f3e
PM Qos: Add min online cpus as PM QoS parameter

Bug 940061

Change-Id: Ibae842fdc3af3c92ec7e6125c602417110d8b55e
Signed-off-by: Gaurav Sarode <gsarode@nvidia.com>
Reviewed-on: http://git-master/r/84521
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
Tested-by: Aleksandr Frid <afrid@nvidia.com>
Reviewed-by: Diwakar Tundlam <dtundlam@nvidia.com>

Rebase-Id: R830d4e99f1e03b61a8c4e52e11645b7ed2f10f56
PM QoS: Add disable parameter

For testing purposes it is useful to be able to disable
PM Qos.

Bug 1020898
Bug 917572

Reviewed-on: http://git-master/r/124667

Change-Id: I266f5b5730cfe4705197d8b09db7f9eda6766c7c
Signed-off-by: Antti P Miettinen <amiettinen@nvidia.com>
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>

Rebase-Id: Re2088674f90436e0b9dd74310d5cda1f9e2868e4
PM / QoS: export pm_qos_update_request_timeout()

This pm_qos_update_request_timeout() was introduced without being exported.
Should export it as all of the other PM QoS APIs so those drivers compiled as
modules can use it.

Change-Id: Ie51ce52db4ca633117fe18441c42b562220399e8
Signed-off-by: Li Li <lli5@nvidia.com>
Reviewed-on: http://git-master/r/189306
Reviewed-by: Automatic_Commit_Validation_User
GVS: Gerrit_Virtual_Submit
Reviewed-by: Eric Miao <emiao@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
PM QoS: Add GPU frequency limits to PM QoS

Added GPU frequency min/max as PM QoS classes.

Bug 1330780

Change-Id: I2428c62748521c17e23b2df9ca409deda8b36160
Signed-off-by: Alex Frid <afrid@nvidia.com>
Reviewed-on: http://git-master/r/267702
Reviewed-by: Ilan Aelion <iaelion@nvidia.com>
Reviewed-by: Mitch Luban <mluban@nvidia.com>
Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>
pmqos: Replace spinlock with mutex for pm_qos_lock

Using a spinlock (taken with irqsave) meant that pm_qos_lock couldn't be
used to synchronize on the notifiers in order to ensure proper order of
the notifications. This is needed in case where there might be two near
simultaneous pmqos client requests for a bound on the same constraint;
the notifiers in pm_qos_update_target for the two clients could
potentially engage in a race.

Example:

Assume two requests are made (A, B with A coming first) for max cpufreq
and these are the only requests currently available.

Current behavior can result in:

notify(max_cpu_freq, minof(A, B))
notify(max_cpu_freq, minof(LONG_MAX, A))

Expected behavior:

notify(max_cpu_freq, minof(LONG_MAX, A))
notify(max_cpu_freq, minof(A, B))

Most of the PM QoS and Dev PM QoS requester clients were reviewed and
none of them were found to be calling pm_qos_add/update/remove request
from interrupt or atomic context since those calls include the blocking
notifier call which cannot be done in atomic context.

Change-Id: I2fb43cc38da4c701e4872b937dd82cd38f1a1c1e
Signed-off-by: Sai Gurrappadi <sgurrappadi@nvidia.com>
Reviewed-on: http://git-master/r/299036
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Diwakar Tundlam <dtundlam@nvidia.com>
power: PM QoS support for bounded constraints

Extended PM QoS to allow binding of two constraints. Bounded constraints
add the following functionality:

	- Priority for min/max bound requests. Targets bounds are set
	  to satisfy all priorities (intersection of all ranges). If it
	  is not possible to do so, higher priorities prevail
	- Timeouts for bound requests
	- Userspace interface that exposes bound requests

PM QoS still supports its original kernelspace and userspace interfaces

Bug 1270839
Bug 1349096

Change-Id: Ic83444912b330fc71335d9a5b59077b1d16496bd
Signed-off-by: Sai Gurrappadi <sgurrappadi@nvidia.com>
Reviewed-on: http://git-master/r/299037
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Paul Walmsley <pwalmsley@nvidia.com>
Reviewed-by: Diwakar Tundlam <dtundlam@nvidia.com>

Conflicts:
	kernel/power/qos.c
PM / QoS: Add notifier for flags

dev_pm_qos has a notifier for DEV_PM_QOS_LATENCY. Add a similar
notifier for DEV_PM_QOS_FLAGS.

Bug 1364240

Change-Id: Ica4c58708855938818a1e75896503b9023b96573
Signed-off-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-on: http://git-master/r/288810
power: Prefer min over max for online cpus

We prefered min_online_cpus over max_online_cpus if min > max.
min_wins is now true for online cpu PmQoS requests.

Bug 1270839

Change-Id: I2888538dd1a4616babb7cd1532264272de5cfe64
Signed-off-by: Sai Gurrappadi <sgurrappadi@nvidia.com>
Reviewed-on: http://git-master/r/301871
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Diwakar Tundlam <dtundlam@nvidia.com>
power: Fix coverity error

Properly null-terminate userspace input string. Otherwise, the subsequent
strsep() could continue off into arbitrary chunks of kmalloc() space
that aren't part of the original string buffer.

Change-Id: I3868dbcdd9df7e7172c001eb6bc41c605d48604b
Signed-off-by: Sai Gurrappadi <sgurrappadi@nvidia.com>
Reviewed-on: http://git-master/r/355578
Reviewed-by: Paul Walmsley <pwalmsley@nvidia.com>
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Diwakar Tundlam <dtundlam@nvidia.com>
Power: pmqos: Add emc freq pmqos constraint

It adds min emc freq pmqos.

Bug 1432476

Change-Id: If05c2e8cceffc9ca071ed0b023c29e1ef2921245
Signed-off-by: Puneet Saxena <puneets@nvidia.com>
Reviewed-on: http://git-master/r/360379
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Aleksandr Frid <afrid@nvidia.com>
Reviewed-by: Sachin Nikam <snikam@nvidia.com>
intelli_plug: add performance boost option

also fixed dependency on __cpuinit

bumped to version 3.9

Signed-off-by: Paul Reioux <reioux@gmail.com>
dm-crypt: add intelli_plug performance boost optimization

Signed-off-by: Paul Reioux <reioux@gmail.com>
dm-crypt: use 2x number of write threads to saturate each cpus pipeline

Signed-off-by: Paul Reioux <reioux@gmail.com>
ARM: be strict about FP exceptions in kernel mode

The support code in vfp_support_entry does not care whether the
exception that caused it to be invoked occurred in kernel mode or
in user mode. However, neither condition that could trigger this
exception (lazy restore and VFP bounce to support code) is
currently allowable in kernel mode.

In either case, print a message describing the condition before
letting the undefined instruction handler run its course and trigger
an oops.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
Acked-by: Nicolas Pitre <nico at linaro.org>
Signed-off-by: Paul Reioux <reioux@gmail.com>
ARM: add support for kernel mode NEON

In order to safely support the use of NEON instructions in
kernel mode, some precautions need to be taken:
- the userland context that may be present in the registers (even
  if the NEON/VFP is currently disabled) must be stored under the
  correct task (which may not be 'current' in the UP case),
- to avoid having to keep track of additional vfpstates for the
  kernel side, disallow the use of NEON in interrupt context
  and run with preemption disabled,
- after use, re-enable preemption and re-enable the lazy restore
  machinery by disabling the NEON/VFP unit.

This patch adds the functions kernel_neon_begin() and
kernel_neon_end() which take care of the above. It also adds
the Kconfig symbol KERNEL_MODE_NEON to enable it.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Paul Reioux <reioux@gmail.com>
ARM: only allow kernel mode neon with AEABI

This prevents the linker erroring with:

arm-linux-ld: error: arch/arm/lib/xor-neon.o uses VFP instructions, whereas arch/arm/lib/built-in.o does not
arm-linux-ld: failed to merge target specific data of file arch/arm/lib/xor-neon.o

This is due to the non-neon files being marked as containing FPA data/
instructions (even though they do not) being mixed with files which
contain VFP, which is an incompatible floating point format.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
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>

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

Conflicts:
	block/Makefile

Conflicts:
	block/Makefile
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>