Re: arch/mips/pci* stuff

[Jun Sun <jsun@mvista.com>]

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

You can if you throw away all the previous assignement done by BIOS, like
pci_auto.c approach.

> > 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
per-device/BIOS-combo basis.

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
complain here.

Jun