feng1 at bnl.gov
Wed Mar 2 22:05:19 UTC 2005
Done! Eveyone will be happy. Thanks to all for clearing the
confusion. I will add :
#define MaxPCIbridgePerBandwidth 8 /* Did not figure out a better name yet */
to the bsp.h of mvme5500. Thus I can use the original PCI API.
"chris at chriscaudle.org" wrote:
> > Imagine that one application has five devices on PCI0. One day, it requires to
> > hot adding two more PCI devices while the system has
> > been serving for three months. However, the application can not
> > disturb any other devices on PCI1 - at least for the prebuilt 1GHZ
> > network. What is the new bus number for the two added devices
> > based on the original proposal ?
> Maybe I don't understand exactly what you are asking, but it is as simple as seems, then the two added devices have the same bus number as the other five devices on the PCI0 bridge. All devices on a single bus segment have the same bus number.
> If one of the cards installed has a bridge, then the secondary devices on that card have a higher bus number. If there are no other busses in the system, all devices on PCI0 would probably have bus number 0, all devices on PCI1 would have bus number 1, and if you added a device that contained a bridge onto the bus segment from PCI0, it would be assigned bus number 2.
Maybe a better example is to look at Peter Default's drawing for his system :
(P.S. : Thanks for the drawing)
MVME5500 PCI diagram
+-PMCSLOT1 IDSEL B(0/7/0)
| | 12,13,14,15
| | 14,15,12,13
| | 15,12,13,14
| | 12,13,14,15
+-PMCSLOT2 IDSEL B(0/7/0)
+-10/100/1000 Ether(0/10/0) /* 1GHZ network */
Till suggested :
>pci_read_config_byte(unchar bus, unchar dev, unchar func, unchar offset)
>if ( bus>= ucMaxPCIBus)
> return -1;
>for (peer=0; peer_subordinates[peer] < bus; peer++)
> bus -= peer_subordinates[peer];
Based on this proposal, if the DEC21150BR is not presented :
the ucMaxPCIBus should return 2.
The bus number for the 1 GHZ network will be 1.
Later on , a hot added DEC21150BR is needed, what bus number will it be ?
Based on the propsal, the 1GHZ network should be reconfigured to be 3.
However, let's say the 1GHZ network is a device the application does not
want to disturb during the hot change. Thus Gregory suggested :
> Assign a range of bus numbers to each tree so the bridges can be
> reconfigured as necessary.
OK. I decided that eight seems to be enough for my architecture to
allow the reconfiguration of the PCI bridges.
However, in your previous E-mail, you wrote :
>That may be acceptable for one particular current hardware implementation, but is completely unacceptable for
>Once you transition to PCI-X it is common to have one bus segment per connector so that you can run at the
>maximum data rate (133M transfers/s, or 266M if you use the dual rate variant). PCI Express systems will have
>similar issues, because that architecture is inherently point to point and relies on switches. The switches
>create multiple bus segments and look to the software like multiple PCI-PCI bridges.
>Some of the large servers I work on have 64 or more bus segments. Those systems typically run a general purpose
>OS rather than a real time OS, but it seems unnecessarily limiting to design an API into the RTOS or even into
> the BSP which is known to be far below the architectural limitations of the bus.
Thus, you can tune your own value of the MaxPCIbridgePerBandwidth
in your bsp.h.
How does that sound ?
Thanks to all including Peter Siddons,
More information about the users