Re: arch/mips/pci* stuff

["Gleb O. Raiko" <raiko@niisi.msk.ru>]

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
free.

Thus, you have to scan pci in two passes. On first pass, just scan
devices and collect allocated rooms in PCI spaces. On second pass,
assign unassigned devices.

Look how Dave Miller did this for ultras in 2.2 when common pci driver
didn't do that. You have to implement more or less the same modulo
ultras hw and OBP bugs. BTW, it's exactly what current drivers/pci code
does.

> 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 ? 

Regards,
Gleb.