msm: pm: Add API to enable/disable retention mode
On 8974 targets, retention mode voltage is controlled by the LDO
regulator, which in turn is powered through a ganged PMIC regulators. At
certain low voltage levels, the ganged PMIC will not be able to power
the LDO retention voltage. The regulator framework would invoke this
API to enable/disable retention mode in these scenarios.

When disabling retention modes, send a IPI to wakeup all online cores
out of idle, to ensure that no core is in a retention low power mode.
Also, disabled support for retention during suspend/hotplug operations
to ensure that a CPU isn't already in retention when the voltage is
lowered. This shouldn't have an effect on suspend, as the driver always
chooses the deepest sleep mode for suspend/hotplug.

Change-Id: I0af18168968c2aaf05ca99188d30762612c87de6
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>

Conflicts:
	arch/arm/mach-msm/no-pm.c
	arch/arm/mach-msm/pm-data.c
	arch/arm/mach-msm/pm.h
msm: pm-8x60: Disable premption in msm_pm_enable_retention

msm_pm_retention_enable() makes smp_call_function_many to ensure that
when a retention is disabled, the cores come out of its low power mode.
Per the smp_call_function_many documentations, preemption should be
disabled before invoking the API.

CRs-fixed: 463188
Change-Id: I4ae9137e8f8e821af729becd0e2d6e6886d5e787
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
msm: pm-8x60: Add early return to msm_pm_enable_retention()

If retention is already disabled, it is not necessary to send IPIs to
the running CPUs to wake them up. Insert an early return for this
scenario to reduce overhead during Krait rail voltage scaling, which
calls this API on every voltage change.

Change-Id: I5db0bafae187ff8a68488e86d4787df9c45787e4
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
msm: pm-8x60: Fix bug where CPU doesn't enter PC
When Krait regulator disables retention mode, an incorrect ordering of
the switch case disables power collapse.

Change-Id: Ic58b0356530e9ecb10d379e2f99d14016bc251e4
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
msm: pm: support retention on CPU0 at suspend
drivers/staging: Configurable android log buffer sizes
Purpose is reduce the buffer size accordingly and observe savings
in the total kernel static size, which is useful for
memory constrained devices.

Change-Id: I926ab85213c82924ec483327d5aa248372efc604
Signed-off-by: Bhargav Upperla <bhargavuln@codeaurora.org>

and reduce log buffer size to 128K for mako --mrg666
msm: acpuclock-krait: Add __init markings to 'krait vmin' functions

These functions are only called during boot and can be safely
discarded after.

Change-Id: I6bf20a42fec8b82c3f35e1c042b799ef2dad7790
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
msm: acpuclock-krait: Only print supported number of frequencies once

The current code prints the number of CPU frequencies supported
once for each possible CPU, even though the number of supported
frequencies is the same for each CPU. Cut down on log noise by
printing this number only once.

For example, print:

  [ 0.412932] acpuclk-8974 qcom,acpuclk.23: CPU Frequencies Supported: 11

...instead of:

  [ 0.426013] acpuclk-8974 qcom,acpuclk.23: CPU0: 11 frequencies supported
  [ 0.426052] acpuclk-8974 qcom,acpuclk.23: CPU1: 11 frequencies supported
  [ 0.426089] acpuclk-8974 qcom,acpuclk.23: CPU2: 11 frequencies supported
  [ 0.426124] acpuclk-8974 qcom,acpuclk.23: CPU3: 11 frequencies supported

Change-Id: Iaf15970e6cfcfaec79c0edf8564cab9141fbc05f
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
msm: acpuclock-krait: Remove inapplicable 8064 errata workaround

The secondary MUX switching errata is worked around in the secure
warm-boot path, and does not require an in-kernel workaround.

For devices with older warm-boot code (without the workaround),
the removal of the kernel workaround is also safe. The errata
symptoms can only manifest themselves after an L2 power-collapse,
which can't occur until after all Krait CPUs have been brought
online at least once. Since the secondary MUX is only touched by
acpuclock when onlining CPUs for the first time, the MUX will
never be switched after L2 power-collapse.

Change-Id: If675cfab7f325a9f7af6e06ff5ed67bd65461f20
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>

Conflicts:
	arch/arm/mach-msm/acpuclock-krait.c
msm: acpuclock-krait: Add support for HFPLL lock detect bit polling

Some recent devices have a lock detect bit that can be used to
determine when the HFPLL frequency has stabilized. Add optional
support for polling this bit instead of delaying pessimistically
for 60us.

Change-Id: I38bb0c98e36f66fc5efadf9189dbe817f648a972
Signed-off-by: Matt Wagantall <mattw@codeaurora.org>
msm: pm-8x60: Do not default to WFI when not enabled

Return MSM_PM_SLEEP_MODE_NOT_SELECTED in msm_pm_idle_prepare as the
default mode instead of WFI. Skip enter low power mode when this
mode is selected.

Change-Id: Id4a07ba1353b358726c81ed441e0327a9154de8a
Signed-off-by: Priyanka Mathur <pmathur@codeaurora.org>
msm: pm-8x60: Use ktime_get for suspend stats

During suspend, the sched clock is stopped and the suspends ops
cannot rely on sched clock to report time spent in suspend. Use ktime
interface to determine the time spent in suspend.

Change-Id: Id244cd8d470c45c1edd408e98ccaf84d30c3e253
Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
autosmp: use cpufreq_get and a counter instead of time functions
autosmp: use cpu frequency instead of load average
- less overhead for the system without the additional load calculation
  by autosmp,
- autosmp needs to work with cpu governor in giving adequate computing
  power to system and CPU governor should have the leading role in this
  task since it must respond earlier,
- since frequency is a function of CPU load determined by the CPU
  governor, autosmp becomes more consistent with the CPU governor when
  CPU frequency is used instead of independently calculating the load
  average,
- works in better sync with the CPU governor by giving the priority
  to increasing the frequency before rushing into hotplugging a core or
  dragging the system
- since autosmp follows the CPU governor it automatically adapts when
  governor is changed.
defconfig: disable powersave, performance
autosmp: use a lower frequency limit for unplug
Make sure it is really quiet out there so that unplugging a fairly
loaded core wouldn't be immediately followed by an hotplug due to
a spike in the frequency of other online cores. 600 lower limit should
be low enough for hearing the crickets
Linux 3.4.76
cpufreq: interactive: fix compiling warnings

The gcc warns like:

  cpufreq_interactive.c:745:6: warning: operation on 'ret' may be
undefined [-Wsequence-point]

It was introduced by commit cf0fad49d17cb8273ce555dd5b7afab67d7923bf.

Since sprintf(...) just return 1 (one character) in this case, ret
should not changed.
Just discarding the result of sprintf(...) leads to the result that
the committer of cf0fad49d17cb8273ce555dd5b7afab67d7923bf wants.

Change-Id: Ifed1cef6d6a31c3ed23dad03a567b3b9eddf3a57
Signed-off-by: Chih-Wei Huang <cwhuang@android-x86.org>
Signed-off-by: Dave Daynard <nardholio@gmail.com>
nf: xt_qtaguid: fix handling for cases where tunnels are used.

* fix skb->dev vs par->in/out
When there is some forwarding going on, it introduces extra state
around devs associated with xt_action_param->in/out and sk_buff->dev.
E.g.
   par->in and par->out are both set, or
   skb->dev and par->out are both set (and different)
This would lead qtaguid to make the wrong assumption about the
direction and update the wrong device stats.
Now we rely more on par->in/out.

* Fix handling when qtaguid is used as "owner"
When qtaguid is used as an owner module, and sk_socket->file is
not there (happens when tunnels are involved), it would
incorrectly do a tag stats update.

* Correct debug messages.

Bug: 11687690
Change-Id: I2b1ff8bd7131969ce9e25f8291d83a6280b3ba7f
Signed-off-by: JP Abgrall <jpa@google.com>
sync: Fix a race condition between release_obj and print_obj

Before this change, a timeline would only be removed from the timeline
list *after* the sync driver had its release_obj() called. However, the
driver's release_obj() may free resources needed by print_obj().

Although the timeline list is locked when print_obj() is called, it is
not locked when release_obj() is called. If one CPU was in print_obj()
when another was in release_obj(), the print_obj() may make unsafe
accesses.

It is not actually necessary to hold the timeline list lock when calling
release_obj() if the call is made after the timeline is unlinked from
the list, since there is no possibility another thread could be in --
or enter -- print_obj() for that timeline.

This change moves the release_obj() call to after the timeline is
unlinked, preventing the above race from occurring.

Signed-off-by: Alistair Strachan <alistair.strachan@imgtec.com>