bootstrap stuffs

Gabriel Paubert paubert at
Wed Feb 17 04:39:38 EST 1999

On Tue, 16 Feb 1999, Geert Uytterhoeven wrote:

> > Actually I have come to the conclusion that the best way to handle this is
> > to add a sync instruction in the mask/disable interrupt routines (the ones
> > that access the interrupt controllers), so that all following __cli/__sti
> > only need to access the MSR (for enable/unmask you don't care to
> > synchronize of course).
> Then do we need sync in the OpenPIC routines, too?

I think so. I would even say that you need to read again the OpenPIC
_Vector_Priority register when you mask an interrupt to make sure
that the interrupt has actually been masked. I don't see any problem 
with my Raven/Falcon right now because the OpenPIC is integrated with the
host bridge so there is actually no arbitration to access the register and
almost no write posting issue with a 603 which has at most 6 instructions
in flight (although the write buffers might delay the actual write for
quite some time). 

However, on the Hydra in the Longtrail, if the GG2 suppports write posting
(which is hopefully true), the delays between even the sync operation
on the bus and the actual update of the OpenPIC register might cause
strange side effects (I don't know how the GG2 reacts to a sync bus
operation on the 604). 

I think that some bridges are even allowed to reorder reads before posted
writes if the addresses do not match, but I should check the specs.
This is probably not possible with processors that do not run bus cycles
to signal the bridges on eieio and sync instructions (603 and 750).

So, if I'm not mistaken, a read from the same location is the only
operation that guarantees that the register has actually been updated, but
it's even slower than a sync :-(


[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to  Cc linuxppc-dev  if your ]]
[[ reply is of general interest. To unsubscribe from linuxppc-dev, send ]]
[[ the message 'unsubscribe' to linuxppc-dev-request at ]]

More information about the Linuxppc-dev mailing list