summaryrefslogtreecommitdiff
path: root/src/mainboard
diff options
context:
space:
mode:
authorDailunxue <lunxue.dai@rock-chips.com>2014-12-03 16:03:23 +0800
committerPatrick Georgi <pgeorgi@google.com>2015-04-13 16:57:51 +0200
commit8188ab738e79172bca3e777440a937ddf51b0bde (patch)
treec0b6977ab8055db270eb11d631fd2ac2f4469d7d /src/mainboard
parent4b4764283a12d52c4fa61037ff7c2a9cb858a115 (diff)
rk3288: Increase the delay after DDR reset de-assert to 10us.
After DDR PHY reset de-asserted, DLL automatically starts to lock, and the lock time is maximum 5.12us. The output clock of DLL supplies the clocks of DDR controller and PHY digital logic. So before DLL lock, the clocks of DDR controller and PHY digital logic are indeterminate. When programming DDR in the period of DLL unlock, the programming maybe unstable because of the indeterminate clocks. So we need wait for at least 5.12us after de-asserting reset, then start to program DDR registers. 10us provide some safety margin. BUG=chrome-os-partner:33148 TEST=I'm using the following command line test ok(15000 cycles). "while sleep 4 && dut-control cold_reset:on sleep:.1 cold_reset:off; do : ; done" BRANCH=None Change-Id: Ie7d615f5a2264c615c4b4413d6b828cd3d78cd2b Signed-off-by: Stefan Reinauer <reinauer@chromium.org> Original-Commit-Id: 54e1a439c0e29aaf4fc542ae756f7bb036ceaf3e Original-Change-Id: I55f8cb11ed3d7962567c5f40a31e6c8aed8fdcb0 Original-Signed-off-by: DaiLunXue <dlx@rock-chips.com> Original-Reviewed-on: https://chromium-review.googlesource.com/232894 Original-Reviewed-by: Julius Werner <jwerner@chromium.org> Original-Commit-Queue: Lunxue Dai <lunxue.dai@rock-chips.com> Original-Tested-by: Lunxue Dai <lunxue.dai@rock-chips.com> Reviewed-on: http://review.coreboot.org/9578 Tested-by: build bot (Jenkins) Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Diffstat (limited to 'src/mainboard')
0 files changed, 0 insertions, 0 deletions