changing info when completing delayed reads.

[Kevin Normoyle <Kevin.Normoyle@Sun.COM>]

Background:

PCI 2.1 page 51 3.3.3.3.2 "Information Required to Complete a Delayed 
Transaction" says

that address, command, byte enables, parity bits (if enabled), data (if write)
and REQ64# (if 64-bit) and LOCK# (if lock supported) should be saved
during a delayed transaction.

It also says that byte enables are not required to be part of the
later compare, under some circumstances.


It then says
	"The master must repeat the transaction exactly as the original
	request ..."
	
		
Enforcement/nonenforcement of "exactly" is the question.


Question:

Some PCI bridges appear to relax this rule. For instance
Intel (ex-DEC) bridges allow any read command to match any read command.

One could also imagine cases where someone started as 64-bit request, and
then decided to change to 32-bit. It doesn't appear to me that Intel
requires the 64-bitness to match. (they don't compare byte enables for prefetchable
stuff, because they always get 8 bytes)

I could imagine a corner case where a retry in the middle of a
burst, is retried and treated generally as a delayed transaction. The
master might come back, and decide he doesn't need as many bytes
as initially, now, and use a different read command.


But lets ignore that case. We can say a retry in the middle of
a burst doesn't have "come back" rules that are the same as a delayed
read that hasn't returned any data yet....

It would still seem there defacto behaviors by host bridges, that might 
allow "non-compliant" devices to make it to market.

Specifically: if the Intel bridges allow read commands to alias (why
did they do that? ) and they don't compare byte enables for prefetchable
stuff, does that mean devices exist that change the read commands, and
maybe change the byte enables (or switch from 64-bit to 32-bit request
on the retry?)

any experiences in this area?

Sure, a DTO should eventually detect and clear out the problem, but you waste
2**15 cycles.

Do people have experience with devices causing a lot of DTO's ?? (I have
no idea how DTO's are reported, if at all, on various systems)



-kevin