Bugs Fixed + stuck_on_sampling
cpufreq_lulzactive(q): some fixes and refactorings
get closer to stock
mali: prevent gpu boost when mali is powered down
mali: reduce utilization sampling timeout (by AndreiLux) and make it variable
bccmd is bccmd, not brcm_poke_helpe (fixes bluetooth)
ondemand: cpuidle detection

I found a problem with the ondemand governor while in earlysuspend
suspend mode (ondemand keeping the freq close to the max at all times
despite near 0% load). The problem is that the cpu starts to go in
long cpuidle cycles, a sampling_rate of 10000 (usec) is applied only
once in a while and the real sampling_rate becomes 1 second (or more).

So when a wakeup happens we return to the 10000usec sampling rate. The
ondemand sees lots of activity after the wakeup but those "loads" must
be adjusted down if the previous wall_time delta was huge and the
current one is tiny. We're too close to long cpuidle to worry about
the cpu freq anyway and it may be just a jitter load that if we take
into account without adjusting it down, will lead to the next long
cpuidle to be entered at the max freq again, and this repeats forever.

So my solution is to tweak the ondemand to scale down the "load"
according to the decrease in the wall_time delta ratio
(deep_sleep_ratio variable). This allows the CPU to stay at the lowest
freq during the deep sleeps even when the ondemand governor is enabled
and the sampling_rate is set to 10000. (setting the sampling_rate to
values >100000 would also tend to hide the problem but it'd screw the
interactive behavior by running at the lowest frequency for too long
during interactive usage)

During interactive usage with the screen on (not in earlysuspend
mode), or during playback or voip with screen off the deep_sleep_rate
is set to 1 practically all the time so it won't alter the behavior of
the ondemand governor unless the system is very idle (and in turn when
we want it to stay at low freq).

Change-Id: If0391e6d6c41c1c8c9fa590502e88e681a800b04

Signed-off-by: Andrea Arcangeli <andrea@cpushare.com>
pegasusq (based on ondemand): cpuidle detection

I found a problem with the ondemand governor while in earlysuspend
suspend mode (ondemand keeping the freq close to the max at all times
despite near 0% load). The problem is that the cpu starts to go in
long cpuidle cycles, a sampling_rate of 10000 (usec) is applied only
once in a while and the real sampling_rate becomes 1 second (or more).

So when a wakeup happens we return to the 10000usec sampling rate. The
ondemand sees lots of activity after the wakeup but those "loads" must
be adjusted down if the previous wall_time delta was huge and the
current one is tiny. We're too close to long cpuidle to worry about
the cpu freq anyway and it may be just a jitter load that if we take
into account without adjusting it down, will lead to the next long
cpuidle to be entered at the max freq again, and this repeats forever.

So my solution is to tweak the ondemand to scale down the "load"
according to the decrease in the wall_time delta ratio
(deep_sleep_ratio variable). This allows the CPU to stay at the lowest
freq during the deep sleeps even when the ondemand governor is enabled
and the sampling_rate is set to 10000. (setting the sampling_rate to
values >100000 would also tend to hide the problem but it'd screw the
interactive behavior by running at the lowest frequency for too long
during interactive usage)

During interactive usage with the screen on (not in earlysuspend
mode), or during playback or voip with screen off the deep_sleep_rate
is set to 1 practically all the time so it won't alter the behavior of
the ondemand governor unless the system is very idle (and in turn when
we want it to stay at low freq).

Change-Id: If0391e6d6c41c1c8c9fa590502e88e681a800b04

Signed-off-by: Andrea Arcangeli <andrea@cpushare.com>
modem_if: Stop printing IPC RX/TX messages
max8997: Implement Accessory Charger Adapter support.

Accessory Charger Adapter is a device which allows one to power both
the OTG A- and B-devices. It identifies itself via a particular
pull-down value on the ID pin.

Accessory Charger Adapter is defined in Battery Charging Specification,
section 6.2 (as of rev 1.2).

Change-Id: I64c390d5c8300229df474d5fcf9d50aeb14bb6bc
bcmdhd: change packet filter settings to block multicast

Conflicts:

	drivers/net/wireless/bcmdhd/src/dhd/sys/dhd_linux.c
usb gadget: fix adb root, use two luns

When adb is enabled, only connect the gadget when adbd is ready. If adbd
dies or is restarted (e.g. "adb root"), the gadget is disconnected when
the adb device is close, and it is re-connected once adb re-open the
device.

- Add callbacks to adb, similar to FunctionFs callbacks, to notify the
  gadget when the daemon is ready or closed.
- Refcount calls to android_enable/android_disable to enable the gadget
  only once all the function daemons are ready.
- Add enable/disble to android_usb_function to notify the function when
  it is added/removed from the list of enabled functions.

Signed-off-by: Benoit Goby <benoit@android.com>

Conflicts:

	drivers/usb/gadget/android.c
compatibility patches for gcc 4.7

Conflicts:

	Makefile
	arch/arm/boot/compressed/Makefile
max8997_vibrator: user configurable vibrator intensity

Based on codeworkx's GT-I9300 implementation

Conflicts:

	drivers/motor/max8997_vibrator.c
mali: increase voltage for the lowest level. fix freq steps.
charge_current: set defauts to 650mA
v4.1.3 config