Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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". :-) Me too! 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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". :-) metooMe 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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.cWed 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 [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
> 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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.cFri 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] = >resource[PCI_BRIDGE_RESOURCES+i];
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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.cFri 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; i3; i++)
+ child-resource[i] = child-parent-resource[i];
+ return;
+ }
+
for(i=0; i3; 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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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.cWed 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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- \ SERR- 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- \ SERR- http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 = 0x, 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: PCI-PCI bridges mess in 2.4.x
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.com503-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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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.cWed Nov 8 01:04:17 2000
> @@ -20,7 +20,7 @@
> #include
> #include
> #include
> -#include
> +#include
>
>
> #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, _io, IORESOURCE_IO);
> pdev_sort_resources(dev, _mem, IORESOURCE_MEM);
> }
> +
> for (list = head_io.next; list;) {
> res = list->res;
> idx = res - >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 - >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.cWed Nov 8 00:21:13 2000
> @@ -22,10 +22,10 @@
> #include
> #include
> #include
> -#include
> +#include
>
>
> -#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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
[ 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~
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
#include
#include
-#include
+#include
#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, _io, IORESOURCE_IO);
pdev_sort_resources(dev, _mem, IORESOURCE_MEM);
}
+
for (list = head_io.next; list;) {
res = list->res;
idx = res - >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 - >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
#include
#include
-#include
+#include
-#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;
diff vs test11-1
Re: PCI-PCI bridges mess in 2.4.x
[ 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~
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;
diff vs test11-1
Re: PCI-PCI bridges mess in 2.4.x
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.cWed 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.cWed 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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
RE: PCI-PCI bridges mess in 2.4.x
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.com503-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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 = 0x, 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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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: 9000-9fff Memory behind bridge: 0230-023f 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 29000 [size=256] Region 1: Memory at 00020231 (32-bit, non-prefetchable) [size=4K] Expansion ROM at 00020230 [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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: PCI-PCI bridges mess in 2.4.x
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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
