[PATCH 9/9] powerpc/pm: support deep sleep feature on T1040
scottwood at freescale.com
Fri Mar 21 09:17:48 EST 2014
On Thu, 2014-03-20 at 19:47 +0800, Kevin Hao wrote:
> OK, so the intention of 'twi, isync' following the load is not to order the
> following storage access, but order the following delay loop instructions,
> right? But according to the e6500 manual, the instructions complete in order.
> The following is the definition of 'complete':
> Complete—An instruction is eligible to complete after it finishes executing
> and makes its results available for subsequent instructions. Instructions
> must complete in order from the bottom two entries of the
> completion queue (CQ). The completion unit coordinates how instructions (which
> may have executed out of order) affect architected registers to ensure the
> appearance of serial execution. This guarantees that the completed instruction
> and all previous instructions can cause no exceptions. An instruction completes
> when it is retired, that is, deleted from the CQ.
> So the following delay loop instructions should never complete before the
> complete of the load instruction.
We don't want the delay loop instructions to *start* until the load has
completed. Completion of the loop only matters when ordering the loop
versus post-loop actions (and again, there we'd want the loop to
complete before subsequent actions start).
> > > > > So if we want to order all the storage access as well
> > > > > as execution synchronization, we should choose sync here.
> > > >
> > > > Do we need execution synchronization or context synchronization?
> > >
> > > There is no context-altering instruction here, so I think an execution
> > > synchronizing instruction should be enough here.
> > Is the ISA ever explicit about what constitutes "context"?
> The following is the definition of context-altering instruction:
> An instruction that alters the context in which data
> addresses or instruction addresses are interpreted, or
> in which instructions are executed or data accesses are
> performed, is called a context-altering instruction.
> So the context should be:
> - in which data addresses or instruction addresses are interpreted
> - in which instructions are executed
> - in which data accesses are performed
By that definition, a store to CCSR could easily change the context in
which data accesses are performed, by changing a mapping.
But still, nothing in the above defines "context" -- or rather, it does
so circularly. While it makes intuitive sense that it would be limited
to context that lives within the core, rather than the rest of the
system, I don't think the ISA generally distinguishes between the two.
More information about the Linuxppc-dev