Added zzmoove governor

Change-Id: I5e6ee8328bd47142f623ec3ac702462915d3e537
Adapted zzmoove to i9100

Change-Id: I92393de2330ee59382ea3c1d162637557b94c8b6
Version 0.6a - scaling logic felxibility (in cooperation with Yank555)

Changelog:

  - added check if CPU freq. table is in ascending or descending order and scale accordingly
    (compatibility for systems with 'inverted' frequency table like it is on OMAP4 platform)
    thanks and credits to Yank555
Version 0.7 - slow down (in cooperation with Yank555)

Changelog:

        - reindroduced the 'old way' of hotplugging and scaling in form of the 'Legacy Mode' (macros for enabling/disabling this done by Yank555, thx)
          NOTE: this mode can only handle 4 cores and a scaling max frequency up to 1800mhz.
        - added hotplug idle threshold for a balanced load at CPU idle to reduce possible higher idle temperatures when running on just one core.
          (inspired by JustArchi's observations, thx)
        - added hotplug block cycles to reduce possible hotplugging overhead (credits to ktoonsez)
        - added possibility to disable hotplugging only at suspend (inspired by a request of STAticKY, thx for the idea)
        - introduced hotplug frequency thresholds (credits to Yank555)
        - hotplug tuneables handling optimized (credits to Yank555)
        - added version information tuneable (credits to Yank555)

          for this functions following new tuneables were indroduced:

          legacy_mode                   -> for switching to the 'old' method of scaling/hotplugging. possible values 0 to disable,
                                           any values above 0 to enable (default is 0)
                                           NOTE: the legacy mode has to be enabled by uncommenting the macro ENABLE_LEGACY_MODE below
          hotplug_idle_threshold        -> amount of load under which hotplugging should be disabled at idle times (respectively at scaling minimum).
                                           possible values 0 disable, from 1 to 100 (default is 0)
          hotplug_block_cycles          -> slow down hotplugging by waiting a given amount of cycles before plugging.
                                           possible values 0 disbale, any values above 0 (default is 0)
          disable_hotplug_sleep         -> same as disable_hotplug but will only take effect at suspend.
                                           possible values 0 disable, any values above 0 to enable (default is 0)
          up_threshold_hotplug_freq1    -> hotplug up frequency threshold for core1.
                                           possible values 0 disable and range from over down_threshold_hotplug_freq1 to max scaling freqency (default is 0)
          up_threshold_hotplug_freq2    -> hotplug up frequency threshold for core2.
                                           possible values 0 disable and range from over down_threshold_hotplug_freq2 to max scaling freqency (default is 0)
          up_threshold_hotplug_freq3    -> hotplug up frequency threshold for core3.
                                           possible values 0 disable and range from over down_threshold_hotplug_freq3 to max scaling freqency (default is 0)
          down_threshold_hotplug_freq1  -> hotplug down frequency threshold for core1.
                                           possible values 0 disable and range from min saling to under up_threshold_hotplug_freq1 freqency (default is 0)
          down_threshold_hotplug_freq2  -> hotplug down frequency threshold for core2.
                                           possible values 0 disable and range from min saling to under up_threshold_hotplug_freq2 freqency (default is 0)
          down_threshold_hotplug_freq3  -> hotplug down frequency threshold for core3.
                                           possible values 0 disable and range from min saling to under up_threshold_hotplug_freq3 freqency (default is 0)
          version                       -> show the version of zzmoove governor
Version 0.7a - little fix

Changelog:

        - fixed a glitch in hotplug freq threshold tuneables which prevented setting of values in hotplug down freq thresholds when hotplug
          up freq thresholds were set to 0
Version 0.7b - compatibility improved and forgotten things

Changelog:

        - fixed stuck at max scaling frequency when using stock kernel sources with unmodified cpufreq driver and without any oc capabilities.
        - readded forgotten frequency search optimisation in scaling logic (only effective when using governor soft frequency limit)
        - readded forgotten minor optimisation in dbs_check_cpu function
        - as forgotten to switch in last version Legacy Mode now again disabled by default
        - minor code format and comment fixes
Version 0.7c - again compatibility and optimisations

Changelog:

        - frequency search optimisation now fully compatible with ascending ordered system frequency tables (thx to psndna88 for testing)
        - again minor optimisations at multiple points in dbs_check_cpu function
        - code cleaning - removed some unnecessary things and whitespaces nuked (sry for the bigger diff but from now on it will be clean ;))
        - corrected changelog for previous version regarding limits
Version 0.7d - broken things

Changelog:

    - fixed hotplug up threshold tuneables to be able again to disable cores manually via sysfs by setting them to 0
    - fixed the problem caused by a wrong tuneable apply order of non sticking values in hotplug down threshold tuneables when
      hotplug up values are lower than down values during apply.
      NOTE: due to this change right after start of the governor the full validation of given values to these tuneables is disabled till
      all the tuneables were set for the first time. so if you set them for example with an init.d script or let them set automatically
      with any tuning app be aware that there are illogical value combinations possible then which might not work properly!
      simply be sure that all up values are higher than the down values and vice versa. after first set full validation checks are enabled
      again and setting of values manually will be checked again.
    - fixed a typo in hotplug threshold tuneable macros (would have been only a issue in 8-core mode)
    - fixed unwanted disabling of cores when setting hotplug threshold tuneables to lowest or highest possible value
      which would be a load of 100%/11% in up/down_hotplug_threshold and/or scaling frequency min/max in up/down_hotplug_threshold_freq
Enabled zzmoove governor for n7000

Change-Id: I7062acd47edf8e0456b163eb3b46e15e68edfb8d
ARM: 7668/1: fix memset-related crashes caused by recent GCC (4.7.2) optimizations

Recent GCC versions (e.g. GCC-4.7.2) perform optimizations based on
assumptions about the implementation of memset and similar functions.
The current ARM optimized memset code does not return the value of
its first argument, as is usually expected from standard implementations.

For instance in the following function:

void debug_mutex_lock_common(struct mutex *lock, struct mutex_waiter *waiter)
{
	memset(waiter, MUTEX_DEBUG_INIT, sizeof(*waiter));
	waiter->magic = waiter;
	INIT_LIST_HEAD(&waiter->list);
}

compiled as:

800554d0 <debug_mutex_lock_common>:
800554d0:       e92d4008        push    {r3, lr}
800554d4:       e1a00001        mov     r0, r1
800554d8:       e3a02010        mov     r2, #16 ; 0x10
800554dc:       e3a01011        mov     r1, #17 ; 0x11
800554e0:       eb04426e        bl      80165ea0 <memset>
800554e4:       e1a03000        mov     r3, r0
800554e8:       e583000c        str     r0, [r3, #12]
800554ec:       e5830000        str     r0, [r3]
800554f0:       e5830004        str     r0, [r3, #4]
800554f4:       e8bd8008        pop     {r3, pc}

GCC assumes memset returns the value of pointer 'waiter' in register r0; causing
register/memory corruptions.

This patch fixes the return value of the assembly version of memset.
It adds a 'mov' instruction and merges an additional load+store into
existing load/store instructions.
For ease of review, here is a breakdown of the patch into 4 simple steps:

Step 1
======
Perform the following substitutions:
ip -> r8, then
r0 -> ip,
and insert 'mov ip, r0' as the first statement of the function.
At this point, we have a memset() implementation returning the proper result,
but corrupting r8 on some paths (the ones that were using ip).

Step 2
======
Make sure r8 is saved and restored when (! CALGN(1)+0) == 1:

save r8:
-       str     lr, [sp, #-4]!
+       stmfd   sp!, {r8, lr}

and restore r8 on both exit paths:
-       ldmeqfd sp!, {pc}               @ Now <64 bytes to go.
+       ldmeqfd sp!, {r8, pc}           @ Now <64 bytes to go.
(...)
        tst     r2, #16
        stmneia ip!, {r1, r3, r8, lr}
-       ldr     lr, [sp], #4
+       ldmfd   sp!, {r8, lr}

Step 3
======
Make sure r8 is saved and restored when (! CALGN(1)+0) == 0:

save r8:
-       stmfd   sp!, {r4-r7, lr}
+       stmfd   sp!, {r4-r8, lr}

and restore r8 on both exit paths:
        bgt     3b
-       ldmeqfd sp!, {r4-r7, pc}
+       ldmeqfd sp!, {r4-r8, pc}
(...)
        tst     r2, #16
        stmneia ip!, {r4-r7}
-       ldmfd   sp!, {r4-r7, lr}
+       ldmfd   sp!, {r4-r8, lr}

Step 4
======
Rewrite register list "r4-r7, r8" as "r4-r8".

Signed-off-by: Ivan Djelic <ivan.djelic@parrot.com>
Reviewed-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Dirk Behme <dirk.behme@gmail.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
ARM: 7670/1: fix the memset fix

Commit 455bd4c430b0 ("ARM: 7668/1: fix memset-related crashes caused by
recent GCC (4.7.2) optimizations") attempted to fix a compliance issue
with the memset return value.  However the memset itself became broken
by that patch for misaligned pointers.

This fixes the above by branching over the entry code from the
misaligned fixup code to avoid reloading the original pointer.

Also, because the function entry alignment is wrong in the Thumb mode
compilation, that fixup code is moved to the end.

While at it, the entry instructions are slightly reworked to help dual
issue pipelines.

Signed-off-by: Nicolas Pitre <nico@linaro.org>
Tested-by: Alexander Holler <holler@ahsoftware.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Increase readahead to 2048. (Credit: Trevin Gandhi)

Change-Id: I29f8586e590290cecf20c327cb0b18951eb84b3d
Add permission checking for binder IPC.

Change-Id: Ia224e29427d39a6eeb0800a65ad2a8df2e91bebc

Conflicts:
	drivers/staging/android/binder.c
Do not apply permission checks to private files.

Change-Id: I472d9630de5113667c289dce7e4fdc8eace04e36
Fix security_binder_transfer_binder hook.

Drop the owning task argument to security_binder_transfer_binder
since ref->node->proc can be NULL (dead owner?).
Revise the SELinux checking to apply a single transfer check between
the source and destination tasks.  Owning task is no longer relevant.
Drop the receive permission definition as it is no longer used.

This makes the transfer permission similar to the call permission; it is only
useful if you want to allow a binder IPC between two tasks (call permission)
but deny passing of binder references between them (transfer permission).

Change-Id: I6ec460ede8e07dadc9f52b61534b2b0021617302