| 5e810a85 | 28-Feb-2017 |
danh-arm <dan.handley@arm.com> |
Merge pull request #847 from douglas-raillard-arm/dr/fix_abort_smc
Fix TSPD implementation of STD SMC ABORT |
| 7befa5a9 | 28-Feb-2017 |
danh-arm <dan.handley@arm.com> |
Merge pull request #837 from douglas-raillard-arm/dr/fix_tools_cflags
build: Use separate CFLAGS for tools |
| 1a9c383b | 21-Mar-2016 |
Varun Wadekar <vwadekar@nvidia.com> |
Tegra: Disable A57/A53 cache non-temporal hints
This change disables the cache non-temporal hints for A57 and A53 CPUs on Tegra.
Change-Id: I279d95aec5afbc3ca3cc4b34aa16de3f2c83a4fc Signed-off-by:
Tegra: Disable A57/A53 cache non-temporal hints
This change disables the cache non-temporal hints for A57 and A53 CPUs on Tegra.
Change-Id: I279d95aec5afbc3ca3cc4b34aa16de3f2c83a4fc Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
show more ...
|
| d6845d3d | 27-Feb-2017 |
davidcunado-arm <david.cunado@arm.com> |
Merge pull request #835 from rockchip-linux/rk3399-atf-cleanup-20170210
RK3399 ARM TF clean up 20170210 |
| b9589fe5 | 14-Feb-2017 |
dp-arm <dimitris.papastamos@arm.com> |
fiptool: Embed a pointer to an image within the image descriptor
Currently, fiptool uses two linked lists. One to chain together all the images and one for all the image descriptors. Initially thi
fiptool: Embed a pointer to an image within the image descriptor
Currently, fiptool uses two linked lists. One to chain together all the images and one for all the image descriptors. Initially this was done because not all images had a corresponding image descriptor. This was the case for unknown images which existed in the FIP but there was no descriptor in the builtin table for them. When support for the --blob option came in, we started building descriptors for the unknown images on the fly. As a result every image now has a corresponding image descriptor and therefore it is no longer necessary to keep track of them separately.
To simplify the design, maintain only a single linked list of image descriptors. An image descriptor contains a pointer to the corresponding image. If the pointer is NULL, then the descriptor is skipped in all the operations. This approach simplifies the traversal code and avoids redundant lookups.
The linked list of image descriptors is populated based on the `toc_entries` array. This means that the order of the images in the FIP file remains the same across add/remove or create/update operations. This is true for all standard images (those specified in `toc_entries`) but not for those specified via the --blob option.
Change-Id: Ic29a263c86c8f1efdad322b430368c7623782e2d Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
show more ...
|
| 86a3b266 | 27-Feb-2017 |
davidcunado-arm <david.cunado@arm.com> |
Merge pull request #849 from vwadekar/tegra-changes-from-downstream-v2
Tegra changes from downstream v2 |
| ccdc044a | 14-Feb-2017 |
Xing Zheng <zhengxing@rock-chips.com> |
rockchip: rk3399: enable secure accessing for SRAM
Sorry to miss the security configuration for SRAM, if we don't support it, somebody may modify the comment of SRAM in the non-secure space. Let's f
rockchip: rk3399: enable secure accessing for SRAM
Sorry to miss the security configuration for SRAM, if we don't support it, somebody may modify the comment of SRAM in the non-secure space. Let's fix this issue.
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
show more ...
|
| cdb6d5e5 | 10-Feb-2017 |
Derek Basehore <dbasehore@chromium.org> |
rockchip: rk3399: Use tFC value instead of tRFC value
This fixes code that set a tFC value in a register using the tRFC value instead.
Signed-off-by: Derek Basehore <dbasehore@chromium.org> |
| 5a5dc617 | 10-Feb-2017 |
Derek Basehore <dbasehore@chromium.org> |
rockchip: rk3399: Fix CAS latency setting
The F1 CAS latency setting was not bit shifted, which resulted in setting the DRAM additive latency value instead.
Signed-off-by: Derek Basehore <dbasehore
rockchip: rk3399: Fix CAS latency setting
The F1 CAS latency setting was not bit shifted, which resulted in setting the DRAM additive latency value instead.
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
show more ...
|
| 43f52e92 | 09-Feb-2017 |
Xing Zheng <zhengxing@rock-chips.com> |
rockchip: rk3399: disable training modules after DDR DFS
On resume, we use the DFS hardware to switch frequency index, followed by a full training sequence on that index. Leaving the DFS training mo
rockchip: rk3399: disable training modules after DDR DFS
On resume, we use the DFS hardware to switch frequency index, followed by a full training sequence on that index. Leaving the DFS training modules enabled causes issues with the full training done at resume. We also only needs these enabled during a call to ddr_set_rate during runtime, so there's no issue disabling them at the end of ddr_set_rate.
Signed-off-by: Derek Basehore <dbasehore@chromium.org> Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
show more ...
|
| 50bde47f | 02-Feb-2017 |
Derek Basehore <dbasehore@chromium.org> |
rockchip: rk3399: Move DQS drive strength setting to M0
This moves the setting of the DQS drive strength to the M0 to minimize the impact on DDR transactions. We need to have the DQS drive strength
rockchip: rk3399: Move DQS drive strength setting to M0
This moves the setting of the DQS drive strength to the M0 to minimize the impact on DDR transactions. We need to have the DQS drive strength changed for data training, which is triggered by the M0, but it also needs to be changed back when data training is finished.
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
show more ...
|
| d8484b1e | 01-Feb-2017 |
Derek Basehore <dbasehore@chromium.org> |
rockchip: rk3399: Remove dram dfs optimization
This removes an optimization to not recalculate parameters if the frequency index being switched to hold the next frequency. This is because some regis
rockchip: rk3399: Remove dram dfs optimization
This removes an optimization to not recalculate parameters if the frequency index being switched to hold the next frequency. This is because some registers do not have a copy per frequency index, so this optimization might be causing problems.
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
show more ...
|
| 951752dd | 31-Jan-2017 |
Derek Basehore <dbasehore@chromium.org> |
rockchip: rk3399: Save and restore RX_CAL_DQS values
We were getting far off values on resume for the RX_CAL_DQS values. This saves and restores the values for suspend/resume until the root of the p
rockchip: rk3399: Save and restore RX_CAL_DQS values
We were getting far off values on resume for the RX_CAL_DQS values. This saves and restores the values for suspend/resume until the root of the problem is figured out
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
show more ...
|
| 4dbab5d2 | 31-Jan-2017 |
Julius Werner <jwerner@chromium.org> |
rockchip: Add MIN() and MAX() macros back to M0 code
These macros were accidentally deleted in a previous cleanup. This slipped through because the code using them is currently unused, but that may
rockchip: Add MIN() and MAX() macros back to M0 code
These macros were accidentally deleted in a previous cleanup. This slipped through because the code using them is currently unused, but that may change in the future.
Signed-off-by: Julius Werner <jwerner@chromium.org>
show more ...
|
| 2d051d2f | 31-Jan-2017 |
Julius Werner <jwerner@chromium.org> |
rockchip: Clean up M0 Makefile, clarify float-abi
This patch shuffles the M0 Makefile flags around a bit trying to make their purpose clearer and remove duplication. Since all three build steps (com
rockchip: Clean up M0 Makefile, clarify float-abi
This patch shuffles the M0 Makefile flags around a bit trying to make their purpose clearer and remove duplication. Since all three build steps (compiling, assembling, linking) actually call GCC, remove the misleading aliases $(AS) and $(LD) to avoid confusion that those tools might be called directly. Split flags into a common group that has meaning for all three steps and separate variables specific to each step. Remove -nostartfiles which is a strict subset of -nostdlib.
Also add explicit parameters for -mfloat-abi=soft, -fomit-frame-pointer and -fno-common. If omitted these settings depend on the toolchain's built-in default and cause various problems if they resolve to unexpected values.
Signed-off-by: Julius Werner <jwerner@chromium.org>
show more ...
|
| e3525114 | 24-Feb-2017 |
Xing Zheng <zhengxing@rock-chips.com> |
rockchip: rk3399: Clean up and seprate secure parts from SoC codes
The goal is that make clear the secure and SoC codes. Now cleaning them will help secure code extensions for RK3399 in the future.
rockchip: rk3399: Clean up and seprate secure parts from SoC codes
The goal is that make clear the secure and SoC codes. Now cleaning them will help secure code extensions for RK3399 in the future.
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
show more ...
|
| ae7a9352 | 22-Dec-2016 |
Xing Zheng <zhengxing@rock-chips.com> |
rockchip: rk3399: sperate the BL31 parameters for sharing
Maybe the coreboot will reference the BL31 parameters (e.g the TZRAM_BASE and TZRAM_SIZE for DDR secure regions), we can split them and don'
rockchip: rk3399: sperate the BL31 parameters for sharing
Maybe the coreboot will reference the BL31 parameters (e.g the TZRAM_BASE and TZRAM_SIZE for DDR secure regions), we can split them and don't have to hardcode the range in two places.
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
show more ...
|
| 941c7147 | 24-Feb-2017 |
Xing Zheng <zhengxing@rock-chips.com> |
rockchip: rk3399: configure the DDR secure region for BL31 image
Move the BL31 loaded base address 0x10000 to 0x1000, and configure the the memory range 0~1MB is secure, the goal is that make sure t
rockchip: rk3399: configure the DDR secure region for BL31 image
Move the BL31 loaded base address 0x10000 to 0x1000, and configure the the memory range 0~1MB is secure, the goal is that make sure the BL31 image will be not modified.
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
show more ...
|
| 1830f790 | 24-Feb-2017 |
Xing Zheng <zhengxing@rock-chips.com> |
rockchip: Clean up header and referenced files
So far, there are more and more features are supported on the RK3399, meanwhile, these features are increasingly being defined and intertwined. It's ti
rockchip: Clean up header and referenced files
So far, there are more and more features are supported on the RK3399, meanwhile, these features are increasingly being defined and intertwined. It's time to clean up and make them clearer.
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
show more ...
|
| a7519b6b | 09-Jan-2017 |
Derek Basehore <dbasehore@chromium.org> |
rockchip: rk3399: Don't wait for vblank in M0 for ddrfreq
This removes waiting for vblank on the M0 during ddrfreq transitions. That will now be done in the kernel to allow scheduling to be done on
rockchip: rk3399: Don't wait for vblank in M0 for ddrfreq
This removes waiting for vblank on the M0 during ddrfreq transitions. That will now be done in the kernel to allow scheduling to be done on the CPU core that changes the ddr frequency. Waiting for vblank in the M0 would have the CPU core that waits on the M0 spin looping for up to 16ms (1 frame for the display).
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
show more ...
|
| ef0a6bfc | 30-Dec-2016 |
Lin Huang <hl@rock-chips.com> |
rockchip: rk3399: restore PMU_CRU_GATEDIS_CON0 value after ddr dvfs
we will set PMU_CRU_GATEDIS_CON0 when idle port, it will enable all clock, for save power consumption, we need to restore old valu
rockchip: rk3399: restore PMU_CRU_GATEDIS_CON0 value after ddr dvfs
we will set PMU_CRU_GATEDIS_CON0 when idle port, it will enable all clock, for save power consumption, we need to restore old value when finish it.
Signed-off-by: Lin Huang <hl@rock-chips.com>
show more ...
|
| 87b5c17f | 30-Dec-2016 |
Lin Huang <hl@rock-chips.com> |
rockchip: rk3399: fix PMU_CRU_GATEDIS_CON0 setting error
As rk3399 TRM1.1 document show, when set PMU_CRU_GATEDIS_CON0/1 register, it need set the write_mask bit (bit16 ~ bit31), but as we test, it
rockchip: rk3399: fix PMU_CRU_GATEDIS_CON0 setting error
As rk3399 TRM1.1 document show, when set PMU_CRU_GATEDIS_CON0/1 register, it need set the write_mask bit (bit16 ~ bit31), but as we test, it not need it. So need to correct the setting way, otherwise it will set wrong value to this register.
Signed-off-by: Lin Huang <hl@rock-chips.com>
show more ...
|
| 175476f9 | 20-Dec-2016 |
Xing Zheng <zhengxing@rock-chips.com> |
FIXUP: rockchip: rk3399: fix the incorrect bit during m0_init
We found that the DUT will be hanged if we don't set the bit_1 of the PMUCRU_GATEDIS_CON0. But, from the TRM, there is weird that the bi
FIXUP: rockchip: rk3399: fix the incorrect bit during m0_init
We found that the DUT will be hanged if we don't set the bit_1 of the PMUCRU_GATEDIS_CON0. But, from the TRM, there is weird that the bit_1 is set the clk_center1_gating_dis, not clk_pmum0_gating_dis. Is the TRM incorrect? We need to check it with the IC team and re-clean the commit message and explain it tomorrow.
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
show more ...
|
| ca9286c6 | 12-Dec-2016 |
Lin Huang <hl@rock-chips.com> |
rockchip: rk3399: improve the m0 enable flow
This patch do following things: 1. Request hresetn_cm0s_pmu_req first then request poresetn_cm0s_pmu_req during M0 enable. 2. Do not diable M0 clock f
rockchip: rk3399: improve the m0 enable flow
This patch do following things: 1. Request hresetn_cm0s_pmu_req first then request poresetn_cm0s_pmu_req during M0 enable. 2. Do not diable M0 clock for ddr dvfs. 3. Correct the clk_pmum0_gating_dis bit, it is BIT0 not BIT1 4. do not set/clear hclk_noc_pmu_en in M0 code, it does not relate to the M0 clock.
Signed-off-by: Lin Huang <hl@rock-chips.com> Signed-off-by: Derek Basehore <dbasehore@chromium.org>
show more ...
|
| a82ec814 | 01-Dec-2016 |
Lin Huang <hl@rock-chips.com> |
rockchip: rk3399: check vop status when we wait dma finish flag
When vop is disabled and we read the vop register the system will hang, so check vop status when we wait for the DMA finish flag to av
rockchip: rk3399: check vop status when we wait dma finish flag
When vop is disabled and we read the vop register the system will hang, so check vop status when we wait for the DMA finish flag to avoid this sitiuation. This is done by checking for standby, DMA stop mode, and disabled window states. Any one of these will prevent the DMA finish flag from triggering.
Signed-off-by: Lin Huang <hl@rock-chips.com> Signed-off-by: Derek Basehore <dbasehore@chromium.org>
show more ...
|