summaryrefslogtreecommitdiff
path: root/Licenses/ibm-pibs.txt
diff options
context:
space:
mode:
authorMeenakshi Aggarwal <meenakshi.aggarwal@nxp.com>2019-05-28 21:37:58 +0530
committerPrabhakar Kushwaha <prabhakar.kushwaha@nxp.com>2019-06-19 12:54:57 +0530
commit1dff14c87d07fc535aaf9e2d3012fd966ed9af89 (patch)
treee306df4a048b8d01de1ebc486f66cd87b801db33 /Licenses/ibm-pibs.txt
parent85e5e21981115fdb64fd39723dd8856bef5c66e9 (diff)
armv8/fsl-layerscape: Add loop to check L3 dcache status
Flushing L3 cache may need variable time depending upon cache line allocation. Coming up with a proper timeout value would be best handled by simulations under multiple scenarios in your actual system. >From the purely HN-F point of view, the flush would take ~15 cycles for a clean line, and ~22 cycles for a dirty line. For the dirty line case, there are many variables outside the HN-F that will increase the duration per line. For example, a *DBIDResp from the SN-F/SBSX, memory controller latency, SN-F/SBSX RetryAck responses, CCN ring congestion, CCN ring hops, etc, etc. The worst-case timeout would have to factor in all of these variables plus the HN-F cycles for every line in the L3, and assuming all lines are dirty In case if L3 is not flushed properly, system behaviour will be erratic, so remove timeout and add loop to check status of L3 cache. System will stuck in while loop if there is some issue in L3 cache flushing. Signed-off-by: Udit Kumar <udit.kumar@nxp.com> Signed-off-by: Meenakshi Aggarwal <meenakshi.aggarwal@nxp.com> Reviewed-by: Prabhakar Kushwaha <prabhakar.kushwaha@nxp.com>
Diffstat (limited to 'Licenses/ibm-pibs.txt')
0 files changed, 0 insertions, 0 deletions