Messages in this thread |  | | From | Benjamin Herrenschmidt <> | Subject | Re: FIXED! Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd) | Date | Thu, 26 Oct 2000 14:36:35 +0200 |
| |
> >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 <bh40@calva.net> To: Martin Mares <mj@suse.cz>, <linux-kernel@vger.kernel.org> 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: <19340920060726.2586@192.168.1.2> In-Reply-To: <20001026111138.A421@albireo.ucw.cz> References: <20001026111138.A421@albireo.ucw.cz> 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 <bh40@calva.net> To: Martin Mares <mj@suse.cz>, <linux-kernel@vger.kernel.org>, Linus Torvalds <torvalds@transmeta.com> 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: <19340920060810.10012@192.168.1.2> In-Reply-To: <20001026111138.A421@albireo.ucw.cz> References: <20001026111138.A421@albireo.ucw.cz> 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 majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |