lkml.org 
[lkml]   [2003]   [Jan]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch 2.5] PCI: allow alternative methods for probing the BARs
On Sun, Jan 05, 2003 at 08:14:53PM -0800, Linus Torvalds wrote:
> Can you do the same with a multi-pass thing?
>
> I really think the single-pass approach is broken, because it means that
> we _cannot_ have a fixup for device that runs _before_ the fixup for the
> bridge that bridges to the device.
>
> As such, the "PCI_FIXUP_EARLY" is not _nearly_ early enough, since it's
> way too late for the actual problem that started this whole thread (ie in
> order to turn off a bridge, we have to make sure that everything behind
> the bridge is turned off _first_).

I totally agree, 2-phase approach is a right way to go. However, I've been
confused by that "feature freeze" thing. ;-)
This patch has zero impact on existing code - I thought it's a "feature"
(and I still believe it's ok for 2.4).
OTOH, I've actually tried to implement 2-phase probing _inside_ the
pci_do_scan_bus, and that was ugly as hell.
I believe the phase #2 must be a separate top-level function -
something like pci_probe_resources (better naming?), but this
assumes some changes to PCI code for every architecture and hotplug
drivers.

> In other words, we really should be able to do all the bus number setup
> _first_. That isn't dependent ont eh BAR's or anything else. The actual
> _sizing_ of the bus is clearly somethign we cannot do early, but we can
> (and should) enumerate the devices first in phase #1.
>
> Alternatively, we could even have a very limited phase #1 that only
> enumerates _reachable_ devices (ie it doesn't even try to create bus
> numbers, it only enumerates devices and buses that have already been set
> up by the firmware, and ignores bridges that aren't set up yet). A pure
> discovery phase, without any configuration at all.

I like the former. Even if we have to reassign the bus numbers,
we won't affect anything but forwarding the PCI configuration
cycles.

For now I'd start with following:
phase #1. pci_do_scan_bus() - build the bus/device tree, read in
dev/vendor IDs, header type and class code; call
"PCI_FIXUP_EARLY" fixups.
phase #2. pci_probe_resources(bus) - walk the bus tree again,
probe the BARs, maybe call pci_read_bridge_bases for
bridges; fill in the rest of PCI header; call "PCI_FIXUP_HEADER"
fixups.
(Also there are phases #3 and #4 - assign resources and assign unassigned
resources, but it's another story)

Then, for example on alpha, we'll have

/* Scan all of the recorded PCI controllers. */
for (next_busno = 0, hose = hose_head; hose; hose = hose->next) {
hose->first_busno = next_busno;
hose->last_busno = 0xff;
bus = pci_scan_bus(next_busno, alpha_mv.pci_ops, hose);
hose->bus = bus;
next_busno = hose->last_busno = bus->subordinate;
+ pci_probe_resources(bus);
next_busno += 1;
}

Hmm, this looks good - now we can do early bus-specific fixups
without introducing "pcibios_init_bus" thing (suggested by Grant and
myself quite a while ago).

I'll try to code up all of this and do some basic testing on alpha
and i386 in next few days.

Comments?

Ivan.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:32    [W:0.103 / U:4.644 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site