Add simple building script
Gcc 4.8 building fixes
Fixes to build with linaro 4.10
Revert "adding Ramdidk"

This reverts commit 57c7270d279989552dc237d7b6f9eb7b1f44c5b6.
Revert "adding Ramdidk"

This reverts commit b3af42d4462cb44990a0ba023ebae19b104e2607.
add CM ramdisk
cpufreq: add generic get_cpuidle_time

Easier to maintain this in one place.

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
mach-msm: disable kernel-side mpdecision

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
arm: add own hotplug driver

Simple SMP hotplug driver, based on @franciscofranco implementation.

For now without the suspend/resume logic, since this needs
to be redone.

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
various log cleanups

Signed-off-by: Blechd0se <alex.christ@hotmail.de>

Conflicts:
	drivers/media/platform/msm/camera_v2/pproc/cpp/msm_cpp.c
hotplug: delete deprecated earlysuspend handler

There is no proper support of earlysuspend in this kernel,
so better delete this stuff until there is a better option
available.
Also adjusting a few tunables.

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
hotplug: add tunable sysfs entries

Allowing to change the current sampling_rate as well
as the first threshold (single core) and second threshold
(all cores).
Actual path will be: /sys/kernel/hotplug_control

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
hotplug: remove single_core_load and all_core_load

Those sysfs caused instability, which is something i don't want.

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
hotplug: delay initial workqueue start

By delaying it a bit, we workaround some kind of
race condition. Enabling effectively four cores
during boot might be a good idea anyway.

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
hotplug: fix core 4 would eventually not go down

We only check if our current cpu is online, not thinking about
which position it might be currently. This would result in a very
long uptime for the fourth cpu even when there is zero load.

The solution is actually pretty simple; we just check every case
and offline accordingly to that. Also reducing the overhead of the
driver a bit and cleaning up unneeded stuff.

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
cpufreq: interactive: fix compiling issues

This commit is just some sort of placeholder during the
merging prcess. The complete logic will be replaced later.

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
workqueue: change BUG_ON() to WARN_ON()

This BUG_ON() can be triggered if you call schedule_work() before
calling INIT_WORK().  It is a bug definitely, but it's nicer to just
print a stack trace and return.

Reported-by: Matt Renzelmann <mjr@cs.wisc.edu>
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>
workqueue: Catch more locking problems with flush_work()

If a workqueue is flushed with flush_work() lockdep checking can
be circumvented. For example:

 static DEFINE_MUTEX(mutex);

 static void my_work(struct work_struct *w)
 {
         mutex_lock(&mutex);
         mutex_unlock(&mutex);
 }

 static DECLARE_WORK(work, my_work);

 static int __init start_test_module(void)
 {
         schedule_work(&work);
         return 0;
 }
 module_init(start_test_module);

 static void __exit stop_test_module(void)
 {
         mutex_lock(&mutex);
         flush_work(&work);
         mutex_unlock(&mutex);
 }
 module_exit(stop_test_module);

would not always print a warning when flush_work() was called.
In this trivial example nothing could go wrong since we are
guaranteed module_init() and module_exit() don't run concurrently,
but if the work item is schedule asynchronously we could have a
scenario where the work item is running just at the time flush_work()
is called resulting in a classic ABBA locking problem.

Add a lockdep hint by acquiring and releasing the work item
lockdep_map in flush_work() so that we always catch this
potential deadlock scenario.

Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Reviewed-by: Yong Zhang <yong.zhang0@gmail.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>
lockdep: fix oops in processing workqueue

Under memory load, on x86_64, with lockdep enabled, the workqueue's
process_one_work() has been seen to oops in __lock_acquire(), barfing
on a 0xffffffff00000000 pointer in the lockdep_map's class_cache[].

Because it's permissible to free a work_struct from its callout function,
the map used is an onstack copy of the map given in the work_struct: and
that copy is made without any locking.

Surprisingly, gcc (4.5.1 in Hugh's case) uses "rep movsl" rather than
"rep movsq" for that structure copy: which might race with a workqueue
user's wait_on_work() doing lock_map_acquire() on the source of the
copy, putting a pointer into the class_cache[], but only in time for
the top half of that pointer to be copied to the destination map.

Boom when process_one_work() subsequently does lock_map_acquire()
on its onstack copy of the lockdep_map.

Fix this, and a similar instance in call_timer_fn(), with a
lockdep_copy_map() function which additionally NULLs the class_cache[].

Note: this oops was actually seen on 3.4-next, where flush_work() newly
does the racing lock_map_acquire(); but Tejun points out that 3.4 and
earlier are already vulnerable to the same through wait_on_work().

* Patch orginally from Peter.  Hugh modified it a bit and wrote the
  description.

Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Reported-by: Hugh Dickins <hughd@google.com>
LKML-Reference: <alpine.LSU.2.00.1205070951170.1544@eggly.anvils>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>
workqueue: drop CPU_DYING notifier operation

Workqueue used CPU_DYING notification to mark GCWQ_DISASSOCIATED.
This was necessary because workqueue's CPU_DOWN_PREPARE happened
before other DOWN_PREPARE notifiers and workqueue needed to stay
associated across the rest of DOWN_PREPARE.

After the previous patch, workqueue's DOWN_PREPARE happens after
others and can set GCWQ_DISASSOCIATED directly.  Drop CPU_DYING and
let the trustee set GCWQ_DISASSOCIATED after disabling concurrency
management.

Signed-off-by: Tejun Heo <tj@kernel.org>
Acked-by: "Rafael J. Wysocki" <rjw@sisk.pl>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>