cpufreq: Save user policy min/max instead of policy min/max during hotplug

When a CPU is hotplugged off, various fields of the policy are saved so
that they can be restored when the CPU is hotplugged back in.

The existing code saves the policy min/max field during hotplug remove and
restores it into user policy min/max during hotplug add. This results in
the loss of the user policy min/max values across a hotplug remove/add.

Fix it by saving the user policy min/max instead of policy min/max during
hotplug remove. During a hotplug add, after user policy min/max is
restored, the policy min/max is already recomputed. So, there's no risk of
going beyound any limits imposed by the CPUFREQ_ADJUST/INCOMPATIBLE
notifiers.

Bug: 17889870
Change-Id: Ib8e09fa324c1f80f095c5754b5dcf2685e8e4a66
Signed-off-by: Saravana Kannan <skannan@codeaurora.org>
Signed-off-by: Naveen Ramaraj <nramaraj@codeaurora.org>
cpufreq: Always allow update of user policy

In the cases where the system boots up in a constraint with policy min and
max lower than cpuinfo min/max, and user tries to set a higher user
policy min, the value would be overridden during the verifying the
limits.

Once user initiates the sysfs write the previous user policy is
maintained in policy min and max thus changing the limits for verification
of the current policy. Once the verification is completed restore the
current user policy min/max with the updated values if any. This would take
care of cases uwhere user policy min/max input is higher/lesser than the
current min and max.

Bug: 17889870
Change-Id: I5ad92ba05162cb5c32c3ba3fdae21d2e505493d3
Signed-off-by: Taniya Das <tdas@codeaurora.org>
Signed-off-by: Naveen Ramaraj <nramaraj@codeaurora.org>
Revert "Revert "Revert "hammerhead: Enable /dev/diag"""

Bug: 12134070

This reverts commit 56a0a3a049bef3ad23ecaf0c80ae95f36d7bd6be.
Inital commit: remove useless stuff, add defconfig

Signed-off-by: engstk <eng.stk@sapo.pt>
Makefile: Remove wrapper

Signed-off-by: Chet Kener <Cl3Kener@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
Makefile: Overhaul

Signed-off-by: Chet Kener <Cl3Kener@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
Disable Tracer

Signed-off-by: Chet Kener <Cl3Kener@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
Update Piggy

Signed-off-by: Chet Kener <Cl3Kener@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
Update arch/arm/Makefile

Signed-off-by: Chet Kener <Cl3Kener@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
Use -O3 for now

Signed-off-by: Chet Kener <Cl3Kener@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
Disable Tracer Part 2

Signed-off-by: Chet Kener <Cl3Kener@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
Netfilter: Fix Build Error

Signed-off-by: Chet Kener <Cl3Kener@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
Disable More Tracer

Signed-off-by: Chet Kener <Cl3Kener@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
block: row: Remove warning massage from add_request

Regular priority queues is marked as "starved" if it skipped a dispatch
due to being empty. When a new request is added to a "starved" queue
it will be marked as urgent.
The removed WARN_ON was warning about an impossible case when a regular
priority (read) queue was marked as starved but wasn't empty. This is
a possible case due to the bellow:
If the device driver fetched a read request that is pending for
transmission and an URGENT request arrives, the fetched read will be
reinserted back to the scheduler. Its possible that the queue it will be
reinserted to was marked as "starved" in the meanwhile due to being empty.

CRs-fixed: 517800
Change-Id: Iaae642ea0ed9c817c41745b0e8ae2217cc684f0c
Signed-off-by: Tatyana Brokhman <tlinder@codeaurora.org>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
block: row: add magic values.

Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
mm: push readahead to 512kB.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
msm: kgsl: Report GPU frequency correctly in sysfs

On our device, slumber is enabled (qcom,strtstp-sleepwake).

Change-Id: Id4444c602ff4dfcd9b74ab8d8124a0061e287bda
Signed-off-by: engstk <eng.stk@sapo.pt>
msm: mdss: Display gamma control

TODO: confirm rgb channels, identify other tunables, cleanup,
apply values without switching screen (off and) on.

sysfs: /sys/devices/qcom,mdss_dsi_jdi_command_ors.69/*
Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
msm: mdss: Apply commands values without switching screen (off and) on

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
msm: mdss: Remove tunable for command 32

Even slight changes look ugly or distort the screen.

Signed-off-by: Francisco Franco <franciscofranco.1990@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>