PCI API (was : Add support for DEC/Intel 21150 PCI-PCI bridge)
strauman at slac.stanford.edu
Wed Mar 2 17:54:45 UTC 2005
Thanks Gregory, I'm with you.
gregory.menke at gsfc.nasa.gov wrote:
>Kate Feng writes:
> > Till Straumann wrote:
> > > gregory.menke at gsfc.nasa.gov wrote:
> > >
> > > >Till Straumann writes:
> > > > > gregory.menke at gsfc.nasa.gov wrote:
> > > > >
> > > > > >Till Straumann writes:
> > > >
> > > > > OTOH, I suggested to collapse the individual ranges of sub-busses behind
> > > > > peer hostbridges
> > > > > into one single range in order to make the presence of peers transparent
> > > > > to the API.
> > > >
> > > >This is the right way to go in my opinion.
> > Pre assigning a range of bus number was what I had in mind as an alternative
> > if one does insist not to change the PCI API of the previous written drivers.
> > I never meant to hardcode the PCI bus number or to write 255 copies of
> > drivers.
> > I meant that the BSP_pciFindDevice() should return the PCI number as well in
> > additional to the bus number, device number and function number to reflect the
>The only way I can see this working would be to add a "pci #" to all
>the pci functions, in addition to the bus, slot and function numbers.
>I don't think its the right approach.
> > hardware architecture. It would be less confusing that the PCI number is used
> > as one
> > of the paramerts in pci_write_config_xxx() and pci_read_config_xxx().
> > After all, each of the PCI0 and PCI1 have 66 MHZ of PCI bandwidth for the PCI
> > devices. Bypassing the PCI number, one would have to keep remembering
> > bus number 0 .. 7 share 66 MHZ bandwidth, and bus number 8..15 share
> > another 66 MHZ bandwidth. This might not be a big deal anyway if it is
> > really painful to modify the previous written drivers.
>All this is highly idiosyncratic to the hardware you're working with.
>It might make sense there, but it doesn't on other machines.
> > I thoguht pre assigning eight buses on each PCI is enough. There should be
> > no need to set it to be 16. Right ?
>No, each pci bus tree should consume whatever number of busses it
>needs, 8, 99, 200, whatever. The pci api should have a routing table
>identifying what ranges of busses are associated with each pci bus
>tree. The find device function should know about this routing table
>and search all trees. Presumably the whole routing table thing can be
>#ifdef'ed out when compiling for single pci tree architectures.
>If there is concern about dynamically extending the number of busses
>via hot-plugging or whatever, then each tree should still consume its
>necessary quantity of bus numbers and the pci setup routine should add
>some #defined constant to offset the starting bus number of the next
>I imagine a compromise could be made, dividing the bus space up into
>regions, each pci device tree being given one region- pretty much what
>you're suggesting if I understand you. I'd rather have that than a
>"pci #" parameter added to all the api functions.
> > > >
> > > > > E.g., if a given board has 2 peer hostbridges and a given PCI
> > > > > configuration (i.e., native
> > > > > devices + PMC cards and extensions etc) results in the first hostbridge
> > > > > having 8 sub-busses
> > > > > and the second one 5 then I would collapse the two bus trees into one
> > > > > ranging from
> > > > > bus #0..12. Only the configuration access routines (which are a BSP
> > > > > dependent piece)
> > > > > would know that bus #0..7 actually reside at the first hostbridge and
> > > > > 8..12 -> bus #0..4
> > > > > at the second one.
> > > >
> > > >But if the bus numbers are set up properly than it simply doesn't
> > > >matter.
> > > >
> > > Sure - but unless the peer hostbridge hardware has some magic to handle
> > > peers
> > > you have to handle this in software. Maybe the MVME5500 does not have
> > > this magic
> > > (don't have the discovery docs), i.e., the peer bridges each have their own
> > > individual 'space' of b/d/f-tuples. In this case, we must handle peer
> > > bridges in software,
> > My magic tale is another concept. The original proposal would limit the
> > future applications of hot changing the PCI system configuration leaving other
> > part of PCI devices (e.g. 1 GHZ networrk) intact while the system
> > is still running.
>You are making wild assumptions here about bus architectures and
More information about the users