PCI: flushing the posted write buffer

[dgi...@my-deja.com]

Paraphrasing some from PCI System Architecture:

In PCI, if a bridge implements a posted write
buffer, another bus master may initiate a posted
read from the target of the posted write before
the data is actually written to the target.

The passage goes on to explain that a fix for
this potential problem is in the device driver to
perform a read on the device, which will flush
all posted writes from the destination targets.
My question is: does vxWorks have a call that
does the "flushing" for you, or is there an
inline assembly call I can implement into my C
code?

Thanks

Sent via Deja.com
http://www.deja.com/

[James Marshall]

The flushing of the posted write buffer is triggered by doing a read after
you've completed your writes - that's the only software involvement. The read
will be queued behind the writes and won't be initiated until all the writes
complete. Any read to a target on the opposite side of a PCI-PCI bridge will
cause the posted-write buffer on that target's side to be flushed.

I don't think a "posted read" exists. Reads will stall the processor until they
complete. Depending on the sophistication of your PCI devices the PCI bus may be
blocked as well, but there is the Retry method where the PCI target tells the
initiator to come back later for the data - it's conceptually similar to
disconnect in SCSI - and it allows other bus masters like the LAN controller to
grab the bus.

James.

[David Laight]

As stated by James, all that is needed is a read cycle.
Note that a modern cpu has other places where write cycles
are 'posted' the read back will flush all these buffers.
(maybe the ppc needs a bigger push to clear the 'out of order'
execution, but I'm not sure.

In your C declare the hardware registers as 'volatile' eg:
volatile unsigned int *hw_reg = xxxxx;
*hw_reg = yyyy;
*hw_reg; (the compiler may compare this against 0!)

It is probable (but check the reference manual) that all writes (to a single
memory area? and not on the ppc?) will be issued by the cpu in the order
requested by the (object) code. This only a single read is required to
flush a block of writes.

Note that Intel do not clearly define whether IO writes and memory writes
are sequenced separately for x86 processors. Indeed I recall seeing
information that implied it was processor dependant! (Pentium may be
different from the 486!)

The most obvious symptom of this driver 'bug' is the 'unexpected interrupt'
message - caused by the cpu leaving an ISR before the hardware has seen
the write that clears the interrupt request.

(FYI I first met this sort of problem on a 286 board! A write to the
interrupt
controller (8259A?) mask followed by a CLI (or is it STI) to enable
interrupts
WILL break the cycle recovery time of the 8259 causing ALL its registers
to get stuffed. The 286 has a single entry write buffer, so any bus
access between the mask write and interrupt enable will fix this.)

David

<dgi...@my-deja.com> wrote in message news:91t855$8r1$1...@nnrp1.deja.com...