linux-mips
[Top] [All Lists]

Re: arch/mips/pci* stuff

To: Jun Sun <jsun@mvista.com>
Subject: Re: arch/mips/pci* stuff
From: "Gleb O. Raiko" <raiko@niisi.msk.ru>
Date: Wed, 19 Sep 2001 12:23:27 +0400
Cc: "linux-mips@oss.sgi.com" <linux-mips@oss.sgi.com>
Organization: NIISI RAN
References: <3B862487.EF22D143@niisi.msk.ru> <3B869596.CBDBC20D@mvista.com> <3B8B7ED8.D2DD9E86@niisi.msk.ru> <3B9E63A9.F2B5703C@mvista.com> <3BA5DCAC.F4E8E236@niisi.msk.ru> <3BA67B2D.604D95E5@mvista.com>
Sender: owner-linux-mips@oss.sgi.com
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.

<Prev in Thread] Current Thread [Next in Thread>