All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.