Thread (13 messages) 13 messages, 5 authors, 2002-02-02

Re: [patch] linux 2.4.17: An mb() rework

From: Alan Cox <hidden>
Date: 2002-02-01 00:59:20

A little more qualification would be that:
    write(...,device);   // Disable int
    wmb()
    enable_ints();
Is expected to have a potential spurious interrupt. But, perhaps this is
OK:
    outl(...,device);
    wmb();
    enable_ints();
This is consistant with how the PCI spec discusses ordering/etc and
barriers are frequently used in the PCI drivers. Looking at the i386 code
this is what I would expect to see.

Anyone know for sure?
The x86 behaviour forced as I understand it is

	barrier()		-	compiler level store barrier
	rmb()			-	read barrier to bus/DMA level
					[no operation]
	wmb()			-	write barrier to bus/DMA level
					[synchronizing instruction sequence
					 of locked add of 0 to stack top]

	(mb and wmb as names come from Alpha so I guess its definitive 8))

It does not enforce PCI posting. Also your spurious interrupt case is
wrong for other horrible reasons. Interrupt delivery must never be 
assumed to be synchronous in a portable driver. (In fact you'll see async
irq delivery on an X86)
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help