lkml.org 
[lkml]   [2001]   [Nov]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch non-x86] PCI-PCI bridges fix
On Fri, Nov 23, 2001 at 08:49:30AM +1100, Paul Mackerras wrote:
> There is code in pci_read_bridge_bases which will decide under some
> circumstances that a PCI-PCI bridge is transparent and set
>
> child->resource[i] = child->parent->resource[i];
>
> for i = 0, 1 or 2. What will happen with your request_resource in
> this case is that the resource will end up being its own parent and
> its own child and all allocations against it will fail. :)

These code paths shouldn't be mixed in the first place, i.e. if
you use stuff in setup-bus.c, don't use pci_read_bridge_bases.
Basically, these are two different approaches to PCI setup:
"We trust our firmware" (i386, ia64) and "We are the firmware"
(alpha, arm, partially parisc).

> I hit this just yesterday on PPC. On our RS/6000 boxes, if you have a
> PCI-PCI bridge with nothing behind it, the firmware will configure it
> with all the apertures closed, i.e. with base set larger than limit.

Right, as required by PCI-PCI bridge specs.

> Then pci_read_bridge_bases goes and decides that the bridge is
> transparent and consequently everything stops working. :(

I think that "assuming transparent" code is not correct. Yes, PCI-PCI
bridge specs allow "transparent" (i.e. subtractive decoding) bridges,
but such bridges must have a class code 0x60401. IMO, we need something
like this instead:

if (!dev) /* It's a host bus, nothing to read */
return;
+ if (dev->class & 1) {
+ printk("Subtractive decoding bridge %s: assuming transparent\n",
+ dev->name);
+ for(i=0; i<3; i++)
+ child->resource[i] = child->parent->resource[i];
+ return;
+ }
Of course, this requires testing on problematic machines.
BTW, currently almost every PC user sees those "Unknown bridge resource"
messages just because a graphic card behind the AGP bridge doesn't use
IO or prefetchable memory...

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:13    [from the cache]
©2003-2011 Jasper Spaans