| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
|
| |
When there is busfreq scaling between low power mode and audio bus
mode, the enabling of MMDC auto self-refresh code will be skipped
as they are both DLL off mode, it will cause DDR power increase,
so we just move the enabling of the MMDC auto self-refresh mode
to the end of busfreq change to make sure it is enabled after a
DDR freq change.
Signed-off-by: Anson Huang <b20788@freescale.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for dynamically calculating the size of all
low power code (suspend, ddr freq change and low power idle). This allows
for easy code changes in the future.
This patch also moves the DDR frequency change code from lower 8K of the memory
allocated for IRAM page table to regular IRAM. With this the lower 8K of the
IRAM page table only contains suspend/resume and low power IDLE code. This
gives a little more flexibility to the cdoe size for suspend/resume and low
power IDLE.
Signed-off-by: Ranjani Vaidyanathan <Ranjani.Vaidyanathan@freescale.com>
|
|
|
|
|
|
|
|
|
| |
When switching to page tables in IRAM, we are switching from a cacheable
to non-cacheable page table. Based on recommendation from ARM, we need to
ensure that branch prediction, L1 data nd L2 are disabled when DDR is put
into self-refresh.
Signed-off-by: Ranjani Vaidyanathan <Ranjani.Vaidyanathan@freescale.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Whenever DDR is explicitly put into self-refresh, we need to ensure
that no access are made to the DDR. All the bus masters excpet ARM
are shutdown gracefully.
The ARM core can continue to access the DDR due to:
1. Speculative accesses
This can be prevented by flushing the Branch Target Address Cache
2. Aggressive Prefetching
This can be minimized by adding nops.
Apart from this the TLB architecture in ARM does not guarantee that
an entry remains in the TLB unless its explicitly locked. Even if
free slots are available an entry maybe evicted. So flushing the TLB
does not guarantee a page table walk will not happen.
The solution is to put a minimized page table in IRAM that can be used when
DDR is in self-refresh. The IRAM page tables should have entries for IRAM,
AIPS1 and AIPS2 as these entries will be needed by the code that puts DDR
into self-refresh. It should not contain any entries that point to the DDR.
This patch set accomplishes the following:
1. Set the IRAM to be mapped as 1M sections in the high mem region.
This makes it possible to create entries for the IRAM code in the IRAM page table.
We need to ensure that both the DDR and IRAM page table have mapping for the IRAM code.
2. Ensure the IRAM, AIPS1, AIPS2 have entries in the IRAM page table.
3. Save TTBR1
4. Set TTBR1 to point to the page tables stored in IRAM. Switch to using
TTBR1 before DDR is put into self-refresh. Ensure the following settings:
a. TTBCR.N = 1
This means the 0-2G virtual address space is translated using TTBR0
and 2G-4G is translated using TTBR1.
b. Set TTBCR.PD0 = 1
With this setting page table walks using TTBR0 are disabled.
4. After the DDR has exited self-refresh, reset TTBCR to 0 (TTBR0 will
be used for translations now).
5. Restore TTBR1
Even though TTBR1 is only used to decode the top 2G of virtual address
space, ARM requires that we allocate the entire 16KB for the page table.
To minimize IRAM/OCRAM required, we put the code in the bottom 8K and
page table entries in the top 8K.
This requires the low power code be optimized to occupy as little space
as possible.
This commit is cherry-picked:
93ae491d9dbe34a91e2dd5832b02b0f0a390ddbe
Signed-off-by: Ranjani Vaidyanathan <Ranjani.Vaidyanathan@freescale.com>
|
|
|
|
|
|
|
|
|
| |
Incorrect clock disable of PLL2 caused random hangs during
DDR freq change in iMX6DL.
Remove PERCLK freq change code as this is not required for TO1.1
and later.
Signed-off-by: Ranjani Vaidyanathan <ra5478@freescale.com>
|
|
Add support to drop DDR and AHB frequency to 24MHz in
system IDLE state.
Signed-off-by: Ranjani Vaidyanathan <ra5478@freescale.com>
|