Age | Commit message (Collapse) | Author |
|
This reverts commit 06c880a6086183173c361b4a9d4f8047c6a39769.
This CL is reverted as it causes write perf regression with lmbench(bw_mem)
benchmark.
Bug 1026077
Change-Id: I7ff9ffbfe74e2083aa43cab75b694b1c61987bc3
Signed-off-by: Krishna Reddy <vdumpa@nvidia.com>
Reviewed-on: http://git-master/r/125097
Reviewed-by: Aleksandr Frid <afrid@nvidia.com>
|
|
This reverts commit b25193d5c3e2c59169c127d23b59123136cfefa7.
This CL is reverted as it causes write perf regression with lmbench(bw_mem)
benchmark.
Bug 1026077
Change-Id: I9858c88a6e846d2c3629f14c7cc62a7feb4f4528
Signed-off-by: Krishna Reddy <vdumpa@nvidia.com>
Reviewed-on: http://git-master/r/125096
Reviewed-by: Aleksandr Frid <afrid@nvidia.com>
|
|
For the CONFIG_TRUSTED_FOUNDATION code paths, differentiate L2
enable vs. reenable, which are different SMCs (won't trigger an
invalidate in the case of a reenable).
On an L2 disable SMC, optionally pass a 0 for the L2 ways arg,
which skips the full clean/invalidate (and simply just disabled
the L2).
In order to safely skip flushing the L2 on the disable, we have
to be careful what we dirty from the type we flush the L1 and
disable the L2.
Bug 939415
Signed-off-by: Chris Johnson<cwj@nvidia.com>
Change-Id: I756d2ceda83d5d8d6bc5670218e9d874d5e5f62a
Reviewed-on: http://git-master/r/119786
Reviewed-by: Simone Willett <swillett@nvidia.com>
Tested-by: Simone Willett <swillett@nvidia.com>
|
|
Bug 947861
Change-Id: I1ac97b5de5e7e79a418b3c38c70df4976616cdf3
Signed-off-by: Krishna Reddy <vdumpa@nvidia.com>
Reviewed-on: http://git-master/r/100457
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Aleksandr Frid <afrid@nvidia.com>
Reviewed-by: Yu-Huan Hsu <yhsu@nvidia.com>
|
|
This reverts commit f31ca2d9e0580b58dc51fde31fc8ace190dd253b.
Bug 967887
Change-Id: I3fe975f7a6939cace5e208947bcb82e09008c0ac
Signed-off-by: Sang-Hun Lee <sanlee@nvidia.com>
Reviewed-on: http://git-master/r/96787
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Varun Wadekar <vwadekar@nvidia.com>
|
|
The current kernel methodology expects that tegra_cpu_suspend
is actually the last function in the entire suspend sequence.
In order to achieve this, the code needs to be remodelled a
bit so that we actually execute native cpu_suspend at the end
of the suspend sequence. This allows us to leverage all the
cpu_suspend code developed by ARM in the upstream kernels.
Bug 934368
Change-Id: I94172d7adaa54c10043c479a57b270925d85a16b
Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
Reviewed-on: http://git-master/r/84481
Reviewed-by: Simone Willett <swillett@nvidia.com>
Tested-by: Simone Willett <swillett@nvidia.com>
|
|
Enable speculative line fill in SCU.
Bug 947861
Change-Id: I2db7515c47715160a4e559931e178b41c01a1744
Signed-off-by: Krishna Reddy <vdumpa@nvidia.com>
Reviewed-on: http://git-master/r/91834
Reviewed-by: Automatic_Commit_Validation_User
Reviewed-by: Scott Williams <scwilliams@nvidia.com>
|
|
Fix "Error: .size expression does not evaluate to a constant" with
binutils since version >= 2.21 due to wrong naming of the label
reference.
Signed-off-by: Marc Dietrich <marvin24@gmx.de>
Signed-off-by: Stephen Warren <swarren@wwwdotorg.org>
Change-Id: I3d09c423f993aa5ec8cdf166199774a7a1b18396
Reviewed-on: http://git-master/r/88102
Reviewed-by: Scott Williams <scwilliams@nvidia.com>
Reviewed-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
|
|
In the CPU hotplug startup routine, besides invalidate d-cache, we also
need,
- invalidate BTAC, i-cache, branch predict array, TLB
- invalidate SCU tags
- enable i-cache, branch prediction
Bug 926063
Bug 925488
Change-Id: I3751192f6aee65d93f6654e768d93ef7a5092023
Signed-off-by: Haley Teng <hteng@nvidia.com>
Change-Id: I35af9d4bbe5d60df2d648d9e7dcc18762194fb11
Reviewed-on: http://git-master/r/84759
Reviewed-by: Foster Cho <ycho@nvidia.com>
Reviewed-by: Varun Wadekar <vwadekar@nvidia.com>
Reviewed-by: Mayuresh Kulkarni <mkulkarni@nvidia.com>
Reviewed-by: Thomas Cherry <tcherry@nvidia.com>
Reviewed-by: Scott Williams <scwilliams@nvidia.com>
|
|
There is no reason to unlock APB CoreSight register access in the
kernel. The debugger can perform it's own unlock operation as
needed. Keep the registers write-protected to prevent inadvertent
access.
Change-Id: I22f28f76b5dd498b3782ab3380a04f865b59d6fd
Signed-off-by: Scott Williams <scwilliams@nvidia.com>
Reviewed-on: http://git-master/r/85039
Reviewed-by: Aleksandr Frid <afrid@nvidia.com>
Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
Reviewed-by: Bo Yan <byan@nvidia.com>
|
|
Add CONFIG_TRUSTED_FOUNDATIONS build option and calls to issue
SMCs to the TL secure monitor (used when needing to update state
not writable by non-secure code).
Make security/tf_driver an optional part of the build, which is
part of the TL framework to interact with secure services.
Bug 883391
Change-Id: I9c6c14ff457fb3a0c612d558fe731a17c2480750
Signed-off-by: Chris Johnson <cwj@nvidia.com>
Reviewed-on: http://git-master/r/65616
Reviewed-by: Varun Colbert <vcolbert@nvidia.com>
Tested-by: Varun Colbert <vcolbert@nvidia.com>
|
|
Bug 804805
(cherry picked from commit 068e6789bd335640ad2b444fae1e74fd9ca974c5)
Change-Id: If79b491133e6080b8b9c90c5adb0f59239ea275f
Reviewed-on: http://git-master/r/54842
Reviewed-by: Scott Williams <scwilliams@nvidia.com>
Reviewed-by: Krishna Reddy <vdumpa@nvidia.com>
Tested-by: Krishna Reddy <vdumpa@nvidia.com>
Rebase-Id: R16eabb01ed2c8197632d6063b5c9f35bed5714dd
|
|
During LP2 for CPU idle on Tegra2, there could be a race condition
between the CPUs. CPU1 cannot autonomously shut itself down (put
itself into reset). CPU1 must be reset by CPU0 but only when it
has no outstanding memory or I/O transactions going on (i.e., it
is in the WFI state). CPU1 indicates its readiness to be reset
by setting status in a PMC scratch register. If CPU1 wakes up
and CPU0 sees CPU1's ready to be reset status before CPU1 can
clear it CPU1 could be reset at inappropriate times resulting
in loss of cache coherency and ultimately a kernel panic.
Eliminate the race condition by ensuring that:
- CPU1's reset ready status is cleared as early as possible
before CPU1 rejoins the coherent world.
- Use writel when updating the IRAM LP2 status flags to ensure
the IRAM and coherent memory views of the flags are consistent.
- If there is not enough time remaining for CPU1 to be in LP2 for
the minimum residency time, clear CPU1's reset status flag
before entering WFI so that CPU0 will not wait for CPU1 to be
ready to reset (since it won't be if there is insufficient time).
Change-Id: I20dc5c6406b1521f20852294d48ce6d67f0926b9
Signed-off-by: Scott Williams <scwilliams@nvidia.com>
Rebase-Id: Rd485f696126d7ca019d15651b839d4f2fc595848
|
|
The standard cpu_suspend does not work if there is an exernal
L2 cache in the system individual CPUs are suspending without
shutting down the whole CPU complex. As a workaround for this
problem, we must save the CPU context to a non-cacheable region
of memory.
Change-Id: I2fffbc77ed4f17fe9710307aaacda80836bacee8
Signed-off-by: Scott Williams <scwilliams@nvidia.com>
Rebase-Id: R7328c032c2a13775aa09432e119ea845ded85930
|
|
All CPUs are not created equal. CPU0 must be the one to perform
the CPU complex suspend actions. CPU complex power gating and rail
gating cannot be triggered from CPU1. The Linux 2.6.39 port for
Tegra2 violates this hardware restriction. While it may have
appeared that the system was entering LP2 state, when entered
on CPU1, essentially all that happened was a WFI with no CPU
complex power gating and no CPU rail gating.
Change-Id: Ie754520264fe8de1b95f523d6575914bf77e747f
Signed-off-by: Scott Williams <scwilliams@nvidia.com>
Signed-off-by: Dan Willemsen <dwillemsen@nvidia.com>
Rebase-Id: R66e19457bc55bcd84124e3a4e23beae7b4ee707c
|
|
- Add a single unified handler for all CPU resets that is copied to
IRAM.
- Add state information to direct the flow of execution through the
reset handler based on the reason a CPU was reset.
- Write the EVP CPU reset vector only once per cold/warm boot session.
- Prevent modification of the EVP CPU reset vector in Tegra3.
Bug 786290
Bug 790458
Change-Id: Ica6707f3514986ee914e73a2d9766a4e06ce2d29
Signed-off-by: Scott Williams <scwilliams@nvidia.com>
DW: Split into logical changes
Signed-off-by: Dan Willemsen <dwillemsen@nvidia.com>
Rebase-Id: R7b9859a83717e76c3c083bdde724bd5fef9ce089
|
|
Should be functionally identical
Change-Id: Ib22b0bf3f529b32fcaec51f42f61a01aba45eec4
Signed-off-by: Scott Williams <scwilliams@nvidia.com>
DW: Split into logical changes
Signed-off-by: Dan Willemsen <dwillemsen@nvidia.com>
Rebase-Id: Ra2a76d338caaed07ada1e24002cefe2bcf643bd2
|
|
The movw/movt instruction pair (encapsulated by the mov32 macro)
is preferred over literals for loading addresses. The use of literals
for singleton data accesses can cause unnecessary cache misses and
evictions for cache lines that are unlikely to be accessed again in
the near future. Furthermore, certain code sequences must refrain
from using data accesses. Therefore, in general, addresses should
be loaded by mov32.
Change-Id: I9bcc3ee191f882996197ce2edc0eb510d4ff7b4a
Reviewed-on: http://git-master/r/40460
Tested-by: Daniel Willemsen <dwillemsen@nvidia.com>
Reviewed-by: Scott Williams <scwilliams@nvidia.com>
Reviewed-by: Daniel Willemsen <dwillemsen@nvidia.com>
Rebase-Id: R7ddd0d9b1e2fc8ab653b9220388acbecdbf4c57f
|
|
For Linux 2.6.39, CONFIG_PM_SLEEP is the proper kernel configuration
parameter to use on Tegra for power management, and not CONFIG_PM.
CONFIG_PM does not have the required dependency on CONFIG_SUSPEND
necessary to pull in the CPU suspend/resume functionality used by
Tegra.
Also fixes compilation errors when CONFIG_PM and by implication
CONFIG_PM_SLEEP are not configured.
Change-Id: I8bb380ae7c6b22759bfbc223febc28f585111aad
Reviewed-on: http://git-master/r/40458
Tested-by: Daniel Willemsen <dwillemsen@nvidia.com>
Reviewed-by: Scott Williams <scwilliams@nvidia.com>
Reviewed-by: Daniel Willemsen <dwillemsen@nvidia.com>
Rebase-Id: R61d656cd67439aa9f466c381845d7a4685fc8648
|
|
Bug 764354
Original-Change-Id: I8a390eb4dae87dceacb97461f23d13554868b046
Reviewed-on: http://git-master/r/12228
Reviewed-by: Scott Williams <scwilliams@nvidia.com>
Tested-by: Scott Williams <scwilliams@nvidia.com>
Original-Change-Id: I8e6b8303898796419fb5a759cd16edff9aeac081
Rebase-Id: R2866240384c6c24f46bd7ef54bc3dc9140d9e96b
|
|
Devs can disable SMP for debugging. However, there
was a build failure when CONFIG_SMP=n. This change
fixes it with minimum change. It looks like
headsmp.s and headsmp-t2.s cannot be removed from
Makefile since there are stuff used for both
multicore/unicore cpus in it.
Bug 809076
Original-Change-Id: Idc440aa912a98f5decff4c59845af4918e504cd2
Reviewed-on: http://git-master/r/24843
Reviewed-by: Donghan Ryu <dryu@nvidia.com>
Tested-by: Donghan Ryu <dryu@nvidia.com>
Reviewed-by: Bharat Nihalani <bnihalani@nvidia.com>
Rebase-Id: R7d80fc13cbff447403c89f4e54b986e96489da15
|
|
Tegra supports three low power modes that involve powering down the CPU.
LP2 powers down both CPU cores and the GICs, but leaves the core
peripherals, including the memory controller and the legacy
interrupt controller, enabled. The legacy interrupt controller
is used as the wakeup source, and any interrupt can wake the device.
LP2 can be used in idle.
LP1 is the same as LP2, but in addition turns off the memory
controller and puts the DDR memory in self-refresh. Any interrupt
can wake the device. LP1 could be used in idle if no peripherals
are doing DMA.
LP0 turns off everything in the SoC except the RTC and a power
management controller, both of which run off a 32 kHz clock.
The power management controller has 32 wake sources, all other
interrupts can not be used to wake from LP0.
These low power modes power-gate the main CPU complex, requiring a
full processor state save and restore from a reset vector.
Platform-specific data (power good times, PMU capabilities, etc.) must be
specified when registering the suspend operations to ensure that platform
power sequencing restrictions are maintained.
In both LP0 and LP1, SDRAM is placed into self-refresh. in order to safely
perform this transition, the final shutdown procedure responsible for
* turning off the MMU and L1 data cache
* putting memory into self-refresh
* setting the DDR pads to the lowest power state
* and turning off PLLs
is copied into IRAM (at the address TEGRA_IRAM_BASE + SZ_4K) at the
start of the suspend process.
In LP1 mode (like LP2), the CPU is reset and executes the code specified
at the EVP reset vector. Since SDRAM is in self-refresh, this code must
also be located in IRAM, and it must re-enable DRAM before restoring the
full context. In this implementation, it enables the CPU on PLLP, enables
PLLC and PLLM, restores the SCLK burst policy, and jumps to the LP2 reset
vector to restore the rest of the system (MMU, PLLX, coresite, etc.). The
LP2 reset vector is expected to be found in PMC_SCRATCH1, and is
initialized during system-bootup.
In LP0 mode, the core voltage domain is also shutoff. As a result, all
of the volatile state in the core voltage domain (e.g., pinmux registers,
clock registers, etc.) must be saved to memory so that it can be restored
after the system resumes. A limited set of wakeups are available from LP0,
and the correct levels for the wakeups must be programmed into the PMC
wakepad configuration register prior to system shutdown. On resume, the
system resets into the boot ROM, and the boot ROM restores SDRAM and other
system state using values saved during kernel initialization in the PMC
scratch registers.
Resuming from LP0 requires the boot ROM to supply a signed recovery codeblob
to the kernel; the kernel expects that the length and address of this blob
is supplied with the lp0_vec= command line argument; if not present, suspend-
to-LP0 will be disabled
For simplicity, the outer cache is shutdown for both LP0 and LP1; it
is possible to optimize the LP1 routine to bypass outer cache shutdown
and restart.
Includes fixes from:
Scott Williams <scwilliams@nvidia.com>
Aleksandr Frid <afrid@nvidia.com>
Vik Kasivajhula <tkasivajhula@nvidia.com>
Bharat Nihalani <Kbnihalani@nvidia.com>
James Wylder <james.wylder@motorola.com>
Allen Martin <amartin@nvidia.com>
Change-Id: I9e4e61c2fbb8c7bb5a29b1832ea38e7ea0524c52
Original-author: Gary King <gking@nvidia.com>
Signed-off-by: Gary King <gking@nvidia.com>
Signed-off-by: Colin Cross <ccross@android.com>
|
|
Signed-off-by: Colin Cross <ccross@android.com>
Signed-off-by: Erik Gilling <konkers@android.com>
|