From: Pavel Roskin <hidden> Date: 2004-05-24 00:30:51
Hello!
I'm using Blue&While G3. I installed a CardBus bridge into a PCI slot.
The bridge uses TI PCI1410 chip. 16-bit PCMCIA cards work fine, but
CardBus cards don't work. They are not shown by lspci. I'm running
Debian unstable with Linux 2.6.6-bk9.
It turns out the PCI bridge (DEC 21154) only handles bus 1 and doesn't
forward requests to higher buses. The CardBus card is configured to act
as a bridge from bus 1 to buses 2-5. That's why requests to bus 2 don't
go through.
If I reconfigure the PCI bridge to handle buses 1-255, the CardBus cards
start working. The attached patch add a fixup for DEC 21154 bridge.
If there are a better way to fix the problem with CardBus, I'm ready to
test other patches.
More information about the system (including kernel log) is available at
http://www.red-bean.com/~proski/g3bw/
As a side not, the kernel says that the Host bridge (Motorola MPC106
Grackle) is configured to support buses 0 and 1. Those values come from
the "bus-range" property. I believe this limitation is not enforced, or
it would also hinder CardBus support.
--
Regards,
Pavel Roskin
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-05-24 01:45:59
On Mon, 2004-05-24 at 10:30, Pavel Roskin wrote:
Hello!
I'm using Blue&While G3. I installed a CardBus bridge into a PCI slot.
The bridge uses TI PCI1410 chip. 16-bit PCMCIA cards work fine, but
CardBus cards don't work. They are not shown by lspci. I'm running
Debian unstable with Linux 2.6.6-bk9.
It turns out the PCI bridge (DEC 21154) only handles bus 1 and doesn't
forward requests to higher buses. The CardBus card is configured to act
as a bridge from bus 1 to buses 2-5. That's why requests to bus 2 don't
go through.
If I reconfigure the PCI bridge to handle buses 1-255, the CardBus cards
start working. The attached patch add a fixup for DEC 21154 bridge.
If there are a better way to fix the problem with CardBus, I'm ready to
test other patches.
More information about the system (including kernel log) is available at
http://www.red-bean.com/~proski/g3bw/
As a side not, the kernel says that the Host bridge (Motorola MPC106
Grackle) is configured to support buses 0 and 1. Those values come from
the "bus-range" property. I believe this limitation is not enforced, or
it would also hinder CardBus support.
It's a bit nasty right now... You may bump into other problems, the
main issue is OF not setting a proper bus range.
Anyway, you should make your patch machine specific to avoid screwing
up other possible busses... (hrm... not too sure in fact if the linux
common PCI code will properly fixup the last subordinate bus number,
you may also want to only give a range of 5 or 10 bus numbers in case
somebody plugs another PCI card with a P2P bridge on it, maybe just
read the bus number and rewrite it adding 5 or so...)
Ben.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Pavel Roskin <hidden> Date: 2004-05-24 05:21:11
Hi, Benjamin!
On Mon, 24 May 2004, Benjamin Herrenschmidt wrote:
quoted
As a side not, the kernel says that the Host bridge (Motorola MPC106
Grackle) is configured to support buses 0 and 1. Those values come from
the "bus-range" property. I believe this limitation is not enforced, or
it would also hinder CardBus support.
It's a bit nasty right now... You may bump into other problems, the
main issue is OF not setting a proper bus range.
I actually tried to replace all references to "bus-range" with "bus-bogus"
in the kernel. The kernel would print
Found Grackle (MPC106) PCI host bridge at 0x80000000. Firmware bus number: 0->255
instead of "0->1", but I didn't notice any difference with regards to
CardBus support.
Anyway, you should make your patch machine specific to avoid screwing up
other possible busses...
I have CONFIG_PPC_PMAC condition already. This plus the exact vendor and
device ID should be machine specific. I can check that the machine is
"PowerMac1,1" if you want. I have no idea if G4 models have this problem.
(hrm... not too sure in fact if the linux common PCI code will properly
fixup the last subordinate bus number, you may also want to only give a
range of 5 or 10 bus numbers in case somebody plugs another PCI card
with a P2P bridge on it, maybe just read the bus number and rewrite it
adding 5 or so...)
I assumed that all PCI devices inserted to the slots would be on the bus 1
and thus behind the DEC bridge I'm reconfiguring.
Now I see that the video card is on bus 0 somehow. Maybe that particular
slot is wired differently. If you really think that somebody could insert
a P2P bridge instead of the video card, then maybe I should leave some
space. I seem to remember that some multihead cards (Colorgraphic
Predator LT) have internal bridges.
There are 3 PCI slots other than VGA. Every card can have 2 CardBus
slots. Every CardBus bridge uses 4 buses. That's 24 buses, from 2 to 25.
The fixed patch is attached.
--
Regards,
Pavel Roskin
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-05-24 05:36:14
On Mon, 2004-05-24 at 15:21, Pavel Roskin wrote:
Hi, Benjamin!
On Mon, 24 May 2004, Benjamin Herrenschmidt wrote:
quoted
quoted
As a side not, the kernel says that the Host bridge (Motorola MPC106
Grackle) is configured to support buses 0 and 1. Those values come from
the "bus-range" property. I believe this limitation is not enforced, or
it would also hinder CardBus support.
It's a bit nasty right now... You may bump into other problems, the
main issue is OF not setting a proper bus range.
I actually tried to replace all references to "bus-range" with "bus-bogus"
in the kernel. The kernel would print
Found Grackle (MPC106) PCI host bridge at 0x80000000. Firmware bus number: 0->255
instead of "0->1", but I didn't notice any difference with regards to
CardBus support.
quoted
Anyway, you should make your patch machine specific to avoid screwing up
other possible busses...
I have CONFIG_PPC_PMAC condition already. This plus the exact vendor and
device ID should be machine specific. I can check that the machine is
"PowerMac1,1" if you want. I have no idea if G4 models have this problem.
quoted
(hrm... not too sure in fact if the linux common PCI code will properly
fixup the last subordinate bus number, you may also want to only give a
range of 5 or 10 bus numbers in case somebody plugs another PCI card
with a P2P bridge on it, maybe just read the bus number and rewrite it
adding 5 or so...)
I assumed that all PCI devices inserted to the slots would be on the bus 1
and thus behind the DEC bridge I'm reconfiguring.
They can have P2P bridges too. For example, some adaptecs have a P2P
bridge and 2 controllers behind it. Some e1000 cards too.
Now I see that the video card is on bus 0 somehow. Maybe that particular
slot is wired differently. If you really think that somebody could insert
a P2P bridge instead of the video card, then maybe I should leave some
space. I seem to remember that some multihead cards (Colorgraphic
Predator LT) have internal bridges.
There are 3 PCI slots other than VGA. Every card can have 2 CardBus
slots. Every CardBus bridge uses 4 buses. That's 24 buses, from 2 to 25.
The fixed patch is attached.
--
Benjamin Herrenschmidt [off-list ref]
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Pavel Roskin <hidden> Date: 2004-05-24 06:42:53
On Mon, 24 May 2004, Benjamin Herrenschmidt wrote:
[snip]
quoted
quoted
(hrm... not too sure in fact if the linux common PCI code will properly
fixup the last subordinate bus number, you may also want to only give a
range of 5 or 10 bus numbers in case somebody plugs another PCI card
with a P2P bridge on it, maybe just read the bus number and rewrite it
adding 5 or so...)
I assumed that all PCI devices inserted to the slots would be on the bus 1
and thus behind the DEC bridge I'm reconfiguring.
They can have P2P bridges too. For example, some adaptecs have a P2P
bridge and 2 controllers behind it. Some e1000 cards too.
I guess we don't understand each other. I thought you didn't like that I
the PCI bridge would handle all buses from 1 to 255. I assumed that you
meant that some of those buses can be used by some other PCI bridges. I
assumed that if the P2P bridge is behind the main PCI bridge, the buses
handled by the P2P bridge would be a subset of the buses handles by the
the main PCI bridge.
I assure you that every CardBus bridge would only use 4 buses. It won't
use all 253 buses.
Anyway, you know PowerPC architecture much better. I might be missing
something obvious. After all, the upper bus range is just a number.
Adjust it in any direction if you want.
--
Regards,
Pavel Roskin
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2004-05-24 06:46:52
I guess we don't understand each other. I thought you didn't like that I
the PCI bridge would handle all buses from 1 to 255. I assumed that you
meant that some of those buses can be used by some other PCI bridges. I
assumed that if the P2P bridge is behind the main PCI bridge, the buses
handled by the P2P bridge would be a subset of the buses handles by the
the main PCI bridge.
You are right, I was on crack
I assure you that every CardBus bridge would only use 4 buses. It won't
use all 253 buses.
Anyway, you know PowerPC architecture much better. I might be missing
something obvious. After all, the upper bus range is just a number.
Adjust it in any direction if you want.
--
Benjamin Herrenschmidt [off-list ref]
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
From: Pavel Roskin <hidden> Date: 2004-05-24 15:53:29
Hello!
The improved patch is attached. The bridge is configured to handle buses
from 1 to 255. Since both the PCI ID and the machine type are checked and
255 is the maximal value, it should be safe not to read the original value
of the upper limit. The quirk has been renamed to
pmac_pci_fixup_bus_range(), which describes better what is does.
--
Regards,
Pavel Roskin