
Understanding the eTPU Channel Hardware, Rev. 0
Channel Service Request
Freescale Semiconductor
36
Example 9.
if ((MatchB_TransA && !MatchA_TransB) || (MatchB_TransA && MatchA_TransB))
/* Handles MRLB OR TDLA regardless of MRLA or TDLB */
{
/*...*/
}
/* ... */
else if (!MatchB_TransA && MatchA_TransB)
/* Handles MRLA or TDLB if MRLB and TDLA are clear */
{
/*...*/
}
/* ... */
The following hints should be considered when deciding on channel service priority:
1. Give priority to the exceptional cases. Normal operation may be contra indicated.
2. Do not assume that later matches will be serviced later. Remember that latency might delay the
scheduling of a service routine until a subsequent channel event occurs. Both events will be
equally considered by the scheduler.
3. Remember the flags that did not request service. They will also be considered when the scheduler
sorts out the service thread.
4. Consider using the channel flags to change priorities at run time.
5.2
Clearing the Channel Latches
In general, all channel latches should be cleared during the service routine they called. There are
exceptions to this rule. In some cases when two channel latches (such as MRLA and TDLB) are requesting
service, the service routing may test for one latch condition, service it, clear that condition, and exit. The
second condition will cause the channel to be rescheduled and the routine entered a second time. This
strategy might be used where the conditions are unrelated (for example, an input pin transition and a
simultaneous time-out of a wake up timer). The system may call for high priority handling of one condition
and low priority handling of the other. If the low priority handling routine is lengthy, it might improve
performance to handle the high priority thread, clear the corresponding latch, and exit the service routine
to enable the eTPU to handle other channels that might be requesting service before the scheduler responds
to the uncleared latch for the low priority thread.
It is a good idea to also clear those channel latches that “cannot” be set. Even in sm_st, it is possible that
host action caused a condition which set MRLB or TDLB. The microcode generated for clearing the
channel latches is a single instruction, regardless how many channel latches are cleared, as long as the
source instructions are grouped together.