ARM: dts: msm: List all possible BW levels in cpubw for 8974

With the cpubw_hwmon devfreq governor available in Krait based CPUs, it's
important to list all the possible BW levels to get all the benefit from
the cpubw_hwmon governor. Also fix the use of a non-existent BW level in
msm-cpufreq device.

Signed-off-by: Panwar Vivek <vpanwa@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
PM / devfreq: Add a new target flag for the performance governor

The new flag for the devfreq profile->target() function is used
by the performance governor to notify the driver that the device
should wakeup on the max frequency.

Signed-off-by: Vladimir Razgulin <vrazguli@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
net/wireless: Fix kernel crash while doing iwlist scan

Remove the code that extracts the information of the rates without
the check for the corresponding bands. Also , this part of the code
is redundant as the following code checks for the same, which also
prevents a possible crash.

Signed-off-by: Ming-yi Lin <mylin@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: kgsl: Fix range checking for profile wrapping

There is a chance that the profile code will not wrap correctly.
This can cause the in stream profiling to cause buffer pre-run
or undershoot (accessing data before the buffer). Fix logic to
cause the correct wrapping.

Signed-off-by: Carter Cooper <ccooper@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: kgsl: Don't open kgsl device in erroneous case

If kgsl_get_process_private() returns NULL, it goes to
err_stop with result = -ENOMEM. If open_count is 0,
adreno_stop() overwrites the result variable with 0.
This leads to kgsl_open() to be successful while it
shouldn't.

Signed-off-by: Prabhat Awasthi <pawasthi@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Merge pull request #2 from Root-StylE/exp

Exp
defconfig: fix mismatches
vibrator: use 75 as default strength
Merge pull request #3 from Root-StylE/test

Merge pull request #2 from Root-StylE/exp
Merge pull request #4 from Root-StylE/exp

Exp
PM: Introduce suspend state PM_SUSPEND_FREEZE

PM_SUSPEND_FREEZE state is a general state that
does not need any platform specific support, it equals
frozen processes + suspended devices + idle processors.

Compared with PM_SUSPEND_MEMORY,
PM_SUSPEND_FREEZE saves less power
because the system is still in a running state.
PM_SUSPEND_FREEZE has less resume latency because it does not
touch BIOS, and the processors are in idle state.

Compared with RTPM/idle,
PM_SUSPEND_FREEZE saves more power as
1. the processor has longer sleep time because processes are frozen.
   The deeper c-state the processor supports, more power saving we can get.
2. PM_SUSPEND_FREEZE uses system suspend code path, thus we can get
   more power saving from the devices that does not have good RTPM support.

This state is useful for
1) platforms that do not have STR, or have a broken STR.
2) platforms that have an extremely low power idle state,
   which can be used to replace STR.

The following describes how PM_SUSPEND_FREEZE state works.
1. echo freeze > /sys/power/state
2. the processes are frozen.
3. all the devices are suspended.
4. all the processors are blocked by a wait queue
5. all the processors idles and enters (Deep) c-state.
6. an interrupt fires.
7. a processor is woken up and handles the irq.
8. if it is a general event,
   a) the irq handler runs and quites.
   b) goto step 4.
9. if it is a real wake event, say, power button pressing, keyboard touch, mouse moving,
   a) the irq handler runs and activate the wakeup source
   b) wakeup_source_activate() notifies the wait queue.
   c) system starts resuming from PM_SUSPEND_FREEZE
10. all the devices are resumed.
11. all the processes are unfrozen.
12. system is back to working.

Known Issue:
The wakeup of this new PM_SUSPEND_FREEZE state may behave differently
from the previous suspend state.
Take ACPI platform for example, there are some GPEs that only enabled
when the system is in sleep state, to wake the system backk from S3/S4.
But we are not touching these GPEs during transition to PM_SUSPEND_FREEZE.
This means we may lose some wake event.
But on the other hand, as we do not disable all the Interrupts during
PM_SUSPEND_FREEZE, we may get some extra "wakeup" Interrupts, that are
not available for S3/S4.

The patches has been tested on an old Sony laptop, and here are the results:

Average Power:
1. RPTM/idle for half an hour:
   14.8W, 12.6W, 14.1W, 12.5W, 14.4W, 13.2W, 12.9W
2. Freeze for half an hour:
   11W, 10.4W, 9.4W, 11.3W 10.5W
3. RTPM/idle for three hours:
   11.6W
4. Freeze for three hours:
   10W
5. Suspend to Memory:
   0.5~0.9W

Average Resume Latency:
1. RTPM/idle with a black screen: (From pressing keyboard to screen back)
   Less than 0.2s
2. Freeze: (From pressing power button to screen back)
   2.50s
3. Suspend to Memory: (From pressing power button to screen back)
   4.33s

From the results, we can see that all the platforms should benefit from
this patch, even if it does not have Low Power S0.

Signed-off-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>

Conflicts:
	kernel/power/main.c
	kernel/power/suspend.c
mm: slub: Tune to perform faster

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: implement ARCH_RANDOM

Currently, the software random number generator is not intialized
until relatively late in the boot process. Software that relies on
random numbers early will not be reliable. Entropy sources are
available early but not early enough for some use cases which means
that moving the software random number generation earlier is not an
option. As an alternate solution, implement the functions associated
with CONFIG_ARCH_RANDOM. These functions currently make a call into
trustzone to get reliable random numbers. The functions are disabled
once the regular random number generator is sufficiently reliable.

Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
defconfig: add arch_random
usb: gadget: Fix race condition in connect/disconnect

This commit fixes race condition in fast connect/disconnect
of USB cable. This race condition can also be reproduced in
USB composition change. Thus this commit also adds support
for USB composition change for BAMtoBAM compositions.

CRs-fixed: 463705
Change-Id: I21abaff6a64bb405ce2d698605aff8e0050ef8d6
Signed-off-by: Anna Perel <aperel@codeaurora.org>
Signed-off-by: Bar Weiner <bweiner@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: let max/min boot frequencies be stock

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
cpufreq: allow for low CPU clock policy when hotplugging new cores

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

Conflicts:
	arch/arm/mach-msm/cpufreq.c
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm:rq_stats: Register for Cpufreq policy notification

Currently the load of the system is calculated using the max
frequency that is read during startup(It does not get updated
when the policy changes). As a result, the average load of the
system is incorrectly calculated and the system might not bring
the cpus online to manage the additional load. This
reduces the performance of the system.

To fix this issue, register rq_stats to receive cpufreq policy
notifications. Update the policy's max frequency when a
notification is received and use that value to calculate the load.

Change-Id: Icc78e28c736c170e198f723fd96c13dfb2dafe8a
Signed-off-by: Archana Sathyakumar <asathyak@codeaurora.org>
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
ARM: Implement kexec-hardboot

"Allows hard booting (i.e., with a full hardware reboot) to a kernel
previously loaded in memory by kexec.  This works around the problem of
soft-booted kernel hangs due to improper device shutdown and/or
reinitialization."
More info in /arch/arm/Kconfig.

Original author: Mike Kasick <mike@kasick.org>

Vojtech Bocek <vbocek@gmail.com>:
  I've ported it to hammerhead, it is based of my mako/grouper port, which is
  based of Asus TF201 patch ported by Jens Andersen <jens.andersen@gmail.com>

  Hammerhead is the first device I've ported this patch to which uses
  device tree binary instead of atags. It is also rather picky - its
  bootloader erases first 128MB of RAM on reboot, so following hacks had
  to be applied:
  * Copy dtb to location passed in r2 before jumping to kexecd' kernel,
    the kernel would just freeze when I left dtb above 128MB of RAM.
  * Copy kexecd' kernel to location in the first 128MB before jumping to it,
    the decompressor operates very slowly if the kernel is above the cached
    area, copying it lower and decompressing it afterwards is much faster.

  Same as my mako/flo patches, the guest kernel does not require any
  modifications, kexec-hardboot is equivalent to standard kexec.

  To support dtb, following commit was backported from the mainline:
    commit 4cabd1d9625c7d88acd143f4021fbef75394f154
    Author: Matthew Leach <matthew.leach@arm.com>
    Date:   Fri Sep 21 18:56:02 2012 +0100

      ARM: 7539/1: kexec: scan for dtb magic in segments

      This patch allows a dtb to be passed to a new kernel using the kexec
      mechinism.

      When loading segments from userspace, scan each segment's first four
      bytes for the dtb magic. If this is found set the kexec_boot_atags
      parameter to the relocate_kernel code to the phyical address of this
      segment.

  and fixes of this commit:
    c564df4db85aac8d1d65a56176a0a25f46138064
    2456f44dd7a9aaffc2cd21a13f78198b3d94da08

ayysir <dresadd09691@gmail.com>:
  kexec: use mem_text_write_kernel_word to set reboot_code_buffer args
  in order to avoid protection faults (writes to read-only
  kernel memory) when CONFIG_STRICT_MEMORY_RWX is enabled.

Signed-off-by: Vojtech Bocek <vbocek@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: ipc: Possible memory corruption due to Sign Conversion

msm_ipc_router_skb_to_buf() takes an unsigned argument and assigns the
same to a signed local variable. This might cause issues when the value
of the argument is too high.

Change the datatype of the local variable to unsigned.

Signed-off-by: Zaheerulla Meer <zmeer@codeaurora.org>