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);
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 [email protected]
> Please read the FAQ at http://www.tux.org/lkml/
>
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.
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.
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.
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.