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/

Reply via email to