"Gleb O. Raiko" wrote:
> Jun Sun wrote:
> > > You may control pci_scan_bridge by pcibios_assign_all_busses, just
> > > return 0 from the latter and the code in pci_scan_bridge assigns all
> > > numbers itself.
> > Do you mean that we call pci_scan_brige first before scaning other devices?
> Yes I do. Look at drivers/pci/pci.c. The code does
> for each bus (by recursion)
> scan devices on this bus
> for each bridge on this bus
> scan bridge
> scan bus behind bridge
> The flow is pci_do_scan_bus -> pci_scan_bridge -> pci_do_scan_bus
> > > You definitely can't mix device discovering and assignment of resources
> > > in one pass a on a multi-board cPCI system.
> > >
> > I have not given enough thought on 3), but it is certainly desirable.
> Well, your previous example works here. You perform scanning of devices
> and assignments in one pass. You find new device unassigned by
> firmware/another CPU in cPCI system, then you need find a room in a PCI
> space. You can't do that, because you don't know yet what rooms
> firmware/another CPU has allocated, so you don't know what rooms are
You can if you throw away all the previous assignement done by BIOS, like
> > Like I said before, this is the old style of doing things. There are many
> > drawbacks in this approach. Among them, one is to require lots of knowledge
> > about PCI and how the following hookup functions are called. Not every
> > porting engineer is willing to dive into that. There are some other
> > problems
> > too.
> Sorry, your reason doesn't convince me. I believe, a porting engineer
> must know hardware and operating system internals very well irrespective
> of what his wishes are.
> Could you explain other problems, please ?
I am not actively working on PCI right now. A couple of problems I remembered
are related to the fixup mechnisms. If you rely on BIOS assignment, than you
cannot do fixup on a per-PCI-device basis, then you have to do fixup based on
I think a couple of days ago, there was a question about the restriction of
PCI memory space being the same as CPU physical address space. Using pci_auto
allows you to control the PCI memory region you use and deal with the
restriction more easily.
BTW, your objection seems to stem from the objection against pci_auto. But so
far I have not seen any good reasons for not using pci_auto. Did I miss
anything? If pci_auto does make porting easier, is there any good reason to
go to a more difficult route?
If you compare code size, PCI auto is much much smaller than the
pci_assign_unassigned_resources(). I really don't understand what is the