- 06 Mar, 2015 5 commits
-
-
Bryan Smith authored
Signed-off-by:Bryan Smith <zarboz@gmail.com>
-
rc420head authored
Signed-off-by:rc420head <dennislebhardt@yahoo.com>
-
rc420head authored
Signed-off-by: -
Bryan Smith authored
Signed-off-by: -
Bryan Smith authored
Signed-off-by:
-
- 05 Mar, 2015 14 commits
-
-
rc420head authored
Signed-off-by: -
rc420head authored
Signed-off-by: -
rc420head authored
Signed-off-by: -
Vikram Mulukutla authored
It is a requirement of PLLs in MSM SoCs that the PLL power supplies be enabled while the PLL is running. If the PLL is locked and outputs enabled, turning off the regulator(s) supplying the PLL will cause the PLL to enter an unpredictable state. Now in the CPU_UP_PREPARE notifier, the CPU clocks are prepared and enabled, causing the source HFPLLs to also turn on. Note that the CPU isn't clocked yet. It is possible that execution is pre-empted and the CPU running the notifier enters power collapse. If all other CPUs also enter power collapse, then it is possible for an RPM notification to go out, allowing the RPM to transition the Apps processor to its sleep set. This can result in the HFPLL supplies being turned off while the HFPLL is running, violating the requirement mentioned above. Once the CPU is unclamped, the CPU is effectively unclocked, due to the HFPLL being in an unknown state. There is a check that is enabled in the PM code's CPU_UP_PREPARE notifier callback. This check ensures that the problematic RPM notification cannot occur until the core that is being brought online also enters power collapse. However, there is no ordering guarantee between that PM's hotplug notifier callback's execution and the cpufreq hotplug notifier callback's execution. This ordering depends on program link order, which is unreliable. It is necessary to ensure that once the HFPLL is enabled, the RPM cannot transition apps to its sleep set. Move the enabling of the CPU clocks to the CPU_STARTING notifier, which runs on the CPU bring brought online. The CPU_STARTING notifier is guaranteed to run after the CPU_UP_PREPARE notifier, which implies that the aforementioned do-not-notify-rpm check is executed *before* the HFPLL is enabled. Therefore even if all cores enter power collapse after the HFPLL is enabled, the HFPLL supplies are guaranteed to stay on, or the CPU clock is switched to the safe source and the HFPLL is turned off. CRs-Fixed: 622738 Change-Id: I136841405806c07e755919859e649ded0c719abb Signed-off-by:Vikram Mulukutla <markivx@codeaurora.org>
-
Junjie Wu authored
When CPUs are in sync, only CPU0 has a non-NULL cpu_clk. clk_get_rate() on other cpu_clk will return 0. msm_cpufreq_get_freq() is used in multiple places in cpufreq framework to determine current hardware frequency. Fix msm_cpufreq_get_freq() to return the right hardware frequency for systems with synchronous CPUs. Change-Id: I6a880764ad51fa9a257a328798b38d574750686a Signed-off-by:Junjie Wu <junjiew@codeaurora.org>
-
Patrick Daly authored
Fix an incorrect patch conflict resolution which results in failing to initialize the cpufreq policy correctly when using an old acpuclock driver version. Change-Id: If8743a2608e720258ebc710718c3041144c00f10 CRs-fixed: 612226 Signed-off-by:Patrick Daly <pdaly@codeaurora.org>
-
Patrick Daly authored
The MSM CPUfreq driver defines a mapping from cpu number to clock pointer. On SOCs with synchronous cpus, only the mapping for cpu#0 is defined, even though there may be more than 1 cpu. Handle this case by skipping certain unnecessary initialization steps for SOCs with synchronous cpus. Signed-off-by:
-
myfluxi authored
acpuclk_get_rate() is broken, so don't even try to call it as it will invoke clk_get_rate() anyway.
-
myfluxi authored
acpuclk_get_rate() is broken, quick fix it by returning msm_cpufreq_get_freq to avoid regressions.
-
-
-
rc420head authored
Signed-off-by: -
rc420head authored
Signed-off-by: -
rc420head authored
Signed-off-by:
-
- 04 Mar, 2015 21 commits
-
-
rc420head authored
Signed-off-by: -
Bryan Smith authored
Signed-off-by: -
Bryan Smith authored
Signed-off-by: -
Bryan Smith authored
Signed-off-by: -
Bryan Smith authored
Signed-off-by: -
Bryan Smith authored
Signed-off-by: -
Bryan Smith authored
Signed-off-by: -
Bryan Smith authored
Signed-off-by: -
Paul Reioux authored
bump version to 3.6 Signed-off-by:
Paul Reioux <reioux@gmail.com> Signed-off-by:
flar2 <asegaert@gmail.com>
-
Paul Reioux authored
with newer hardware revisions coming from Qualcomm, single register lock control isn't sufficient to cover both playback and recording usage scenarios bump to version 3.5 Signed-off-by:
-
Paul Reioux authored
Signed-off-by:
-
Paul Reioux authored
Bump driver version to 3.4 Signed-off-by:
-
Paul Reioux authored
bump driver version to 3.3 Signed-off-by:
-
Paul Reioux authored
Signed-off-by:
-
Paul Reioux authored
bump to version 3.2 Signed-off-by:
-
Paul Reioux authored
Signed-off-by:
-
Paul Reioux authored
(Use this only for devices with audio reset issues) Also bump version to 3.1 Signed-off-by:
-
Paul Reioux authored
Signed-off-by:
-
Paul Reioux authored
This is first official GPL release based on my private implementation. This release has been tested for xperia Z officially. It may work with other devices using the same WCD9320 Audio Codec as well, but not tested Signed-off-by:
-
Paul Reioux authored
Signed-off-by:
-
myfluxi authored
It does not make sense to run kgsl on high and devfreq on regular priority. Signed-off-by:
-
