Re: PCI-PCI bridges mess in 2.4.x

Re: PCI-PCI bridges mess in 2.4.x

[Richard Henderson]

[-- Attachment #1: Type: text/plain, Size: 681 bytes --]

[ For l-k, the issue is that pci-pci bridges and the devices behind
  them are not initialized properly.  There are a number of Alphas
  whose built-in scsi controlers are behind such a bridge preventing
  these machines from booting at all.  Ivan provided an initial 
  patch to solve this issue.  ]

I've not gotten a chance to try this on the rawhide yet,
but I did give it a whirl on my up1000, which does have
an agp bridge that acts like a pci bridge.

Notable changes from your patch:

  * Use kmalloc, not vmalloc.  (ouch!)
  * Replace cropped found_vga detection code.
  * Handle bridges with empty I/O (or MEM) ranges.
  * Collect the proper width of the bus range.


r~

[-- Attachment #2: diff vs bridges-2.4.0t10 --]
[-- Type: text/plain, Size: 2676 bytes --]

diff -rup linux/drivers/pci/setup-bus.c 2.4.0-11-1/drivers/pci/setup-bus.c
--- linux/drivers/pci/setup-bus.c	Wed Nov  8 01:24:16 2000
+++ 2.4.0-11-1/drivers/pci/setup-bus.c	Wed Nov  8 01:04:17 2000
@@ -20,7 +20,7 @@
 #include <linux/errno.h>
 #include <linux/ioport.h>
 #include <linux/cache.h>
-#include <linux/vmalloc.h>
+#include <linux/slab.h>
 
 
 #define DEBUG_CONFIG 1
@@ -56,31 +56,50 @@ pbus_assign_resources_sorted(struct pci_
 			mem_reserved += 32*1024*1024;
 			continue;
 		}
+
+		if (dev->class >> 8 == PCI_CLASS_DISPLAY_VGA)
+			found_vga = 1;
+
 		pdev_sort_resources(dev, &head_io, IORESOURCE_IO);
 		pdev_sort_resources(dev, &head_mem, IORESOURCE_MEM);
 	}
+
 	for (list = head_io.next; list;) {
 		res = list->res;
 		idx = res - &list->dev->resource[0];
-		if (pci_assign_resource(list->dev, idx) == 0)
+		if (pci_assign_resource(list->dev, idx) == 0
+		    && ranges->io_end < res->end)
 			ranges->io_end = res->end;
 		tmp = list;
 		list = list->next;
-		vfree(tmp);
+		kfree(tmp);
 	}
 	for (list = head_mem.next; list;) {
 		res = list->res;
 		idx = res - &list->dev->resource[0];
-		if (pci_assign_resource(list->dev, idx) == 0)
+		if (pci_assign_resource(list->dev, idx) == 0
+		    && ranges->mem_end < res->end)
 			ranges->mem_end = res->end;
 		tmp = list;
 		list = list->next;
-		vfree(tmp);
+		kfree(tmp);
 	}
+
 	ranges->io_end += io_reserved;
 	ranges->mem_end += mem_reserved;
+
+	/* ??? How to turn off a bus from responding to, say, I/O at
+	   all if there are no I/O ports behind the bus?  Turning off
+	   PCI_COMMAND_IO doesn't seem to do the job.  So we must
+	   allow for at least one unit.  */
+	if (ranges->io_end == ranges->io_start)
+		ranges->io_end += 1;
+	if (ranges->mem_end == ranges->mem_start)
+		ranges->mem_end += 1;
+
 	ranges->io_end = ROUND_UP(ranges->io_end, 4*1024);
 	ranges->mem_end = ROUND_UP(ranges->mem_end, 1024*1024);
+
 	return found_vga;
 }
 
diff -rup linux/drivers/pci/setup-res.c 2.4.0-11-1/drivers/pci/setup-res.c
--- linux/drivers/pci/setup-res.c	Wed Nov  8 01:24:16 2000
+++ 2.4.0-11-1/drivers/pci/setup-res.c	Wed Nov  8 00:21:13 2000
@@ -22,10 +22,10 @@
 #include <linux/errno.h>
 #include <linux/ioport.h>
 #include <linux/cache.h>
-#include <linux/vmalloc.h>
+#include <linux/slab.h>
 
 
-#define DEBUG_CONFIG 0
+#define DEBUG_CONFIG 1
 #if DEBUG_CONFIG
 # define DBGC(args)     printk args
 #else
@@ -146,7 +146,7 @@ pdev_sort_resources(struct pci_dev *dev,
 			if (ln)
 				size = ln->res->end - ln->res->start;
 			if (r->end - r->start > size) {
-				tmp = vmalloc(sizeof(*tmp));
+				tmp = kmalloc(sizeof(*tmp), GFP_KERNEL);
 				tmp->next = ln;
 				tmp->res = r;
 				tmp->dev = dev;

[-- Attachment #3: diff vs test11-1 --]
[-- Type: application/octet-stream, Size: 7521 bytes --]

Re: PCI-PCI bridges mess in 2.4.x

[Sean Hunter]

Hi Richard.

I'm _very_ keen to try this (my Alpha won't boot 2.4 at the mo), however I
think the attachments faery has been playing tricks again.

Do you have a patch relative to 2.4.0-test10?

Sean

On Wed, Nov 08, 2000 at 01:39:31AM -0800, Richard Henderson wrote:
> [ For l-k, the issue is that pci-pci bridges and the devices behind
>   them are not initialized properly.  There are a number of Alphas
>   whose built-in scsi controlers are behind such a bridge preventing
>   these machines from booting at all.  Ivan provided an initial 
>   patch to solve this issue.  ]
> 
> I've not gotten a chance to try this on the rawhide yet,
> but I did give it a whirl on my up1000, which does have
> an agp bridge that acts like a pci bridge.
> 
> Notable changes from your patch:
> 
>   * Use kmalloc, not vmalloc.  (ouch!)
>   * Replace cropped found_vga detection code.
>   * Handle bridges with empty I/O (or MEM) ranges.
>   * Collect the proper width of the bus range.
> 
> 
> r~

Content-Description: diff vs bridges-2.4.0t10
> diff -rup linux/drivers/pci/setup-bus.c 2.4.0-11-1/drivers/pci/setup-bus.c
> --- linux/drivers/pci/setup-bus.c	Wed Nov  8 01:24:16 2000
> +++ 2.4.0-11-1/drivers/pci/setup-bus.c	Wed Nov  8 01:04:17 2000
> @@ -20,7 +20,7 @@
>  #include <linux/errno.h>
>  #include <linux/ioport.h>
>  #include <linux/cache.h>
> -#include <linux/vmalloc.h>
> +#include <linux/slab.h>
>  
>  
>  #define DEBUG_CONFIG 1
> @@ -56,31 +56,50 @@ pbus_assign_resources_sorted(struct pci_
>  			mem_reserved += 32*1024*1024;
>  			continue;
>  		}
> +
> +		if (dev->class >> 8 == PCI_CLASS_DISPLAY_VGA)
> +			found_vga = 1;
> +
>  		pdev_sort_resources(dev, &head_io, IORESOURCE_IO);
>  		pdev_sort_resources(dev, &head_mem, IORESOURCE_MEM);
>  	}
> +
>  	for (list = head_io.next; list;) {
>  		res = list->res;
>  		idx = res - &list->dev->resource[0];
> -		if (pci_assign_resource(list->dev, idx) == 0)
> +		if (pci_assign_resource(list->dev, idx) == 0
> +		    && ranges->io_end < res->end)
>  			ranges->io_end = res->end;
>  		tmp = list;
>  		list = list->next;
> -		vfree(tmp);
> +		kfree(tmp);
>  	}
>  	for (list = head_mem.next; list;) {
>  		res = list->res;
>  		idx = res - &list->dev->resource[0];
> -		if (pci_assign_resource(list->dev, idx) == 0)
> +		if (pci_assign_resource(list->dev, idx) == 0
> +		    && ranges->mem_end < res->end)
>  			ranges->mem_end = res->end;
>  		tmp = list;
>  		list = list->next;
> -		vfree(tmp);
> +		kfree(tmp);
>  	}
> +
>  	ranges->io_end += io_reserved;
>  	ranges->mem_end += mem_reserved;
> +
> +	/* ??? How to turn off a bus from responding to, say, I/O at
> +	   all if there are no I/O ports behind the bus?  Turning off
> +	   PCI_COMMAND_IO doesn't seem to do the job.  So we must
> +	   allow for at least one unit.  */
> +	if (ranges->io_end == ranges->io_start)
> +		ranges->io_end += 1;
> +	if (ranges->mem_end == ranges->mem_start)
> +		ranges->mem_end += 1;
> +
>  	ranges->io_end = ROUND_UP(ranges->io_end, 4*1024);
>  	ranges->mem_end = ROUND_UP(ranges->mem_end, 1024*1024);
> +
>  	return found_vga;
>  }
>  
> diff -rup linux/drivers/pci/setup-res.c 2.4.0-11-1/drivers/pci/setup-res.c
> --- linux/drivers/pci/setup-res.c	Wed Nov  8 01:24:16 2000
> +++ 2.4.0-11-1/drivers/pci/setup-res.c	Wed Nov  8 00:21:13 2000
> @@ -22,10 +22,10 @@
>  #include <linux/errno.h>
>  #include <linux/ioport.h>
>  #include <linux/cache.h>
> -#include <linux/vmalloc.h>
> +#include <linux/slab.h>
>  
>  
> -#define DEBUG_CONFIG 0
> +#define DEBUG_CONFIG 1
>  #if DEBUG_CONFIG
>  # define DBGC(args)     printk args
>  #else
> @@ -146,7 +146,7 @@ pdev_sort_resources(struct pci_dev *dev,
>  			if (ln)
>  				size = ln->res->end - ln->res->start;
>  			if (r->end - r->start > size) {
> -				tmp = vmalloc(sizeof(*tmp));
> +				tmp = kmalloc(sizeof(*tmp), GFP_KERNEL);
>  				tmp->next = ln;
>  				tmp->res = r;
>  				tmp->dev = dev;


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

Re: PCI-PCI bridges mess in 2.4.x

[Ivan Kokshaysky]

On Wed, Nov 08, 2000 at 01:39:31AM -0800, Richard Henderson wrote:
>   * Replace cropped found_vga detection code.

I wonder where could I lose this, it was in place initially :-)

> +	/* ??? How to turn off a bus from responding to, say, I/O at
> +	   all if there are no I/O ports behind the bus?  Turning off
> +	   PCI_COMMAND_IO doesn't seem to do the job.  So we must
> +	   allow for at least one unit.  */

I relied on DEC^WIntel 21153 datasheet which says that to turn off
io/mem window this bridge must be programmed with base > limit
values (and the code actually did that).
But this could be wrong for other bridges.
OTOH, we turn off prefetchable memory range this way in 2.2, and
it works...

Thanks for the patch,

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

Re: PCI-PCI bridges mess in 2.4.x

[Richard Henderson]

On Wed, Nov 08, 2000 at 02:25:13PM +0300, Ivan Kokshaysky wrote:
> I relied on DEC^WIntel 21153 datasheet which says that to turn off
> io/mem window this bridge must be programmed with base > limit
> values (and the code actually did that).

Interesting.  I hadn't known that.  It didn't actually fail with
the ALI bridge, I just assumed it was a mistake.  Can anyone with
docs on non-DEC bridges confirm that this is a common thing?

Certainly the fact should be commented if the old code goes back
in to avoid disruption by helpful folks like myself.  :-)


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

Re: PCI-PCI bridges mess in 2.4.x

[Ivan Kokshaysky]

On Wed, Nov 08, 2000 at 09:37:44AM -0800, Richard Henderson wrote:
> Interesting.  I hadn't known that.  It didn't actually fail with
> the ALI bridge, I just assumed it was a mistake.  Can anyone with
> docs on non-DEC bridges confirm that this is a common thing?

It would be better if someone who has "PCI-to-PCI Bridge Architecture
Specification" handy could confirm this. Non-conforming hardware
must live in quirks/fixups etc. ;-)

I've found some interesting info today - application note on programming
the DEC 21052 bridge (ruffian has this chip, btw):
http://download.sourceforge.net/mirrors/NetBSD/misc/dec-docs/ec-qlzba-te.ps.gz

Particularly, there are examples for setting up that bridge for IO or MEM
only configurations. For example, with IO disabled:
1. Set IO base = 0xffff, limit = 0
2. Set command register = PCI_COMMAND_MEMORY | PCI_COMMAND_MASTER

> Certainly the fact should be commented if the old code goes back
> in to avoid disruption by helpful folks like myself.  :-)

That change wasn't bad at all - at least it's 100% safe :-)
But of course, it would be better to have unused regions disabled
in a clean way.

But actually I'm concerned that all this code doesn't work at all -
see reports from Michal Jaegermann (the bridge acts as if it drops
config space transactions randomly). I have a lot of suggestions, but
it's a pain to debug something without access to real hardware - just
a waste of the precious time of everyone who is involved...
So I would probably wait a week or two until I'll have something with
bridges :-(

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

Re: PCI-PCI bridges mess in 2.4.x

[Jeff Garzik]

Ivan Kokshaysky wrote:
> But actually I'm concerned that all this code doesn't work at all -
> see reports from Michal Jaegermann (the bridge acts as if it drops
> config space transactions randomly). I have a lot of suggestions, but
> it's a pain to debug something without access to real hardware - just
> a waste of the precious time of everyone who is involved...
> So I would probably wait a week or two until I'll have something with
> bridges :-(

FWIW, I just tested rth's update of your path on my x86 SMP box, and a
laptop with two CardBus bridges (two CardBus slots).  Both worked
fine...

I am still worried that the conditions which generate the following
message indicate a problem still exists.  (this message exists w/out
your patch..)
Unknown bridge resource 0: assuming transparent

	Jeff


-- 
Jeff Garzik             | "When I do this, my computer freezes."
Building 1024           |          -user
MandrakeSoft            | "Don't do that."
                        |          -level 1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: PCI-PCI bridges mess in 2.4.x

[Richard Henderson]

On Wed, Nov 08, 2000 at 05:43:54PM -0500, Jeff Garzik wrote:
> FWIW, I just tested rth's update of your path on my x86 SMP box, and a
> laptop with two CardBus bridges (two CardBus slots).  Both worked
> fine...

x86 doesn't use this code at all.  Only alpha, arm, and mips.


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

Re: PCI-PCI bridges mess in 2.4.x

[Ivan Kokshaysky]

On Wed, Nov 08, 2000 at 05:43:54PM -0500, Jeff Garzik wrote:
> I am still worried that the conditions which generate the following
> message indicate a problem still exists.  (this message exists w/out
> your patch..)
> Unknown bridge resource 0: assuming transparent

Well, I believe that transparent bridge must use subtractive decoding.
Specification allows such thing, but the bridge with subtractive
decoding enabled _must_ have programming interface code == 01h.
If you're curious try this patch (not for applying, just for
testing).

Ivan.

--- 2.4.0t11p1/drivers/pci/pci.c	Fri Oct 27 02:16:46 2000
+++ linux/drivers/pci/pci.c	Thu Nov  9 17:08:16 2000
@@ -574,6 +574,14 @@ void __init pci_read_bridge_bases(struct
 	if (!dev)		/* It's a host bus, nothing to read */
 		return;
 
+	if (dev->class & 1) {
+		printk("Subtractive decoding bridge %s\nAssuming transparent\n",
+					dev->name);
+		for(i=0; i<3; i++)
+			child->resource[i] = child->parent->resource[i];
+		return;
+	}
+
 	for(i=0; i<3; i++)
 		child->resource[i] = &dev->resource[PCI_BRIDGE_RESOURCES+i];
 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: PCI-PCI bridges mess in 2.4.x

[Richard Henderson]

On Thu, Nov 09, 2000 at 01:03:36AM +0300, Ivan Kokshaysky wrote:
> But actually I'm concerned that all this code doesn't work at all -
> see reports from Michal Jaegermann (the bridge acts as if it drops
> config space transactions randomly).

I have no idea what Michal is seeing.  It does, however, work
just dandy on my rawhide:

-+-[01]-+-01.0
 |      +-02.0-[02]----00.0
 |      +-04.0
 |      \-04.1
 \-[00]-+-01.0
        +-02.0
        \-05.0

01:02.0 PCI bridge: Digital Equipment Corporation DECchip 21050 (rev 02) \
		(prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- \
		Stepping- SERR- FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- \
		<TAbort- <MAbort- >SERR- <PERR-
        Latency: 248, cache line size 10
        Bus: primary=01, secondary=02, subordinate=02, sec-latency=0
        I/O behind bridge: 00009000-00009fff
        Memory behind bridge: 02300000-023fffff
        BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-

02:00.0 SCSI storage controller: Q Logic ISP1020 (rev 02)
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ \
		Stepping- SERR+ FastB2B-
        Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- \
		<TAbort- <MAbort- >SERR- <PERR-
        Latency: 248, cache line size 10
        Interrupt: pin A routed to IRQ 40
        Region 0: I/O ports at 200009000 [size=256]
        Region 1: Memory at 0000000202310000 (32-bit, non-prefetchable) [size=4K]
        Expansion ROM at 0000000202300000 [disabled] [size=64K]

Whee!  We're back in Bootsville.


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

Re: PCI-PCI bridges mess in 2.4.x

[Ivan Kokshaysky]

On Wed, Nov 08, 2000 at 03:48:11PM -0800, Richard Henderson wrote:
> Whee!  We're back in Bootsville.

Cool!
Meanwhile this base/limit stuff got confirmation :-)
Here is a patch against bridges-2.4.0t11-rth.

Ivan.

--- 2.4.0t11p1/drivers/pci/setup-bus.c	Wed Nov  8 19:44:42 2000
+++ linux/drivers/pci/setup-bus.c	Thu Nov  9 15:11:01 2000
@@ -88,14 +88,14 @@ pbus_assign_resources_sorted(struct pci_
 	ranges->io_end += io_reserved;
 	ranges->mem_end += mem_reserved;
 
-	/* ??? How to turn off a bus from responding to, say, I/O at
-	   all if there are no I/O ports behind the bus?  Turning off
-	   PCI_COMMAND_IO doesn't seem to do the job.  So we must
-	   allow for at least one unit.  */
-	if (ranges->io_end == ranges->io_start)
-		ranges->io_end += 1;
-	if (ranges->mem_end == ranges->mem_start)
-		ranges->mem_end += 1;
+	/* Interesting case is when, say, io_end == io_start, i.e.
+	   there is no I/O behind the bridge at all. We initialize
+	   the bridge with base=io_start and limit=io_end-1, so
+	   in this case we'll have base > limit. According to
+	   the `PCI-to-PCI Bridge Architecture Specification', this
+	   means that the bridge will not forward any I/O transactions
+	   from the primary bus to the secondary bus and will forward
+	   all I/O transactions upstream. Exactly what we want.  */
 
 	ranges->io_end = ROUND_UP(ranges->io_end, 4*1024);
 	ranges->mem_end = ROUND_UP(ranges->mem_end, 1024*1024);

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

Re: PCI-PCI bridges mess in 2.4.x

[Gérard Roudier]

On Thu, 9 Nov 2000, Ivan Kokshaysky wrote:

Hmmm...
The PCI spec. says that Limit registers define the top addresses
_inclusive_.

The spec. does not seem to imagine that a Limit register lower than the
corresponding Base register will ever exist anywhere, in my opinion. :-)

This let me think that trying to be clever here is probably a very bad
idea. What is so catastrophic of having 1 to 4 bytes of addresses and no
more being possibly in a forwardable range?

  Gérard.


> On Wed, Nov 08, 2000 at 03:48:11PM -0800, Richard Henderson wrote:
> > Whee!  We're back in Bootsville.
> 
> Cool!
> Meanwhile this base/limit stuff got confirmation :-)
> Here is a patch against bridges-2.4.0t11-rth.
> 
> Ivan.
> 
> --- 2.4.0t11p1/drivers/pci/setup-bus.c	Wed Nov  8 19:44:42 2000
> +++ linux/drivers/pci/setup-bus.c	Thu Nov  9 15:11:01 2000
> @@ -88,14 +88,14 @@ pbus_assign_resources_sorted(struct pci_
>  	ranges->io_end += io_reserved;
>  	ranges->mem_end += mem_reserved;
>  
> -	/* ??? How to turn off a bus from responding to, say, I/O at
> -	   all if there are no I/O ports behind the bus?  Turning off
> -	   PCI_COMMAND_IO doesn't seem to do the job.  So we must
> -	   allow for at least one unit.  */
> -	if (ranges->io_end == ranges->io_start)
> -		ranges->io_end += 1;
> -	if (ranges->mem_end == ranges->mem_start)
> -		ranges->mem_end += 1;
> +	/* Interesting case is when, say, io_end == io_start, i.e.
> +	   there is no I/O behind the bridge at all. We initialize
> +	   the bridge with base=io_start and limit=io_end-1, so
> +	   in this case we'll have base > limit. According to
> +	   the `PCI-to-PCI Bridge Architecture Specification', this
> +	   means that the bridge will not forward any I/O transactions
> +	   from the primary bus to the secondary bus and will forward
> +	   all I/O transactions upstream. Exactly what we want.  */
>  
>  	ranges->io_end = ROUND_UP(ranges->io_end, 4*1024);
>  	ranges->mem_end = ROUND_UP(ranges->mem_end, 1024*1024);
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/
> 

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

Re: PCI-PCI bridges mess in 2.4.x

[Ivan Kokshaysky]

On Thu, Nov 09, 2000 at 09:37:41PM +0100, Gerard Roudier wrote:
> Hmmm...
> The PCI spec. says that Limit registers define the top addresses
> _inclusive_.

Correct.

> The spec. does not seem to imagine that a Limit register lower than the
> corresponding Base register will ever exist anywhere, in my opinion. :-)

Not correct.
Here's a quote from `PCI-to-PCI Bridge Architecture Specification rev 1.1':
   The Memory Limit register _must_ be programmed to a smaller value
   than the Memory Base if there are no memory-mapped I/O addresses on the
   secondary side of the bridge.

I/O is slightly different because it's optional for the bridge -
but if it's implemented same rules apply.

> This let me think that trying to be clever here is probably a very bad
> idea. What is so catastrophic of having 1 to 4 bytes of addresses and no
> more being possibly in a forwardable range?
> 
Huh. 1 to 4 bytes? 4K for I/O and 1M for memory.
And it's not trying to be clever (anymore :-) - just strictly following
the Specs.

I understand your point very well, btw. I asked similar questions to myself
until I've had the docs.

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

Re: PCI-PCI bridges mess in 2.4.x

[Gérard Roudier]

On Fri, 10 Nov 2000, Ivan Kokshaysky wrote:

> On Thu, Nov 09, 2000 at 09:37:41PM +0100, Gerard Roudier wrote:
> > Hmmm...
> > The PCI spec. says that Limit registers define the top addresses
> > _inclusive_.
> 
> Correct.
> 
> > The spec. does not seem to imagine that a Limit register lower than the
> > corresponding Base register will ever exist anywhere, in my opinion. :-)
> 
> Not correct.
> Here's a quote from `PCI-to-PCI Bridge Architecture Specification rev 1.1':
>    The Memory Limit register _must_ be programmed to a smaller value
>    than the Memory Base if there are no memory-mapped I/O addresses on the
>    secondary side of the bridge.

I only have spec 1.0 on paper. I should have checked 1.1. Anyway, it may
still exist bridges that have been designed prior to spec. 1.1.

> I/O is slightly different because it's optional for the bridge -
> but if it's implemented same rules apply.

Will also check the spec. on this point. :)

> > This let me think that trying to be clever here is probably a very bad
> > idea. What is so catastrophic of having 1 to 4 bytes of addresses and no
> > more being possibly in a forwardable range?
> > 
> Huh. 1 to 4 bytes? 4K for I/O and 1M for memory.
> And it's not trying to be clever (anymore :-) - just strictly following
> the Specs.

I just missed the units, but absolute values weren't so wrong. :-)

> I understand your point very well, btw. I asked similar questions to myself
> until I've had the docs.

Ok. Thanks for the reply.

  Gérard.

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

Re: PCI-PCI bridges mess in 2.4.x

[Ivan Kokshaysky]

On Fri, Nov 10, 2000 at 07:35:41PM +0100, Gerard Roudier wrote:
> I only have spec 1.0 on paper. I should have checked 1.1. Anyway, it may
> still exist bridges that have been designed prior to spec. 1.1.

Yes, DEC 2105x bridges, for example.

The only update listed in revision history is "Update to include
target initial latency requirements", so this (base > limit) stuff
must be in rev. 1.0 as well. Please check chapters 3.2.5.[6,8,9].

> 
> > I/O is slightly different because it's optional for the bridge -
> > but if it's implemented same rules apply.
> 
> Will also check the spec. on this point. :)

Also, according the spec, we need some paranoia checks ;-)
1. check if the bridge has an I/O window not implemented
2. if the bridge has regular BARs, allocate them properly
   on the primary bus.

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

Re: PCI-PCI bridges mess in 2.4.x

[Gérard Roudier]

On Sat, 11 Nov 2000, Ivan Kokshaysky wrote:

> On Fri, Nov 10, 2000 at 07:35:41PM +0100, Gerard Roudier wrote:
> > I only have spec 1.0 on paper. I should have checked 1.1. Anyway, it may
> > still exist bridges that have been designed prior to spec. 1.1.
> 
> Yes, DEC 2105x bridges, for example.
> 
> The only update listed in revision history is "Update to include
> target initial latency requirements", so this (base > limit) stuff
> must be in rev. 1.0 as well. Please check chapters 3.2.5.[6,8,9].

The revision history should be a lot pessimistic about the amount of
additions. Btw, rev. 1.0 April 5, 1994 is 63 pages, and rev 1.1 is about
147 pages, as you know.

> > > I/O is slightly different because it's optional for the bridge -
> > > but if it's implemented same rules apply.
> > 
> > Will also check the spec. on this point. :)
> 
> Also, according the spec, we need some paranoia checks ;-)
> 1. check if the bridge has an I/O window not implemented

Read-only, returning zero on read. Already present in spec. 1.0.

> 2. if the bridge has regular BARs, allocate them properly
>    on the primary bus.

Limit < Base (new in 1.1, unless I missed the point. Btw, I actually
              donnot want to read again P2P spec. 1.0 :-) )

  Gérard.

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

Re: PCI-PCI bridges mess in 2.4.x

[Jeff Garzik]

Setting bit 1 in dev->resource[x].start, below, seems incorrect.  Should
you be programming the PCI BAR directly, instead?

> +static void __init
> +quirk_cypress_ide_ports(struct pci_dev *dev)
> +{
> +       if (dev->class >> 8 != PCI_CLASS_STORAGE_IDE)
> +               return;
> +       dev->resource[1].start |= 2;
> +       dev->resource[1].end = dev->resource[1].start;
> +       pci_claim_resource(dev, 0);
> +       pci_claim_resource(dev, 1);
> +}


I wonder about this code:

> +               /* ??? Reserve some resources for CardBus */
> +               if (dev->class >> 8 == PCI_CLASS_BRIDGE_CARDBUS) {
> +                       io_reserved += 8*1024;
> +                       mem_reserved += 32*1024*1024;
> +                       continue;
> +               }


I think "pdev_enable_device" is a poorly-chosen name, since "pdev_" is
not a common prefix, and we already have pci_enable_device.

Also, should we be setting PCI_CACHE_LINE_SIZE for PCI devices as well
as bridges?

	Jeff


-- 
Jeff Garzik             | "When I do this, my computer freezes."
Building 1024           |          -user
MandrakeSoft            | "Don't do that."
                        |          -level 1
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: PCI-PCI bridges mess in 2.4.x

[Richard Henderson]

On Wed, Nov 08, 2000 at 10:56:23AM -0500, Jeff Garzik wrote:
> Setting bit 1 in dev->resource[x].start, below, seems incorrect.  Should
> you be programming the PCI BAR directly, instead?

No, that's the reason this is a quirk.  The hardware is already
only responding to one and only one address.  The old code did
exactly the same thing, only not inside the quirk framework,
which made it kinda harder to figure out what was going on.

> I wonder about this code:
> 
> > +               /* ??? Reserve some resources for CardBus */
> > +               if (dev->class >> 8 == PCI_CLASS_BRIDGE_CARDBUS) {
> > +                       io_reserved += 8*1024;
> > +                       mem_reserved += 32*1024*1024;
> > +                       continue;
> > +               }

Got a better suggestion?  It does seem completely reasonable to
reserve some address space for a CardBus bridge if we find one.


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

Re: PCI-PCI bridges mess in 2.4.x

[Wakko Warner]

> It was posted to lkml, so no link (except if you want to dig through
> lkml mail archives).

It booted but then it oops'ed before userland I belive.  I tried it this
morning and didn't have much time.  It did find the scsi controller (which
is across the bridge) and the drives attached so it does appear to be
working.  Maybe they can add that patch in for test11pre2 (or 3 if 2 is
already out)

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: PCI-PCI bridges mess in 2.4.x

[Michal Jaegermann]

On Thu, Nov 09, 2000 at 11:33:47AM -0500, Wakko Warner wrote:
> > It was posted to lkml, so no link (except if you want to dig through
> > lkml mail archives).
> 
> It booted but then it oops'ed before userland I belive.  I tried it this
> morning and didn't have much time.  It did find the scsi controller (which
> is across the bridge) and the drives attached so it does appear to be
> working.

Looks so far that I am the worst off.  If I am trying to boot with
a root on a SCSI device then either a controller is misdetected,
or goes into an infinite "abort/reset" loop, or it does not initialize
properly and disks are not found.  This is a non-exclusive, logical,
"or". :-)

Booting to an IDE device makes difference only in that that if I can
boot then SCSI disks will be simply ignored.  If somebody is interested
in a collection of dmesg outputs, with DEBUG printks, from such attempts
then I am game.  Ivan was getting these pretty consistently. :-)

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

Re: PCI-PCI bridges mess in 2.4.x

[Sean Hunter]

On Thu, Nov 09, 2000 at 04:31:24PM -0700, Michal Jaegermann wrote:
> On Thu, Nov 09, 2000 at 11:33:47AM -0500, Wakko Warner wrote:
> > > It was posted to lkml, so no link (except if you want to dig through
> > > lkml mail archives).
> > 
> > It booted but then it oops'ed before userland I belive.  I tried it this
> > morning and didn't have much time.  It did find the scsi controller (which
> > is across the bridge) and the drives attached so it does appear to be
> > working.
> 
> Looks so far that I am the worst off.  If I am trying to boot with
> a root on a SCSI device then either a controller is misdetected,
> or goes into an infinite "abort/reset" loop, or it does not initialize
> properly and disks are not found.  This is a non-exclusive, logical,
> "or". :-)

<metoo>Me too!</metoo>

Exact same symptoms on my ruffian.

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

RE: PCI-PCI bridges mess in 2.4.x

[Dunlap, Randy]

Hi Jeff-

> Also, should we be setting PCI_CACHE_LINE_SIZE for PCI devices as well
> as bridges?

If/when we do set PCI_CACHE_LINE_SIZE, please don't
set it to a hard-coded, inline constant, like 8 (e.g.),
like some drivers do.

Please use something like (PCI_CACHE_LINE_SIZE / 4)
instead.  ["/ 4" to convert bytes to "dwords" or
whatever, since the PCI_CACHE_LINE_SIZE register
is in 4-byte units.]

~Randy
_______________________________________________
|randy.dunlap_at_intel.com        503-677-5408|
|NOTE: Any views presented here are mine alone|
|& may not represent the views of my employer.|
----------------------------------------------- 

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

Re: PCI-PCI bridges mess in 2.4.x

[Wakko Warner]

> It was posted to lkml, so no link (except if you want to dig through
> lkml mail archives).

It booted but then it oops'ed before userland I belive.  I tried it this
morning and didn't have much time.  It did find the scsi controller (which
is across the bridge) and the drives attached so it does appear to be
working.  Maybe they can add that patch in for test11pre2 (or 3 if 2 is
already out)

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/