"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
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 something
>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
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
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
"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
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
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...
"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
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
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 into
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 or
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
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 forced
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 tree numbers?
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,
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
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 a
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...
Right,
"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
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
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,
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 numbers.
24 matches
Mail list logo
