>
>Yes, it will break on any machine with multiple primary PCI busses, because
>the registers assigning bus number ranges to primary busses are chipset
>specific.
>
>In 2.5, I'd like to rewrite the resource + bus number assignment code to be
>able to re-layout the busses and resources even on i386 if it detects it's
>safe to do so (that is there is either only one primary bus or the host
bridge
>is known). This will be needed for proper PCI hotplug and it will also help
>us to get rid of some more BIOS bugs (especially on some embedded systems).
The current 2.4 code with assign_all_busses enabled works nicely on the
Apple "UniNorth" 3-host mecanism. There's apparently no register to
configure to set the primary bus number (the bridge doesn't care what
it's bus number is, it just has different mecanism to issue type 0 and
type 1 config cycles).
We also have something that is not directly supported in the 2.4 PCI
code, but that I implemented via fixups & pcibios_update_resource(),
which is to have a offset applied to all MMIO resources. Some PPC
machines don't have a 1:1 mapping of PCI memory space vs. CPU physical
space, and so we must add this offset to all memory resources and
substract it ffrom pcibios_update_resource().
I still have not implemented per-host parent resoures (we currently have
one parent resource for all 3 hosts), I'm still not completely sure of
the best way to implement it (the bus resources management still has a
few obscure zones to me).
The main problem with PCI we are facing on all our platforms is related
to IOs. There are way too may assumtions in the kernel based on the x86
fact that PCI IOs are more or else equivalent to ISA IOs, limited to one
64k space, and so on.
We have several cases of machines with several IO busses, each one having
it's own IO address space 0->xxxxxxx mapped differently (elsewhere) in
the CPU physical memory space (those CPUs don't have specific in/out
instructions), and which can be more than 64k long. Also, not all host
bridge can do remapping of legacy ISA addresses.
That leads to several issues with this: If we want to support "normal"
PCI IOs (devices that expose registers as IO ranges only, but that also
fully support PCI 32 bits IO space) on all of these busses, and still be
"compatible" with drivers that do in/out functions on legacy (<64k)
addresses and expect reaching either an ISA bus or legacy devices on the
PCI bus, we need to do all sort of hacking and we have not yet figured
out a solution that would make everybody happy.
We can put the real physical address used to generate the proper IO cycle
in the PCI drive resource structure and have in/out just do the same as
readb/writeb. This allows to handle properly PCI IOs on all busses, but
breaks legacy crap.
We can (and that's what we do today) decide that only one bus support IOs
and have a "global" IO_BASE which is added to all in/out accesses, and
which is the ioremap'ed IO space of the single bus we decide supports
IOs. But that means that we can't access both the VGA registers of a card
in the AGP slot and PCI IO space of another card in the main PCI slots
(different busses and different IO spaces).
We can use MMU tricks to "append" together all IO spaces, one of them
beeing considered as the primary and beeing mapped at the bottom of this
virtual IO space (for legacy in/out) and all other beeing appended to
this one (with proper fixup of PCI resources). This was discussed on
linuxppc-dev list a lot, but not implemented yet.
My personal point of view would be to either separate completely ISA &
PCI IO macros, or have a mecanism for all legacy (VGA, ISA, ...) drivers,
to ask for a base address from the "legacy" address they intend to use.
(get_legacy_base(VGA_LEGACY) for example, would return the IO base to
apply to all in/out macros used to access the IO space).
That's still not perfect since we can't support two VGA cards on separate
busses (which would be theorically possible on a Mac: one in the AGP
slot, one in a PCI slot, both having different IO space).
So I'm still open to suggestions, but I'd really like to see this problem
adressed for _2_5 in a "generic" way. Currently, it's more or less
choosing between supporting legacy devices on one bus and no real PCI IOs
on any other bus but the first one, or
supporting real PCI IOs on all busses, but no legacy IOs. Note that we
don't have such a problem for MMIOs fortunately ;)
Ben.
------------------ RFC822 Header Follows ------------------
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
To: Martin Mares <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
Subject: Re: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI
resourcecollisions (fwd)
Date: Thu, 26 Oct 2000 14:35:42 +0200
Message-Id: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
X-Mailer: CTM PowerMail 3.0.5 <http://www.ctmdev.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
-----------------------------------------------------------
------------------ RFC822 Header Follows ------------------
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
To: Martin Mares <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, Linus
Torvalds <[EMAIL PROTECTED]>
Subject: Re: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI
resourcecollisions (fwd)
Date: Thu, 26 Oct 2000 14:36:26 +0200
Message-Id: <[EMAIL PROTECTED]>
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
X-Mailer: CTM PowerMail 3.0.5 <http://www.ctmdev.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
-----------------------------------------------------------
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
