Otherwise, when the contents of DEC0 change, the exception effects
of the Decrementer become consistent with the new contents of the
Decrementer reasonably soon after the change.
And that is guaranteed on all PowerPC as far as I can see.
The main thing is that a decrementer exception won't go
away until the high bit becomes 0.
On both POWER4 and POWER4+, the Decrementer must be implemented such
that requirements 1 to 3 below are satisfied. On POWER4, requirements
4 and 5 must also be satisfied.
<snip>
4. Whenever bit 0 of the Decrementer changes from 0 to 1, an interrupt
request is signaled. If multiple Decrementer interrupt requests are
received before the first can be reported, only one interrupt is
reported. The occurrence of a Decrementer interrupt cancels the
request.
5. If the Decrementer is altered by software and the contents of bit 0
are changed from 0 to 1, an interrupt request is signaled.
From the POWER ISA 2.03, the latest public version of the
architecture definition:
When the contents of DEC32 change from 0 to 1, a Decrementer
exception will come into existence within a reasonable period
or time. When the contents of DEC32 change from 1 to 0, an
existing Decrementer exception will cease to exist within a
reasonable period of time, but not later than the completion
of the next context synchronizing instruction or event.
(4) clearly contradicts your point.
Yes, on some implementations there can be other conditions that
make a decrementer exception go away; there is no contradiction
here (thankfully). My wording was sloppy.
I don't mind changing #ifdef though (so it'll cover all non Book E
cases)
That was exactly my point; thank you.
Segher
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
