"David S. Miller" wrote:
>
> Jeff Garzik writes:
> > ok with me. would bus #0 be the system or root bus? that would be my
> > preference, in a tiered system like this.
>
> Bus 0 is controller 0, of whatever bus type that happens to be.
> If we want to do something special we could create som
>It's funny you mention this because I have been working on something
>similar recently. Basically making xfree86 int10 and VGA poking happy
>on sparc64.
Heh, world is small ;)
>But this has no real use in the kernel. (actually I take this back,
>read below)
yup, fbcon at least...
>You have
Jeff Garzik writes:
> I think rth requested pci_ioremap also...
It really isn't needed, and I understand why Linus didn't like the
idea either. Because you can encode the bus etc. info into the
resource addresses themselves.
On sparc64 we just so happen to stick raw physical addresses into th
Jeff Garzik writes:
> ok with me. would bus #0 be the system or root bus? that would be my
> preference, in a tiered system like this.
Bus 0 is controller 0, of whatever bus type that happens to be.
If we want to do something special we could create something
like /proc/bus/root or whatever,
"David S. Miller" wrote:
>
> Jeff Garzik writes:
> > Thinking a bit more independently of bus type, and with an eye toward's
> > 2.5's s/pci_dev/device/ and s/pci_driver/driver/, would it be useful to
> > go ahead and codify the concept of PCI domains into a more generic
> > concept of bus tr
David S. Miller writes:
> Jeff Garzik writes:
>> According to the PCI spec it is -impossible- to have more than 256
>> buses on a single "hose", so you simply have to implement multiple
>> hoses, just like Alpha (and Sparc64?) already do. That's how the
>> hardware is forced to implement it...
>
Jonathan Lundell wrote:
>
> At 10:14 AM -0400 2001-06-14, Jeff Garzik wrote:
> >According to the PCI spec it is -impossible- to have more than 256 buses
> >on a single "hose", so you simply have to implement multiple hoses, just
> >like Alpha (and Sparc64?) already do. That's how the hardware is
At 10:14 AM -0400 2001-06-14, Jeff Garzik wrote:
>According to the PCI spec it is -impossible- to have more than 256 buses
>on a single "hose", so you simply have to implement multiple hoses, just
>like Alpha (and Sparc64?) already do. That's how the hardware is forced
>to implement it...
That's
"David S. Miller" wrote:
> 1) Extending the type bus numbers use inside the kernel.
>
>Basically how most multi-controller platforms work now
>is they allocate bus numbers in the 256 bus space as
>controllers are probed. If we change the internal type
>used by the kernel to "u32"
Tom Gall wrote:
> The box that I'm wrestling with, has a setup where each PHB has an
> additional id, then each PHB can have up to 256 buses. So when you are
> talking to a device, the scheme is phbid, bus, dev etc etc. Pretty easy
> really.
>
> I am getting for putting something like this i
"Albert D. Cahalan" wrote:
>
> Tom Gall writes:
>
> > I was wondering if there are any other folks out there like me who
> > have the 256 PCI bus limit looking at them straight in the face?
>
> I might. The need to reserve bus numbers for hot-plug looks like
> a quick way to waste all 256 bus
Tom Gall writes:
> I was wondering if there are any other folks out there like me who
> have the 256 PCI bus limit looking at them straight in the face?
I might. The need to reserve bus numbers for hot-plug looks like
a quick way to waste all 256 bus numbers.
> each PHB has an
> additional id
12 matches
Mail list logo
