Thoughts about DBDMA and cache coherency

Benjamin Herrenschmidt bh40 at
Fri Mar 19 10:41:54 EST 1999

On Fri, Mar 19, 1999, Paul Mackerras <paulus at> wrote:

>No, what happens (on the 60x bus) is that the read is snooped by the
>cache controller, which asserts a `backoff and retry' signal.  The
>PCI bridge then terminates the transaction, the cache controller gets
>the 60x bus and writes the cache line out to memory, then the PCI
>bridge retries the read and gets the right data from memory.

Ok, thanks for the clarification.

>One small wrinkle is that for all this to work, the bridge has to
>assert the GBL (global) signal for all its accesses.  On some
>Starmaxes, we weren't getting the cache coherency maintained, but
>someone (Harry Eaton, from memory) found a bit to set in the bridge's
>configuration space which turned on the cache coherency - most likely
>this bit controlled whether the GBL signal was asserted or not.

I beleive MacOS can run without it (MacOS probably assumes cache coherency
is not here since it makes DMA space uncachable).

>> That would mean that we need to flush the range occupied by DBDMA
>> descriptors, but also any buffers used by DBDMA when outputing via a
>> DBDMA channel.
>Fortunately we don't need to, on PCI powermacs at least.  As I said,
>nubus powermacs are a whole 'nother can of worms, as are 68k macs.

Hum, asun will have fun making them work... and I too since I promised I would
help fixing head.S and kernel mappings...

>> Either I missed something big, either linux fails to do so and may have
>> unreliable writes to DBDMA devices all the time (looks like it would
>> crash a lot more often than it does, I must be wrong somewhere).
>It would crash a lot more often.  Things just basically wouldn't work.


           E-Mail: <mailto:bh40 at>
BenH.      Web   : <>

[[ 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. Please check ]]
[[ and for useful information before posting.   ]]

More information about the Linuxppc-dev mailing list