cpuidle: move field disable from per-driver to per-cpu

Andrew J.Schorr raises a question.  When he changes the disable setting on
a single CPU, it affects all the other CPUs.  Basically, currently, the
disable field is per-driver instead of per-cpu.  All the C states of the
same driver are shared by all CPU in the same machine.

The patch changes the `disable' field to per-cpu, so we could set this
separately for each cpu.

Change-Id: I7d6b4392c920fe70c89d44a2df0935d72c842cf4
Signed-off-by: ShuoX Liu <shuox.liu@intel.com>
Reported-by: Andrew J.Schorr <aschorr@telemetry-investments.com>
Reviewed-by: Yanmin Zhang <yanmin_zhang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
cpuidle: Quickly notice prediction failure for repeat mode

The prediction for future is difficult and when the cpuidle governor prediction
fails and govenor possibly choose the shallower C-state than it should. How to
quickly notice and find the failure becomes important for power saving.

cpuidle menu governor has a method to predict the repeat pattern if there are 8
C-states residency which are continuous and the same or very close, so it will
predict the next C-states residency will keep same residency time.

There is a real case that turbostat utility (tools/power/x86/turbostat)
at kernel 3.3 or early. turbostat utility will read 10 registers one by one at
Sandybridge, so it will generate 10 IPIs to wake up idle CPUs. So cpuidle menu
 governor will predict it is repeat mode and there is another IPI wake up idle
 CPU soon, so it keeps idle CPU stay at C1 state even though CPU is totally
idle. However, in the turbostat, following 10 registers reading is sleep 5
seconds by default, so the idle CPU will keep at C1 for a long time though it is
 idle until break event occurs.
In a idle Sandybridge system, run "./turbostat -v", we will notice that deep
C-state dangles between "70% ~ 99%". After patched the kernel, we will notice
deep C-state stays at >99.98%.

In the patch, a timer is added when menu governor detects a repeat mode and
choose a shallow C-state. The timer is set to a time out value that greater
than predicted time, and we conclude repeat mode prediction failure if timer is
triggered. When repeat mode happens as expected, the timer is not triggered
and CPU waken up from C-states and it will cancel the timer initiatively.
When repeat mode does not happen, the timer will be time out and menu governor
will quickly notice that the repeat mode prediction fails and then re-evaluates
deeper C-states possibility.

Below is another case which will clearly show the patch much benefit:

volatile int * shutdown;
volatile long * count;
int delay = 20;
int loop = 8;

void usage(void)
{
	fprintf(stderr,
		"Usage: idle_predict [options]\n"
		"  --help	-h  Print this help\n"
		"  --thread	-n  Thread number\n"
		"  --loop     	-l  Loop times in shallow Cstate\n"
		"  --delay	-t  Sleep time (uS)in shallow Cstate\n");
}

void *simple_loop() {
	int idle_num = 1;
	while (!(*shutdown)) {
		*count = *count + 1;

		if (idle_num % loop)
			usleep(delay);
		else {
			/* sleep 1 second */
			usleep(1000000);
			idle_num = 0;
		}
		idle_num++;
	}

}

static void sighand(int sig)
{
	*shutdown = 1;
}

int main(int argc, char *argv[])
{
	sigset_t sigset;
	int signum = SIGALRM;
	int i, c, er = 0, thread_num = 8;
	pthread_t pt[1024];

	static char optstr[] = "n:l:t:h:";

	while ((c = getopt(argc, argv, optstr)) != EOF)
		switch (c) {
			case 'n':
				thread_num = atoi(optarg);
				break;
			case 'l':
				loop = atoi(optarg);
				break;
			case 't':
				delay = atoi(optarg);
				break;
			case 'h':
			default:
				usage();
				exit(1);
		}

	printf("thread=%d,loop=%d,delay=%d\n",thread_num,loop,delay);
	count = malloc(sizeof(long));
	shutdown = malloc(sizeof(int));
	*count = 0;
	*shutdown = 0;

	sigemptyset(&sigset);
	sigaddset(&sigset, signum);
	sigprocmask (SIG_BLOCK, &sigset, NULL);
	signal(SIGINT, sighand);
	signal(SIGTERM, sighand);

	for(i = 0; i < thread_num ; i++)
		pthread_create(&pt[i], NULL, simple_loop, NULL);

	for (i = 0; i < thread_num; i++)
		pthread_join(pt[i], NULL);

	exit(0);
}

Get powertop V2 from git://github.com/fenrus75/powertop, build powertop.
After build the above test application, then run it.
Test plaform can be Intel Sandybridge or other recent platforms.

We will find that deep C-state will dangle between 40%~100% and much time spent
on C1 state. It is because menu governor wrongly predict that repeat mode
is kept, so it will choose the C1 shallow C-state even though it has chance to
sleep 1 second in deep C-state.

While after patched the kernel, we find that deep C-state will keep >99.6%.

Signed-off-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Youquan Song <youquan.song@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

Conflicts:

	kernel/time/tick-sched.c

Change-Id: I7e6721f06572b0620572690779ae2414c41b036d
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
cpuidle: Quickly notice prediction failure in general case

The prediction for future is difficult and when the cpuidle governor prediction
fails and govenor possibly choose the shallower C-state than it should. How to
quickly notice and find the failure becomes important for power saving.

The patch extends to general case that prediction logic get a small predicted
residency, so it choose a shallow C-state though the expected residency is large
. Once the prediction will be fail, the CPU will keep staying at shallow C-state
for a long time. Acutally, the CPU has change enter into deep C-state.
So when the expected residency is long enough but governor choose a shallow
C-state, an timer will be added in order to monitor if the prediction failure.

When C-state is waken up prior to the adding timer, the timer will be cancelled
initiatively. When the timer is triggered and menu governor will quickly notice
prediction failure and re-evaluates deeper C-states possibility.

Change-Id: I9287cbbe798d143fb2ee1b472c8d56cc3a76c7ae
Signed-off-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Youquan Song <youquan.song@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
cpuidle: Get typical recent sleep interval

The function detect_repeating_patterns was not very useful for
workloads with alternating long and short pauses, for example
virtual machines handling network requests for each other (say
a web and database server).

Instead, try to find a recent sleep interval that is somewhere
between the median and the mode sleep time, by discarding outliers
to the up side and recalculating the average and standard deviation
until that is no longer required.

This should do something sane with a sleep interval series like:

	200 180 210 10000 30 1000 170 200

The current code would simply discard such a series, while the
new code will guess a typical sleep interval just shy of 200.

The original patch come from Rik van Riel <riel@redhat.com>.

Change-Id: I975c9d0df1b7e9902c576bcf13a76efec87211e8
Signed-off-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Youquan Song <youquan.song@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
cpuidle: Fix finding state with min power_usage

Since cpuidle_state.power_usage is a signed value, use INT_MAX (instead
of -1) to init the local copies so that functions that tries to find
cpuidle states with minimum power usage works correctly even if they use
non-negative values.

Change-Id: I30d32cda5dcc22184752ac4c8642f73e7d1e7dde
Signed-off-by: Sivaram Nair <sivaramn@nvidia.com>
Reviewed-by: Rik van Riel <riel@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
cpuidle: remove the power_specified field in the driver

We realized that the power usage field is never filled and when it
is filled for tegra, the power_specified flag is not set causing all
of these values to be reset when the driver is initialized with
set_power_state().

However, the power_specified flag can be simply removed under the
assumption that the states are always backward sorted, which is the
case with the current code.

This change allows the menu governor select function and the
cpuidle_play_dead() to be simplified.  Moreover, the
set_power_states() function can removed as it does not make sense
any more.

Drop the power_specified flag from struct cpuidle_driver and make
the related changes as described above.

As a consequence, this also fixes the bug where on the dynamic
C-states system, the power fields are not initialized.

[rjw: Changelog]
References: https://bugzilla.kernel.org/show_bug.cgi?id=42870
References: https://bugzilla.kernel.org/show_bug.cgi?id=43349
References: https://lkml.org/lkml/2012/10/16/518
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>

Conflicts:

	drivers/cpuidle/cpuidle.c
	drivers/cpuidle/driver.c

Change-Id: I934c43d1ad2d93175c3c2d5ca15744842c3e3be3
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
cpuidle: remove unused variable dead_state

Change-Id: Iccf2d18bcb696437a13a7a28012b9c2d20330885
video: msm: Increase MDP clock multiplier

 * The porch values used on Samsung's panel drivers are very tight, and
   cause the MDP clock rate calculation to be right on the edge of
   stability. Underrun was occurring when FLIP_LR was set on any pipe,
   which is the case for 180 rotation (FLIP_LR|FLIP_UD).
 * Raise the multiplier from 1.15 to 2 to fix the underrun.

Change-Id: Iadd7facde88520a90a4394f57fe28214a92741a3
Revert "video: msm: Increase MDP clock multiplier"

This reverts commit 92a6853f5b461325bbcd2f4d4587b1b834101fb8.
msm_fb: Set RR sched policy for Glupdator thread

Set Round Robin Scheduling policy for GLUpdator
thread to improve performance.

Change-Id: I637ca364d325d6c847c73e8eec403e76094d93c5
Signed-off-by: Kalyan Thota <kalyant@codeaurora.org>
Signed-off-by: Ken Zhang <kenz@codeaurora.org>
video: msm: Increase video encoding output buffer size

When bistream buffer size is half of YUV buffer size, video core
may be put into a bad state where output buffers are not returned
back to user space. Increasing the output buffer size solves the issue.

Signed-off-by: Shuzhen Wang <shuzhenw@codeaurora.org>
Asynchronous Fsync: initial extraction of Async Fsync from HTC

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

Conflicts:

	drivers/mmc/core/mmc.c

Conflicts:

	drivers/mmc/core/mmc.c
	fs/Kconfig

Conflicts:
	fs/Kconfig

	modified:   arch/arm/configs/cm_rhine_honami_row_defconfig
	modified:   arch/arm/configs/msm8974_defconfig
	modified:   arch/arm/mach-msm/Kconfig
	modified:   arch/arm/mach-msm/board-8974.c
	modified:   drivers/mmc/core/mmc.c
	modified:   fs/Kconfig
	modified:   fs/namespace.c
	modified:   fs/sync.c
	modified:   include/linux/fs.h

Change-Id: I61166e537c737e626327ba2ee7a5be27c1e6b148
	modified:   arch/arm/configs/cm_rhine_honami_row_defconfig
	modified:   arch/arm/mach-msm/Kconfig
	modified:   arch/arm/mach-msm/clock-krait-8974.c
	modified:   drivers/cpufreq/cpufreq.c

Change-Id: Ib5922b6b7b4d7143717d900e580a1cfffb220db7
clock-krait/cpufreq: custom voltage control v1

* TODO: control only available frequencies

Conflicts:
	drivers/cpufreq/cpufreq.c

	modified:   arch/arm/mach-msm/clock-krait-8974.c
	modified:   drivers/cpufreq/cpufreq.c

Change-Id: I25e2db51b98fcaf2b20e2228aaf76af710208123
Add defconfig flag for the VDD Control

Change-Id: I357d023cd05e49eab6b883a1456a06449ac31275

Conflicts:
	drivers/cpufreq/cpufreq.c

	modified:   arch/arm/mach-msm/clock-krait-8974.c
	modified:   drivers/cpufreq/cpufreq.c
mach-msm: forgot Kconfig flag for VDD Control

Change-Id: Ic93b3933ce30808e2cf9c7a3af4688392f098a4a

Conflicts:
	arch/arm/mach-msm/Kconfig

	modified:   arch/arm/configs/cm_rhine_honami_row_defconfig
	modified:   arch/arm/mach-msm/Kconfig