Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: "Gleb O. Raiko" <raiko@niisi.msk.ru>
To: Jun Sun <jsun@mvista.com>
Cc: "linux-mips@oss.sgi.com" <linux-mips@oss.sgi.com>
Subject: Re: arch/mips/pci* stuff
Date: Mon, 17 Sep 2001 15:21:16 +0400	[thread overview]
Message-ID: <3BA5DCAC.F4E8E236@niisi.msk.ru> (raw)
In-Reply-To: 3B9E63A9.F2B5703C@mvista.com

Jun,

Jun Sun wrote:
> 
> Gleb,
> 
> Sorry to get back to this late.  I have been on a trip.
> 
> If I understand you correctly, your major argument is that "we do scan first,
> so that we can do resource assignment more easily because we have got all the
> dev structures and lists".

Yes. Also, "no code duplication".

> 
> This unfortunately may not work, mainly because the PCI bridge may not be
> setup properly so the scan results may be incomplete or invalid.

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.

> 
> However, I do see your point.  Actually the most desirable result might be
> that we do the resource assignement while we do the scan.
> 
> I think more and more people are realizing that bus number assignment and
> fixup must be done separately and done at the beginning.  It is a more
> complicated problem.  For example, in a multi-CPU cPCI system, you don't want
> to re-assign bus numbers unless you are the first CPU to boot up.

Thus, pcibios_assign_all_busses should just check CPU number.

> 
> pci_auto.c is not the ultimate solution.  But the nice thing is that it solves
> the broken firmware problem and yet still works with pci_scan_bus() scheme.
> 
> My personal view is that we ultimately should do something like this:
> 
> 1. do one pass scan for PCI bridges and do bus number assigment or fixup.
> 
> 2. based on the above results, we should have a uniformed access to all
> devices on all buses (such as read_pci_config(busno, ...)).
> 
> 3. do another pass of pci scan to discover pci devs and assign proper
> resources.

You definitely can't mix device discovering and assignment of resources
in one pass a on a multi-board cPCI system.

While you may implement the algorithm above, I think it isn't necessary.
Between my previous mail and your reply, I just implemented pcibios_
calls for a mips board that has 2 PCI busses with a PCI bridge between.
Yes, BIOS doesn't initialize PCI properly. 

What I had to do is just call pci_scan_bus,
pci_assign_unassigned_resources, and provide callbacks for 

- pcibios_fixup_bus (sets bus->resource[] to board private resources
describing PCI spaces for root bus and to corresponding bridge resources
for child bus. For the latter case, I had to inherit values from parent
bus also.)

- pcibios_update_resource (just write supplied value to the
configuration register)

- pcibios_fixup_pbus_ranges (convert addresses on the system bus to
addresses on PCI bus)

I also implemented registration of resources in the global resource
tree, but it's not necessary.

The only problem I observed is that PCI code treats 0 as invalid
address. It's bad but non-fatal.

> 
> BTW, I think your pcibios_assign_resources(bus) function may have already been
> implemented in the current pci code.  See pbus_assign_resources().  Those
> functions are relatively new.  I have not got time to fully digest them yet.

I had. Basically, pci_assign_unassigned_resources will do the job if
pcibios_fixup_bus will provide places for bus->resources.

Regards,
Gleb.

  reply	other threads:[~2001-09-17 11:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-24  9:55 arch/mips/pci* stuff Gleb O. Raiko
2001-08-24 13:33 ` Ralf Baechle
2001-08-24 16:13 ` Pete Popov
2001-08-24 17:57 ` Jun Sun
2001-08-24 18:20   ` Ralf Baechle
2001-08-28 11:22   ` Gleb O. Raiko
2001-09-11 19:19     ` Jun Sun
2001-09-17 11:21       ` Gleb O. Raiko [this message]
2001-09-17 22:37         ` Jun Sun
2001-09-19  8:23           ` Gleb O. Raiko
2001-09-19 18:00             ` Jun Sun

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3BA5DCAC.F4E8E236@niisi.msk.ru \
    --to=raiko@niisi.msk.ru \
    --cc=jsun@mvista.com \
    --cc=linux-mips@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox