[PATCH] Don't touch BARs of host bridges

[PATCH] Don't touch BARs of host bridges

[Maciej W. Rozycki]

Hello,

 BARs of host bridges often have special meaning and AFAIK are best left 
to be setup by the firmware or system-specific startup code and kept 
intact by the generic resource handler.  For example a couple of host 
bridges used for MIPS processors interpret BARs as target-mode decoders 
for accessing host memory by PCI masters (which is quite reasonable).  
For them it's desirable to keep their decoded address range overlapping 
with the host RAM for simplicity if nothing else (I can imagine running 
out of address space with lots of memory and 32-bit PCI with no DAC 
support in the participating devices).

 This is already the case with the i386 and ppc platform-specific PCI 
resource allocators.  Please consider the following change for the generic 
allocator.  Currently we have a pile of hacks implemented for host bridges 
to be left untouched and I'd be pleased to remove them.

  Maciej

patch-mips-2.6.10-rc2-20041124-pci-hb-0
diff -up --recursive --new-file linux-mips-2.6.10-rc2-20041124.macro/drivers/pci/setup-bus.c linux-mips-2.6.10-rc2-20041124/drivers/pci/setup-bus.c
--- linux-mips-2.6.10-rc2-20041124.macro/drivers/pci/setup-bus.c	2004-11-12 13:12:47.000000000 +0000
+++ linux-mips-2.6.10-rc2-20041124/drivers/pci/setup-bus.c	2004-12-08 13:32:06.000000000 +0000
@@ -57,8 +57,13 @@ pbus_assign_resources_sorted(struct pci_
 	list_for_each_entry(dev, &bus->devices, bus_list) {
 		u16 class = dev->class >> 8;
 
-		if (class == PCI_CLASS_DISPLAY_VGA
-				|| class == PCI_CLASS_NOT_DEFINED_VGA)
+		/* Don't touch classless devices and host bridges.  */
+		if (class == PCI_CLASS_NOT_DEFINED ||
+		    class == PCI_CLASS_BRIDGE_HOST)
+			continue;
+
+		if (class == PCI_CLASS_DISPLAY_VGA ||
+		    class == PCI_CLASS_NOT_DEFINED_VGA)
 			bus->bridge_ctl |= PCI_BRIDGE_CTL_VGA;
 
 		pdev_sort_resources(dev, &head);

Re: [PATCH] Don't touch BARs of host bridges

[Benjamin Herrenschmidt]

On Fri, 2004-12-10 at 00:20 +0000, Maciej W. Rozycki wrote:
> Hello,
> 
>  BARs of host bridges often have special meaning and AFAIK are best left 
> to be setup by the firmware or system-specific startup code and kept 
> intact by the generic resource handler.  For example a couple of host 
> bridges used for MIPS processors interpret BARs as target-mode decoders 
> for accessing host memory by PCI masters (which is quite reasonable).  

Not very reasonable in fact imho but that happens on some embedded PPCs
was well :) So I agree, that would be useful to skip them. I'm not sure
about PCI_CLASS_NOT_DEFINED tho ...

Re: [PATCH] Don't touch BARs of host bridges

[Maciej W. Rozycki]

On Fri, 10 Dec 2004, Benjamin Herrenschmidt wrote:

> >  BARs of host bridges often have special meaning and AFAIK are best left 
> > to be setup by the firmware or system-specific startup code and kept 
> > intact by the generic resource handler.  For example a couple of host 
> > bridges used for MIPS processors interpret BARs as target-mode decoders 
> > for accessing host memory by PCI masters (which is quite reasonable).  
> 
> Not very reasonable in fact imho but that happens on some embedded PPCs

 Well, some of these bridges may be used for peripheral devices (option
cards) built around a CPU, typically after reprogramming the class code to
something corresponding to their actual function.  Why should the address
decoder circuitry suddenly change in this case?

 Also even in the "host mode" another device may wish to examine what
resources have been reserved by the host bridge (unlikely, I admit, but 
in principle why not?).

> was well :) So I agree, that would be useful to skip them. I'm not sure
> about PCI_CLASS_NOT_DEFINED tho ...

 These are pre-2.0 PCI devices -- from before the detailed classification
was agreed upon.  AFAIK, just a couple of them exist -- I can name:  
Intel's 82424 and 82425 families of i486 host bridges, their 82375 family
of PCI-EISA bridges and their 82378/9 family of PCI-ISA bridges (also used
in a few DEC Alpha systems).  There are probably a handful of other chips,
all of them about ten years old.  Our i386 and ppc resource managers skip
over them as well and I suppose this is a safe default.  If any of them
needs BAR setup (none of these Intel ones), it can be added explicitly by
means of its vendor:device ID.

  Maciej

Re: [PATCH] Don't touch BARs of host bridges

[Benjamin Herrenschmidt]

On Fri, 2004-12-10 at 13:11 +0000, Maciej W. Rozycki wrote:

>  Well, some of these bridges may be used for peripheral devices (option
> cards) built around a CPU, typically after reprogramming the class code to
> something corresponding to their actual function.  Why should the address
> decoder circuitry suddenly change in this case?

To stay in the PCI spec ? :) They would need at least a way to "lock"
the BARs.

>  Also even in the "host mode" another device may wish to examine what
> resources have been reserved by the host bridge (unlikely, I admit, but 
> in principle why not?).

Very unlikely.

> > was well :) So I agree, that would be useful to skip them. I'm not sure
> > about PCI_CLASS_NOT_DEFINED tho ...
> 
>  These are pre-2.0 PCI devices -- from before the detailed classification
> was agreed upon.  AFAIK, just a couple of them exist -- I can name:  
> Intel's 82424 and 82425 families of i486 host bridges, their 82375 family
> of PCI-EISA bridges and their 82378/9 family of PCI-ISA bridges (also used
> in a few DEC Alpha systems).  There are probably a handful of other chips,
> all of them about ten years old.  Our i386 and ppc resource managers skip
> over them as well and I suppose this is a safe default.  If any of them
> needs BAR setup (none of these Intel ones), it can be added explicitly by
> means of its vendor:device ID.

Ok.

Ben.

Re: [PATCH] Don't touch BARs of host bridges

[Maciej W. Rozycki]

On Sat, 11 Dec 2004, Benjamin Herrenschmidt wrote:

> >  Well, some of these bridges may be used for peripheral devices (option
> > cards) built around a CPU, typically after reprogramming the class code to
> > something corresponding to their actual function.  Why should the address
> > decoder circuitry suddenly change in this case?
> 
> To stay in the PCI spec ? :) They would need at least a way to "lock"
> the BARs.

 What do you mean?  If used in an option card, you may want some of the
device's internal address space to be accessible from your host somehow,
e.g. as a way of interfacing the device's firmware, so you need a BAR to
map it somewhere in the PCI address space.

> >  These are pre-2.0 PCI devices -- from before the detailed classification
> > was agreed upon.  AFAIK, just a couple of them exist -- I can name:  
> > Intel's 82424 and 82425 families of i486 host bridges, their 82375 family
> > of PCI-EISA bridges and their 82378/9 family of PCI-ISA bridges (also used
> > in a few DEC Alpha systems).  There are probably a handful of other chips,
> > all of them about ten years old.  Our i386 and ppc resource managers skip
> > over them as well and I suppose this is a safe default.  If any of them
> > needs BAR setup (none of these Intel ones), it can be added explicitly by
> > means of its vendor:device ID.
> 
> Ok.

 And BTW, we fix it up for the 82375 as a quirk, by substituting the
"right" class code.  It can be done for others if there's a need.

  Maciej

Re: [PATCH] Don't touch BARs of host bridges

[Greg KH]

On Fri, Dec 10, 2004 at 12:20:40AM +0000, Maciej W. Rozycki wrote:
> Hello,
> 
>  BARs of host bridges often have special meaning and AFAIK are best left 
> to be setup by the firmware or system-specific startup code and kept 
> intact by the generic resource handler.  For example a couple of host 
> bridges used for MIPS processors interpret BARs as target-mode decoders 
> for accessing host memory by PCI masters (which is quite reasonable).  
> For them it's desirable to keep their decoded address range overlapping 
> with the host RAM for simplicity if nothing else (I can imagine running 
> out of address space with lots of memory and 32-bit PCI with no DAC 
> support in the participating devices).
> 
>  This is already the case with the i386 and ppc platform-specific PCI 
> resource allocators.  Please consider the following change for the generic 
> allocator.  Currently we have a pile of hacks implemented for host bridges 
> to be left untouched and I'd be pleased to remove them.

I've applied this to my trees, and it will show up in the next -mm
release, and then on to Linus's tree after 2.6.10 is out.

Oh, and next time, I need a "Signed-off-by:" line as per
Documentation/SubmittingPatches.

thanks,

greg k-h