msm: pm: Add support to query cpu status

During hotplug operation primary core is required to query
cpu registers to determine whether secondary core has
successfully shutdown.

Change-Id: I81bd47ba851698e86269652afe381b0571ca912a
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
clean
gproj: Add support to query cpu status

Change-Id: I02ec600ef4a1fdbefe9b5be5c9db30736dcc5cd3
msm: hotplug: wait for hotplug completion event from secondary core

Primary core has to wait for hotplug completion event from secondary
core to avoid race between ongoing hotplug and already queued online
event. This also prevent CPU_DEAD notifiers from executing before the
SPM has completed the collapse of the CPU. CPU DEAD notifiers executing
early have been attributed to MDD hardware block for the CPU being
turned off prematurely, resulting in crashes.
The patch also adds support for probing with device tree for 8974
targets.

Change-Id: Ibd35a7c56f42f156a643ca6d531509f019b2a3be
CRs-fixed: 438314
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
msm: avs: Restore core voltage when disabling AVS

AVS changes the core voltage to match the current operating conditions
on the part. Not all frequencies supported by the target have characterized
AVS delay synthesizer (AVSDSCR) values. For frequencies that do not have
AVSDSCR set, AVS is not enabled and so need to operate at the
characterized voltage for that frequency. Disabling AVS does not
however, restore the operating voltage to the value the rail was
configured to. This may cause frequencies that do not have AVSDSCR to
run at lower voltage than prescibed.
Set up the core voltage back to the last known good value when disabling
AVS.

Change-Id: I5389996288fa49e45c469d2a8917e00900261de7
CRs-fixed: 457772
Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
msm: pm: Add support for retention on each core

Allow each core on 8974 to enter retention and retain
the state of the CPU. On 8960 as hardware restriction does
not permit all cores to enter retention at the same time,
allow only core 0 to enter retention when all other cores
are offline to maintain backward compatibility.

CRs-fixed: 437281
Change-Id: I6690e901afc9fa3a27010c264fa3acc9a0722c1a
Signed-off-by: Priyanka Mathur <pmathur@codeaurora.org>
Signed-off-by: Venkat Devarasetty <vdevaras@codeaurora.org>
msm: pm: Update spm retention sequence to support per core retention

On krait revision < 3, power driver is not using full spm sequence and
calling into trustzone as a part of executing krait retention.
Also krait retention is not supported on secondary cores.

krait pass3 is upgraded to use full spm sequence, hence add support
for per core retention and avoid calling into trustzone
while executing retention.

CRs-fixed: 437281
Change-Id: I6a2b3d7c4d0fd5b9a340957b16b940b7a09bbd91
Signed-off-by: Anji Jonnala <anjir@codeaurora.org>
Signed-off-by: Venkat Devarasetty <vdevaras@codeaurora.org>
gproj: Update spm retention sequence to support per core retention

Apply change I6a2b3d7c4d0fd5b9a340957b16b940b7a09bbd91

Change-Id: I7056725ec808fb39892825ac8d81d690b678f9a9
msm: board-8064: Initialize SPM driver earlier than thermal

Thermal driver needs to be able to do core control and force cores to
be offline during certain thermal conditions. SPM driver is needed for
cores to do power collapse.

CRs-Fixed: 460083
Change-Id: Id64fe7529438aad68a515c19317db2b95b8b9b65
Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>
gproj: Initialize SPM driver earlier than thermal

Apply change Id64fe7529438aad68a515c19317db2b95b8b9b65

Change-Id: I06dc32e7275467b894352a044b7d2e2896564fef
msm: pm-data: Enable powercollapse/suspend_enabled for non-boot cpus

Allow non-boot cpus to be hotplugged and power collapsed by default.
This facilitates the cores to be offlined by kernel drivers during the
boot process.

CRs-Fixed: 460083
Change-Id: If44b6b594504dab61dff662c581b60e6fb664936
Signed-off-by: Praveen Chidambaram <pchidamb@codeaurora.org>
msm: 8974: Enable DONT_MAP_HOLE_AFTER_MEMBANK0

If this config option is enabled, the kernel does not map the
memory corresponding to the largest hole into the virtual
memory resulting in more lowmem. If multiple holes exist, the
largest hole in the first 256MB of the memory is not mapped.

In device tree based targets the kernel is no longer dependant
on the bootloader for the start and size of the memory holes.
Thus the meminfo is adjusted to reflect the memory hole, if it
is present, using the start and end of the memory hole, while
parsing the device tree.

For non-device tree based targets, the meminfo is used to find
the start and size of the memory hole. No adjustment is needed
to be made to the meminfo, as the hole is taken into account,
based on the memory information passed by the atags.

Change-Id: Ib2619f72ac2b4142330534c8bbe1c7d9f64ea38c
Signed-off-by: Neeti Desai <neetid@codeaurora.org>
msm: Account for unaligned memory hole

The memory hole is required to be section size aligned. The
PMD size internally may be greater than the section size. If the
end of the memory hole is not PMD aligned, we may end up with the
case where the physical address is PMD aligned but not the virtual
address or vice versa. This results in crashes in features such
as CMA that (reasonablly) assume that the virtual address will be PMD
aligned if and only if the physical address is aligned. Account
for this in the memory hole code by aligning the virtual address
up to PMD_SIZE if there is a mismatch with the physical address.
This does result in a loss in virtual address space but the
amount should be small compared to what is gained by by turning
on CONFIG_DONT_MAP_HOLE_AFTER_MEMBANK0. The virtual address loss
will go away if the memory hole is properly aligned to PMD_SIZE.

Change-Id: I985568a7cc6bc22bdd65586111ff078ab61b6c34
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
msm: Use phys_addr_t for the memory hole

On systems with 64-bit physical addresses, unsigned long
is not big enough to store the memory hole information.
Use phys_addr_t to store this information.

Change-Id: I5d5f2fff9864a0da4f8f14085d9d61a1419fc550
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
msm: Remove alloc bootmem aligned

This function has no more callers and should never be used again.
Remove it.

Change-Id: I3006c03ba2294c7dfb49539dff92b21b6670b4be
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
msm: memory: remove obsolete stable_size function

The notion of `stable' memory is going away (i.e. all memory is now
treated as `stable'). Remove the stable_size function. Remove the
notion of stability from the total_stable_size function and rename it
to total_size.

Change-Id: I8fd08a36b4948d57f430aea9113a0c704b8a00d0
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
msm: memory: use memblock instead of meminfo

msm currently uses meminfo (not memblock) in memory.c for several
purposes (mainly the placement of the memory pool(s)).  When the code
was written originally, memblock didn't exist yet.

Now that memblock exists, this is not strictly correct, but works as
long as nobody calls memblock_remove() besides this code (if that
occurs then the meminfo data no longer reflect reality and will likely
cause overlap problems).

To avoid problems meminfo usage should be replaced with memblock.

Also, since memblock regions of the same type can't be contiguous, the
total_size function, which calculated the aggregate size of contiguous
meminfo banks, can be removed.

Change-Id: I34054c4fe367986f472bdaae65be67cd8fbf273a
Signed-off-by: Mitchel Humpherys <mitchelh@codeaurora.org>
msm: Completely remove memory from the memblock allocator

memblock_remove may not be sufficient to prevent placing
regions on top of each other. Call memblock_reserve and
memblock_free as well to completely remove the memory
from the allocator.

Change-Id: Iec481d7ce7a51c243e43a2d9be2fbfbf7b2717ed
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
msm: Remove android_pmem.h from board and devices files

CONFIG_ANDROID_PMEM is completely deprecated. Remove all references
to the android pmem header.

Change-Id: Ic68a3af6b9cd01a439a841af26ae6dba09db2911
Signed-off-by: Laura Abbott <lauraa@codeaurora.org>
msm: simplify placing memory pools

The algorithm for placing memory pools was manually inspecting
the memblock data structures and then doing a memblock_remove()
on the region it decided that the memory pool should be located at.

If other code already did a memblock_remove() it was possible
that the memblock data structures which this algorithm
was inspecting would not be correct and the memory pool might
be placed overlapping this previous allocation.

Instead use arm_memblock_steal() which will not have this
problem (and also lets the memblock subsystem do
the allocation without any manual inspection of memblocks).

Change-Id: I7db5cba0a8d5f222f9f2f131b4b42eb81171c45b
Signed-off-by: Larry Bassel <lbassel@codeaurora.org>