> 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?
Bad spotting. :)
I donnot reveal the vendor because the last time I did so I have had to
deal will unnecessary noise.
> 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.
Note that ISA is officially PC99/00-dead, IIRC, so this will perhaps
become for you as simple as PCI in some near future. :-)
> It gets worse, now that I have a broader insight into the madness.
>
> Is this familar?
Pure PCI seem a lot more clean that the ISA/IDE inheritance with regards
to silicon we may have to deal with.
I am just wondering about how and why ingenieers decided not to follow the
standard for PCI. They may just not have read or not have understood the
specs or perhaps based their design rather on stolen documents from their
concurrents instead of just following available specifications. :-) Or
may-be, it has unfortunately been the same PCI-skimed guys that moved from
one company to another and that, each time, missed to learn to read. ;-)
> > 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............
If we assume that all PCI-HOST bridges that are used with X86 hardware are
all fine (I mean that we just don't care about those that are not so ;) ),
then the number of remaining bridges (used on non-X86 systems) we can get
documentation about should not be that large.
No documentation means not supported or just finger-crossed support and no
more.
> Andre Hedrick
> The Linux IDE guy
Gérard Roudier
A IDE-immune-for-ever guy. :-)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/