ENGR00262435 MX6x-Drain L1/L2 buffers before DDR enters self-refresh.

The DDR freq change code and the low power WFI code in
MX6SL runs from non-cacheable but bufferable IRAM space.
Its possible for an eviction to occur from the L1
and/or L2 sync buffers after the DDR has been put into
self-refresh. This will cause the system to hang. To
avoid this ensure that the L1/L2 sync buffers are drained
properly.

Following is the info from ARM on L2 store buffers:
**********************************************************
You can use L2 sync operation to drain L2store buffer manually,
and the store buffer would be drained in such conditions:

* store buffer slot is immediately drained if targeting
  device memory area
* store buffer slots are drained as soon as they are full
* store buffer is drained at each strongly  ordered read
  occurrence in slave ports
* store buffer is drained at each strongly ordered write
  occurrence in slave ports
* as soon as all three slots of the store buffer contain data,
  the least recently accessed slot starts draining
* if a hazard is detected in a store buffer slot , that slot
  is drained to resolve the hazard
* store buffer slots are drained when a lock ed transaction is
  received by one slave port
* store buffer slots are drained when a transaction targeting
  the configuration registers is received by one slave port
* store buffer slots are automatically drained after 256 cycles
  of presence in the store buffer.

You can refer to 2.5.3 Store buffer operation of PL310 trm(r3p3, DDI0246H)
for the detail.

You have to apply the explicit cache sync operation, which should be
followed by DSB, before entering the low power mode. And the bit0 of
the cache sync register(base offset 0x730) should be polling to guarantee
that the PL310 has finished sync operation.

PL310 owns three 256 bit entry store buffer & eviction buffer, and
four 256 bit LFB & LRB, and Cache sync would complete when all buffers,
LRB, LFB, STB, and EB, are empty.

The actual overhead should be close to your L3 access latency.
*************************************************************************
~
~

Signed-off-by: Ranjani Vaidyanathan <ra5478@freescale.com>

0 files changed, 0 insertions, 0 deletions