When a kernel panic occurs on one CPU, other CPUs are instructed to stop
execution via the IPI_CPU_STOP message. These other CPUs dump their stack,
which may not be good enough to reconstruct their context to perform
post-mortem analysis. Dump each CPU's context (before it started
processing the IPI) into a globally accessible structure and print them on
the dmesg/console to allow for easier post-mortem debugging.
[eberman@codeaurora.org: make regs_before_stop static]
Change-Id: Ifd7589af4327992540196c87f8b640045d7eaf19
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
As the best clocksource is not selected till core boot completion,
only periodic tick timer works and it increases jiffies by one at
every tick updates. If interrupt is disabled more than one tick(10ms),
timer interrupts are missed and jiffies can't be updated at every
10ms and It can be behind the real time. So make it possible to select
the best clocksource right after arm arch timer initialization, so that
jiffies can be increased by multiple counts since then.
Change-Id: Id8c4e3ce9b9e44061fef7ad7e678ca1c27d84bb1
Signed-off-by: Se Wang (Patrick) Oh <sewango@codeaurora.org>
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
As the best clocksource is not selected till core boot completion,
only periodic tick timer works and it increases jiffies by one at
every tick updates. If interrupt is disabled more than one tick(10ms),
timer interrupts are missed and jiffies can't be updated at every
10ms and it can be behind the real time. So add API to force re-
selection of the best clocksource among registered clocksources so
that the best clocksource can be selected whenever it is available.
Change-Id: I481de3cdf1df8f0e35ed10aee7ab3882bf7a35b3
Signed-off-by: Se Wang (Patrick) Oh <sewango@codeaurora.org>
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
Enable panic on RCU stalls if the RCU_PANIC_ON_STALL is enabled. This
helps collecting the cpu context for debugging.
Change-Id: Ibc95799df995bf31053152ab9b3894710fcd9f43
Signed-off-by: Channagoud Kadabi <ckadabi@codeaurora.org>
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
This is a snapshot of the IPCC controller driver as of msm-4.19 commit
<d3d6e9be4297471f88c2a14d31424c508a5b7174>. (Merge "cnss2: Add idle state
to bus voting").
Change-Id: I5b8a3b1e7f71d7cd7e59cf0271e8eac7549c5b6c
Signed-off-by: Prakruthi Deepak Heragu <pheragu@codeaurora.org>
The irq_domain_remove() API expects all the irqs of the domain be cleared
before it is called, else it throws a warning. A framework creating a
radix tree to map all the irqs used by its clients cannot be sure if all
the clients cleared their irqs. Thus to avoid this warning, we can use
this API irq_dispose_all_tree_mappings() to ensure that all irqs
belonging to the domain are cleared before the domain is itself removed.
Change-Id: Ied1f20c990aba9d4760091d9ed3d48c3e4f3d5d9
Signed-off-by: Prakruthi Deepak Heragu <pheragu@codeaurora.org>
Add a global deferrable timer in addition to the per-cpu deferrable timer
to allow deferrable timers without the TIMER_PINNED flag to run
on any active CPU.
[rishabhb@codeaurora.org: Resolved conflicts in kernel/time/timer.c]
Change-Id: I8e6b77cef972589912ad18f324c46c936fbbb96f
Signed-off-by: Kyle Yan <kyan@codeaurora.org>
Signed-off-by: Rishabh Bhatnagar <rishabhb@codeaurora.org>
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
Protect against integer overflows caused by malformed fdt headers.
[eberman@codeaurora.org: most of changes have been fixed in
commit f858927fd6 ("scripts/dtc: Update to upstream version
v1.4.7-14-gc86da84d30e4"). The upstream was commit eb890c0f77dc
("libfdt: Make fdt_check_header() more thorough"))]
CRs-Fixed: 749977
Change-Id: I51d87038f520bc761b163d291b0138c513c69a33
Signed-off-by: Vijay Kumar Pendoti <vpendo@codeaurora.org>
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
This patch merges all of the IOMMU/SMMU, DMA mapping, fast, and
lazy mapping changes from msm-4.19 into msm-lahaina.
Change-Id: If7c1f641a8c836dbb799e2f3439f443ff299b299
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
The thread which initiates the hot plug can get scheduled
out, while trying to acquire the console lock,
thus increasing the hot plug latency. This option
allows to selectively disable the console flush and
in turn reduce the hot plug latency.
Change-Id: I42507804d321b29b7761146a6c175d959bf79925
Signed-off-by: Mohammed Khajapasha <mkhaja@codeaurora.org>
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
This reverts the upstream commit <68234df4ea>
("arm64: kill flush_cache_all()"). This is required internally
for certain use-cases like flushing cache before reboot to
ensure all the data is available in the ramdump.
Change-Id: I6dfd240603c05053b7d341faa613dd4866bb7f62
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
This reverts commit <d3127afa71>
("arm64: Remove unused macros from assembler.h")
This is required for flush_cache_all to work.
Change-Id: I469602e2f35b15bf13667322f3ffbe61dab90f91
Signed-off-by: Rohit Vaswani <rvaswani@codeaurora.org>
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
This reverts commit a82785a953.
This is required for flush_cache_all to work.
Change-Id: I0c817ca02ff7f113d2058a81814b611342bc111a
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
CPU hotplug operations take place in preemptible context. This leaves
the hotplugging thread at the mercy of overall system load and CPU
availability. If the hotplugging thread does not get an opportunity
to execute after it has already begun a hotplug operation, CPUs can
end up being stuck in a quasi online state. In the worst case a CPU
can be stuck in a state where the migration thread is parked while
another task is executing and changing affinity in a loop. This
combination can result in unbounded execution time for the running
task until the hotplugging thread gets the chance to run to complete
the hotplug operation.
Fix the said problem by ensuring that hotplug can only occur from
threads belonging to the RT sched class. This allows the hotplugging
thread priority on the CPU no matter what the system load or the
number of available CPUs are. If a SCHED_NORMAL task attempts to
hotplug a CPU, we temporarily elevate it's scheduling policy to RT.
Furthermore, we disallow hotplugging operations to begin if the
calling task belongs to the idle and deadline classes or those that
use the SCHED_BATCH policy.
Change-Id: Idbb1384626e6ddff46c0d2ce752eee68396c78af
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
[psodagud@codeaurora.org: Fixed compilation issues]
Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
In a heterogenous multiprocessor system, specifying the
'maxcpus' parameter on the kernel command line does not
provide sufficient control over which CPUs are brought
online at kernel boot time, since CPUs may have nonuniform
performance characteristics. Thus, we introduce a
'boot_cpus' command line argument, allowing the user to
explicitly specify the list of CPUs that shall be brought
online during kernel boot.
Change-Id: I7bf5efa94785bc6cf1236aa71f4d7364e859fc37
Signed-off-by: Channagoud Kadabi <ckadabi@codeaurora.org>
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
Add ftrace event trace_cpuhp_latency to track cpu
hotplug latency and this entry is useful in power,
performance and debug analysis.
Change-Id: Ie6b2a91027c665ccaf6325b0836bb629a4e91dd7
Signed-off-by: Prasad Sodagudi <psodagud@codeaurora.org>
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
When mod_delayed_work() is concurrently executed, there a potential
live lock scenario due to pool->lock contention.
Lets say both CPU#0 and CPU#4 calls mod_delayed_work() on the same
work item with 0 delay on a bounded workqueue. This workitem has
run on CPU#4 previously. CPU#0 wins the work item PENDING bit race
and proceeds to queueing. As this work has previously run on CPU#4,
it tries to acquire the corresponding pool->lock to check if it is
still running there. In the meantime, CPU#4 loops in
try_to_grab_pending() for the workitem to be linked with a pwq so
that it can steal it from pwq->pool->worklist. The CPU#4 essentially
acquires and releases the pool->lock in a busy loop and CPU#0 may
never gets this lock.
---------------- --------------------
CPU#0 CPU#4
--------------- --------------------
blk_run_queue_async()
mod_delayed_work_on() queue_unplugged()
--> try_to_grab_pending() returns blk_run_queue_async()
0 indicating PENDING bit is set
now.
__queue_delayed_work() mod_delayed_work_on()
__queue_work() try_to_grab_pending()
{
--> waiting for the CPU#4's acquire pool->lock()
pool->lock release pool->lock()
}
Change-Id: I9aeab111f55a19478a9d045c8e3576bce3b7a7c5
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
If kernel stack variables are not initialized properly,
there is a chance of kernel information disclosure.
So, initialize kernel stack variables with null characters.
CRs-fixed: 2042592
Change-Id: I213c0e5c7f67824c2cecace276ff2f8f81599d51
Signed-off-by: Sai Krishna Juturi <jsaikrishna@codeaurora.org>
Signed-off-by: Mayank Rana <mrana@codeaurora.org>
Signed-off-by: Sriharsha Allenki <sallenki@codeaurora.org>
Add the stack dump and printk of other CPUs when they are stopped
during an abnormal operation like a panic - This information is useful
for debugging to get a clear idea of what might have caused a crash.
Change-Id: I91a62cfc7cdb49b9cdbb247869b5ba799947ece5
Signed-off-by: Kyle Yan <kyan@codeaurora.org>
Signed-off-by: Elliot Berman <eberman@codeaurora.org>
Add usecase IDs such as LLCC_MDMHW, LLCC_CVP, LLCC_MDMVPE,
LLCC_APTCM, LLCC_WRTCH, LLCC_CVPFW, and LLCC_CPUSS1 for the
respective clients.
Change-Id: I0b6666f3c17b9e880568f27782e967c5f9b587bf
Signed-off-by: Raghavendra Rao Ananta <rananta@codeaurora.org>
For older targets, it is possible that they are not allowed
to configure certain llcc registers, as that is handled by
the secure side. However, this is not the case for newer
targets, and as such, they must configure these registers
according to the contents of the SCT table, while keeping in
mind that older targets may not have these capabilities.
Allow configuration of registers to enable capacity based
allocation and power collapse retention for capable targets.
Squashed commit:
drivers: llcc: Check the return value after write
Check the return value after writing to power collapse and
capacity based allocation registers.
Change-Id: I2106f98812a9369f1fdb7e20453741f1375c0a58
Signed-off-by: Isaac J. Manjarres <isaacm@codeaurora.org>
[vgutta@codeaurora.org: Resolved trivial merge conflicts]
Signed-off-by: Venkata Narendra Kumar Gutta <vnkgutta@codeaurora.org>
[rananta@codeaurora.org: Resolved trivial merge conflicts]
Signed-off-by: Raghavendra Rao Ananta <rananta@codeaurora.org>
