msm: cpufreq: Avoid NULL clock pointer references

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.

Conflicts:
	arch/arm/mach-msm/cpufreq.c

Change-Id: Iaeba7a8615e3cb7da2c725250db92595450bfa46
Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
msm: cpufreq: Correct synchronous cpu logic

Fix an incorrect patch conflict resolution which results in failing to
initialize the cpufreq policy correctly when using an old acpuclock driver
version.

Signed-off-by: Patrick Daly <pdaly@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: cpufreq: Move the enabling of the CPU/L2 clocks to CPU_STARTING

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>
Kernel 8.0.1 SOD BUG FIX.
Merge branch 'LG-STOCK-KK' of https://github.com/dorimanx/Dorimanx-LG-G2-D802-Kernel into merge
CPUFREQ: Fixed OLD grenpa ondemandplus, was making kernel panic!

on store_inter_hifreq and store_inter_lofreq
qcom: rpm-smd: Mask the interrupt before sending the sleep set.

Sending a sleep set would cause an SMD interrupt to fire. If the
interrupt was previously affine to a different CPU, it could cause a
premature wakeup of that CPU. Prevent this by masking the interrupt
before sending the sleep set.

Signed-off-by: Mahesh Sivasubramanian <msivasub@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: tspp: Request IRQs on first use

Reserving the IRQs on driver initialization is redundant and should
be done only when client first uses the driver. Also, it may prevent
transition to power saving modes.
Move IRQ requests to be done when first stream is opened, and free
when last stream is closed.

Signed-off-by: Gilad Broner <gbroner@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
tspp: fix bam irq request preventing sleep

Registering and resetting BAM device upon initialization of tspp
driver requests bam irq resource, which prevents entering sleep.
Instead, BAM device is now initialized only when first needed which
is when the first channel is opened. BAM device is uninitialized
when channel is closed.

Signed-off-by: Gilad Broner <gbroner@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
msm: tspp: use an actual device structure for DMA allocation

Not supplying the device struct for arch arm64 causes some DMA
functions to issue runtime warning and fail.

Signed-off-by: Gilad Broner <gbroner@codeaurora.org>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
platform: msm: Fix compile when CONFIG_PFT is not set

Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
Added Synapse APP to boot install.
Fix drivers/usb/serial/usb_wwan.c driver.
Config Update! enabled USB SERIAL + WWAN + OPTION for PPP Widget

https://play.google.com/store/apps/details?id=de.draisberghof.pppwidget&hl=en
Config Update. USE USB SERIAL AS IN KERNEL CODE.
Merge branch 'LG-STOCK-KK' of https://github.com/dorimanx/Dorimanx-LG-G2-D802-Kernel into merge