QoS: add back comments
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>
PM / QoS: add dev_pm_qos_update_request_timeout()

Add dev_pm_qos_update_request_timeout() that works in the same way as
pm_qos_request_timeout().

Bug 1364240

Change-Id: I9da700df443f48099eac929055e9fe2db4c2f540
Signed-off-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-on: http://git-master/r/288808
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>
PM QoS: Fix pmqos notifiers in pm_qos_enabled_set

Send out the notifiers if the enabled flag has been changed. This will
ensure that the notifier fires in all cases.

Bug 1516219

Change-Id: Ie97422f61a9ad56f0ce194a99ce69193d429eadc
Signed-off-by: Sai Gurrappadi <sgurrappadi@nvidia.com>
Reviewed-on: http://git-master/r/413433
Reviewed-by: Automatic_Commit_Validation_User
Tested-by: Diwakar Tundlam <dtundlam@nvidia.com>
Reviewed-by: Diwakar Tundlam <dtundlam@nvidia.com>
PM / QoS: cleanup FLAGS notifiers during removing

DEV_PM_QOS_FLAGS was introduced in commit
c92b96f94cdc26e33ea490a9a0e02c16988a6dd6, but it was forgot to remove
in dev_pm_qos_remove_notifier().

So without this patch, kernel will enter an endless loop in
notifier_chain_register() when reloading a module multiple times.

Bug 1421146

Change-Id: I6b98fe57a70f172d110cc5f257ce4f853a447802
Signed-off-by: Bryan Wu <pengw@nvidia.com>
Reviewed-on: http://git-master/r/347823
Reviewed-by: Terje Bergstrom <tbergstrom@nvidia.com>
PM / QoS: check NULL and ENODEV on power.qos

fix kernel panic when qos is not null

Bug 1442069
Bug 1430231

Change-Id: I8810009e8f2a72730cfb253b245434d9e0806b9c
Signed-off-by: pchiang <pchiang@nvidia.com>
Reviewed-on: http://git-master/r/357069
Reviewed-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-on: http://git-master/r/360175
GVS: Gerrit_Virtual_Submit
power: Update QoS Max boundaries to use INT_MAX

Use INT_MAX rather than LONG_MAX as on a 64 bit system, the s32's
target_value and default_value will overflow.

Bug 1432878

Change-Id: Id9720e79c286802594620db65d8f50303d1a88d7
Signed-off-by: Sai Gurrappadi <sgurrappadi@nvidia.com>
Reviewed-on: http://git-master/r/373795
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Samuel Russell <samuelr@nvidia.com>
Reviewed-by: Diwakar Tundlam <dtundlam@nvidia.com>
PM_QoS: add back comments to header
PM / QoS: Introduce new classes: DMA-Throughput and DVFS-Latency

1. CPU_DMA_THROUGHPUT

This might look simliar to CPU_DMA_LATENCY. However, there are H/W
blocks that creates QoS requirement based on DMA throughput, not
latency, while their (those QoS requester H/W blocks) services are
short-term bursts that cannot be effectively responsed by DVFS
mechanisms (CPUFreq and Devfreq).

In the Exynos4412 systems that are being tested, such H/W blocks include
MFC (multi-function codec)'s decoding and enconding features, TV-out
(including HDMI), and Cameras. When the display is operated at 60Hz,
each chunk of task should be done within 16ms and the workload on DMA is
not well spread and fluctuates between frames; some frame requires more
and some do not and within a frame, the workload also fluctuates
heavily and the tasks within a frame are usually not parallelized; they
are processed through specific H/W blocks, not CPU cores. They often
have PPMU capabilities; however, they need to be polled very frequently
in order to let DVFS mechanisms react properly. (less than 5ms).

For such specific tasks, allowing them to request QoS requirements seems
adequete because DVFS mechanisms (as long as the polling rate is 5ms or
longer) cannot follow up with them. Besides, the device drivers know
when to request and cancel QoS exactly.

2. DVFS_LATENCY

Both CPUFreq and Devfreq have response latency to a sudden workload
increase. With near-100% (e.g., 95%) up-threshold, the average response
latency is approximately 1.5 x polling-rate.

A specific polling rate (e.g., 100ms) may generally fit for its system;
however, there could be exceptions for that. For example,
- When a user input suddenly starts: typing, clicking, moving cursors, and
  such, the user might need the full performance immediately. However,
  we do not know whether the full performance is actually needed or not
  until we calculate the utilization; thus, we need to calculate it
  faster with user inputs or any similar events. Specifying QoS on CPU
  processing power or Memory bandwidth at every user input is an
  overkill because there are many cases where such speed-up isn't
  necessary.
- When a device driver needs a faster performance response from DVFS
  mechanism. This could be addressed by simply putting QoS requests.
  However, such QoS requests may keep the system running fast
  unnecessary in some cases, especially if a) the device's resource
  usage bursts with some duration (e.g., 100ms-long bursts) and
  b) the driver doesn't know when such burst come. MMC/WiFi often had
  such behaviors although there are possibilities that part (b) might
  be addressed with further efforts.

The cases shown above can be tackled with putting QoS requests on the
response time or latency of DVFS mechanism, which is directly related to
its polling interval (if the DVFS mechanism is polling based).

Signed-off-by: MyungJoo Ham <myungjoo.ham@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>

--
Changes from RFC(v1)
- Added omitted part (registering new classes)
fix kernel/power/qos.c