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)

Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>
ARM: mm: enable non-cacheable streaming enhancement

This is cortex-a15 specific

bug 1178938

Change-Id: Id695d89dbe1411d277f2c1296c74586ca9c1584e
Signed-off-by: Bo Yan <byan@nvidia.com>
Reviewed-on: http://git-master/r/164168
Reviewed-by: Mrutyunjay Sawant <msawant@nvidia.com>
Tested-by: Mrutyunjay Sawant <msawant@nvidia.com>
Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>
ARM: mm: Enable NCSE feature for A15 only

Change-Id: If966ee69f1d5e4314f79685238ecff3c44eadac0
Signed-off-by: Bo Yan <byan@nvidia.com>
Reviewed-on: http://git-master/r/167879
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>
freezer: set PF_SUSPEND_TASK flag on tasks that call freeze_processes

Calling freeze_processes sets a global flag that will cause any
process that calls try_to_freeze to enter the refrigerator.  It
skips sending a signal to the current task, but if the current
task ever hits try_to_freeze, all threads will be frozen and the
system will deadlock.

Set a new flag, PF_SUSPEND_TASK, on the task that calls
freeze_processes.  The flag notifies the freezer that the thread
is involved in suspend and should not be frozen.  Also add a
WARN_ON in thaw_processes if the caller does not have the
PF_SUSPEND_TASK flag set to catch if a different task calls
thaw_processes than the one that called freeze_processes, leaving
a task with PF_SUSPEND_TASK permanently set on it.

Threads that spawn off a task with PF_SUSPEND_TASK set (which
swsusp does) will also have PF_SUSPEND_TASK set, preventing them
from freezing while they are helping with suspend, but they need
to be dead by the time suspend is triggered, otherwise they may
run when userspace is expected to be frozen.  Add a WARN_ON in
thaw_processes if more than one thread has the PF_SUSPEND_TASK
flag set.

Reported-and-tested-by: Michael Leun <lkml20130126@newton.leun.net>
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
(cherry picked from commit 2b44c4db2e2f1765d35163a861d301038e0c8a75)
Change-Id: I12e00d2ba61db827c07b8f4ef48e88a722f02d71
Reviewed-on: http://git-master/r/259126
Reviewed-by: Prashant Gaikwad <pgaikwad@nvidia.com>
Tested-by: Prashant Gaikwad <pgaikwad@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>

Conflicts:
	include/linux/sched.h
	kernel/power/process.c

Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>

Conflicts:
	include/linux/sched.h
kernel: power: Add PM_USERSPACE_FROZEN workqueue

Some device drivers require a callback to be called after the userspace
processes are frozen. This patch adds PM_USERSPACE_FROZEN workqueue
which is called after userspace processes are frozen but when the
kernel threads are still functioning.

Bug 1344551

Change-Id: I0e6fd7e2473db168d01c88bc0192326ceea92ebe
Signed-off-by: Arto Merilainen <amerilainen@nvidia.com>
Reviewed-on: http://git-master/r/266774
(cherry picked from commit d964493291ef87eea1a2ee47b5b66305bb18bcf3)
Reviewed-on: http://git-master/r/274939
Tested-by: Sang-Hun Lee <sanlee@nvidia.com>
Reviewed-by: Kevin Huang (Eng-SW) <kevinh@nvidia.com>
Reviewed-by: Mitch Luban <mluban@nvidia.com>
Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>

Conflicts:
	include/linux/suspend.h

Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>
wcd9320: Enable class AB mode always

Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>

Conflicts:
	sound/soc/codecs/wcd9320.c
cpufreq: interactive: don't schedule timer on offline cpu

It shall not add timer on an offline CPUs, else it will cause
kernel panic.

And also don't reschedule the timer on an offline cpu in idle
and timer callback. Actually the timer shall be cancelled when
cpu is offline.

Change-Id: Id314f15be3d12ab49e5cdcf6ae89bd88b376308a
Signed-off-by: Lianwei Wang <a22439@motorola.com>
Reviewed-on: http://gerrit.pcs.mot.com/539160
SLT-Approved: Slta Waiver <sltawvr@motorola.com>
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Jeffrey Carlyle <jeff.carlyle@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>
cpufreq: Avoid using global variable total_cpus

The change is to compile on kernels where cpufreq stats are compiled as
a module (CONFIG_CPU_FREQ_STAT=m), because total_cpus is not exported for
module use.

Reported-By: Emilio López <elopez93@gmail.com>
Signed-off-by: Ruchi Kandoi <kandoiruchi@google.com>
Change-Id: I4f3c74f0fac5e8d9449655b26bf3b407b0fe4290
Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>
GPU: update to LA.BF.1.1_rb1.11

Conflicts:
	drivers/gpu/msm/kgsl_pwrscale.c
sync: update to LA.BF.1.1_rb1.11
devfreq: update to LA.BF.1.1_rb1.11

Conflicts:
	drivers/devfreq/devfreq.c
	drivers/devfreq/governor_simpleondemand.c
PM: devfreq: Use high priority workqueue

It does not make sense to run kgsl on high and devfreq on regular
priority.

Signed-off-by: flar2 <asegaert@gmail.com>
Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>
PM: devfreq: Always reflect a change of polling interval

Change-Id: Ie895bdf1ed1126e05483890f7ed64ac05890710a
Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>
devfreq: Export profile frequency table to sysfs

devfreq exported the frequencies based that were available from OPP,
however, some devices that use devfreq do not utilise OPP, but they
give the list of supported frequencies separately for devfreq. This
patch makes devfreq use the given table (if available) and fallback
to OPP.

Bug 1330780

Change-Id: I60ec2eade6066b0c3520f7e372384f0a42734048
Signed-off-by: Arto Merilainen <amerilainen@nvidia.com>
Reviewed-on: http://git-master/r/256695
Reviewed-by: Automatic_Commit_Validation_User
GVS: Gerrit_Virtual_Submit
Reviewed-by: Terje Bergstrom <tbergstrom@nvidia.com>
Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>
devfreq: Round frequencies in transition stats

Transition statistics required that the new frequency was *exactly*
as it was in the table. However, we may unexpectedly select a
frequency that is not in the table (i.e. thermal limit forces us to
select a bit lower frequency, the original DVFS table does not hold
for the current PLL for some reason, etc.)

This patch modifies transition table to select the best candidate
from the frequency table.

Bug 1366760

Change-Id: I4329f77e733f5f1d39b9d9c3aebe3681a0760d90
Signed-off-by: Arto Merilainen <amerilainen@nvidia.com>
Reviewed-on: http://git-master/r/273596
Reviewed-by: Automatic_Commit_Validation_User
GVS: Gerrit_Virtual_Submit
Reviewed-by: Terje Bergstrom <tbergstrom@nvidia.com>
Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>
devfreq: Fix type of frequency table

Frequencies are always expressed as ulong, but devfreq's table is of
type uint *. Fix the mismatch.

Change-Id: I0ed6b43f397331d1940c7f573d37796e50e8ac58
Signed-off-by: Terje Bergstrom <tbergstrom@nvidia.com>
Reviewed-on: http://git-master/r/352720
Reviewed-by: Juha Tukkinen <jtukkinen@nvidia.com>
Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>
devfreq: Account only powered time in trans_stat

This patch modifies devfreq to account only the time a device is
powered in trans_stat. In addition, this patch also fixes a race
in trans_stat maintenance in cases where the node is readed at
the same time the transition table is being updated by frequency
re-estimation.

Change-Id: I6e4341317b6dda88d69028c9f67785400e5a7a65
Signed-off-by: Arto Merilainen <amerilainen@nvidia.com>
Reviewed-on: http://git-master/r/435174
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Diwakar Tundlam <dtundlam@nvidia.com>
Reviewed-by: Prajakta Gudadhe <pgudadhe@nvidia.com>
Reviewed-by: Samuel Russell <samuelr@nvidia.com>
Tested-by: Samuel Russell <samuelr@nvidia.com>
Reviewed-by: Ilan Aelion <iaelion@nvidia.com>
Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>
msm: kgsl: set the correct max_state

Max_state from the driver should be set to the number of power
levels. The devfreq governor then checks the frequencies from
0 to max_state -1.

Change-Id: I79a6da698ff8bcb2840774ccc5d792b7ddbf126b
Signed-off-by: Suman Tatiraju <sumant@codeaurora.org>
Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>

Conflicts:
	drivers/gpu/msm/kgsl_pwrscale.c

Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>

Conflicts:
	drivers/gpu/msm/kgsl_pwrscale.c
msm: kgsl: Respect power constraints for a full interval

No matter what type of constraint leave it in effect until
the constraint has expired.

Change-Id: I75118823fd484f87dda8e0f26fa3fe1ae12ca07d
Signed-off-by: Lucille Sylester <lsylvest@codeaurora.org>
Signed-off-by: Jake Weinstein <xboxlover360@gmail.com>
Fix copmpiling