I just read the following about a non-Intel, non-IBM, non-SUN, non-HP, and
non-Digital PCI-HOST bridge (guess vendor :) ):
Ordering is guaranteed when interrupts are used. An interrupt handler
is not executed until all writes initiated by the interrupting device
have completed.
(+ some confusing explanations about the fact that it is the only
mechanism PCI device drivers must rely on for transaction ordering)
As opposite, we can read from PCI:
Interrupt requests do not appear as transactions on PCI bus (they are
sideband signals), and, therefore, have no ordering relationship to any
transactions. Furthermore, the system is not required to use the
Interrupt Acknowledge bus transaction to service interrupts. So
interrupts are not synchronizing events, and device drivers cannot
depend on then to flush posting buffers.
(I didn't read anything about this 'non' PCI-HOST bridge that address
Interrupt Acknowledge Transactions)
Based on my current investigations, it may be the case that numerous PCI
device drivers of ours may encounter problems on some non-Intel and
non-IBM bridge-based systems, due to bridge not implementing the standard
about transaction ordering rules.
As I wrote in some previous posting, I plan to propose serious work-arounds
for joking PCI bridges:) for the stuff I maintain (ncr/sym driver) before
the end of August if we survive August the 11'th obviously:-).
This may consist in a few number of lines mostly trivial, or to end up
with crossing fingers for some situations, but I need to investigate
the issue prior to do the changes in the code.
It will be interesting, in my opinion, to allow PCI device drivers to have
knowledge about the PCI-HOST bridge of the system or to have access to
some quirk flags associated with that bridge.
Regards,
G?rard.
On Sat, 24 Jul 1999, Gerard Roudier wrote:
> Based on my current investigations, it may be the case that numerous PCI
> device drivers of ours may encounter problems on some non-Intel and
> non-IBM bridge-based systems, due to bridge not implementing the standard
> about transaction ordering rules.
Do you mean the super socket 7 hell?
I am have to access host and isa bridges to setup/identify capablity of
these ide-chipsets. One of them is so bad that I have to determine the
revision of the isa-bridge to decide the feature limits of the ide
host-adapter, or determine the identity of the host-host device to try and
guess the setep of the isa-bridge lot/stamp.
The other chipset vender places a double ident chipset with two level of
access. The two possible isa-bridge devices must be detected to determine
the features list. If you get the one with latest bridge, you still have
to access the lower bridge to setup the ide host-adapter. Oh did I forget
to mention that the irq routing table for the IDE is only settable in the
isa-bridge, or that you have to dork with a few bits to disable the pnp
simplex block.
It gets worse, now that I have a broader insight into the madness.
Is this familar?
> As I wrote in some previous posting, I plan to propose serious work-arounds
> for joking PCI bridges:) for the stuff I maintain (ncr/sym driver) before
> the end of August if we survive August the 11'th obviously:-).
> This may consist in a few number of lines mostly trivial, or to end up
> with crossing fingers for some situations, but I need to investigate
> the issue prior to do the changes in the code.
>
> It will be interesting, in my opinion, to allow PCI device drivers to have
> knowledge about the PCI-HOST bridge of the system or to have access to
> some quirk flags associated with that bridge.
Been there........got the T-Shirt............
Andre Hedrick
The Linux IDE guy