cpufreq: interactive: I guess queuing everything up to the governor kthread is what should be done to avoid panics.

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

Conflicts:
	drivers/cpufreq/cpufreq_interactive.c
writeback: fix race that cause writeback hung

There is a race between mark inode dirty and writeback thread, see the
following scenario.  In this case, writeback thread will not run though
there is dirty_io.

__mark_inode_dirty()                                          bdi_writeback_workfn()
	...                                                       	...
	spin_lock(&inode->i_lock);
	...
	if (bdi_cap_writeback_dirty(bdi)) {
	    <<< assume wb has dirty_io, so wakeup_bdi is false.
	    <<< the following inode_dirty also have wakeup_bdi false.
	    if (!wb_has_dirty_io(&bdi->wb))
		    wakeup_bdi = true;
	}
	spin_unlock(&inode->i_lock);
	                                                            <<< assume last dirty_io is removed here.
	                                                            pages_written = wb_do_writeback(wb);
	                                                            ...
	                                                            <<< work_list empty and wb has no dirty_io,
	                                                            <<< delayed_work will not be queued.
	                                                            if (!list_empty(&bdi->work_list) ||
	                                                                (wb_has_dirty_io(wb) && dirty_writeback_interval))
	                                                                queue_delayed_work(bdi_wq, &wb->dwork,
	                                                                    msecs_to_jiffies(dirty_writeback_interval * 10));
	spin_lock(&bdi->wb.list_lock);
	inode->dirtied_when = jiffies;
	<<< new dirty_io is added.
	list_move(&inode->i_wb_list, &bdi->wb.b_dirty);
	spin_unlock(&bdi->wb.list_lock);

	<<< though there is dirty_io, but wakeup_bdi is false,
	<<< so writeback thread will not be waked up and
	<<< the new dirty_io will not be flushed.
	if (wakeup_bdi)
	    bdi_wakeup_thread_delayed(bdi);

Writeback will run until there is a new flush work queued.  This may cause
a lot of dirty pages stay in memory for a long time.

Signed-off-by: Junxiao Bi <junxiao.bi@oracle.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
cpufreq: interactive: instead of bumping the target_cpu freq to the source_cpu current freq make it boost to SYNC_FREQ instead at 960MHz (maybe configurable in the future?) and that should be enough and help with the performance/battery ratio.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
cpufreq: interactive: fix input_boost_freq not being always choosen for target_freq when boosted is true. Also do not boost the target_cpu to SYNC_FREQ if the source_cpu current frequency is not higher than target_cpu current freq to avoid overusage of SYNC_FREQ.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
mako_hotplug: read the policy contents every get_cpu_load() call

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

Conflicts:
	arch/arm/kernel/mako_hotplug.c
dts: gpu: remove duplicates freqs (even though being duplicates they had different bus values).

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
dts: mdss: reduce the display voltage for (hopefully) increased battery during screen on.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
mako_hotplug: add a mode to online all cores if the GPU busy count is very high for at least 8-10 consecutive seconds.

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

Conflicts:
	drivers/misc/mako_hotplug_control.c
mako_hotplug: disable gpu_busy_quad_mode by default.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
cpufreq: interactive: instead of using choose_freq() to calculate the new_freq lets try a more ondemand approach by using the actual load scaling to make it more consistent, specially when gaming.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Revert "dts: panel: make colors saturated and vivid. Also whites are whiter."

According to faux we should not mess with this set of bits, so with lack of better evidence lets revert it.

This reverts commit 6747c5003dba8fda142b7a4041db3033dda6d036.
sched: Fix select_idle_sibling() bouncing cow syndrome

If the previous CPU is cache affine and idle, select it.

The current implementation simply traverses the sd_llc domain,
taking the first idle CPU encountered, which walks buddy pairs
hand in hand over the package, inflicting excruciating pain.

1 tbench pair (worst case) in a 10 core + SMT package:

  pre   15.22 MB/sec 1 procs
  post 252.01 MB/sec 1 procs

Signed-off-by: Mike Galbraith <bitbucket@online.de>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1359371965.5783.127.camel@marge.simpson.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
cpufreq: interactive: fix a bug where the thread_migration notifier was wrongly pushing the cpu to use higher freqs a lot more than it should.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
sched: Fix clear NOHZ_BALANCE_KICK

I have faced a sequence where the Idle Load Balance was sometime not
triggered for a while on my platform, in the following scenario:

 CPU 0 and CPU 1 are running tasks and CPU 2 is idle

 CPU 1 kicks the Idle Load Balance
 CPU 1 selects CPU 2 as the new Idle Load Balancer
 CPU 2 sets NOHZ_BALANCE_KICK for CPU 2
 CPU 2 sends a reschedule IPI to CPU 2

 While CPU 3 wakes up, CPU 0 or CPU 1 migrates a waking up task A on CPU 2

 CPU 2 finally wakes up, runs task A and discards the Idle Load Balance
       task A quickly goes back to sleep (before a tick occurs on CPU 2)
 CPU 2 goes back to idle with NOHZ_BALANCE_KICK set

Whenever CPU 2 will be selected as the ILB, no reschedule IPI will be sent
because NOHZ_BALANCE_KICK is already set and no Idle Load Balance will be
performed.

We must wait for the sched softirq to be raised on CPU 2 thanks to another
part the kernel to come back to clear NOHZ_BALANCE_KICK.

The proposed solution clears NOHZ_BALANCE_KICK in schedule_ipi if
we can't raise the sched_softirq for the Idle Load Balance.

Change since V1:

- move the clear of NOHZ_BALANCE_KICK in got_nohz_idle_kick if the ILB
  can't run on this CPU (as suggested by Peter)

Signed-off-by: Vincent Guittot <vincent.guittot@linaro.org>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/1370419991-13870-1-git-send-email-vincent.guittot@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Git-commit: 873b4c65b519fd769940eb281f77848227d4e5c1
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[smuckle@codeaurora.org: minor merge resolution for 3.4 in scheduler_ipi()]
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
Change-Id: I3548612057cccc2ecc29429c129c44183083831f

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
cpufreq: interactive: fallback to previous new_freq calculation as it is much more conservative. Also fix the new_freq logic, specially if boosted is true.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
cfg80211: Fix memory leak

When a driver requests a specific regulatory domain after cfg80211 already
has one, a struct ieee80211_regdomain is leaked.

Change-Id: Id28fc9861b9c911a97bd242439eabca097d76258
Reported-by: Larry Finger <Larry.Finger@lwfinger.net>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Git-commit: b7566fc363e23f0efd3fa1e1460f9421cdc0d77e
Git-repo: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
[mattw@codeaurora.org: trivially backport to the msm-3.4 kernel]
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm: vidc: Initialize kernel space stack variables

This change initializes kernel space stack variables
that are passed between kernel space and user space
using ioctls.
Non initialization of these variables may lead to
leakage of memory values from the kernel stack to
user space.

PS2-3: Correct authorship and date.

Change-Id: I5b45f3a7baf9c538fee2ec356cd8545f8b042b5e
CRs-fixed: 556771,563420
Signed-off-by: Deepak Verma <dverma@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm: krait-regulator: fix up CPU_UP_CANCELED handling

The driver handles CPU_UP_CANCELED as if the core went ONLINE. This
leads to smp call functions on that cpu even when the cpu is offline.
Make CPU_UP_CANCELED force bhs on the target cpu, since it is still
offline.

Change-Id: I668dbfd947d836a1f468d57372e73fbd08dd437e
Signed-off-by: Abhijeet Dharmapurikar <adharmap@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm: clock: Don't update clk->parent in clk_set_parent()

Any change to the parent field has to be done between __clk_pre_reparent()
and __clk_post_reparent() to avoid race conditions. So, stop setting the
parent field and leave it to the ops->set_parent() implementations to
update the parent field. All current implementations of ops->set_parent()
already do so.

Change-Id: Idc41bee306881a885335ecb322a21509231048cc
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
msm: clock: Check that round_rate is less than fmax

HW has maximum frequency requirements. Ensure that the clock frequency
returned from clk_round_rate() is within these limits.

Change-Id: I0d4ed5851fc1f9f76c0ad0622cc6609e64e5311f
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>